พลังของการตั้งเป้าหมาย แม้ทำไม่ได้ ยังมีประโยชน์

อ่านบล็อกตัวเองแล้วสงสัยว่าเราจะตั้งเป้าหมายของปีนี้ หรือปลายปีนี้ ไปทำไมถ้าทำไม่ได้ แต่พอลองคิดๆดูอีกที การมีเป้าหมายก็กระตุ้นจิตใต้สำนึกของเราในเรื่องนั้นๆ มาตลอดทั้งปี เพราะเมื่อเราทำอะไรที่เกี่ยวกับสิ่งนั้น ใจเราจะย้อนคิดถึงเป้าหมายนั้นๆตลอด มันเหมือนการสัญญากับตัวเอง พอทำไม่ได้เราก็จะรู้สึกผิดเล็กๆ

แต่ถ้าลองทบทวนเป้าหมายดีๆ ก็พบว่าบางอย่างเราก็ทำได้แล้ว, บางอย่างเราก็เริ่มลงมือทำแล้ว และก็มีบางอย่างที่แม้จะยังไม่ได้ทำแต่ก็ติดอยู่ในใจมาตลอดทั้งปี แม้จะไม่บรรลุเป้าหมายทั้งหมดของปีนี้ แต่ก็เป็นการเริ่มต้นที่ดี

โค้ชที่ดี

โค้ชที่ดี ต้องฟังเยอะๆ พยายามทำความเข้าใจให้มาก อย่าคอยห้าม(ถ้าไม่ใช่เรื่องคอขาดบาดตาย) ปล่อยให้เค้าได้ทำให้ได้เรียนรู้  อย่าบ้าสอนให้ใช้คำถามนำให้เค้าคิดเอง

Burn Rate อัตราการเผาเงินทิ้ง

สำหรับคนที่เพิ่งพยายามทำ Startup อย่างผม เรื่องแบบนี้ยังไม่มีประสบการณ์ตรง ยังไปไม่ถึงในจุดนั้น ก็คงต้องศึกษาจากประสบการณ์ของคนที่เค้าเคยผ่านจุดนั้นมาแล้วซึ่งเค้าได้เตือนเอาไว้ และเพื่อเตือนตัวเองไว้ในวันนึงว่าเรื่อง Cash flow นั้นเป็นเรื่องที่สำคัญมาก ถ้าอยากให้ธุรกิจของเรายืนได้ยาวๆ เลยเอามาแปะไว้ซะหน่อย

ที่มา http://isriya.com/node/4108/burn-rate

เมื่อไม่กี่วันที่ผ่านมา Marc Andreessen แห่ง a16z ออกมาโพสต์เตือนสภาวะ “ฟองสบู่ 2.0” ของวงการ startup ในซิลิคอนวัลเลย์

ประเด็นที่เขาเตือนนั้นน่าสนใจมาก นั่นคือเรื่อง burn rate หรือ “ค่าใช้จ่ายต่อเดือน” ของ startup ที่ยังไม่มีรายรับ

Andreessen ยกบทความของนักลงทุนสองคนคือ Bill Gurley จาก Benchmark Capital และ Fred Wilson จาก Union Square Ventures ที่เขียนถึงเรื่องนี้

ประเด็นที่ Fred Wilson บอกคือ startup ซิลิคอนวัลเลย์ (รวมถึงที่อื่นๆ ด้วย แต่เน้นซิลิคอนวัลเลย์เป็นหลัก) มักให้ความสำคัญกับ “valuation” หรือมูลค่าบริษัทตามราคาหุ้น (ที่จะเพิ่มขึ้นเรื่อยๆ ตามรอบของการระดมทุน) ซึ่งเขามองว่ามันเป็นตัวเลขในอากาศ ถ้าน้อยไปก็สามารถเพิ่มได้ไม่ยากนัก แต่อันที่ควรจะใส่ใจคือ “burn rate” หรือ “อัตราการเผาเงิน” ซึ่งเป็นของจริง

ส่วน Gurley เตือนว่า startup ยุคนี้ใช้เงินมากเกินไป อาการจะคล้ายกับปี 1999 ก่อนฟองสบู่ดอทคอมแตก เหตุผลที่ใช้เงินเปลืองเป็นเพราะได้เงินมาง่าย (ต้นทุนการเงินต่ำ หรือ low cost capital) นักลงทุนอยากจ่ายเพื่อเกาะกระแส startup บูม แต่สำหรับ startup ที่ยังไม่มีรายได้จริงๆ เข้ามา ถ้ายังใช้เงินเยอะขนาดนี้แล้วฟองสบู่แตก บริษัทก็จะล่มสลายลงแทบจะทันที

Gurley บอกว่าสัญญาณเตือนที่น่าสนใจคือเจ้าของตึกในซานฟรานซิสโก เริ่มเจรจาให้ startup ที่มาเช่าตึกเซ็นสัญญาเช่านาน 10 ปี ซึ่งเป็นสัญญาณว่าวงการอสังการิมทรัพย์มองว่าฟองสบู่ใกล้แตกแล้ว ทำให้ “อัตราค่าเช่า” ในอนาคตไม่น่าจะขึ้นสูงไปกว่านี้อีก จึงพยายามผูกมัดให้ startup (ซึ่งในที่นี้คือผู้เช่า) จ่ายค่าเช่าในราคาปัจจุบัน (ที่น่าจะสูงที่สุดแล้ว) ไปอีก 10 ปีให้ได้

Andreessen มีมุมมองคล้ายๆ กันคือถ้าตลาดทุนถึง “ขาลง” เมื่อใด startup ที่มี burn rate เยอะๆ จะ “ระเหย” (vaporized) ไปในทันที

