งาน Barcamp Bangkhen ครั้งที่ 6 2015

1. โท Levelup Plus
CPE19
Facebook.com/paiboonpa
paiboonpa@gmail.com

2.  วันที่เราสัญญากับลูกค้าว่าเราจะส่งงานได้
 วันที่เราสัญญากับหัวหน้าว่าเราจะส่งงานได้
 วันที่เราสัญญากับทีมอีกทีมว่าเราจะส่งงานไปให้ทาต่อ
 วันที่เราสัญญากับตัวเองว่าเราจะทาสิ่งๆ หนึ่งให้เสร็จ
 วันที่เราสัญญากับนาย…ว่าจะส่งงานได้

3.  ลูกค้าขอแก้แล้วแก้อีก
 สมาชิกในทีมคนสาคัญเกิดป่วยยาว
 HDD เสีย ข้อมูลหาย ทาใหม่หมด
 Bug แล้ว Bug อีก
 เสียเวลาทาในสิ่งที่ลูกค้าไม่ต้องการ
 อื่นๆ

4.  เลื่อน Deadline! (เจรจาต่อรองกับลูกค้า)
 ตัด Feature ที่ต้องทาให้น้อยลง... (เจรจาต่อรองกับลูกค้า)
 ทางานวันละ 12 ชั่วโมงแม่มเลย ทุกคนต้องช่วยกัน!
 เพิ่มคน? (เงิน?)
 ไม่ต้อง test??
 ยกเลิกโปรเจค???

5.  Product ที่ไม่พบ bug เลย
 Product ที่ไม่มีลูกค้ากล่าวว่า ติติงเลย
 Feature เยอะๆ ให้มากกว่าคู่แข่ง
 Feature เป็นไปตามที่ต้องการของลูกค้า, หัวหน้า, ฝ่าย business ,
ผู้ว่าจ้าง
 Feature เป็นไปตามที่ต้องการของผู้ใช้ (ตัวจริง ที่ไม่ได้จ่ายตัง หรือออก
คาสั่ง)
 Product ออกสู่ตลาดได้เร็วกว่าคู่แข่ง
 ทุกอย่างเป็นไปตาม Plan ไม่มีอะไรเปลี่ยนแปลง

6.  Software ที่ไม่มี bug เลย ไม่มีอยู่จริงบนโลก
 มีผู้ใช้ที่ด่าเรา ผู้ใช้เป็นเด็กเกรียน นักเลงคีย์บอร์ด มนุษย์ลุง มนุษย์ป้าอยู่เต็มไปหมด
 Feature ที่เยอะๆ เป็น 100 อย่าง มีผู้ใช้ ใช้งานจริงแค่ 10 อย่าง
 Feature ที่ ลูกค้า, หัวหน้า, ฝ่าย business ,ผู้ว่าจ้าง บอกว่าต้องมี แต่กลับ
ไม่มีผู้ใช้คนไหน ใช้งานจริงเลย
 Feature ที่มีลูกค้าจริงใช้งานเยอะแยะ เป็น Killer Feature กลับถูกลูกค้า
, หัวหน้า, ฝ่าย business ,ผู้ว่าจ้าง มองว่ามันไม่เท่ห์ ไม่ Cool และบอกว่า
ห้ามทา
 มีคู่แข่งที่ออก Product เร็วกว่าเราเสมอ
 ไม่มีอะไรเป็นไปตาม Plan 100% หรอก!

7. Quality Time
Feature
?
Less
Feature
Delay Bug

8.  Deadline ไม่สามารถเลื่อนได้ เพราะลูกค้าไม่รับการเจรจาใดๆ จากเรา
 เมื่อเราไม่สามารถเปลี่ยนแปลง Time ได้ เราต้องเลือกว่าจะเอา
Quality หรือ Feature
 แต่เมื่อเราเสนอ Time และ Feature ไปแล้ว มีเพียง Quality ที่
มองไม่เห็นด้วยตาเปล่า ดังนั้นจึงถูกบังคับเลือก Feature
 Quality? รอแก้ Bug หลังส่งงานอีกที
 สรุป: ทา Feature ให้ครบ มีหน้าตาสวยงามพร้อม ส่งทันตามกาหนด แต่
แทบไม่ได้ Test เมื่อใช้งานจริงจึงห้ามทาผิดพลาดแม้แต่นิดเดียว ไม่งั้นพัง!
อย่างน้อยก็ทันแถลงข่าวเปิดตัวนะเออ!

9. ปลอม!
เปลือก!
ภาพจากฮอร์โมน season 3 ตอนที่ 6

10. ภาพจาก 9gag.com ละครเรื่องธิดาพยายม
อ่านรายละเอียดดราม่า: http://pantip.com/topic/31170640
http://www.thairath.co.th/content/379219

