- การประเมินระยะเวลาของโครงการซอฟต์แวร์อย่างแม่นยำนั้นเป็นไปไม่ได้ และงานส่วนใหญ่ถูกครอบงำโดย ‘สิ่งที่ไม่รู้’ ที่คาดเดาไม่ได้
- ค่าประมาณถูกใช้เป็นเครื่องมือทางการเมืองของฝ่ายบริหาร มากกว่าของวิศวกร เพื่อกำหนดลำดับความสำคัญของโครงการและการจัดสรรงบประมาณ
- ในทางปฏิบัติ ค่าประมาณเป็นตัวกำหนดนิยามของงาน และทีมทำงานในลักษณะของการค้นหาแนวทางเชิงเทคนิคที่ทำได้ภายในเวลาที่กำหนด
- เพื่อให้ประเมินได้อย่างมีประสิทธิภาพ วิศวกรควรโฟกัสที่ การเข้าใจบริบททางการเมือง การประเมินความเสี่ยงจากสิ่งที่ยังไม่รู้ และการนำเสนอหลายสถานการณ์ของการดำเนินงาน
- แนวทางนี้ให้ความสำคัญกับ ความไว้วางใจและความร่วมมือที่ตั้งอยู่บนความเป็นจริง มากกว่าความแม่นยำ และเน้นย้ำความสามารถทางวิศวกรรมในการเข้าใจโครงสร้างการตัดสินใจภายในองค์กร
ภาพลวงของการประเมินงานซอฟต์แวร์
- ในอุตสาหกรรมมี “เรื่องแต่งที่พูดกันอย่างสุภาพ” ว่าทีมที่มีทักษะ หากทุ่มเทมากพอ จะสามารถ คาดการณ์กำหนดการได้อย่างแม่นยำ
- แต่ในความเป็นจริง วิศวกรส่วนใหญ่ ตระหนักดีว่าการคาดการณ์อย่างแม่นยำนั้นเป็นไปไม่ได้
- บางทีมใช้ วิธี t-shirt sizing ในการประเมิน แต่สุดท้ายก็ถูกแปลงกลับเป็นหน่วยเวลาแล้วส่งต่อไปยังลำดับชั้นการจัดการ
- บางครั้งยังมีการใช้ heuristic ที่ไม่สมจริง เช่น “เอาค่าประมาณแรกคูณสองแล้วบวกอีก 20%”
ทำไมการประเมินจึงเป็นไปไม่ได้
- งานเล็กและชัดเจน พอจะคาดการณ์ได้ แต่โครงการส่วนใหญ่เกิดขึ้นใน ระบบที่ไม่แน่นอนและซับซ้อน
- ตัวอย่าง: การเปลี่ยนข้อความของลิงก์ธรรมดาอาจคาดการณ์ได้ว่าใช้ 45 นาที แต่การเปลี่ยนระบบขนาดใหญ่ทำไม่ได้
- งานเขียนโปรแกรมส่วนใหญ่เป็น กิจกรรมวิจัยเชิงสำรวจ ที่ไม่อาจรู้ได้ล่วงหน้าด้วยการวางแผนอย่างเดียวว่าต้องทำอะไรบ้าง
- แนวทาง การออกแบบสถาปัตยกรรมแบบรวมศูนย์ ในอดีตล้มเหลวมาแล้ว และผู้ที่ควรตัดสินใจคือผู้พัฒนาที่ต้องจัดการกับโค้ดจริง
- ผลก็คือ งานที่รู้แน่มีเพียง 10% ของทั้งหมด ส่วนอีก 90% ไม่อาจประเมินได้เพราะอยู่ในพื้นที่ที่ยังไม่รู้
การประเมินเป็นเครื่องมือของฝ่ายบริหาร ไม่ใช่ของวิศวกร
- การประเมิน ไม่ได้เกี่ยวข้องกับการเพิ่มผลิตภาพของทีม และหลายทีมที่มีประสิทธิภาพก็ทำงานได้โดยไม่ต้องประเมิน
- ฝ่ายบริหารมักพยายาม ปรับค่าประมาณให้สอดคล้องกับผลลัพธ์ที่ต้องการ โดยกำหนดการที่ยาวจะถูกกดให้สั้นลง ส่วนกำหนดการที่สั้นจะถูกขอให้เพิ่ม buffer
- มีเพียง โครงการที่เป็นไปไม่ได้ในทางเทคนิค เท่านั้นที่บางครั้งทำให้เกิดการตัดสินใจที่สมจริงขึ้นมาได้
- ใน พื้นที่ที่องค์กรให้ความสนใจต่ำ ขั้นตอนเชิงพิธีการอาจยังคงดำเนินต่อไปตามเดิม
- ดังนั้น การประเมินจึงทำงานเป็น เครื่องมือทางการเมืองให้คนที่ไม่ใช่วิศวกรใช้เลือกหรือยกเลิกโครงการ
การประเมินเป็นตัวกำหนดนิยามของงาน
- ตรงกันข้ามกับความเข้าใจทั่วไป สิ่งที่ถูกกำหนดก่อนไม่ใช่งาน แต่เป็นค่าประมาณ แล้วค่อยตัดสินใจเลือกแนวทางเชิงเทคนิคให้สอดคล้อง
- ตัวอย่าง: แนวทางในการสร้างฟีเจอร์ “คุยกับ PDF” ภายใน 6 เดือน กับภายใน 1 วัน ย่อมต่างกันโดยสิ้นเชิง
- ข้อจำกัดด้านเวลาเป็นตัวกำหนดความลึกและคุณภาพของการออกแบบโค้ด และวิศวกรก็เลือกวิธีแก้ปัญหาที่ทำได้ภายในเวลาที่กำหนด
วิธีประเมินจริงในทางปฏิบัติ
- เริ่มจาก ทำความเข้าใจบริบททางการเมือง เพื่อมองให้ออกว่าโครงการสำคัญแค่ไหนและคาดหวังกำหนดเวลาไว้ประมาณใด
- จากนั้น สำรวจแนวทางที่เป็นไปได้โดยยึดตามช่วงเวลาที่ถูกกำหนดไว้แล้ว
- ยิ่งมี unknowns มากเท่าไร ค่าประมาณก็ยิ่งต้องสูงขึ้น และขอบเขตของแนวทางก็ต้องแคบลง
- สุดท้ายควรนำเสนอ การประเมินความเสี่ยงและหลายสถานการณ์ในการดำเนินงาน แทนการระบุระยะเวลาอย่างแม่นยำ
- ตัวอย่าง: แก้ทุกองค์ประกอบเองทั้งหมด, เลี่ยงบางส่วน, หรือขอการสนับสนุนจากทีมอื่น
- บทบาทของวิศวกรไม่ใช่การตอบว่า “จะใช้เวลานานเท่าไร” แต่คือการหาให้ได้ว่า “มีวิธีใดบ้างที่ทำได้ภายในเวลาที่กำหนด”
ข้อโต้แย้งและการรับมือ
- วิศวกรบางคนพยายาม หลีกเลี่ยงการประเมินภายใต้เงื่อนไขที่ไม่แน่นอน แต่ผลคือทำให้คนที่ไม่ใช่สายเทคนิคต้องเข้ามาประเมินแทน
- การไม่ร่วมมือกับฝ่ายบริหารและมี ท่าทีเผชิญหน้าตลอดเวลา เป็นเรื่องที่ไม่ก่อผลดีและบั่นทอนความไว้วางใจ
- ทีมที่ไม่รู้สึกถึงแรงกดดัน อาจเป็นเพียงเพราะอยู่ใน พื้นที่ที่อยู่นอกความสนใจขององค์กร
บทสรุป
- ในความเป็นจริง ผู้จัดการมักเข้าหาทีมพร้อมกับกรอบเวลาที่มีอยู่ในใจแล้ว และทีมก็ต้องหาแนวทางเชิงเทคนิคที่เป็นไปได้ภายในกรอบนั้น
- การประเมินคือ เครื่องมือสำหรับการต่อรองระหว่างผู้บริหาร และมีเพียงโครงการที่เป็นไปไม่ได้เท่านั้นที่บางครั้งจะทำหน้าที่เป็นช่องทางส่งผ่านความจริงได้
- การประเมินที่ถูกต้องควรประกอบด้วย การนำเสนอความเสี่ยงและตัวเลือก ไม่ใช่ตัวเลขที่ดูแม่นยำ
- การประเมินงานซอฟต์แวร์อย่างแม่นยำเป็นไปไม่ได้ และความสำเร็จของการประเมินขึ้นอยู่กับความสามารถในการรับรู้และจัดการความเสี่ยงจากสิ่งที่ยังไม่รู้
2 ความคิดเห็น
> ก่อนอื่นต้องทำความเข้าใจบริบททางการเมืองเพื่อเข้าใจความสำคัญของโปรเจกต์และกำหนดการที่คาดหวังไว้
> จากนั้นค่อยสำรวจแนวทางที่เป็นไปได้โดยอิงจากระยะเวลาที่กำหนดไว้แล้ว
โอ้โห
ความคิดเห็นจาก Hacker News
ขอแชร์ ตารางเกณฑ์ประเมินโปรเจ็กต์ แบบกึ่งขำ ๆ ของผม
โปรเจ็กต์ภายใน (เช่น ย้ายผู้ให้บริการ โดยไม่มีผลกระทบต่อผู้ใช้) ก็เผื่อเวลาเท่าที่จะอธิบายให้หัวหน้าเห็นด้วยได้
โปรเจ็กต์ที่มีผลต่อผู้ใช้ (เช่น เพิ่มฟีเจอร์ใหม่) ก็ทำต่อไป ตราบใดที่ ROI ยังเป็นบวก
โปรเจ็กต์ที่ต้องร่วมงานกับพาร์ตเนอร์ภายนอก ฝ่ายขายจะเป็นคนกำหนดเดดไลน์ แล้วทีมวิศวกรรมก็ ปรับนิยามของ MVP เล็กน้อย ให้เข้ากับกำหนดนั้น
สงสัยว่าทำไมไม่มีใครพูดถึง planning poker หรือ story point เลย
มันไม่สมบูรณ์แบบ แต่ก็เป็นวิธีที่ค่อนข้างดี งานทุกอย่างควรจบได้ภายในสปรินต์ และถ้าใหญ่เกินก็ต้องแตกย่อย
ทุกคนในทีมต้องเห็นพ้องกับพอยต์ และในกระบวนการนั้นเองที่เกิด คุณค่าของการพูดคุยจริง ๆ
ผ่านไปไม่กี่เดือน ความเร็วของทีมจะนิ่งขึ้นจนคาดการณ์ได้ด้วยความแม่นยำราว ±10%
มันไม่ใช่เวทมนตร์ แต่ช่วยให้ส่งมอบคุณค่าได้สม่ำเสมอ และได้ทบทวน ความคุ้มค่าต่อค่าใช้จ่าย ในทุกสปรินต์
คนที่เพิ่งเข้าทีมใหม่อาจใช้เวลากับตั๋วงานเดียวกันนานกว่า 2 เท่า
แถมองค์กรยังชอบตั้งกฎอย่างเช่นให้รีวิว PR ให้เสร็จภายใน 24 ชั่วโมง ซึ่งห่างไกลจากความจริง
นักพัฒนาและ QA จะช่วยกันเทียบความซับซ้อนตอนประเมิน และ QA จะดูความยากของการทดสอบหรือความเป็นไปได้ในการทำอัตโนมัติ
เลยทำให้ ตัวชี้วัดความเร็วการพัฒนา ค่อนข้างนิ่ง และการประเมินรายเวอร์ชันก็แม่นพอสมควร
จะมีความหมายก็ต่อเมื่อทั้งทีมมีความเข้าใจร่วมกันเกี่ยวกับหน่วยขั้นต่ำ และแปลงมันเป็นเวลาได้
ซึ่งถ้าเป็นแบบนั้น สุดท้ายก็ใช้เวลาไปตรง ๆ ได้เลย พอยต์จึงไม่จำเป็น
ผมใช้การประเมินแบบ อิงช่วงความเชื่อมั่น โดยถามเป็นหน่วย “2 ชั่วโมง, 2 วัน, 2 สัปดาห์, 2 เดือน, 2 ปี”
ถ้าช่วงกว้างเกินไปก็จะแตกย่อยเพิ่ม และถ้ายังทำไม่ได้ก็จะตัดสินใจว่าคุ้มไหมที่จะใช้เวลาเก็บข้อมูลเพิ่ม
ถ้าไม่คุ้มก็ยกเลิกโปรเจ็กต์
ถ้ากำหนดผลลัพธ์ให้ชัดและแยกไอเดียออกเป็นขั้นย่อย ๆ ก็จะประเมินได้สมจริง
ถ้ายังแยกให้เป็นระดับวันหรือสัปดาห์ไม่ได้ แปลว่ายัง วางแผนไม่พอ
สำหรับกรณีแบบนี้ ผมคิดว่ามันประเมินยาก เพราะเป็นกระบวนการลองหลายแนวทางไปเรื่อย ๆ พร้อมกับเรียนรู้ระหว่างทาง
เพราะทำให้คิดแบบยึดการลงมือทำ มากกว่าประเมินแค่ความยาวเวลา
ครั้งหนึ่งผมเคยประเมินงาน ย้ายรหัสผ่านจากเก็บแบบ plaintext ไปเป็น hash ว่าจะใช้หนึ่งสปรินต์ แต่ความจริงกินเวลา 6 เดือน
มารู้ทีหลังเพราะลูกค้าอัดวิดีโอให้ดูว่าเขาใช้รหัสผ่านแบบไม่แยกตัวพิมพ์ใหญ่พิมพ์เล็ก
แถมอิมเมจ PHP ยังถูกลบอีก จน บิลด์ล้มเหลว ซ้ำเข้าไปอีก
การประเมินนี่เป็นการผจญภัยที่สนุกเสมอ
หนังสือแสดง สถิติการใช้งบเกิน จากข้อมูลโครงการจริง
โปรเจ็กต์ IT ใช้งบเกินเฉลี่ย 73% แย่เป็นรองแค่ที่เก็บกากนิวเคลียร์ โอลิมปิก และไฟฟ้าพลังน้ำ
18% ของโปรเจ็กต์ IT เกินมากกว่า 50% และค่าเฉลี่ยการเกินของกลุ่มนั้นอยู่ที่ 447%
สุดท้ายมันชี้ให้เห็นว่าในอุตสาหกรรมส่วนใหญ่ การประเมินมักมองโลกในแง่ดีเชิงโครงสร้าง อย่างหลีกเลี่ยงไม่ได้
น่าแปลกที่วิศวกรและผู้จัดการจำนวนมากไม่ประเมินโดยอิงจาก เมตริกของโปรเจ็กต์ที่ผ่านมา
ถ้าดูข้อมูล throughput ของทีม ก็พอคำนวณช่วงเวลาโดยประมาณและ ช่วงความเชื่อมั่น (เช่น 90%, 70%, 50%) ได้
แบบนี้ยังช่วยให้ผู้มีส่วนได้ส่วนเสียภายนอกเข้าใจบริบทเชิงความน่าจะเป็นด้วย
แต่วิศวกรจำนวนมากมองว่ามันเป็นภาระงานเอกสาร
แนวปฏิบัติที่ดีคือใช้ การประเมินแบบช่วง โดยจำลอง 3 ค่าแบบ PERT คือ ดีที่สุด คาดหมาย และแย่ที่สุด
ยิ่งเป็นคนเทคนิคเก่ง ๆ ยิ่งมีแนวโน้ม มั่นใจเกินไป กับการประเมินเวลาของตัวเอง
วิธีที่แต่ละคนประเมินเองก่อนแล้วค่อยบวกเผื่อ 20% ให้ผลค่อนข้างดี
ถ้าฝ่ายบริหารยืนยันกำหนดเวลา ก็ควรอธิบายขอบเขตที่ทำได้ภายในเวลานั้น หรือเสนอให้ กำหนดสโคปให้ชัดแล้วค่อยประเมินใหม่
อ้างอิง: PMI PMP, PMBOK no Lessons Learned Repository
prediction เรียนรู้จากความคลาดเคลื่อน แต่ prescription กลับนำไปสู่ แรงกดดันด้านผลิตภาพ
ผมมองว่าการประเมินคือ กระบวนการต่อรอง
เหมือนตัวเลือกระดับรถยนต์ที่มี Economy, Mid-tier, Luxury ให้เลือกสามแบบ
ฝั่งธุรกิจมักอยากได้ฟังก์ชันแบบตัวเลือกที่ 3 แต่ใช้งบแบบตัวเลือกที่ 1 ดังนั้นสุดท้ายผมก็ต้องปรับตามสถานการณ์
การเตรียม แผน #1 ไว้ล่วงหน้าทำให้สลับได้เร็วในยามวิกฤต และช่วยมองเห็น ราคาที่ต้องจ่ายของทางลัด ระหว่างการเจรจา
มันช่วยให้ผมหลีกเลี่ยงการตัดสินใจ ไร้เหตุผล ของ PM หรือผู้บริหารที่กำลังลนลานได้หลายครั้ง
ผมทำงานกับ ระบบกระจายขนาดใหญ่ ระดับ FAANG และที่นี่แทบเป็นไปไม่ได้เลยที่จะประเมินให้แม่น
มี unknown-unknowns มากเกินไป และแค่ทำต้นแบบก็ต้องใช้ข้อมูลกับเวลามหาศาลแล้ว
เพราะงั้นแทนที่จะโฟกัสที่การประเมิน ผมจึงโฟกัสที่ การจัดการความไม่แน่นอน มากกว่า
วิธีที่น่าเชื่อถือที่สุดคือ เทียบกับโปรเจ็กต์ที่คล้ายกัน
เช่น “อันนี้ซับซ้อนกว่าโปรเจ็กต์ X อยู่ 20% ก็เลยน่าจะใช้เวลามากกว่า 20%”
แต่การทำแบบนี้ได้ ต้องมีการบันทึก ข้อมูลเวลาที่ใช้จริง ของโปรเจ็กต์เก่าอย่างต่อเนื่อง
ตอนแรกผมตั้งใจจะคัดค้านคำกล่าวที่ว่า “การประเมินเป็นไปไม่ได้” แต่สุดท้ายก็พบว่า บทบาทในองค์กร สำคัญกว่า
ต่อให้ทีมดูจากกำลังคนเทียบกับงานแล้วบอกว่าเป็นไปไม่ได้ กำหนดการก็ไม่เปลี่ยนอยู่ดี
สุดท้ายก็ต้องแก้ด้วย ลดขอบเขตงานหรือยอมแลกคุณภาพ
เพราะงั้นคำว่า “การประเมินไร้ประโยชน์” อาจจะตรงกว่าด้วยซ้ำ
รู้สึกว่าหัวใจของการประเมินคือ ความกำกวม (ambiguity)
งานที่ดูเล็กอย่างการปรับ UI ละเอียด ๆ บางทีกลับเป็นงานที่ต้อง ทำไปเรียนรู้ไป เยอะมาก
ในทางกลับกัน ต่อให้เป็นการเปลี่ยนแปลงใหญ่ ถ้านิยามชัดเจนก็ทำเสร็จได้เร็ว
ในยุค LLM ปัจจัยที่กำหนดเวลาที่ต้องใช้คงไม่ใช่ขนาดของการเปลี่ยนแปลง แต่เป็น ระดับของความไม่แน่นอน มากกว่า