เขาแยกแยะข้อเสียของสภาวะที่ burn rate มากๆ ไว้ดังนี้

  • burn rate เยอะแปลว่าบริษัทเริ่มอ้วน ปรับตัวตามตลาดได้ช้าลง เปลี่ยนแปลงได้ยาก
  • การจ้างคนเข้าบริษัทเป็นเรื่องง่าย แต่การปลดคนออกเป็นเรื่องยาก ถ้าจ้างคนห่วยๆ เข้ามาเยอะๆ การปลดออกนั้นไม่ง่าย คนแบบนี้ก็จะอยู่กินเงินเดือนไปเรื่อยๆ
  • บริษัทจะพยายามแก้ปัญหาใดๆ ก็ตามด้วยการจ้างคนเข้ามาเพิ่ม (“งานเยอะเกินไปใช่ไหม จ้างคนเข้ามาอีกสิ”) จนกลายเป็นวัฒนธรรมองค์กร
  • การที่มีพนักงานเยอะๆ ออฟฟิศสวยๆ ช่วยสร้างสภาวะปลอมๆ ให้รู้สึกว่าบริษัทเริ่มประสบความสำเร็จแล้ว และแรงกดดันที่บีบให้ต้องทำงานจริงๆ ให้สำเร็จนั้นลดลงไป
  • พอคนเยอะ การสื่อสารภายในองค์กรก็เริ่มซับซ้อน กระบวนการทำงานเริ่มช้าลง สภาพการทำงานในบริษัทแย่ลง
  • เมื่อเดือนนึงต้องใช้เงินเยอะ การระดมทุนรอบถัดๆ ไปก็ยากขึ้น เพราะต้องระดมทุนให้ได้เยอะมากขึ้น (มาชดเชยกับ burn rate)
  • หรือต่อให้ระดมทุนได้ เงื่อนไขของเงินที่ได้มาก็จะสลับซับซ้อนขึ้นในแง่ของโครงสร้างผู้ถือหุ้น
  • เมื่อตลาดถึงขาลง โอกาสจะถอนตัวด้วยการขายบริษัทก็ยิ่งน้อย เพราะไม่มีใครอยากมาซื้อกิจการของเราแล้วต้องแบกรับค่าใช้จ่ายมหาศาลแทนเรา

เนื่องจากตัวผมเองก็เคยผ่านสภาวะการณ์ burn rate สูงๆ มาแล้วเลยรู้ซึ้งในประเด็นนี้ (และจากประสบการณ์ของเพื่อนๆ ในวงการผู้ประกอบการก็มาแนวเดียวกันหมด)

จริงๆ เรื่องนี้วงการผู้ประกอบการเขาสอนกันมานานแสนนานแล้วว่า cash flow เป็นเรื่องสำคัญที่สุด (แต่เราไม่ค่อยจะนึกถึงมันมากนักในช่วงขาขึ้น)

การลดค่าใช้จ่ายไม่ใช่เรื่องง่ายโดยเฉพาะเรื่องของคน และการหาเงินทุนเพิ่มในช่วงที่ต้องการเงินก็ไม่ใช่เรื่องง่าย เพราะต้องใช้เวลา ดังนั้น วิธีการที่ดีที่สุดในฝั่งของ burn rate คือทำตัวให้ lean ที่สุดเท่าที่จะทำได้ในแง่ค่าใช้จ่ายประจำ เพื่อให้สามารถปรับตัวหรือพลิกแพลงตามสภาพการณ์ ณ เวลานั้นได้ง่ายที่สุดครับ (การทำตัว lean ยังมีผลช่วยให้มีเงิน cash flow ในมือเยอะขึ้นอย่างที่ควรจะมีด้วย ไม่เสียเงินไปกับสิ่งที่ไม่จำเป็นต้องเสีย)

Photo credit: Lesum Flickr

[J-Seed Ventures] หลุมพราง 7 ประการที่สตาร์ตอัพมักทำผิดพลาด

เมื่อวันพุธที่ 1 ตุลาคม 2557 ผมได้ไปร่วมงานของ True Incube งานนี้ด้วย ตอนที่คุณ Jeffrey Char พูด ผมนั่งฟังเพียงอย่างเดียวไม่ได้จดรายละเอียดไว้ เพียงแต่โน้ตจุดสำคัญเพื่อเก็บไว้ทบทวน เพราะมัวแต่เตรียมตัวขึ้น pitch ในช่วง Co-founder dating (ไม่ได้เตรียมตัวมาก่อนเพราะจำวันผิด มารู้ตัวตอน 15.30น. แล้ว ซึ่งงานจะเริ่ม 18.00น. แต่สุดท้ายก็ตัดสินใจไม่ขึ้น pitch เพราะตอนนั้นพยายามขายไอเดียเพื่อชักชวนคุณ Art และคุณ Aun มาร่วมทีม) โชคดีที่ทาง blognone เอามาลงไว้ที่ https://www.blognone.com/node/61146 ผมเลยเอามาเก็บไว้ซะหน่อย เพื่อเก็บไว้ทบทวน

ในงานแถลงข่าวของ True Incube เมื่อวานนี้ มีพาร์ทเนอร์ร่วมจัดงานคือคุณ Jeffrey Char ซีอีโอของ J-Seed Ventures บริษัทลงทุนด้านเทคโนโลยีจากญี่ปุ่น มาร่วมบรรยายด้วย

คุณ Jeffrey เป็นผู้ประกอบการด้านเทคโนโลยีของญี่ปุ่นที่มีประสบการณ์สูง เปิดบริษัทมาแล้ว 15 แห่ง ภายหลังผันตัวมาเป็นนักลงทุน และเดินสายบรรยายเรื่องผู้ประกอบการตามสถาบันการศึกษาทั่วโลก

หัวข้อการบรรยายของคุณ Jeffrey Char พูดเรื่อง “หลุมพราง 7 ประการของสตาร์ตอัพ” (7 Pitfalls That Can Kill Your Startup) น่าจะเป็นประโยชน์กับผู้ประกอบการในบ้านเรา

J-Seed Venture

คุณ Jeffrey บอกว่าสอนวิชาสตาร์ตอัพมาเยอะ เจอปัญหาที่ซ้ำๆ กัน เลยอยากนำเสนอประเด็นพวกนี้ให้สตาร์ตอัพรุ่นใหม่ๆ ได้เรียนรู้ไว้ จะได้ไม่ทำพลาดซ้ำกันอีก

