Blog นีัเขียนดองมานานเกือบปีและ แต่พยายามให้ใจเย็น และมา Re-Write ให้มัน Soft ลงหน่อยมั้งเรามาดูกันครับว่าทำไมก่อนจะทำอะไรไป ต้องมีการ Estimate (ประมาณ) เวลา / resource ที่ใช้ แล้วทำไมต้องเผื่อเวลาขึ้นมา เพื่อให้งานมันไม่บีบรัดจนเกินไป มาดูกันครับว่าทำไมต้องเผื่อ

คนซื้อไม่ได้ใช้ คนใช้ไม่ได้ซื้อ

• ต้องขยายความนิดนึง เพราะส่วนนึงมาจากคนซื้อไม่ได้ใช้ และคนใช้ไม่ได้ซื้อจริงๆแหละ แต่มันอีกเคสนึง

• จาก Quote ข้างต้น เพราะส่วนใหญ่เลย มันจะเป็นปัญหาว่าผู้ใหญ่คิดว่า Requirement เท่านี้พอแล้ว หรืออาจจะจงใจตัดไป เพื่อลดราคา กับเวลา แล้วปัญหาจริงๆ มันไปแดงตอนที่เข้าไป Life Cycle ของการพัฒนาแล้ว ซึ่งถ้าหากรู้ในช่วง Requirement เราสามารถเจอ End-User จริงๆ ได้จะเจ็บตัวน้อยหน่อย (เวลาที่ Estimate เพิ่มมาระดับนึง) แต่ถ้าไปเอ๊ะตอน UAT หรือ Go-live หละ ?

คนที่ Deal / Estimate ไม่ได้ทำเอง ?

• คล้ายกันหัวข้อที่แล้ว แต่เปลี่ยนฝั่งจาก User มาเป็นข้างในของเราแหละ มีหลายตัวอย่าง เช่น
  • อันแรก SA > DEV บางที DEV มันไปเจอเคสพิเศษที่ควรตรวจสอบ / ดักเพิ่ม จาก SPEC ของ SA อย่างเช่น ถ้าค่านี้เป็น 0 มาระบบต้องเอาไปคิดยังไง หรือปรับ Helper นี้แล้ว มันไปโดนอีกจุดนึง ต้องทดสอบเพิ่ม
  • Skill ของคนในทีมไม่เท่ากัน บางคนเขียน Code เร็ว ไว แต่บางคนได้ผลลัพธ์เหมือน แต่ใช้เวลามากกว่าคนแรก
  • โดนตัดออก เช่น ทีม Engineer ประเมินมา 240 วัน แต่ตอนจะ bid ตัดออกเหลือ 180 วัน เพื่อให้ขายได้ - Marketing/Sale จะชอบทำกัน

คน Estimate ประเมินแบบ Estimate

• เป็นอีกมุมนึงนะ จะแตกมาจากหัวข้อก่อนหน้า ซึ่งในเคสนี้เราได้โอกาสมาประเมินแล้วนะ แต่
• Data ไม่เพียงพอ
  • ลูกค้าบอกไม่ละเอียด หรือ ข้อมูลตกหล่น จนมาถึงคน Estimate ไม่ครบ
  • อันนี้ปรับโดยตั้ง Skill การถาม อาจจะใช้ 5Why / Fishbone มาช่วยก็ได้ หรือไม่แตกประเด็นที่คาดว่าจะเกี่ยวข้องไป ถามใน role อื่นๆ อย่างผมเป็น Dev ตั้งคำถามโยนไปทาง BA เพื่อช่วยตีว่ามันเกี่ยวข้องจริงๆไหม
  • หรือใส่ Assumption ในการประเมินไป เพราะ ถ้ามีเหตุต้อง Charge เงินเพิ่มระหว่างพัฒนาจริงๆ จะได้ Reference ได้ (แต่หมดสิทธิ์กับงานราชการนะ มาจาก TOR)