11.  ลูกค้าอยากได้ Feature ครบๆ และ Quality ที่ไร้ข้อผิดพลาด ไร้
Bug แม้ภาพเบี้ยว 1 pixel ก็ไม่ยอม! (Perfectionist)
 Time จึงเป็นตัวแปรเดียวที่ลูกค้ายอมได้ เพราะถ้าทาให้ Software
ออกมาไร้ที่ติได้ เค้ายอมทุกอย่าง
 ทา Feature จนครบ มี Test Plan ครอบคลุมทุกการใช้งาน,
Automate Test ครบเครื่อง
 ทาออกมาแล้วลูกค้ารู้สึกขัดใจ อยาก improve ขึ้นไปอีก ขอเพิ่ม
Feature
 สรุป: งาน Delay เพราะ Feature งอกมากมาย แต่ผู้ใช้ได้ใช้ของมี
คุณภาพอย่างแท้จริง

12. 2006 2016
ที่มา: http://forum.tirkx.com/main/showthread.php?185796

13.  Quality กับ Time ต้องมาคู่กัน
 Time to market เป็นตัวเร่งอยู่ว่าออกช้าก็เจอคู่แข่งตัดหน้า
 ออกช้า ค่าใช้จ่ายบาน รายได้อาจเข้ามาไม่ทัน ทาให้ไม่มีเงินหมุน เอาไปจ่ายเงินเดือน
พนักงานได้
 Bug เยอะก็คงไม่ได้ ไม่งั้นไม่มีใครใช้
 Feature เป็นตัวแปรที่ถูกควบคุมได้มากที่สุด
 Product ต้องอยู่ในสถานะพร้อมปล่อยออกขายตลอดเวลา เพราะเมื่อถึงจุดที่
เวลาหมดแล้วจริงๆ (เงินหมดแล้วจริงๆ) จะถูกบังคับปล่อย
 Feature ที่ทาไปแล้วต้องแน่ใจว่าทางานได้ในระดับที่รับได้
 สรุป: ตัด Feature ที่ไม่จาเป็นทิ้ง เหลือแต่ Feature ที่เป็นแก่นสาคัญจริงๆ
เป็น MVP (Mininum Viable Product) (Lean Startup)

14. ภาพจาก http://www.startupdaily.net/2012/05/why-your-startup-will-probably-fail/

15. เหตุการณ์สมมติ: การเดินทางมางาน Barcamp Bangkhen

17. ภาพจาก thairath.co.th

20. ภาพจาก thairath.co.th

23.  เจอม๊อบ, เจอน้าท่วมครับ เลยต้องอ้อมไปอีกทาง

24.  อ๋อ พอดีผมต้องอ้อมไปออกลาดพร้าววังหิน เข้ารัชดา แล้วต่อมายังวิภาวดี ถึง
จะมาได้ทันน่ะครับ

25.  อ๋อ ผมวิ่งอ้อมมาทางนี้ เพราะเจอม๊อป น้าท่วมที่จุดนี้ๆ เลยบังคับให้อ้อมตาม
ภาพเลยครับ

26.  คนถามเป็นคนที่รู้สถานที่ตั้งม.เกษตรไหม?
 คนถามรู้ไหมว่าแผนที่รอบม.เกษตรเป็นอย่างไร?
 คนถามรู้ไหมว่ามีทางอ้อมหลบไปทางใดบ้าง ที่จะเร็วที่สุด?
 คนถามคาดหวังไหมว่าต่อให้เกิดเหตุสุดวิสัยใดๆ ก็ตาม คุณควรจะต้องมา
ทันเวลาภายใน 7 นาที อยู่ดี (เวลาที่ไม่เจอเหตุสุดวิสัยเลย)

27.  บอส: เห้ย! ทาไมงาน Delay วะ?
 นาย ก: อ๋อ พอดีมันมี Bug อะครับ
 บอส: แต่มันก็ควรจะใช้เวลาแก้ไม่นานป่าววะ?
 นาย ก: อ๋อ พอดีมันแก้แล้วระบบที่บอสบอกคราวก่อนยังไม่รองรับการแก้แบบ
นี้ ไม่ได้ทาเผื่อไว้ เลยต้องทาเพิ่มเยอะหน่อยครับ
 บอส: ไม่รองรับยังไง ผมไม่เข้าใจ พูดจาไม่รู้เรื่อง เอาอะไรก็ไม่รู้มาอ้าง ยังไง
คุณต้องแก้ให้เสร็จในวันพรุ่งนี้!
 นาย ก: ครับ T_T

28.  เงิน
 ความอยู่รอดของบริษัท
 ขายฝันนักลงทุน
 ผู้ใช้มีความสุข แก้ปัญหาของเค้าได้ (อนาคตอาจบอกต่อความดีของเรา)
 สนอง need ผู้ว่าจ้าง