อย่างแรกสุดเลยคือสตาร์ตอัพมักคิดว่า “ไอเดีย” ของตัวเองเจ๋งมาก และหลงใหลในไอเดียของตัวเอง จนละเลยความเป็นจริงทางธุรกิจ ซึ่งคุณ Jeffrey แนะนำว่าควรเริ่มต้นจาก “ปัญหา” ไม่ใช่ “ไอเดีย” ให้ดูก่อนว่าเรื่องที่เราสนใจมีปัญหาอะไร แล้วค่อยหาวิธีแก้ปัญหานั้น

การเริ่มต้นที่ “ปัญหา” จะช่วยให้เราอยู่กับโลกความเป็นจริงมากขึ้น เพราะปัญหามีอยู่จริง (แค่ยังไม่ถูกแก้ไข) แต่ไอเดียนั้นไม่รู้เลยว่าจะใช้งานได้จริงหรือไม่

J-Seed Venture

ประเด็นที่สองต่อเนื่องมาจากประเด็นแรก คือเรารีบลงมือสร้างผลิตภัณฑ์เร็วเกินไป กระบวนการที่ถูกต้องคือทดสอบ “ปัญหา” ก่อนว่ามันมีจริงหรือไม่ มันร้ายแรงแค่ไหน ข้อสันนิษฐานต่างๆ ของเราถูกต้องหรือไม่ จากนั้นค่อยลงมือสร้างผลิตภัณฑ์

J-Seed Venture

หลุมพรางประการที่สามคือเรามัวแต่ไปจดจ่อกับการสร้าง “ผลิตภัณฑ์ที่สมบูรณ์” ซุ่มทำอยู่นาน พอทำเสร็จแล้วพบว่าไม่มีใครสนใจเราเลย

กระบวนการพัฒนาผลิตภัณฑ์ที่ถูกต้องคือค่อยเป็นค่อยไป สร้างต้นแบบขั้นต่ำ (MVP หรือ minimum viable product) ขึ้นมาก่อน แล้วค่อยๆ รับฟังความเห็นจากลูกค้า ก่อนจะปรับปรุงผลิตภัณฑ์ของเราไปเรื่อยๆ วิธีนี้จะช่วยให้เราอยู่กับโลกความเป็นจริงได้ดีขึ้น

J-Seed Venture

ประการที่สี่ ระดมทุนเร็วเกินไป คุณ Jeffrey บอกว่าการได้เงินมาเร็วเกินไปทำให้เราใช้เงินเปลือง และ “สิ้นเปลืองความสัมพันธ์” (burn relations) ของเรากับคนที่ควรจะพึ่งพิงได้ไปอย่างที่ไม่สมควรจะเป็น

ทางแก้ปัญหาก็ให้กลับไปที่ข้อแรกคือ กลับไปโฟกัสที่ปัญหาก่อน ถ้ายังหาวิธีแก้ปัญหาไม่ได้จริง อย่าเพิ่งระดมทุน

J-Seed Venture

หลุมพรางอย่างที่ห้า ขยายตัวเร็วเกินไป เป็นประเด็นที่ควบคู่ไปกับการระดมทุนเร็วเกินไป

คุณ Jeffrey เล่าประสบการณ์ว่าเขาเคยเปิดบริษัทแห่งหนึ่ง ตอนเดือนกุมภาพันธ์ยังไม่มีพนักงานเลย พอถึงเดือนธันวาคม มีพนักงานมากถึง 100 คน อัตราการเติบโตขนาดนี้คุมไม่ได้ สุดท้ายบริษัทนี้เจ๊ง

J-Seed Venture

หลุมพรางอย่างที่หก วัฒนธรรมองค์กร

คุณ Jeffrey แนะนำให้สร้างวัฒนธรรมองค์กรที่ดีขึ้นมา เพราะจะมีประโยชน์มากในระยะยาว องค์กรที่มีวัฒนธรรมแข็งแรงจะมีขั้นตอนการตัดสินใจน้อย คนในองค์กรจะระลึกถึงวัฒนธรรมองค์กรเสมอแล้วตัดสินใจได้ว่าควรทำหรือไม่ควร ทำอะไร

เทคนิคการสร้างวัฒนธรรมองค์กรคือเลือกคำที่เราอยากให้เกิดเป็นค่านิยมของ องค์กรมาสัก 1-2 คำ แล้วพูดย้ำเรื่องนี้อยู่เสมอเพื่อให้คนทั้งองค์กรจดจำได้ ส่วนค่านิยมจะเป็นอะไรนั้นแตกต่างกันไป ขึ้นอยู่กับรูปแบบธุรกิจ

J-Seed Venture

หลุมพรางอย่างสุดท้าย จงสร้างทีมที่มีทักษะแตกต่างหลากหลาย เพราะการสร้างธุรกิจจำเป็นต้องใช้ทักษะหลายๆ อย่าง เราไม่ควรนำเพื่อนร่วมทีมที่มีทักษะประเภทเดียวกันมาเป็นผู้ร่วมก่อตั้ง

คุณ Jeffrey แนะนำให้เราหัดทำความรู้จักกับคนหลายๆ ประเภท ถึงแม้จะฝืนอยู่บ้างในช่วงแรกๆ เพราะธรรมชาติของคนมักนิยมคุยกับคนที่สนใจหัวข้อเดียวกันมากกว่า แต่ถ้ามองถึงประโยชน์ระยะยาวแล้ว ก็ควรเป็นเพื่อนกับคนหลายๆ แบบ

J-Seed Venture

คอร์ส How to Start a Startup

คอร์ส How to Start a Startup นี้เป็นคอร์สของมหาวิทยาลัย Standford ซึ่งเชิญคนที่ประสบความสำเร็จในวงการ Startup ของอเมริกามาสอน และเปิดโอกาสให้คนทั่วไปเข้าเรียนได้ฟรี สามารถเข้าไปเรียนได้ที่ http://startupclass.samaltman.com

Lecture 1: Welcome, and Ideas, Products, Teams and Execution Part I,  Why to Start a Startup
สอนโดย Sam Altman  , Dustin Moskovitz

 