• Time ไม่เพียงพอ
  • อันนี้เป็นเคสที่เจอประจำ แล้วมาคู่กับข้อแรกเลย Data ที่เราได้รับมาไม่พอ แต่โดนเร่ง เพราะลูกค้าต้องเอาตัวเลขไปเสนอผู้ใหญ่ หรือ พี่ต้องการเอาตัวเลขพร้อมคำอธิบายพรุ่งนี้
  • ตรงนี้เจ็บมาเยอะแล้ว
• Fact ไม่เพียงพอ (ที่จะชนะ Bias)
  • เราอาจจะประเมินแบบเข้าข้างตัวเอง ทำให้ Estimate อาจจะน้อยกว่าความเป็นจริงได้
  • มันมีศัพท์เฉพาะทางมันอยู่นะ The Dunning-Kruger effect เรามักคิดว่าทำได้ไวกว่า เราเก่งกว่า จริงๆการสร้างความท้าท้ายที่ละนิดก็ดีนะครับ แต่ก็ต้องดูหลายๆองค์ประกอบด้วย ว่า Domain ที่เราประเมินเชี่ยวชาญไหม หรือ ในหัวข้อถัดไป Tech ที่ใช้เราเชี่ยวชาญจริงๆไหม

ทีมพัฒนาไม่ได้รู้ในทุกเรื่องของ Technology

• Technology มันเปลี่ยนไปเรื่อยๆ บางทีตอนที่เราตกลง Stack ที่ใช้งานกัน พัฒนามาหมดและ มาตายตอนลงจริงที่ Site ลูกค้า UAT / Production เลย
• เจออะไรแปลกตอนเขียน Code ก็ตามรูปและกันครับ

• จริงๆแล้วมันแนวทางช่วยป้องกัน แต่มันก็ไม่ 100% อย่างเช่น
  • Container - ยกไปทั้ง Set แต่ต้องระวังนะ เพราะเคยเจอว่า Base Image Ver นึงตอน UAT พอจะจบ UAT เอามา Deploy ติดปัญหา 555
  • Automate Test - ทำไมต้อง Automate เพราะคนมัน Regression Test ไม่ไหวไง แล้วถ้ามันพังต้อง Revert Code หรือแก้ให้มันเขียวคืน
  • จากเคส Container ที่ยกมาจริงๆ ตัว Library ต่างๆ พวก mvn / nuget ต้อง Freeze Dependency ด้วย ถ้ามีใคร merge มาพร้อมขยับ Lib พวกนี้ต้องไล่กลับไป Test ก่อนครับ ถ้ามั่นใจมากก็ส่งไป Standby หน้างานเลย หึหึ
  • ตระกูล XXX As A Code - ช่วยได้เยอะตอน Deploy นะ

เรา และเธอเข้าใจเหมือนกันไหม ?

• ปัญหาตัว Requirement แหละครับ ผู้ให้สาร กับผู้รับสาร ตีความได้ตรงกันไหม ปัญหานี้ในด้าน Software Engineering มีคนมาเสนอ Idea แก้ปัญหานะ ทั้ง DSL / Diagram ต่างๆ อย่าง UML แต่

• ที่ยกมาข้างต้นเป็นส่วนของ Functional Requirement
• มันยังมีงานส่วนของ Non-Functional Requirement (Quality Attribute) - ที่มันซ่อนต้องดูเรื่อง
  • Performance ไหม ? - ตอนแรกมันก็เร็ว ใช้ไปนานๆ ข้อมูลเยอะขึ้นเป็นล้านๆ Record มันช้า รอไม่ได้
  • Security ไหม ? - ต้อง Hardening ไหม / รองรับ Pen Test ไหม บางที End User หรือ IT ฝั่งลูกค้าไม่ได้บอก จะไปเจออีกทีตอนขอติดตั้ง Production เลยก็ได้
  • และอื่นๆ

ทำเสร็จและ แต่พี่ว่ามันต้องเพิ่มอะไรนิดหน่อยนะ ?