29. Quality Time
Feature
Impossible?
Less
Feature
Delay Bug

30.  เพื่อจะได้ภูมิใจว่าเราทาตามแผนได้? เป็นขวัญกาลังใจให้ลูกทีมว่าเราทางาน
เสร็จทัน? (ไม่นับแก้งาน ไม่นับ bug ที่ต้องแก้เพิ่มอีกกี่วัน แค่มีงานส่งพอ)
 เพื่อจะได้คุมว่าลูกน้องเราไม่ขี้เกียจหรืออู้งานระหว่างนั้น ทาให้ใช้เวลามากกว่า
ที่วางแผนไว้? (แต่ไม่คานึงถึงปัจจัยไม่คาดฝัน หรือการเปลี่ยน
requirement ระหว่างทาง)
 เพื่อติดตามความคืบหน้าว่าตอนนี้งานเดินไปถึงไหนแล้ว
 เพื่อจะได้แจ้งฝ่ายที่ทางานต่อจากเราได้ว่าต้องเตรียมทางานต่อช่วงไหน
อย่างไร
 เพื่อประมาณงบประมาณที่ต้องใช้ (เช่นเงินเดือนพนักงานที่ต้องใช้)

31.  สร้างเสริมกาลังใจหลังมีคนมาใช้งานของเราจริง และรับคาชื่นชมจากผู้ใช้หรือลูกค้าแทนได้ไหม?
 ในทางปฏิบัติเราไม่สามารถควบคุมลูกน้องให้ไม่อู้ได้หรอก ระบบที่เพิ่มขั้นตอนตรวจสอบให้ไม่อู้ได้
จะเสียเวลาเราเพิ่มขึ้น และจะเพิ่มความกดดันให้ลูกน้องเสียเอง และยังกันได้ไม่ 100% อยู่ดี เราดู
ผลลัพธ์สุดท้ายได้ไหมว่าทาออกมาแล้วลูกค้าชอบไหม หรือลูกน้องเรามีการป้องกันปัญหาเดิมๆ
ไม่ให้เกิดซ้าไหม
 หากต้องการติดตามงาน ถ้าให้ลูกน้องเตรียมตัว Demo ระบบที่ทาได้ตลอดเวลาได้ไหม? ให้
รายงานและ Demo บ่อยๆ ตามที่เราต้องการ นอกจากจะรู้ว่างานเดินตลอดและเจอปัญหา
อะไรบ้างแล้ว หากไม่ถูกใจอยากแก้ก็สามารถสั่งแก้ได้ทันที ไม่ต้องเสียเวลารอทาเสร็จก่อนเพื่อมา
บอกว่าให้ทาใหม่หมด
 เราสามารถทาระบบเป็นคล้ายตะกร้า “งานที่เสร็จแล้ว รอส่งต่อ” ทิ้งเอาไว้ได้หรือไม่? ให้ทีมที่ทางาน
ต่อมาสังเกตเอาเองว่าตะกร้านี้มีงานเสร็จเพิ่มมาหรือยัง ถ้าเสร็จแล้วทีมเราก็ทางานอื่นต่อไปเลย โดย
ที่ทีมที่มารับงานต่อไม่ต้องสนใจว่าจะเสร็จเมื่อไหร่ ถ้ามีงานกองในตะกร้าแสดงว่างานพร้อมแล้ว
สามารถรับไปทาต่อได้เลย ต่อให้เราทาเสร็จเร็วจนงานกองในตะกร้าเยอะ ทีมที่มารับงานต่อก็จะเห็น
เองเพราะต้องมาคอยเช็คตะกร้าทุกๆ วันอยู่แล้ว (Kanban)
 เรื่องประมาณงบควรประมาณเผื่อ ดีกว่าประมาณขาด เพราะใช้ไม่ถึงแผนแสดงว่าเก่ง ใช้เกินแผน
แสดงว่ากาก

32. ภาพจาก http://www.telegraph.co.uk/technology/apple/iphone/5477324/Apples-iPhone-a-history-in-pictures.html

33.  ตอนที่สตีฟ จ็อบส์ เปิดตัว iPhone ในเดือนมกราคม 2007 ตอนนั้นตัว iPhone ยังไม่
สมบูรณ์มากๆ ทั้งเสถียรภาพของระบบปฏิบัติการที่รันงานได้ไม่เยอะแล้วจะรีบูตเพราะหน่วยความจา
เต็ม เล่นวิดีโอได้ไม่เต็มความยาวคลิปเพราะแบตจะหมดก่อน และมีปัญหาการเชื่อมต่อกับสัญญาณ
เครือข่าย แต่จ็อบส์ก็ยืนยันว่าจะเดโมฟีเจอร์ทั้งหมดแบบสดๆ ไม่บันทึกเทปไว้ก่อน (นาน 90 นาที!)
ซึ่งรวมถึงการโทรออกไปสั่งกาแฟ ซึ่งก็ต้องเชื่อมเครือข่ายจริงๆ ด้วย
 ทีมงานของแอปเปิลจึงต้องเตรียมพร้อมทุกอย่างเพื่อไม่ให้เดโมเจ๊งกลางงาน เช่น มี iPhone