Lecture 2: Ideas, Products, Teams and Execution Part II
สอนโดย Sam Altman

 

Lecture 3: Counterintuitive Parts of Startups, and How to Have Ideas
สอนโดย Paul Graham

 

Lecture 4: Building Product, Talking to Users, and Growing
สอนโดย Adora Cheung

 

Lecture 5: Business Strategy and Monopoly Theory
สอนโดย Peter Thiel

 

Lecture 6: Growth
สอนโดย Alex Schultz

 

11 ประโยคเด็ดจาก How to start a start up

ช่วงนี้คอยติดตามคอร์สนี้ http://startupclass.samaltman.com/ พอดีว่ามีคนสรุป Quote จากคอร์สนี้ เลยเอามาแปะซะหน่อย

ที่มา : https://www.facebook.com/techstartupth/

11 ประโยคเด็ดจาก How to start a start up ซึ่งเป็นคลาสสอน startup ที่ stanford โดยกลุ่มคนที่ประสบความสำเร็จที่สุดในวงการ tech startup

แอดมินเห็นว่ามีประโยชน์มากๆ เลยขออนุญาติเอามาแชร์ให้ได้อ่านกันครับ

คาบแรก Ideas, Products, Teams and Execution, Part I
ผู้สอน Sam Altman (YCombinator President), Dustin Moskovitz (Co-Founder of Facebook)

1. คุณไม่ควรจะเริ่มทำ startup เพียงเพราะอยากได้เงิน โลกนี้มีหลากหลายวิธีในการหาเงิน คุณควรจะมี Passion ก่อนแล้วถึงเริ่มทำ startup

2. โลกอยากให้คุณสร้างอะไรซักอย่าง ถ้าสิ่งที่คุณทำไม่ใช่สิ่งที่โลกต้องการ คุณควรจะหาอย่างอื่นที่โลกต้องการ – มันคือ passion ครับ คุณต้องรู้สึกว่า ถ้าคุณไม่ทำก็คงไม่มีใครทำอีกแล้ว คุณถึงออกมาลุย startup เต็มตัว

3. Startup ที่ประสบความสำเร็จมักจะเริ่มจากไอเดียที่สุดยอด บริษัทที่ทำๆ อยู่แล้วเปลี่ยนไปทำไอเดียที่ไม่ได้ตั้งใจไว้แต่แรกมักจะไม่ประสบความสำเร็จ ส่วนที่ประสบความสำเร็จคือเปลี่ยนโดยมีพื้นฐานจากไอเดียเดิม

4. คุณควรจะมีไอเดียก่อนเริ่มทำ startup ถ้าคุณมีไอเดียหลายๆ อันที่รู้สึกว่ามันดี ให้เริ่มทำไอเดียที่คุณนึกถึงมันมากที่สุด

5. คุณต้องการทำในสิ่งที่ตลาดจะเติบโตในอีก 10 ปี นักลงทุนส่วนใหญ่มักมองพลาดมาดูแต่การเติบโตของ startup นั้นๆ แต่ลืมไวไปว่าจริงๆ แล้วสิ่งที่สำคัญกว่าคือโอกาสเติบโตของ market – ยกตัวอย่างเช่น facebook ที่ตอนแรกโตแค่ในมหาวิทยาลัย แต่การเติบโตของตลาด social network นั้นรวดเร็วมากๆ กว่าการโตของผู้ใช้บน facebook ซะอีก

6. ถ้าคุณสร้างสิ่งที่คุณต้องการใช้เองคุณจะเข้าใจมันได้ดีกว่าการไปสร้างสิ่งที่คุณต้องไปทำความเข้าใจด้วยการพูดคุยกับคนอื่น

7. ถ้าการอธิบายสินค้าหรือบริการของคุณต้องใช้ประโยคหลายๆ ประโยค นั่นอาจจะเป็นสัญญาณว่าสินค้าของคุณซับซ้อนเกินไป – พยายามทำให้มันง่ายๆ เข้าไว้

8. อีกสิ่งหนึ่งที่สำคัญมากๆ ในการทำ startup คือการหา co-founder ที่ดี คุณต้องรู้จักออกไปพบปะผู้คนในวงสังคมบ้าง เผื่อจะมีโอกาสได้เจอ co-founder ที่ถูกใจ

9. เวลา startup ที่ประสบความสำเร็จเล่าถึงเรื่องราวช่วงแรกๆ ในการทำ startup ส่วนใหญ่จะเล่าคล้ายๆ กัน คือทุกคนนั่งทำงานอยู่หน้าคอมพิวเตอร์เพื่อสร้างสินค้าหรือไม่ก็พูดคุยกับลูกค้า พวกเค้าแทบจะไม่ทำอย่างอื่นเลย

10. การสร้างอะไรซักอย่างที่ผู้ใช้จำนวนน้อยรักมัน ดีกว่า การสร้างอะไรซักอย่างที่มีคนชอบจำนวนมาก – คุณจะเติบโตได้ต้องอาศัยการบอกต่อ คนที่รักสินค้าของคุณจะบอกต่อ คนที่แค่ชอบสินค้าของคุณจะไม่บอกต่อ

11. ไอเดียเจ๋งๆ จะฟังดูแย่ในตอนแรก ส่วนไอเดียที่ดีจริงๆ จะฟังดูไม่น่าขโมยมาทำ – ไอเดียที่ดีๆ และใครๆ ก็มองออกจะถูกบริษัทใหญ่ๆ เอาไปทำอยู่แล้ว ส่วน startup มักจะทำอะไรที่ดูบ้าบอแต่จริงๆ แล้วมันกับเป็นไอเดียที่ฉลาดมากๆ

11 ข้อนี้คือจากคาบเดียวนะครับ บอกได้เลยว่าเป็นบทเรียนที่คุ้มค่ามากๆ สุดท้ายนี้แอดมินขอจบด้วยรูปภาพของประโยคคลาสสิคที่มีการใช้ในสไลด์การสอนนี้ด้วย

“Great products win”

