นิลครับ พี่ขอคุยด้วยซัก 5 นาทีหน่อยได้ไหมครับ
คำพูดนี้ช่วงนี้นิลได้ยินทีนี้สั่นซู่วขึ้นมาเลยครับ ช่วงนี้ในฐานะที่นิลเริ่มเติบโตขึ้นมา (นิดนึง) ในฐานะ Software Engineer คนนึง นิลเริ่มเห็นปัญหาใหญ่ ๆ ที่ Dev หลาย ๆ คนมักจะเจอนะครับ นั่นคือการ Estimate เวลาที่ใช้ทำ Task ใน Sprint นั่นเอง ปกติตอน Planning เหล่า PM ก็จะให้ Dev ลาก Card จาก Backlog เข้า Sprint พอเราลากเสร็จก็จะย้อนกลับมาถามเราว่าเราสามารถทำ Task เหล่านี้ให้เสร็จใน Sprint หรือเปล่า ตัวเรา ณ ตอนนั้นก็คิดแค่ว่า Task แต่ละใบน่าจะทำให้เสร็จในเท่านี้วัน เท่านี้ชั่วโมงแหละ แต่อาจจะลืมคิดถึงปัจจัยอื่น ๆ ไป วันนี้นิลจะมาลองยกตัวอย่างปัจจัยเหล่านั้นแล้วพาทุกคนคิดตามดูนะครับ ว่ากำลังเจอปัญหาเดียวกันอยู่หรือเปล่า
Meeting
ในโปรเจคที่นิลทำช่วงนี้ สิ่งนี้นับเป็นเกือบ ๆ 40% ของ Task ใน Sprint นึงเลยก็ว่าได้ ซึ่งมีทั้ง Meeting ที่เป็น Scheduled Meeting และ Unexpected Meeting ซึ่งในความเป็นจริงแล้วเราควรเอา Scheduled Meeting มาคำนวนในเวลาที่เราเหลือใน Sprint ด้วย และถ้าสมมติเราทำข้อมูลเก็บไว้ เราก็สามารถเอาข้อมูล Unexpected Meeting มาวิเคราะห์และ Buffer เผื่อไว้ให้เราสามารถคิดเวลาที่เหลือใน Sprint ได้อย่างใกล้เคียงความเป็นจริงมากที่สุดด้วย
นอกจากนี้หาก Meeting นั้น ๆ มีความนานเกินไปหรือเราไม่มีความจำเป็นจะต้องอยู่ใน Meeting นั้นแล้ว อาจจะขอตัดจบเข้าการสรุปการประชุมหรือออกจากการประชุมได้เพื่อให้เราไป Focus งานใน Sprint ต่อได้ครับ
Review PR
สิ่งนี้เป็นสิ่งที่ Dev หลาย ๆ คนอาจจะลืมเผื่อกันเอาไว้ตอนที่วาง Task กัน ทุกคนก็จะคิดแต่งานตัวเองกัน แต่ยังไงก็ดี สิ่งนี้นิลคิดว่าเหล่า Dev น่าจะต้องเอาไปคิดเพื่อลบเวลาใน Sprint ด้วย เช่น เราเห็นแล้วว่าเพื่อน ๆ ลากการ์ดเข้ามา 4 ใบใน Sprint และเป็น Issue ที่เราต้องไปช่วย Review เราอาจจะต้องประเมินเผื่อหักลบตรงนี้ไปเพื่อให้เราไม่ต้องไป Review PR นอกเวลาหรือว่าทำงานของตัวเองไม่ทันเพราะไปนั่ง Review PR คนอื่นอยู่
Misestimation
อันนี้อาจจะเป็นสิ่งที่ Subjective นิดนึงครับ อันนี้จากประสบการณ์ของนิลนะว่าหลาย ๆ ครั้งเราชอบคิดว่า Task มันง่าย อาจเป็นเพราะเราคิดว่ามันก็แค่นิดเดียวกับเราไม่มีความรู้มากพอที่จะประเมินเวลาที่แน่ชัดของมันได้ ทำให้สุดท้ายแล้วเราก็ Underestimate ไปยับ ๆ ซึ่งถ้าความผิดพลาดนั้นเกิดขึ้นในระดับชั่วโมงก็อาจจะโชคดีไป แต่ที่เกิดกับนิลล่าสุดคือด้วยความที่นิลไม่รู้เกี่ยวกับ WordPress เยอะมาก นิลคิดว่า Task ที่นิลต้องทำจะเสร็จใน 4 วันแต่ในความเป็นจริงแล้วนั้น… ใช้ไป 4 อาทิตย์แหนะ บ้าบอ แค่นี้ PM ก็ปาดเหงื่อแล้วครับ หรือบางทีนิลได้ Task นึงมา ด้วยความใหม่นิลก็รู้สึกว่ามันน่าจะยาก แต่ในความเป็นจริงอาจจะแบบดีดนิ้วเสร็จ ซึ่งในเคสเหล่านี้จริง ๆ ควรมี Senior/คนที่มีความรู้เกี่ยวกับเรื่องนี้มา Estimate เพื่อให้ค่าของการ Estimate มันไม่แกว่งมากเกินไปครับ
Support
หลาย ๆ ครั้งพอเราทำสิ่ง ๆ นึงเสร็จไป มักจะมีคนมาถามเรา ไม่ว่าจะเป็น PM Designer หรือลูกค้าก็ตาม ยกตัวอย่างเช่น เรา Release ของเสร็จปุ๊ป ทางลูกค้าอาจจะเจอ Bug หรือ Designer อาจจะอยากถามเรื่องของหน้าตาของที่เปลี่ยนไปบ้าง หรือแม้แต่ PM อาจจะต้องมาถามในเรื่องของการใช้ Feature นั้น ๆ ที่เราเพิ่ง Release ไป ซึ่งในความเป็นจริงแล้ว ควรจะต้อง Lock ไปเลยว่า Sprint นี้จะใช้ Resource เราในการ Support กี่วันเพื่อให้จำนวนวันที่เราเหลือใน Sprint นั้นเป็นตัวเลขที่ใกล้เคียงความเป็นจริงที่สุด
งั้นแปลว่าใน Sprint นึงเราอาจจะมีเวลาทำงานน้อยมาก ๆ เลยล่ะสิ
เป็นคำถามที่ดีครับ งั้นลองมายกตัวอย่างกันดีกว่า สมมติ 1 Sprint มี 10 mandays และนิลรู้ว่าต้องมีงานแทรกดังนี้
| Activity | Time (mandays) |
| Planning | 0.5 |
| Review PR (6 Issues) | 0.5 |
| Meeting With Client #1 | 0.3 |
| Meeting With Client #2 | 0.2 |
| Support After Release | 2 |
| Sprint Review + Retro + Grooming | 1 |
จากตารางนี้จะพบว่า 1 Sprint เราจะเสียเวลาไปทั้งสิ้น 4.5 mandays สำหรับงานอื่น ๆ ที่ไม่ใช่งานหลักใน Sprint ที่อยู่ใน Backlog เลย แปลว่าถ้า Sprint นึง มี 10 mandays เราก็จะเหลือเวลาทำ Task หลักใน Sprint อยู่ทั้งสิ้น 5.5 mandays นั่นเอง เย่ะ ๆ จากตอนแรก ถ้าสมมติเราไม่กางตัวเลขนี้มา เราอาจจะตีว่าเราจะมีอยู่ 10 mandays หรือบางคนอาจจะลบ Meeting ที่เป็น Planning กับ Review ไปอยู่แล้ว ก็อาจจะคิดว่าตัวเองมีอยู่ 9 mandays ใน Sprint ก็เป็นได้ครับ
ซึ่งจากตารางที่ยกตัวอย่างมา ถามว่า 5.5 mandays ต่อ Sprint ในการเคลียร์ของน้อยไหม? ต้องตอบว่าดูน้อยครับ เพราะจริง ๆ อันนี้เรายังไม่ได้รวมเรื่องของการ Misestimate หรือ Unexpected Meeting ที่เป็นปัจจัยแปรผันและ Backlog ของบริษัทก็ไม่ได้น้อยนะครับ แต่ Resource ของ Dev ถูกเอาไปใช้ในงานอื่น ๆ ซะเยอะจนสุดท้าย Resource ของ Dev ก็ไม่ได้เอามาทำงานที่เป็น Development อย่างเต็มที่ครับ
แล้วชีวิตจำเป็นต้องเป๊ะขนาดนี้ไหม?
นิลตอบตรง ๆ ว่าไม่ครับ และก็ไม่ใช่ทุกครั้งที่เราจะทำให้ Estimate ใกล้เคียงกับความเป็นจริงครับ สุดท้าย Estimate ก็แค่ค่าประมาณครับ เวลาที่ใช้ทำ Task นั้นจริง ๆ ก็อาจจะขึ้นกับประสบการณ์หรือเวลาที่เราใช้เพื่อประมวลข้อมูลก็ได้ครับ ถ้าย้อนกลับไป นิลจะใช้คำว่า Estimate ได้แค่ “ใกล้เคียง” กับความเป็นจริง แต่ไม่ใช้คำว่า “ถูกต้อง” หรือ “ตรงเป๊ะ” ด้วยเหตุผลนี้แหละครับ ว่าสุดท้ายมันอาจจะไม่เป๊ะแหละ นิลแค่อยากมาชวนให้ทุกคนลองคิดว่าเจอปัญหาเหล่านี้อยู่หรือเปล่าครับ
เราจะทำอย่างไรเพื่อลดปัญหาเหล่านี้?
นิลว่ามันมีวิธีลดปัจจัยที่ควบคุมได้ เช่นพวก Scheduled Meeting หรือการ Estimate Task รวมถึงการ Dedicated Support ด้วย ซึ่งแต่ละหมวดก็มีวิธีการควบคุมและลดได้อยู่แล้ว เช่น Meeting ก็อาจจะสามารถตัด Meeting ที่วกไปวันมาเข้าสู่การสรุปประชุมเพื่อจบ Meeting ที่ไม่มีประโยชน์ในการคุยต่อ หรือในหมวด Misestimation ก็อาจจะต้องหา Senior มาคอยช่วยน้อง ๆ Junior ในการ Estimate นิดนึงเพื่อลดความแกว่งที่อาจจะเกิดขึ้นได้
จบไปแล้วนะครับ กับ Blog ที่มาแบบงง ๆ ตัว Blog นี้มันเริ่มมาเพราะช่วงนี้นิลเสียเวลากับการ Activity เหล่านี้ในอัตราส่วนที่ค่อนข้างเยอะแหละครับ และทำให้นิลต้องไปทำงานนอกเวลาเยอะมาก สุดท้ายก็ส่งผลเสียกับสุขภาพนิลครับ ตอนแรกก็ไม่ได้ Capture จริงจังว่าใช้เวลาไปแต่ละ Activity เท่าไหร่บ้าง แต่นิลก็แบบ ไม่ได้ละ ต้องหาตัวการละว่าอะไรที่ทำให้นิลทำงานเกินขนาดนี้ได้ ก็ไปเจอเข้ากับสาเหตุเหล่านี้แหละครับ เลยออกมาเป็นเนื้อหาของ Blog แบบนี้ ยังไงถ้าอ่านแล้วมี Feedback อะไรก็สามารถให้ Feedback ทาง DM ของ Instagram ได้เหมือนเดิมนะครับ จนกว่านิลจะเปิดช่องทางเพิ่ม 555555 ขอบคุณทุกคนที่อ่านมาถึงจุดนี้ด้วยครับ
ขอให้สนุกกับการ Estimate Task
– นิล –
ps. จริง ๆ มี Intro อีกอันนึงที่น้องในทีมเสนอมาเมื่อช่วงเย็นวันศุกร์และชอบมาก แต่กลับมาแก้แล้วรู้สึกไม่เข้ากับ Intro + อาจจะทำให้ต้องรื้อ Intro เลยไม่ได้แก้ตามไปแต่ขอเอามาแปะตรงนี้
จริง ๆ แล้ว Blog นี้ควรเสร็จตั้งแต่วีคที่แล้ว
แต่ด้วยความชิบหายของงานแทรก ผนวกกับความสามารถในการ Estimate ที่ต่ำต้อยของนิลนั้น ทำให้มันถูกเลื่อนออกมาครับ…