หลายเครื่องเตรียมไว้เดโมฟีเจอร์เครื่องละ 2-3 อย่างเท่านั้น, มีลาดับการพรีเซนต์ฟีเจอร์ต่างๆ ที่รู้
ล่วงหน้าว่าจะไม่แครช
 ทีมงานแก้ปัญหาเรื่อง Wi-Fi ที่อาจมีปัญหาในงาน โดยเปลี่ยนความถี่ของเราเตอร์ Wi-Fi และ
ตัว iPhone เองเป็นความถี่พิเศษของญี่ปุ่น เพื่อไม่ให้ชนกับอุปกรณ์ Wi-Fi ที่ใช้ความถี่
มาตรฐานของนักข่าวทั้งหลาย
 AT&T ตั้งสถานีฐาน (cell site) ขนาดเล็กไว้ในงานเพื่อการันตีว่าจะโทรออกได้ และทีมงาน
ใช้วิธี hard code แถบสัญญาณของ iPhone ให้เต็ม 5 ขีดตลอดเวลา โดยไม่ขึ้นกับคุณภาพ
สัญญาณจริง เพราะกลัวสัญญาณร่วงระหว่างเดโม
 บทความเต็ม: https://www.blognone.com/node/49517

34. 2010 2013 2015

35. ภาพจาก: http://blog.onemonthrails.com/famous-first-landing-pages/

36. ภาพจาก: http://www.tmonews.com/2012/10/happy-birthday-to-the-t-mobile-g1-the-very-first-android-phone/

37.  ปรับแผนบ่อยๆ หมั่นสังเกตว่ายังเป็นไปตามแผนหรือไม่
 จัดลาดับความสาคัญให้ถูกต้อง เพื่อที่ว่าเวลาเราทาเลย Deadline จริงๆ ส่วนที่
สาคัญที่สุดจะได้ยัง Demo หรือยังใช้งานจริงได้ และนาไปใช้ได้บ้าง และ
Feature ที่ไม่สาคัญจริงๆ ถ้าทาไม่ทันก็จะเสียหายน้อยที่สุด เพราะเราทาอันที่
สาคัญกว่าก่อนแล้ว
 ควรมีกลไลในการแจ้งเตือนว่ามีปัญหาเกิดขึ้นแล้วนะ Delay แล้วนะ ไม่ใช่ปัญหา
ถูกเก็บไว้กับคนใดคนหนึ่งโดยไม่บอกใคร เน้นการสื่อสารในทีมให้ดี
 เมื่อมีปัญหาเกิดขึ้น ควรตั้งสติ อย่าใช้อารมณ์ แล้วช่วยกันคิดโดยไม่หาคนผิด เพราะ
ไม่ช่วยในการแก้ปัญหา
 ประเมินความเสี่ยง และเผื่อในส่วนของความเสี่ยง เท่าที่เป็นไปได้
 อย่าเสียเวลาวางแผนงานมากไป หากมีความเสี่ยงที่ไม่รู้เยอะมากๆ เพราะมันจะต้อง
ถูกเปลี่ยนไปตามสถานการณ์เรื่อยๆ
 Estimate คือการเดา อย่าให้มันมากดดันเรามากเกินไป เดาก็คือเดา

38.  Plan ที่เรากาหนดได้แน่นอนคือ Worst Case Scenario แต่
Plan ที่เรากาหนดได้ไม่แน่นอนนักคือ Best Case Scenario
 ถ้าขนาด Worst Case ยังไปไม่รอด ทาไม่ทันชัวร์ๆ ทาไปก็ไม่คุ้มก็ควร
พิจารณาปรับ Plan ใหม่ หรือถ้าปรับแล้วยังไม่รอดอยู่ดี และไม่สามารถ
ยืดหยุ่นอะไรเพิ่มเดิมได้ แม้แต่เวลาที่ต้องใช้เพิ่มก็ยืดไม่ได้ ก็ควรพิจารณาถึง
การยกเลิกโปรเจคเพื่อ Cut Lost ความสูญเสียที่กาลังจะเกิดขึ้นแน่ๆ ใน
Plan ที่วางไว้ และเริ่ม Project ใหม่ที่มีความเป็นไปได้มากกว่าแทน