ดูเต็มๆ ได้ที่นี่ http://www.youtube.com/watch?v=CBYhVcO4WgI
http://venturebeat.com/2014/09/25/how-the-tech-elite-teach-stanford-students-to-build-billion-dollar-companies-in-11-quotes/

เรียนรู้การสร้าง Mobile application จาก Facebook

มาลองดูแนวทางการพัฒนา Mobile App จากทีมงานของ facebook กันหน่อย

ที่มา http://www.somkiat.cc/how-facebook-make-mobile-app/

ในงาน @Scale Conference
ทีมพัฒนา Mobile application ของ Facebook ได้มาพูดเกี่ยวกับ
การพัฒนาระบบเพื่อให้สามารถทำงานได้บนมือถือและ network ต่างๆ ทั่วโลกได้

มาดูกันว่าทีมพัฒนาของ Facebook ทำการพัฒนา สร้าง product กันอย่างไร
เพื่อรองรับการใช้งานจากคนทั้งโลกกันอย่างไร

สิ่งที่ทางทีมพัฒนาชี้ประเด็นคือ

เรื่องความเร็ว network ของมือถือ
ซึ่งเป็นปัญหาแรกๆ ที่พบเจอ โดยสรุปได้ว่า

  • ในประเทศสหรัฐอเมริกา นั้นความเร็วของเครื่องข่าย 3G ใช้เวลาในการรับส่งข้อมูลต่อครั้ง 280 milisecond
  • ในประเทศอินเดีย นั้นความเร็วของเครื่องข่าย 3G ใช้เวลาในการรับส่งข้อมูลต่อครั้ง 500 milisecond
  • ในประเทศบราซิล นั้นความเร็วของเครื่องข่าย 3G ใช้เวลาในการรับส่งข้อมูลต่อครั้ง 800 milisecond

โดยทีมพัฒนาที่ทำการวิจัยสามารถสรุปกลุ่มผู้ใช้งาน facebook ไว้ง่ายๆ ว่า

Not everyone is on a fast
Not everyone has a large screen
Not everyone is on a fast network

ดังนั้น สิ่งที่ทางทีมพัฒนาจะเน้นเป็นพิเศษ คือ เรื่องปัญหาของ network

สิ่งที่ต้องจัดการประกอบไปด้วย 3 เรื่องคือ

  1. ขนาดของรูป ที่ต้องทำการ download ผ่าน network
  2. การตรวจสอบคุณภาพของ network ก่อนเลือกวิธีการทำงานให้เหมาะสม
  3. การแอบดึงข้อมูลบางส่วนมาก่อน

1. การลดขนาดของรูป

รูปแบบที่ใช้สำหรับรูปภาพคือ WebP
ซึ่งสร้างด้วยทีมของ Google ในปี 2010

จากข้อมูลของการใช้งาน Facebook for Android นั้นพบว่า 85% คือรูปภาพ
และ Facebook messenger นั้นพบว่า 67% คือรูปภาพ
ดังนั้น ถ้าสามารถลดขนาดของรูปภาพได้
ก็จะทำให้ application ทำงานได้เร็วขึ้น

ดังนั้นสิ่งที่ทีมพัฒนาต้องทำมีดังนี้

สิ่งแรกคือ การส่งข้อมูลที่เหมาะสมมาให้ผู้ใช้งาน
หมายความว่า จะทำการตรวจสอบก่อนว่าผู้ใช้งานนั้นเป็นอย่างไร
เช่นมีความเร็วของ network ความสามารถของมือถือ หรือ tablet และ ขนาดของหน้าจอ เป็นต้น
ทำให้ server สามารถเลือกข้อมูลที่เหมาะสมได้ เช่น ขนาดของภาพ
จะได้ไม่เปลือง bandwidth และ เปลืองเวลาในการรอของผู้ใช้งาน

แต่ในปัจจุบันเรื่องขนาดหน้าจอที่ใหญ่ และ ละเอียดขึ้น
ส่งผลให้ต้องส่งรูปภาพที่ละเอียด และ ขนาดใหญ่ขึ้น
ซึ่งวิธีการนี้อาจจะไม่ค่อยมีประสิทธิภาพเท่าไรนัก
แต่โดยรวมแล้วถือว่าคุ้มกับการลงมือทำ

สิ่งต่อมาคือ การเปลี่ยนรูปแบบของรูปภาพมาอยู่ในรูปแบบ WebP
ซึ่งสามารถลดขนาดของภาพ JPEG ลงไปได้ 7% เมื่อต้องการคุณภาพเท่ากัน
แต่ถ้าทำการเปลี่ยนแปลงค่าต่างๆ เช่นคุณภาพ สามารถลดขนาดภาพลงไปมากกว่า 30%
สามารถลดขนาดภาพลงไปมากกว่า 80% ของรูป PNG
เป็นการปรับปรุงที่ได้ผลดีมากมาย

สำหรับใน Android เวอร์ชั่นเก่าๆ ที่ไม่สนับสนุน WebP นั้น
ใช้วิธีการส่งข้อมูลเป็น WebP แต่ในการแสดงผลยังเป็น JPEG อยู่

2. การตรวจสอบคุณภาพของ Network

สิ่งหนึ่งที่ทางทีมพัฒนาได้เรียนรู้ก็คือ อย่าตัดสินเรื่องความเร็วของ Network ต่างๆ
ตาม technology เช่น 2G, 3G, LTE และ WIFI เป็นต้น
เพราะว่า แต่ละประเทศมันมีความเร็วที่แตกต่างกันมากพอสมควร

ดังนั้น สิ่งที่นำมาใช้ในการตัดสินใจก็คือ
การวัดจากความเร็วจากผู้ใช้งานที่เกิดขึ้นจริงๆ ณ ขณะนั้น