• อันนี้มาจากทั้งทางข้างใน และข้างนอก (User) ได้เหมือนกันนะ
• หลายๆอย่าง มันต้องเห็นภาพมากขึ้น ถึงมี Idea เพิ่มเติมขึ้นมา อย่าง เช่น
  • Business Flow มีปรับ เพื่อให้รัดกุมมากขึ้น
  • ตัวรายงานน่าจะเอาข้อมูล B มา Link เสริมนะ จะได้เห็นภาพมากขึ้นตอนใช้งาน
• หรือ แม้กระทั่งเรื่องของ UX/UI จริงๆ เรื่องนี้ผมว่ามันเอาไปใส่พวก Non-Functional ได้นะ แต่แยกมาดีกว่า
• ในแง่ของ Software Engineering เองมีแนวทางแก้ปัญหาไว้นะ ทำ Prototype ให้เห็นภาพ แต่ปัญหาที่ทุกคนมักลืมกัน เห็นภาพแล้ว มีการแก้ไม่ได้ใส่เวลาไว้ ถ้าแก้น้อยก็ดีไป ถ้าแก้เยอะก็วันหยุดเราแหละ 555

จริงๆ Estimate มันเป็นงานที่โคตร Art

แบบต้องใช้ประสบการณ์ด้วย อย่างผมจะมีหลายวิธี เช่น

• แบ่งงานเป็นส่วนย่อยๆ แล้วให้ลองประเมินหลายๆคน A B C D - ถ้าใครเร็วสุด กับช้าสุด ต้องมาถามหาเหตุผล
• เผื่อไปก่อน อันนี้ต้องใช้ประสบการณ์ล้วนๆเลย อาจจะเผื่อ 0.5 / 2 / 5 หรือ x เท่า
  • ถ้าเผื่อมากไป จะเจอ Resource ว่าง น้อยไปโดยไฟลนสุดๆ หรือต้องเผื่อโดนตัด แบบว่าตัดไปแล้วเวลามันพอดีๆ
  • ผมก็มีเลขในใจนะ และ condition ต่างๆ แต่ขออุ๊บไว้ก่อน เดวมันจะกลายเป็นว่าคนที่อ่าน Blog ผม ด้วยรู้ทริก และเอาตัดเผื่อเลย
• หรือถ้าถล้ำตัวเข้าไปแล้ว ต้องพยายามไป Educate ลูกค้า ถ้าไปปรับตอนนี้ มันจะมีผลกับอนาคตอย่างไรนะ แต่ต้องดูมุมมองของลูกค้าที่มีต่อเราด้วยนะ
  • มองว่าเป็น Partners เข้ามาจ้างเข้ามาพัฒนาระบบ Module A B C จริงๆ
  • มองว่าเป็น Outsource ที่ทางลูกค้าจะทำอะไรก็ได้ เพราะที่เคยเจอมาบางทีสัญญาที่ Deal ไปเราเป็นแค่ Outsource เข้าไป Dev จริงๆ ทางลูกค้าเป็น SA ด้วย แต่ไปๆมาๆ เรามีตำแหน่งนี้ขึ้นมาด้วยเหมือนกัน แก้ตามพี่แล้วดี แต่พอใช้จริงไป 3 เดือนบน Production พี่อยากได้แบบเดิม
• มันมีอีกแนวคิดนึงนะ คือ No Estimate แต่มันจะดูขัดแย้งกับ Project ที่มันมีระยะเวลาชัดเจน และอย่าลืม Cost ด้วยนะ เราให้ลูกค้าฟรี แต่ถ้าลูกค้าดึงเชงไปเรื่อยๆ ค่าใช้จ่ายมันต้องจ่ายทุกเดือนนะ เช่น เงินเดือนให้ทีม / ค่าเสียโอกาส เพราะ Resource จม ซึ่งเรื่องพวกนี้คนที่อยู่ต้นน้ำมักจะลืมกัน