Estimate มาเท่าไร ใส่เข้าไปเพิ่มอีกเท่า
ผมลีดโปรเจ็คครั้งแรกตอนทำงานไปได้ปีนึง
โปรเจ็คนั้นทำงานกับคอนซัลท์ (ที่ปรึกษา) อีกคน ชื่อว่าแคลวิน
แคลวินเป็นชาวสิงค์โปร์เชื้อสายจีน อายุประมาณสี่สิบ เป็นคนเก่ง ใจเย็น และรับความกดดันได้ดี สมเป็นคอนซัลท์
สมัยนั้นทุกอย่างเป็น Waterfall หมด
คอนซัลท์จะทำหน้าที่ Requirement Gathering ไปเก็บความต้องการของลูกค้ามาให้ก่อน
หลังจากหายไปเดือนกว่า แคลวินกลับมาพร้อมกับเอกสารโปรเจ็คประมาณ 40+ หน้า หนามาก
ผมปริ้นท์ออกมานั่งอ่านอยู่สองวัน
กลับไปบอกว่าน่าจะใช้เวลาประมาณ 45 Man-day
แคลวินฟังเสร็จ ก็ตอบทันว่า
“I have a tip for you” (ไอมีทิปจะแนะนำ)
ผมเงียบไปพักนึง งงว่าอยู่ดีๆทำไมถึงเปลี่ยนเรื่องไว แต่ด้วยประสบการณ์ที่ต่างกันมาก ผมก็ฟังไว้ก่อน
“Whanever you estimate, double it before telling your Project Manager (PM)” (เมื่อไรที่ Estimate ได้มาเท่าไร ใส่เพิ่มอีกเท่าตัว แล้วค่อยไปบอกโปรเจ็คเมเนอเจอร์)
ผมในวัยใส (พึ่งทำงานมาได้ปีนึง) อึ้งไปเลยกับประโยคนี้
ตอนแรกนึกว่าพูดเล่น แต่พี่แกจริงจัง
เฮ้ย มันจะดีเหรอแคลวิน เดี๋ยว PM ก็กินหัวผมหรอก
“If PM isn’t ok with it, she’ll say so. Then we negotiate” (ถ้าโปรเจ็คเมเนเจอร์ ไม่โอเคกับตัวเลข เดี๋ยวเค้าก็จะบอกเอง แล้วเราค่อยต่อรองกัน)
ผมไม่ค่อยมั่นใจกับคำแนะนำนี้เท่าไร แคลวินเองเป็นคอนซัลท์ ถ้าโปรเจ็คยิ่งลากยาว เค้ายิ่งได้ค่าตัวเพิ่มเป็นรายชั่วโมง
ตอนนั้นผมเลยเพิ่ม Estimate ไปแค่ 50%
ส่งตัวเลขไปให้ PM ทางนั้นก็ไม่ได้ว่า
หลังจากนั้นเราก็พัฒนาโปรแกรมกันไปตามประสา
สรุปโปรเจ็คนั้นใช้เวลาทั้งสิ้น 6 เดือนตั้งแต่ต้นจนจบ หลังปิดโปรเจ็ค ผมกลับมานั่งนับวัน
…ใช้ไปประมาณ 90 กว่า Man-day…
ใกล้เคียงกับสองเท่าของที่ประมาณไว้ตอนแรก (45 Man-day)…
ตอนนั้น หน้าแคลวินก็ลอยขึ้นมา ยักคิ้วให้ แล้วพูดว่า
“See la? Trust me now la?” “เป็นไง เชื่อไอรึยัง”
ทำไม Estimate ถึงไม่เคยตรง
ผ่านมาสิบกว่าปี ผมอายุใกล้แคลวินมากขึ้น แต่สิ่งที่ไม่เปลี่ยนเลยคือไม่มีโปรเจ็คไหนที่ผม Estimate แล้วตรงตามที่กะไว้ตอนแรกเลย
พอประสบการณ์มากขึ้น ผมเริ่มเดาได้ว่าโปรเจ็คจะต้องเลทตั้งแต่ต้น แม้จะอธิบายไม่ค่อยได้ว่าทำไม (ทั้งที่ทุกอย่างยังดูไปได้สวย) ทำให้ผมกะได้แม่นขึ้น ด้วยการใส่เวลาเพิ่มไปตามสัญชาตญาณ
บางครั้งก็เพิ่มไป 50% บางครั้งก็เพิ่มไปเท่าตัวแบบที่แคลวินทำ
วันนี้ลองมานั่งสรุปดู ว่าทำไม Estimate ไม่เคยตรงเลย สรุปที่เจอบ่อยๆมา 4 อย่าง
1. มี Technical problem ที่ไม่ได้คาดคิดเกิดขึ้น
ตัวอย่างของหัวข้อนี้คือ
“รันบนเครื่องยังได้อยู่เลย ทำไม Deploy แล้วใช้ไม่ได้”
“ทำไมยูนิทเทสต์อยู่ดีๆก็พัง เกิดอะไรขึ้น เมื่อวานยังรันได้อยู่เลย”
“Dependency เวอร์ชั่นนี้พังซะงั้น นั่งดีบั้กอยู่ตั้งครึ่งวัน สุดท้ายแค่เปลี่ยนเวอร์ชั่นกลับก็หายแล้ว”
“อ้าว ใช้ Node 16 รันหรอกเหรอ มิน่าล่ะ เรานั่งรันเท่าไรก็ไม่ติด เราใช้ Node 8 อยู่”
หัวข้อนี้มักจะเป็นอะไรที่กินเวลาตั้งแต่ชั่วโมง ไปจนถึง 2-3 วัน
แทนที่จะได้เขียนตัวโปรแกรมจริงๆ เราต้องมานั่งแก้พวก Technical problem นี้ให้เสร็จก่อน
อยากให้สังเกตด้วยนะครับ ว่าปัญหาทั้งหมดที่อยู่ในหมวดนี้ มักจะป้องกัน หรือแก้ไขได้
พวก Senior จะมี Technical problem ที่ไม่คาดไว้น้อยกว่า
หรือพอมีปุ๊บก็พอจะเดาได้ทันทีว่าต้องแก้ที่ไหน
ดังนั้นปัญหาพวกนี้ ถ้าคิดไม่ออก ติดสักสองชั่วโมง ลองไปถามคนอื่นใน อาจจะได้คำตอบเร็วมาก เพราะเคยโดนมาก่อนแล้ว
ถ้าทีมที่แข็งและอยู่มานาน ก็มักจะมีโปรเซสหรือ Tool ที่คอยช่วยป้องกันปัญหาพวกนี้ให้มากที่สุด เช่น
- ใช้ Container เป็นหลักเพื่อลดปัญหารันบนเครื่องตัวเองได้ แต่ Deploy ไม่ได้
- มีการ Freeze dependency ไว้ ไม่ Install latest major/minor เวอร์ชั่นอัตโนมัติ
- Revert กันทันทีถ้า Unit test พังม ใช้ Mock ให้เหมาะสม
- ใน Onboarding process มีการให้ลง NVM และคอมมิต .nvmrc ไว้ใน Repository (เพื่อบังคับให้สลับ Node Version อัตโนมัติ)
แต่ทั้งนี้ทั้งนั้น เราไม่มีทางป้องกันปัญหาในหมวดนี้ได้ 100% ครับ
ต้องเข้าใจว่า การเขียนโปรแกรมไม่ใช่ Repeatable process
ทุกครั้งที่เราขึ้นโปรเจ็คใหม่ ต่อให้คล้ายกันแค่ไหน มันก็จะมีส่วนที่เราคาดไม่ถึงอยู่ (ไม่งั้นก็ใช้โค้ดของโปรเจ็คเดิมได้เลย จบ)
ทุกครั้งที่ทำโปรเจ็ค เราก็จะเจอปัญหาใหม่ๆที่ไม่คาดการ และต้องใช้เวลาเรียนรู้เพิ่มอยู่เสมอ ซึ่งเวลาตรงส่วนนี้ มักจะหลุดหายไปใน Estimate ครับ
2. Requirement ในหัวแต่ละคนไม่เหมือนกัน
ตัวอย่างในหัวข้อนี้ มีตั้งแต่ระดับ Technical ด้วยกันเอง
“อ้าว ต้องใส่ Metrics กับ Log แล้วทำ Operation dashboard ด้วยเหรอ ไม่ได้บอกไว้”
“Unit test ต้อง branch coverage 80% เชียวเหรอ ตอน Estimate ไม่ได้กะเอาไว้”
ไล่ไปจนถึงระดับ Functional กับ Non-functional requirement
“ตอนแรกคิดว่าแค่ดึงข้อมูลธรรมดา นึกว่าแค่ select * จึ้กเดียว ไม่เห็นรู้เลยว่าต้องดึงเป็นล้าน Record”
“โทษทีนะ พึ่งไปคุยกับลูกค้ามา มันต้องซัพพอร์ทั้งภาษาไทยและภาษาอังกฤษ พี่ไม่ได้ถามลูกค้า ลูกค้าก็ลืมบอกตอนแรก เพิ่มอีกภาษาไม่น่าจะเป็นไรนะ…”
กลับไปโปรเจ็คของผมกับแคลวิน
หนึ่งในสาเหตุหลักที่ทำให้ใช้เวลานานกว่าที่กะไว้ คือ Requirement ที่อยู่ในหัวลูกค้า หัวแคลวิน และหัวผม มันไม่ตรงกันเลย !!
เอกสารของแคลวินละเอียดก็จริง แต่มีหลายๆจุดที่แม้แต่ลูกค้า(หลายคน)ก็ลืมไปตอนนั่งคุย แคลวินก็ไม่มีทางถามได้หมด เพราะแกไม่ใช่ผู้ใช้จริง
ส่วนผมที่อ่านเอกสารของแคลวินอีกต่อ ก็มีจินตนาการอีกแบบ
พอถึงจุดที่เริ่มเทสต์กับข้อมูลจริง ตัวเลขออกมาคนละเรื่องกับที่คิดเอาไว้ ทุกอย่างเลยต้องวนลูปได้คุยและแก้เพิ่มอีกสองรอบ กว่าจะได้ Requirement ที่ถูกต้อง
ยังไม่รวมถึง Non-functional requirement ที่ขาดไป ผมไม่รู้ว่าข้อมูลบัญชีของบริษัทมันมีเป็นล้าน Record
ดึงตรงๆไม่ไหว ต้องสร้าง Batch job มา Preprocess เพื่อลดจำนวนและไปเก็บไว้อีก Table นึง
เทียบกับ Technical problem ในกรณีแรกแล้ว ปัญหาแนวนี้มักจะกินเวลาทำเพิ่มนานมาก บางทีเป็นหลักหลายสัปดาห์ หรือเดือน
แต่ก็ต้องยอมรับความจริง ว่าเวลาเรา Estimate เราทำแค่กับสิ่งที่เราเห็นแล้ว แต่สิ่งที่เรามองข้ามไป เราไม่ได้ Estimate
เราจึงต้องเผื่อเวลาตรงส่วนนี้ไว้ด้วย จะเท่าไร ก็แล้วแต่ลักษณะของระบบ และประสบการณ์เราว่าเคยพัฒนาระบบแนวนี้มามากแค่ไหน
3. Scope creep: ลูกค้าขอเปลี่ยน หรืออยากได้นู่นนิดนี่หน่อยเพิ่มเข้าไป
อันนี้ไม่ต้องมีตัวอย่าง น่าจะโดนกันมาหมดแล้ว ผมมี Quote แถมให้
“ลูกค้าส่วนใหญ่ 80% ไม่รู้ว่าต้องการอะไร ส่วนอีก 20% รู้ว่าต้องการอะไร แต่เปลี่ยนใจทีหลัง” – Not about code
เวลาเริ่มโปรเจ็ค ไปคุยกับลูกค้าหรือผู้ใช้ ผมจะ Assume the worst ไว้ก่อน ว่าลูกค้าอยู่ในหมวด 80% นี้แหละ
ที่สำคัญ ผมจะพยายามไม่คิดให้ลูกค้า เพราะถึงแม้จะคุยจบเร็ว แต่มันมีโอกาสต้องมาเปลี่ยนทีหลังสูงกว่า
โปรเจ็คไหนที่เห็นชัดเลยว่าลูกค้าไม่มั่นใจว่าจะได้อะไร ผมเสนอให้บังคับทำ Workshop (เอา Stakeholders มานั่งรวมกันเพื่อเขียน Business process ให้ชัดเจนตั้งแต่ต้นจนจบ), เขียน Wireframe, Mockup, หรือ Prototype
เอาให้ชัวร์ในระดับหนึ่งก่อนค่อยเริ่ม เจอตอนแรกมันคุ้มกว่ามาแก้ตอนท้ายๆ
4. คน Estimate ไม่ใช่คนทำ คนทำไม่ได้ Estimate
บางบริษัท เค้าจะให้ลีดเป็นคน Estimate (หรือแย่กว่า คือเอา PM มา Estimate)
ในมุมมองคนภายนอก มันเมคเซนส์นะ ถ้าผมจะสร้างบ้าน ผมก็จะเอาวิศวกรอาวุโสมาประเมิน ไม่ใช่ให้คนก่ออิฐมาประเมิน
แต่ในเชิงของซอฟท์แวร์ มันไม่ใช่ เอา Senior ประสบการณ์สิบปีมาประเมิน เค้าอาจจะเห็นความซับซ้อนที่ Junior ปีเดียวมามองไม่เห็น หรือเค้าอาจจะเคยทำอะไรแนวนี้มาแล้ว คิดว่าทำแล้วใช้เวลาเร็วกว่า
เวลาที่ใช้จริงมันมักจะเป็นเวลาที่คนทำจริงๆทำ เพราะงั้น ใครทำส่วนไหน ให้เค้าประเมินส่วนนั้น
ถ้าทำไม่ได้ในทางปฏิบัติ คนประเมินต้องเข้าใจความสามารถของคนทำด้วย ว่าไม่ใช่ทุกคนที่มีประสบการณ์เท่าเรา จะทำได้เร็วหรือละเอียดเท่าเรา ซึ่งอันนี้พูดตามตรง มันยากมาก เดาไม่ได้หรอก
บางที่ แก้ปัญหานี้ด้วยการพยายามให้ทุกคนในทีม Estimate
อันนี้ก็ต้องระวังหน่อย ที่ผมเคยเจอคือ Senior จะ Estimate ออกมาไล่ๆกัน ส่วน Junior จะแตกแยกออกมาคนละข้าง แล้วคุยสักพักทุกคนก็จะยอม Senior
แต่สุดท้าย คนทำงานนั้นคือ Junior
—
สรุปแล้ว ผมต้องยอมรับว่าแคลวินถูกนะ ถึงผมไม่เพิ่มเท่าตัวตลอด แต่ส่วนใหญ่ก็เพิ่มในระดับหนึ่ง
การ Estimate ของเรามันมีส่วนที่เรามองไม่เห็นและคาดไม่ถึงเยอะมาก ดังนั้น จงระวังให้ดี หาก Estimate ของคุณจะต้องกลายเป็น Promise ในการส่งมอบให้กับลูกค้า
ส่วนตัว ผมให้ทีม Estimate ประจำ ผมรู้สึกว่ากระบวนการในการ Estimate มันทำให้คนคิดละเอียด และพอเวลามันเลท เค้าจะได้พิจารณาว่ามองข้ามอะไรไป คราวหน้าจะได้วางแผนได้ดีขึ้น เพราะบางอย่างถ้าไม่คิดหรือวางไว้ก่อนใน Software Design จะกินเวลาแก้ทีหลังมากๆ
เวลาคุยกับลูกค้า ผมจะเผื่อด้วยการบอกเป็น Range (best case -> worst case) เพื่อให้อีกฝั่งเห็นภาพ ผมมองว่าหน้าที่ผมคือการให้ความรู้ลูกค้าด้วย ว่าการพัฒนาซอฟท์แวร์มันไม่มีเป๊ะขนาดนั้น ทีมพัฒนาไม่ใช่สายพานการผลิต
แต่ที่ต้องไม่ทำคือการลงโทษ(ทั้งทางตรงและทางอ้อม) เวลาที่ Estimate ของใครผิด ทุกคนต้องเข้าใจว่านี่เป็น Nature ของงาน และเรายังไม่มีเทคนิคอะไรที่สามารถทำให้ Estimate มันเป๊ะได้
บางบริษัท โดยเฉพาะ Tech companies ก็สามารถใช้แนวคิด #NoEstimate เลย
แต่ก็ต้องยอมรับว่าไม่ใช่ทุกบริษัทที่จะโอเคกับไอเดียนี้ เพราะฝั่ง Business เองก็ต้องการ Timeline เพื่อที่ฝั่งเค้าจะวางแผนได้ถูก
ในบางองค์กรที่ฝั่ง Business ไม่ได้เข้าใจถึงการพัฒนาซอฟท์แวร์ และเราไม่มีอำนาจในการต่อรองเลย
เราก็ไม่มีทางเลือกนอกจากเผื่อเอาไว้ก่อน ไม่งั้นอาจจะได้พาทีมโต้รุ่งกัน
ที่น่ากลัวที่สุดไม่ใช่การโต้รุ่งอย่างเดียว แต่ทีมต้อง Compromise กับเรื่องของ Code Quality
คราวนี้ล่ะ โปรเจ็คจบ แต่พอ Maintain นี่งานงอกยาวเลย เสีย Productivity โดยรวมอีก เพราะต้องมาชดใช้หนี้กันบน Production กันไปอีกหลายปี
---
ติดตามบทความสำหรับโปรแกรมเมอร์ทั้งด้านได้ที่ Facebook page Not about code หรือ Twitter @notaboutcode บทความของเพจจะเน้นเนื้อหาที่นำไปใช้ได้กับชีวิตจริง แต่ไม่ยึดติดกับเทคโนโลยีหรือภาษา เช่น System Design, Continuous Delivery, Testing, Career, etc.
สำหรับท่านที่อยากสนับสนุนผู้เขียน รบกวนช่วยแชร์โพสต์ในเฟสบุ้คให้กับเพื่อนๆที่น่าจะสนใจหัวข้อพวกนี้ด้วยครับ