โดยจะวัดจากความเร็วของ network ที่ใช้งานตอนนั้น
ซึ่งทุกๆ response ที่ส่งกลับมาจาก server ของ Facebook
จะมี RTT (Round Trip Time) มาให้เสมอ เพื่อใช้ประมาณเวลาการรับส่งข้อมูล
และการตัดสินใจว่าจะส่งข้อมูลมาให้ด้วยคุณภาพสูงหรือต่ำเพียงใด
แบ่งออกเป็น 4 ระดับคือ

  1. Poor มีความเร็วน้อยกว่า 150kbps
  2. Moderate มีความเร็วระหว่าง 150-600kbps
  3. Good มีความเร็วระหว่า 600-2000kbps
  4. Excellent มีความเร็วมากกว่า 2000kbps ขึ้นไป

เมื่อรู้คุณภาพของ network แล้ว สิ่งที่จะต่อไปที่ต้องทำก็คือ

  • การเพิ่มหรือลดคุณภาพของข้อมูล
  • การส่งข้อมูลแบบขนานหรือไม่
  • การเปิดและปิด Auto play ของ VDO
  • การแอบดึงข้อมูลบางอย่างมาก่อน

ในการทดสอบนั้น ทีมพัฒนาได้สร้างระบบภายในที่เรียกว่า  Air Traffic Control ขึ้นมา
เพื่อจำลองรูปแบบต่างๆ ของ network
ทำให้เจอปัญหาที่ไม่คาดคิด บนระบบ network ที่ช้าได้อย่างรวดเร็ว
ซึ่งทำให้แก้ไขได้อย่างรวดเร็ว

3. การดึงข้อมูลบางส่วนมาไว้ก่อน (Prefetch content)

เนื่องจากปัญหาความเร็วของ Network ดังนั้นระบบอาจจะต้องทำการดึงข้อมูลบางอย่าง
ที่ยังไม่ถูกใช้งานมาเก็บไว้ก่อน ซึ่งข้อมูลเหล่านี้จำเป็นต่อการทำงาน

ยิ่งถ้า network ที่ช้าๆ แล้วจะพบว่า จะทำการดึงข้อมูลมาไม่ทัน
เช่นดึงข้อมูลมาไม่ได้ แล้ว ผู้ใช้งานจะพบเจอกับรูปภาพหน้าขาวขึ้นมา (ผมเจอประจำเลย)

โดยการดึงข้อมูลมาก่อนนั้น สามารถทำได้ตั้งแต่ตอนเปิด application ขึ้นมาใช้งาน
หรือทำในขณะที่กำลังใช้งานก็ได้

แต่สิ่งที่ต้องคำนึง คือ การดึงข้อมูลต้องไม่ไปทำให้ผู้ใช้งานสะดุด
หรือ block การใช้งานของผู้ใช้งานโดยเด็ดขาด
นั่นคือต้องแยกการทำงานระหว่าง foreground process และ background process ออกจากกัน
รวมทั้งไม่ดึงข้อมูลที่ผู้ใช้งานไม่จำเป็นมาด้วย

และสิ่งสำคัญสุดๆ ก็คือ
ต้องมีระบบ monitoring สำหรับดูว่าผู้ใช้งานแต่ละคนหรือแต่ละเครื่อง
ไม่ทำการดึงข้อมูลมาไว้ก่อนมากจนเกินไป ไม่เช่นนั้นจะเปลือง bandwidth การใช้งานมากๆ

ปิดท้าย

ทีมพัฒนานายังบอกด้วยว่า Facebook application for Android นั้นมีไฟล์ APK มากกว่า 20 ไฟล์
ซึ่งแยกตาม API Level, ขนาดของหน้าจอ และ สถาปัตยกรรมของ CPU อีกด้วย
มันไม่ใช่เรื่องที่ง่าย หรือ เล่นๆ เลยนะ

ดังนั้นลองนำแนวคิดเหล่านี้ ไปใช้เพื่อปรับปรุง Mobile application กันได้
น่าจะมีประโยชน์ไม่มากก็น้อยครับ

Reference VDO

สุดยอด

ผมเห็นคลิปนี้คิดว่ามันเป็นอะไรที่สุดยอดมากเลย เพราะมันมีส่วนผสมที่ลงตัวทุกด้านทั้งสภาพร่างกายที่แข็งแรงมากซึงเกิดจากการดูแลตัวเองอย่างดี การฝึกซ้อมที่หนักอันเกิดจากวินัยในการฝึกส่งผลให้เกิดทักษะที่สุดยอดทั้งการวิ่ง,การจับบอล,การหลอกล่อ จนสามารถทำทุกทักษะออกมาได้โดยอัตโนมัติ การตัดสินใจที่รวดเร็วและแม่นยำ การเลือกจังหวะเวลาว่าจะทำอะไรในตอนไหนไม่ใช่สักแต่จะวิ่งให้เร็วเพียงอย่างเดียว สุดท้ายคือเค้ามีทีมที่ดีคอยสนับสนุน หากขาดองค์ประกอบใดองค์ประกอบหนึ่ง สิ่งสุดยอดนี้คงไม่เกิดขึ้น

Technical Debt กับการล้มละลายของซอฟท์แวร์

ผมยกให้โพสนี้เป็น Post of the day ของเมื่อวานเลย ผมชอบมาก มันสะท้อนสถานะการจริงได้ดี แสดงผลกระทบจากการที่ Developer ไม่สามารถเข้าไปมีส่วนในการกำหนดระยะเวลาในการพัฒนางานได้ ทำให้เกิดการเผางาน ลูกค้าอาจได้งานเร็วดังใจ แต่มันเหมือนระเบิดเวลาที่พร้อมจะทำให้ทุกอย่างพินาศในอนาคต สุดท้ายโพสนี้ได้นำเสนอวิธีการแก้ปัญหาที่สามารนำไปปรับใช้ได้ตามสถานะการณ์ได้อีกด้วย

ที่มา https://medium.com/the-way-it-should-be/efb39c7b7699

การล้มละลายของซอฟท์แวร์

How to Avoid “Technical Bankruptcy”

The Way It Is

Manager: “เรื่องเชื่อมต่อธนาคาร ABC จะเสร็จวันไหนครับ?”

Junior Developer: “น่าจะศุกร์หน้าค่ะ”

Manager: “ช้าไปอะครับ พี่บอกลูกค้าไปแล้วว่าเราจะจ่ายเงินผ่านธนาคาร ABC ได้วันศุกร์นี้ ถ้าเสร็จไม่ทันมีหวังลูกค้าไม่จ่ายเงินงวดที่เหลือแน่”

Junior Developer: “แต่หนูคิดว่าถ้าจะทำให้ดีมันต้องใช้เวลานิดนึงอะค่ะ เพราะว่า …”

Manager: “พี่ขอนะรอบนี้ ทำอะไรที่มันง่ายๆไปก่อนได้มั้ย พี่ไม่อยากมีปัญหากับลูกค้า รายใหญ่ซะด้วยครับ”

Junior Developer: “อ่อ ค่ะ”

Manager: “ได้นะ เสร็จศุกร์นี้เลยนะ”

Junior Developer: “ค่ะ”

The Way It Should Be

เหตุการณ์ที่เกิดขึ้นรายวัน บทสนทนาแบบนี้มักจบลงด้วยชัยชนะของผู้มีอำนาจมากกว่าซึ่งส่วนใหญ่ก็จะเป็นคนที่มาจากหน่วยงานธุรกิจ ด้วยความไม่รู้หรือความละเลยก็ตามแต่พวกเค้ากำลังก่อ “หนี้ทางเทคนิค” (Technical Debt) ขึ้นมา

“หนี้” โดยธรรมชาติคือการที่เรายอมแลกสิ่งที่ต้องการในระยะสั้นกับภาระที่ตามมาในระยะยาว เช่น การกู้เงิน เราได้เงินมาใช้วันนี้โดยแลกกับภาระทางการเงินที่ผูกพันในระยะยาว ความน่ากลัวของหนี้คือเราไม่ได้ใช้คืนแค่สิ่งที่เราได้มา แต่เราต้องจ่ายมากกว่านั้นในรูปแบบของ “ดอกเบี้ย” ที่เติบโตขึ้นทุกวันไม่ว่าเราจะจ่ายเงินต้นคืนหรือไม่ แล้วถ้าวันหนึ่งเราหมดปัญญาจ่ายหนี้เราก็จะ “ล้มละลาย”

ถ้าคุณ Manager ไม่รีบร้อนตัดบทไปซะก่อน … บทสนทนาข้างบนจะมีเนื้อหาเพิ่มเติมแบบนี้

  • ทางเลือกที่หนึ่ง: 5 แต้ม (สำหรับระบบเชื่อมต่อธนาคาร ABC) ตอนนี้ หลังจากนั้น 21 แต้ม (เพื่อการทำ Refactoring ใน Sprint หน้า) แล้วหลังจากนั้น 1 แต้มสำหรับทุกๆการเชื่อมต่อกับธนาคารใหม่ๆ … ทางเลือกนี้จะทำให้เราส่งมอบงานให้ลูกค้าได้ตามเวลาและมีระบบที่ยืดหยุ่นเพียงพอเพื่อรองรับความต้องการในอนาคต
  • ทางเลือกที่สอง: 21 แต้ม (สำหรับระบบเชื่อมต่อธนาคารที่สมบูรณ์) หลังจากนั้น 0 แต้มเลยสำหรับการเชื่อมต่อธนาคารใหม่ๆ … ทางเลือกนี้คือการยอมรับความเสี่ยงที่จะส่งงานล้าช้าแต่เราจะมีระบบที่สมบูรณ์แบบมากในการรองรับความต้องการในอนาคต
  • ทางเลือกที่สาม: 5 แต้ม (สำหรับระบบเชื่อมต่อธนาคาร ABC) ไม่มีการทำ Refactoring ใดๆ การเชื่อมต่อกับธนาคารอื่นๆในอนาคตอาจจะเป็น 8, 13, 21 แต้ม จนถึงจุดหนึ่งที่โค๊ดมันไปไม่ได้แล้วก็ต้องมีการทำ Refactoring / Rearchitect ครั้งใหญ่ซึ่งตอนนั้นก็คงประมาณ 100+ แต้ม … ทางเลือกนี้เราจะส่งมอบงานได้ตรงเวลาแต่ต้องใช้เวลามากขึ้นเรื่อยๆกับการเชื่อมต่อธนาคารใหม่ๆ

ทางเลือกที่ดีที่สุดคือทางเลือกที่หนึ่งแต่ทางเลือกที่ได้รับความนิยมที่สุดคือทางเลือกที่สามเพราะสิ่งที่คุณ Manager ต้องการคืองานต้องเสร็จศุกร์นี้มันจึงเป็นทางเลือกเดียวที่เค้ามองเห็น … ช่างน่าเศร้าใจยิ่งนัก

เราจะทำอย่างไรเพื่อหลีกเลี่ยงทางเลือกที่สาม?

  1. ถามคุณ Manager ก่อนเลยว่า “พี่คะ พี่เข้าใจคำว่า ‘Technical Debt’ มั้ย?” ถ้าไม่เข้าใจก็อธิบายถึงผลกระทบให้เค้าฟังไป … สาเหตุหนึ่งที่ทำให้เรามีหนี้สินพะรุงพะรังก็เพราะคนที่มีอำนาจไม่เข้าใจคำว่า Technical Debt ไม่เข้าใจของผลกระทบที่จะตามมาของการตัดสินใจแบบลวกๆของเค้า และชอบคิดว่าอะไรๆก็ง่ายไปหมด
  2. จากข้อหนึ่ง … พยายามอย่าให้คุณ Manager มาคุยเรื่องแบบนี้กับ Junior Developer … น้องเค้ายังเด็ก หัวอ่อน ไม่กล้าเถียงผู้ใหญ่ (ฮ่าๆ) และอาจจะมีความเข้าใจและประสบการณ์ในโค๊ดไม่มากพอจะจัดการบทสนทนาเรื่องนี้ได้ดี เราต้องเป็นกำแพงให้ทีม เราต้องมีจุดยืนที่ชัดเจน
  3. ทุกครั้งก่อนที่เราจะก่อหนี้ เราต้องรู้ว่าเราจะใช้หนี้อย่างไรและเมื่อไร การเป็นหนี้ไม่ใช่เรื่องไม่ดีเสมอไปตราบใดที่เราพิจารณาอย่างรอบคอบและมีวินัยที่ดี มองการมี Technical Debt เหมือนเราเข้าครัวทำกับข้าว ช่วงที่หั่นผักหั่นเนื้อเราก็โอเคที่จะปล่อยให้มันมีขยะรกๆอยู่บนเขียงบ้าง แต่หลังจากผัดข้าวเสร็จเราก็เก็บล้างให้ครัวสะอาดเอี่ยมเหมือนเดิม … ประเด็นสำคัญที่สุดคือเราต้องมีวินัย

Technical Debt vs. Cooking

Technical Debt ก็ไม่ต่างจากการเป็นหนี้ทางการเงิน เริ่มต้นมันอาจจะไม่ใช่ภาระอะไรมากแต่ถ้าเราติดนิสัยก่อหนี้ยืมสินไปเรื่อยๆ ถึงวันนึงมันก็จะมาถึงทางตัน ซอฟท์แวร์ของเราก็จะล้มละลาย … อย่าปล่อยให้เป็นแบบนั้นเลยครับ

กฏ 27 ข้อ จากหนังสือ INNOCENT CODE

อ่านมาจากบล็อกของคุณ Somkiat Puisungnoen แล้วรู้สึกว่าดีมากเลย เป็นเบสิกด้าน Security ที่ต้องตระหนักในการพัฒนาระบบต่างๆ จึงอยากเก็บไว้เพื่อเตือนตัวเอง, ใช้ในการตรวจสอบระบบงานที่ทำต่อไป ซึ่งพอมาคิดๆดูก็พบว่างานที่เคยเขียนก็ยังมีช่องโหว่หลายอย่างอยู่ ซึ่งตงต้องตามไปปิดให้หมด

ที่มา http://www.somkiat.cc/innocent-code/

1. อย่าประเมินความสามารถของผู้บุกรุกต่ำเกินไป ( พลังด้านมึดมันน่ากลัวมาก )
2. แนะนำให้ใช้ HTTP POST เมื่อต้องการเปลี่ยนแปลงข้อมูลต่างๆ ของระบบ
3. อย่าไว้ใจข้อมูลที่ส่งมาจากฝั่งผู้ใช้งาน (Client side)
4. อย่าใช้ข้อมูลใน Referer header มาใช้ทำการ authentication และ authorisation
5. ควรที่จะสร้าง session id ใหม่ เมื่อผู้ใช้งานทำการ login เข้าระบบ
6. อย่าส่งรายละเอียดของความผิดพลาดไปยังผู้ใช้งาน
7. ตรวจสอบข้อมูล ก่อนที่จะส่งไปให้ระบบอื่นๆ ก่อนเสมอ
8. ตรวจสอบข้อมูล ที่ได้รับมาจากระบบอื่นๆ ก่อนนำไปใช้งานก่อนเสมอ
9. ควรมีระบบตรวจสอบข้อมูลเพียงที่เดียว ไม่กระจัดกระจาย เพราะว่าสามารถจัดการได้ง่าย
10. ในการตรวจสอบข้อมูล ต้องดูด้วยว่าระบบที่นำไปใช้งานคืออะไร เพื่อให้การตรวจสอบข้อมูลเหมาะสม
11. ต้องใช้ความพยายามอย่างมากในการต่อสู้กับการโจมตีรูปแบบต่างๆ เพราะว่าการต้องมีการเตรียมพร้อมในหลายๆ ส่วน ไม่ใช่เพียงการ coding เท่านั้น
12. อย่าเชื่อเอกสารของ API มากนัก เพราะว่ามันอาจจะผิดก็ได้ ดังนั้นต้องมีการตรวจสอบอยู่เสมอ
13. ต้องทำการตรวจสอบที่มาของข้อมูลเข้าเสมอ ห้ามละเลย ว่ามาจากที่เราอนุญาตไว้หรือไม่
14. ต้องทำการตรวจสอบข้อมูลเข้าทุกๆ ตัว เสมอ โดยไม่มีข้อยกเว้น
15. ในการกรองข้อมูล ให้ใช้วิธีการ whitelist นะ
16. อย่าอนุญาตให้ข้อมูลเข้าที่มันไม่ถูกต้อง ทำงานโดยเด็ดขาด บางครั้งระบบชอบไปลบข้อมูลที่ไม่ถูกต้อง แล้วให้ทำงานต่อไป ซึ่งน่ากลัวมากๆ
17. ระบบงานต้องมีการเก็บ logging ในการใช้งานระบบทั้งหมดไว้เสมอ
18. อย่าทำการตรวจสอบข้อมูลในฝั่ง client เพียงอย่างเดียวโดยเด็ดขาด
19. ถ้าเป็นไปได้ อย่าใช้ข้อมูลที่ส่งมาจากผู้ใช้งาน มาทำงานโดยตรง
20. ระหว่าง client และ server ควรส่งข้อมูลให้มีขนาดเล็กมากที่สุดเท่าที่จะทำได้
21. อย่าคิดว่า request ของผู้ใช้งานจะมาเรียงต่อกัน  หรือมาในแบบเดิมเสมอนะ เพราะว่าผู้ใช้งานสามารถทำได้มากกว่านั้น
22. ต้องทำการกรองข้อมูล ก่อนนำไปแสดงผลเสมอ
23. ในการเข้ารหัสข้อมูล ควรใช้ algorithm ที่เป็นมาตรฐาน
24. อย่าเก็บข้อมูล password ในรูปแบบ plain-text หรือเข้ารหัสแบบง่ายๆ โดยเด็ดขาด
25. อย่างส่งข้อมูลที่มีความสำคัญผ่าน HTTP GET โดยเด็ดขาด
26. จำไว้ว่า code ทุกๆ ตัวในฝั่ง server นั้นสามารถถูกโจมตีได้เสมอ
27. จำไว้ว่า security มันไม่ใช่ product แต่มันคือ process ที่ต้องเกิดขึ้นอยู่ตลอดเวลา

 

3 of 18
1234567