การดำเนินการปรับสถาปัตยกรรมให้ทันสมัย: เมื่อไหร่ที่การประเมินกลายเป็นเส้นตาย?
(domainanalysis.io)- การปรับปรุงซอฟต์แวร์เลกาซีให้ทันสมัย มักยากที่จะกำหนดขอบเขตทั้งหมดจากข้อมูลที่มองเห็นก่อนเริ่มงาน ดังนั้นควรมองค่าประเมินเบื้องต้นเป็นเกณฑ์อ้างอิงที่ปรับได้ ไม่ใช่เส้นตาย
- เช่นเดียวกับการซ่อมรถ ในตอนแรกอาจประเมินได้ว่า $18,000·30 วัน แต่หลังจากถอดชิ้นส่วนและตรวจสอบแล้ว หากพบความเสียหายที่ซ่อนอยู่ ก็จำเป็นต้องมีใบประเมินเพิ่มเติมและการอนุมัติใหม่
- โปรเจกต์ปรับให้ทันสมัยก็มี ความซับซ้อนที่ซ่อนอยู่ ปรากฏขึ้นได้เช่นกัน เช่น การผสานระบบล้มเหลวหรือพฤติกรรมที่คาดไม่ถึง หากฝืนให้ตรงกับค่าประเมินเดิมในตอนนั้น ก็จะขัดแย้งกับความเป็นจริง
- ภาวะผู้นำที่ดีจะถามถึงความซับซ้อน แนวทางแก้ไข trade-off และทางเลี่ยง มากกว่าถามว่า “ทำไมถึงมองไม่เห็น” แล้วจึงตัดสินใจว่าจะเดินหน้าต่อหรือหยุด
- ในบริบทที่ซับซ้อน จำเป็นต้องวนซ้ำการลองทำ การทดลอง และการค้นพบ มากกว่าการยึดคู่มือกฎตายตัว ผู้นำควรสร้าง สภาพแวดล้อมให้ pattern ปรากฏ มากกว่าควบคุมมากเกินไป
ค่าประเมินไม่ใช่เส้นตาย แต่เป็นเกณฑ์อ้างอิงในการเดินหน้า
- ในการปรับปรุงซอฟต์แวร์ที่ซับซ้อนให้ทันสมัย หากปฏิบัติกับ ค่าประเมิน ราวกับเป็นเส้นตายที่แน่นอน ก็จะชนกับความเป็นจริงที่เปิดเผยระหว่างงานจริง
- ค่าประเมินเบื้องต้นสร้างจากข้อมูลที่มองเห็นได้จากภายนอกและประสบการณ์ แต่หลังจากเริ่มงานแล้ว ความซับซ้อนใหม่อาจปรากฏขึ้นได้
- “การประเมิน” คือค่าประมาณของค่าจริง และในการปรับให้ทันสมัยที่ซับซ้อนนั้น เป็นเรื่องยากที่จะคาดการณ์ผลลัพธ์ทั้งหมดได้อย่างสมบูรณ์ก่อนเริ่มต้น
อุปมาการซ่อมรถ: ความเสียหายที่มองไม่เห็นและใบประเมินเพิ่มเติม
- ในการซ่อมรถ ผู้ประเมินของบริษัทประกันจะส่งการประเมินความเสียหายให้ศูนย์ซ่อมก่อน และศูนย์ซ่อมก็ส่งใบประเมินของตนเองให้บริษัทประกันเช่นกัน
- ตัวอย่างเช่น ผู้ประเมินประกันประเมินความเสียหายไว้ที่ $15,000
- ศูนย์ซ่อมประเมินความเสียหายที่ $18,000 และระยะเวลาซ่อม 30 วัน
- ผู้ประเมินประกันและผู้เชี่ยวชาญจากศูนย์ซ่อมจะประเมินความเสียหายร่วมกัน และเมื่อบริษัทประกันอนุมัติใบประเมินใหม่ การซ่อมจึงเริ่มต้น
- ระหว่างซ่อม อาจพบความเสียหายที่ตอนแรกมองไม่เห็น
- อาจพบความเสียหายเพิ่มเติมขณะถอดชิ้นส่วน
- อาจใช้เครื่องดึงตัวถังตรวจสอบความเสียหายของ unibody frame
- ต้องตรวจสอบด้วยว่าแรงกระแทกส่งผลไปถึงด้านหลังของเฟรมหรือไม่ ไม่ใช่ดูแค่จุดกระแทก
- หากความเสียหายเพิ่มเติมต้องใช้ค่าใช้จ่ายเพิ่มอีก $20,000 ศูนย์ซ่อมจะส่งคำขอซ่อมเพิ่มเติมให้บริษัทประกัน และบริษัทประกันจะตัดสินใจว่าจะซ่อมต่อหรือจัดการเป็น ความเสียหายสิ้นเชิง (total loss)
- การที่บริษัทประกันปฏิเสธเงินเพิ่ม $20,000 เพียงเพราะใบประเมินเดิมคือ $18,000 ไม่สอดคล้องกับกระบวนการซ่อมที่เป็นจริง
ความซับซ้อนที่ซ่อนอยู่ก็ปรากฏในการปรับปรุงระบบเลกาซีให้ทันสมัยเช่นกัน
- การปรับปรุงซอฟต์แวร์เลกาซีให้ทันสมัยอยู่ในขอบเขตของ ซอฟต์แวร์ที่ซับซ้อน
- สามารถสร้างค่าประเมินเบื้องต้นจากปัญหาที่ดูชัดเจนจากภายนอกได้ แต่ระหว่างทำงานจริงมักมีความซับซ้อนเพิ่มขึ้นอีกมาก
- เช่นเดียวกับการซ่อมรถที่พบความเสียหายที่ซ่อนอยู่หรือความเสียหายของเฟรม การปรับให้ทันสมัยก็อาจเกิดปัญหาที่ไม่อยู่ในค่าประเมินแรกได้
- ในสถานการณ์เช่นนี้ ควรกำหนดขั้นตอนถัดไปผ่านการอนุมัติเพิ่มเติมและการประเมินตัดสินใหม่ มากกว่าถูกผูกติดกับค่าประเมินเดิม
คำถามที่ผู้นำที่ดีถาม
- ในสภาพแวดล้อมการพัฒนาซอฟต์แวร์ที่ดี เมื่อปัญหาปรากฏขึ้น จะตั้ง คำถามที่จำเป็นต่อการตัดสินใจ แทนการกล่าวโทษ
- ปัญหานี้ซับซ้อนแค่ไหน
- มีวิธีแก้อะไรบ้าง
- trade-off ของแต่ละวิธีคืออะไร
- มีทางเลี่ยงหรือโซลูชันทางเลือกหรือไม่
- ในทางกลับกัน หากบทสนทนาไหลไปสู่ “ทำไมถึงไม่เห็นความซับซ้อนนี้”, “ทำไมใช้เวลานานขนาดนี้”, “ทำไมรักษาวันตามค่าประเมินเดิมไม่ได้” ทีมก็จะถูกผูกติดกับวันที่ประเมินไว้เดิม
- โปรเจกต์ปรับให้ทันสมัยมีทั้งกรณีที่เดินหน้าต่อและกรณีที่หยุด
- หากอนุมัติค่าใช้จ่ายเพิ่มเติม ก็ย้ายไปขั้นตอนถัดไป และทำซ้ำกระบวนการนี้จนเข้าใกล้การเสร็จสิ้น
- หากค่าใช้จ่ายสูงกว่าคุณค่า โปรเจกต์อาจถูก หยุด ได้
- การตัดสินใจแยกระหว่างเดินหน้ากับหยุดไม่ใช่เรื่องง่าย และอาจใช้ framework สำหรับกำหนดทิศทางและเวิร์กช็อปการตัดสินใจ
ความต่างระหว่างบริบทที่ยุ่งยากกับบริบทที่ซับซ้อน
- ใน Cynefin framework จาก A Leader’s Framework for Decision Making การซ่อมรถยนต์หรือการซ่อมบำรุงมอเตอร์ไซค์อาจใกล้เคียงกับ บริบทที่ยุ่งยาก (complicated context)
- ในการซ่อมรถ ผู้เชี่ยวชาญจะฟังสถานการณ์อุบัติเหตุ วิเคราะห์และทดสอบหลายปัจจัย เช่น ความเสียหายที่มองไม่เห็นหรือความเสียหายของเฟรม แล้วตัดสินใจวิธีดำเนินการที่ดีที่สุด
- ใน บริบทที่ซับซ้อน (complex context) จะตัดสินได้ว่าอะไรถูกหรือผิดก็ต่อเมื่อได้ลองทำแล้ว
- integration ที่คาดว่าจะทำงานได้อาจล้มเหลว
- อาจค้นพบพฤติกรรมใหม่ที่ไม่เคยรู้ และต้องนำมาสะท้อนในการทำงาน
- การปรับปรุงระบบเลกาซีที่ซับซ้อนให้ทันสมัยไม่มีเส้นทางตายตัวหรือคู่มือกฎให้ทำตาม
- การปรับให้ทันสมัยคือการวนซ้ำกระบวนการลองทำ ทดลอง ค้นพบ แก้ไข แล้วขยับไปยังชิ้นถัดไป
ลูกโค้งไม่ใช่ข้อยกเว้น แต่คือความเป็นจริง
- หากการปรับปรุงแอปพลิเคชันให้ทันสมัยอยู่ระหว่าง complex กับ complicated ก็จำเป็นต้องมี แดชบอร์ดที่เหมาะสม สำหรับตัดสินความคืบหน้าและความสำเร็จ
- การนำกระบวนการประเมินแบบเรียบง่ายไปใช้กับบริบทที่ซับซ้อน ก็เหมือนพยายามใช้ค้อนแก้ปัญหาสกรูและน็อตล้อทุกตัว
- ลูกโค้งที่คาดไม่ถึงในโปรเจกต์ปรับให้ทันสมัยคือความเป็นจริง
- ไม่สามารถคาดการณ์ผลลัพธ์ทั้งหมดล่วงหน้าได้
- ต่อให้วิเคราะห์ล่วงหน้ามากเพียงใด ก็ไปไม่ถึง data model ที่สมบูรณ์แบบ
- เกือบทุกขั้นตอนจะเกิดการเรียนรู้ใหม่
- data model ต้องเปลี่ยนไปตามความซับซ้อนที่ค้นพบ
- เมื่อค่าประเมินเปลี่ยนไป ควรมองหาวิธีเดินหน้าต่อ แทนที่จะโกรธ กล่าวโทษ หรือยึดติดกับการวิเคราะห์เพื่อฝืนให้กำหนดการตรงตามเดิม
วิธีที่วัฒนธรรมองค์กรรับมือกับลูกโค้ง
- โมเดลวัฒนธรรมองค์กรของ Ron Westrum แยกแยะว่าองค์กรปฏิบัติต่อผู้แจ้งลูกโค้งและความล้มเหลวอย่างไร
- องค์กรแบบ Power-Oriented ยิงผู้ส่งสารที่แจ้งลูกโค้ง และความล้มเหลวนำไปสู่การหาแพะรับบาป
- องค์กรแบบ Rule-Oriented เพิกเฉยต่อผู้ส่งสารที่แจ้งลูกโค้ง และมองความล้มเหลวเป็นปัญหาของการบังคับใช้คำจำกัดความ
- องค์กรแบบ Performance-Oriented ฝึกผู้ส่งสารที่แจ้งลูกโค้ง และนำความล้มเหลวไปสู่การสำรวจค้นหา
- หากปัญหาที่ต้องการแก้ยังคงเกี่ยวข้องและตอบโจทย์ความต้องการทางธุรกิจ ก็ควรเดินหน้าไปทีละขั้น
- เป้าหมายปลายทางของซอฟต์แวร์ที่จะปรับให้ทันสมัยคือ ผู้ใช้
ขอบเขตที่ซับซ้อนต้องการการจัดการเชิงทดลอง
- ผู้นำที่ไม่ตระหนักถึงขอบเขตที่ซับซ้อนอาจใจร้อนเมื่อผลลัพธ์ที่ตั้งเป้าไว้ไม่เกิดขึ้นอย่างรวดเร็ว
- ในขอบเขตที่ซับซ้อน ความสามารถในการทนต่อความล้มเหลวเป็นสิ่งสำคัญ และความล้มเหลวเป็นองค์ประกอบจำเป็นของความเข้าใจเชิงทดลอง
- หากควบคุมองค์กรมากเกินไป ก็จะปิดกั้นโอกาสที่ pattern ที่เป็นประโยชน์จะปรากฏ
- ผู้นำที่พยายามบังคับยัดเยียดระเบียบให้กับบริบทที่ซับซ้อนจะล้มเหลว
- ผู้นำที่จัดเวที ถอยออกมาหนึ่งก้าว ปล่อยให้ pattern ปรากฏ และตัดสินว่า pattern ใดพึงประสงค์ อาจประสบความสำเร็จได้
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เคยเจอช่วงที่ผู้บริหารปฏิบัติต่อ ค่าประมาณเหมือนเดดไลน์ และยังเปลี่ยนสเปกไปเรื่อย ๆ โดยไม่ยอมฟังเลยว่าทำไมมันถึงเปลี่ยนได้
ตอนนั้นเลยเลือกตอบสนองแบบ “กวางค้างไฟหน้า” กับทุกเรื่องที่ไม่เล็กน้อย พอพูดว่า “อันนี้อาจเป็นงานใหญ่พอสมควรนะครับ/นะคะ น่าจะต้องมีใครในทีมใช้เวลาสักชั่วโมงดูว่าจริง ๆ ต้องทำอะไรบ้าง” ผู้จัดการก็จะถามกลับตามเคยว่า “ขอคร่าว ๆ ก็ได้” งั้นก็ให้ตัวเลขที่ใหญ่พอจะทำให้ลุกพรวดจากเก้าอี้ และตัวเลขนั้นก็มักจะติดอยู่ในความทรงจำ จากนั้นใช้เวลาสำรวจจริงหนึ่งชั่วโมง แล้วพยายามไม่ให้ตัวเลขอื่นนอกจากตัวเลขคร่าว ๆ นั้น สุดท้ายก็ได้ดูดีเพราะเสร็จ “เร็วกว่าแผน”
กับผู้จัดการที่ดีไม่เคยต้องใช้กลยุทธ์แบบนี้เลย ซึ่งก็ดีมาก แต่กับคนที่ไม่คิดจะพัฒนาความสามารถในหน้าที่ตัวเอง ก็ต้องรับมือกันแบบนี้ แถมการประชุมก็สนุกขึ้นเยอะด้วย
ทีมดีไซน์ ทีมฟรอนต์เอนด์ ทีมแบ็กเอนด์ และทีม QA ต่างก็พองตัวเลขกันแบบนั้น แล้วผู้จัดการโครงการก็นำผลรวมนั้นไปบวกเพิ่มอีก 150~200% จากนั้นผู้จัดการบัญชีและฝ่ายขายก็ยังบวกอีก 150~200% ก่อนคิดราคา
ผลก็คือการดูแลเว็บไซต์ที่ทีมพัฒนาเว็บ/ฟูลสแต็กระดับ decent จำนวน 8~10 คนก็น่าจะรับไหว กลับมีค่าใช้จ่ายเกือบ 1 ล้านดอลลาร์ต่อเดือน ทั้งที่ถ้าไม่นับซัพพอร์ต 24 ชั่วโมง ก็น่าจะใช้แค่นักพัฒนา Rails หรือ Django เก่ง ๆ ไม่กี่คน หรือคนเดียวกับกราฟิกดีไซเนอร์พาร์ตไทม์ก็พอ
หลายปีต่อมาลูกค้าก็รู้ทันสถานการณ์ และผู้บริหารบริษัทก็ทำเรื่องนี้พังไม่เป็นท่า จนมีคนราว 100 คนเสียงานและเสียสิทธิที่ยังไม่ได้รับ วันนั้นเจ้าตัวเองก็เสียเงินไปราว 26,000 ดอลลาร์
ความจุรวมของทีมอาจอยู่ที่ประมาณ 40 แต้ม และจะเปลี่ยนขึ้นลงเล็กน้อยเมื่อมีคนออกหรือเข้าทีม Velocity คือปริมาณงานเฉลี่ยที่ทำได้ วัดเป็นแต้มต่อคนต่อวัน
ส่วน Volatility คือระดับที่สปรินต์ถูกเปลี่ยนแปลง งาน 5 แต้มหนึ่งใบถูกเอาออกแล้วแทนด้วยงาน 3 แต้มกับ 2 แต้มอาจไม่เป็นไร แต่ถ้าเกิดแบบนั้น 12 ครั้งในสปรินต์ 2 สัปดาห์ ถึงยอดรวมจะยังไม่เกิน 40 แต้ม ก็จบสปรินต์ไม่ลงอยู่ดี
มีการเก็บสแนปช็อตของสปรินต์ทุกวันเพื่อดูปริมาณตั๋วงานที่เพิ่มและลบ แล้วก็สามารถแสดงให้ผู้จัดการเห็นได้ว่า เมื่อความผันผวนต่ำก็มักจะทำเสร็จเกือบตลอด แต่ถ้าความผันผวนสูงก็ล้มเหลวไม่ว่า Velocity จะเกินหรือไม่ เพราะไม่มีเวลาพอให้วางแผนและทำความต้องการให้ชัด ถ้าทำให้ทีมผลิตภัณฑ์มองไกลเกิน 2 สัปดาห์ได้บ้างก็ช่วยได้ระดับหนึ่ง
วิศวกรที่ให้ค่าประมาณพองเกินจริงกับงานง่าย ๆ ก็มักมีโอกาสสูงที่จะเป็นพนักงานผลงานต่ำ วิธีนี้อาจใช้ได้กับคนที่ไม่ตัดสินจากการส่งมอบช้า หรือผู้จัดการที่ไม่รู้สถานการณ์ แต่ผู้จัดการที่รู้เรื่องจะดูออกอย่างรวดเร็ว
แทนที่จะให้ค่าเดียวตายตัว ควรให้ ช่วงความคลาดเคลื่อน ไปด้วย เช่น “3 เดือน, ±4 สัปดาห์” วิศวกรส่วนใหญ่รู้ว่าค่าประมาณของตัวเองมีช่วงคลาดเคลื่อน แต่ด้วยเหตุผลบางอย่างกลับถูกฝึกจนลืมพูดมันออกมา
ในมุมการบริหาร ขนาดของช่วงคลาดเคลื่อนยังแสดงระดับความมั่นใจต่อค่าประมาณได้ทันที และช่วยเปิดบทสนทนาเรื่องความเสี่ยง เช่น “ตอนนี้มีความคลาดเคลื่อน 30% ทั้งสองด้าน ปัจจัยใหญ่ที่สุดคืออะไร และใช้เวลาสืบหากี่วันถึงจะลดลงทีละข้อได้?”
เข้าใจยากจริง ๆ ที่ในเมื่อเรียกตัวเองว่าเป็นสายงานวิศวกรรม แต่กลับคุยเรื่อง ความเสี่ยง ความน่าจะเป็น และช่วงความเชื่อมั่น กันอย่างจริงจังไม่ได้ เรื่องนี้ก็ไม่ใช่ความผิดของผู้จัดการฝ่ายเดียว
ถ้าเป็นผู้จัดการมือใหม่ หรือคนที่มาอุดตำแหน่งชั่วคราวแล้วไม่คุ้นกับความไม่แน่นอนก็ยังพอเข้าใจได้ แต่ในกรณีอื่นไม่มีข้อแก้ตัวเลย
บทความนี้พูดถึงโครงการ modernization และโครงการแบบนี้มี เดดไลน์ที่หลวมกว่า เพราะซอฟต์แวร์เดิมยังทำงานต่อได้ระหว่างพัฒนาระบบทดแทน
ถึงจะมีแรงกดดันด้านงบประมาณ คำมั่นสัญญา และความคาดหวังของผู้ใช้ต่อฟีเจอร์ใหม่ แต่ระบบทดแทนช้าไปหนึ่งวันก็ไม่ได้ถึงขั้นหายนะ
ในทางกลับกัน ถ้ากำลังยิงยานสำรวจอวกาศแล้วตำแหน่งดาวเคราะห์ไม่ตรงกับหน้าต่างช่วยแรงโน้มถ่วง ยานก็ไปไม่ถึงจุดหมาย หรือถ้าบริษัทผลิตเครื่องมือขนาดเล็กที่มีรายได้ปีละ 100 ล้านดอลลาร์ ทำสัญญากับ Ford ให้ส่งมอบแม่พิมพ์สำหรับสายการผลิต 2026 F150 ภายในเดือนมีนาคม และถ้าช้าจะโดนปรับนาทีละ 20,000 ดอลลาร์ ก็ไม่อาจมาพูดในเดือนกุมภาพันธ์ได้ว่า “มีเรื่องไม่คาดคิดเกิดขึ้น เลยทำไม่ได้แล้ว” ควรเซ็นรับงานก็ต่อเมื่อมั่นใจว่าทำได้เท่านั้น
Ford หรือ NASA จะไม่แปลกใจเลยแม้การทำใบเสนอราคาจะมีต้นทุน หลายหมื่นดอลลาร์ พวกเขาจะออก ECO และแม้จะเป็นชิ้นส่วนที่ดูเหมือนทำด้วยมือแค่ 30 นาทีก็เสร็จ แต่ถ้าต้องใช้ 3 สัปดาห์กับ 8,000 ดอลลาร์ พวกเขาก็รู้ว่านั่นรวมความเสี่ยงด้านกำหนดส่ง ขั้นตอนรับมอบ ขั้นตอนตรวจสอบ และแผนฉุกเฉินไว้แล้ว
แต่ถ้าในกลุ่ม modernization ของ OP ไปบอกว่า “ข้อมูลยังไม่ครบ เลยเป็นไปได้ว่างานเปลี่ยนข้อความบนปุ่มที่ใช้เวลา 30 นาที อาจกินเวลาสูงสุด 3 สัปดาห์และ 8,000 ดอลลาร์” ก็คงถูกไล่ออกนอกประตูทันที การประเมินแบบมองโลกสวยได้รับรางวัล การประเมินแบบมองโลกแย่ถูกกดไว้ และการประเมินที่แม่นยำก็กลายเป็นเรื่องไม่สำคัญ สุดท้ายก็เลยช้ากว่ากำหนดอยู่เสมอ และแทบไม่มีใครแปลกใจ
งานบำรุงรักษาอาจรวมถึงการเปลี่ยนฮาร์ดแวร์ การอัปเกรดระบบปฏิบัติการ และการรองรับฟีเจอร์ใหม่ ๆ เคยเห็นโครงการที่เดินขนานกันแบบนี้นานเกิน 10 ปีก็มี
ในปี 1505 Michelangelo ประเมินว่าจะใช้เวลา 5 ปี ในการสร้างสุสานของ Pope Julius II ให้เสร็จ
แต่เพราะมีงานเสริมเล็ก ๆ อย่างการวาดเพดาน Sistine Chapel เลยใช้เวลาจริงประมาณ 40 ปี
เขาไม่สามารถทำตามเดดไลน์ที่ตั้งจากค่าประมาณได้ และขอบเขตโครงการก็ถูกลดลงอย่างมาก เพราะ Pope Julius II เสียชีวิตก่อนงานเสร็จ อีกทั้งยังมีคำขอเปลี่ยนแปลงจากลูกค้าอย่าง Julius และทายาท ปัญหาซัพพลายเชน การเจรจาสัญญาใหม่ ข้อพิพาทแรงงาน การขาดแคลนแรงงานมีฝีมือ และเงินทุนที่ร่อยหรอเพราะโครงการยืดเยื้อ
ดังนั้นอย่างน้อยเรื่องแบบนี้ก็มีมาตั้งแต่ปี 1505 แล้ว ที่น่าขำคือสุดท้ายพระสันตะปาปาก็ไม่ได้ถูกฝังในสุสานนั้นด้วย
ช่วงต้นอาชีพได้เรียนรู้อย่างหนึ่งที่สำคัญมากว่า ตัวเลขแรกที่เราพูดออกไป มักจะติดอยู่ในความทรงจำของคน
น่าเสียดายที่ในความเป็นจริงก็มักเป็นแบบนั้น และคนจะพูดซ้ำ ๆ ว่า “ตอนแรกไม่ได้บอกว่า X เหรอ?” คำว่า “ใช่ แต่เราได้ข้อมูลใหม่แล้ว” ก็ไม่ได้ใช้ได้ผลเสมอไป
คนที่รู้เรื่องนี้ก็อาจเกิดผลข้างเคียงคือพยายามหลีกเลี่ยงการให้ตัวเลขตั้งแต่แรก
Scotty: “แน่นอนครับกัปตัน แบบนั้นถึงจะรักษาชื่อเสียงว่าเป็นคนสร้างปาฏิหาริย์ได้”
เช่น จากวัน→สัปดาห์, สัปดาห์→เดือน, เดือน→ไตรมาส ถ้างานดูเหมือนใช้เวลา 1 วัน ก็จะบอกว่า 3 สัปดาห์ ฟังดูเยอะ แต่สุดท้ายก็มักลงเอยประมาณนั้นเพราะระบบราชการ ขั้นตอน และหนี้ทางเทคนิค
มีช่วงหนึ่งที่บอกว่า “นึกภาพออกไหมว่าบริษัทประกันไปเถียงกับอู่ซ่อมว่าเดิมประเมินไว้ 18,000 ดอลลาร์ เลยจะไม่ยอมจ่ายเพิ่มอีก 20,000 ดอลลาร์? ฟังดูไร้สาระใช่ไหม? ผมก็คิดแบบนั้น โชคดีที่โลกจริงไม่ได้ทำงานแบบนั้น” แต่ในวงการประกัน เรื่องแบบนั้นเกิดขึ้นตลอด
ไม่ใช่แค่ประกันรถยนต์หรือบ้าน แต่ ประกันสุขภาพ ก็เหมือนกัน บ่อยครั้งก็เจรจากันจนได้จุดที่พอรับได้ แต่ไม่เสมอไป จึงน่าแปลกใจกับน้ำเสียงที่มั่นใจว่า “โลกจริงไม่ได้ทำงานแบบนั้น”
ถึงการตีเป็นความเสียหายสิ้นเชิงอาจจะแพงกว่า แต่เพดานชัดเจนและปิดเคลมได้ บริษัทประกันไม่ชอบเคลมที่เปิดค้างไว้
อย่างหลัง ซึ่งในประกันรถยนต์บางครั้งเรียกว่า “preferred rate” คือข้อตกลงแบบครอบคลุมว่าจะแจ้งค่าใช้จ่ายงานบางประเภทตามอัตราที่ต่อรองคงที่ไว้
นี่ต่างจากใบเสนอราคาแบบผูกมัดอย่างมาก ใบเสนอราคาแบบผูกมัดมักเป็นราคาครั้งเดียวสำหรับงานเฉพาะ และผู้ประเมินเป็นฝ่ายรับความเสี่ยงว่าจะทำให้เสร็จในราคานั้น แม้งานจริงจะซับซ้อนกว่าที่คาดมากก็ตาม
ถ้าทำได้ เคล็ดลับอย่างหนึ่งคือประเมินเฉพาะ ขอบเขตที่ตายตัว เสมอ และตัดสิ่งที่ยังไม่รู้ซึ่งไม่อาจคาดเดาได้ออกไป
อย่าประเมินว่า “ทำฟีเจอร์ X” แต่ให้ประเมิน “เอนจินของฟีเจอร์ X” ถ้าพบงานเพิ่ม ก็ให้บวกเข้าไปเป็น milestone ที่ค้นพบใหม่ เช่น “รีแฟกเตอร์โค้ดเดิม” หรือ “รวมฟีเจอร์ X+Y”
แต่แนวทางการตั้งชื่อนี้และความเข้าใจนี้ต้องถูกส่งต่อขึ้นไปด้วยถึงจะได้ผล ถ้ามีใครเอา milestone ชื่อ “เอนจินของฟีเจอร์ X” ไปเปลี่ยนเป็น “ฟีเจอร์ X เสร็จสมบูรณ์” โดยใช้ค่าประเมินเดิม ก็จบเห่
เคยเจอปัญหาที่เกี่ยวข้องกันด้วย คือฝ่ายผู้นำมองว่า deadline เป็น “แรงจูงใจ” เหมือนคนที่อยากให้บ้านอุ่นถึง 72F แล้วไปตั้ง thermostat เป็น 80F เพื่อให้ “มันเร็วขึ้น”
ครั้งหนึ่งฉันซึ่งเป็นวิศวกรระดับล่างถูกเชิญเข้าประชุมฝ่ายบริหาร แต่ผู้เข้าร่วมคนอื่นลืมไปว่าฉันอยู่ตรงนั้น มีคนหนึ่งยอมรับว่าการให้ทัน deadline X นั้นยากมาก และถามว่าควรเลื่อนไปเป็นวันที่สมจริงกว่านี้ไหม PM อาวุโสตอบว่า “เราไม่เลื่อน deadline เด็ดขาด! ฝั่งวิศวกรรมจะใช้เวลาที่ให้ไปจนหมดอยู่แล้ว!”
ในกรณีนั้น ฝั่งวิศวกรรมก็ “คืนเวลา” ให้ตอนที่ฉันลาออกจากทีมนั้น
และก็เป็นความจริงว่าหลายทีมวิศวกรรมจะใช้เวลาที่ได้รับไปจนหมด
แต่ผู้จัดการควรทำให้องค์กรเตรียมรับมือการเกินแผน แทนที่จะทำให้ estimate กับ plan กลายเป็น deadline แข็ง ๆ ต่อหน้าวิศวกร เมื่อใกล้ถึงเวลาที่คาดว่าจะเสร็จ ถ้านักพัฒนาสามารถอธิบายได้ว่าส่วนไหนใช้เวลานานกว่าที่คิดและเพราะอะไร ก็ควรรับฟังอย่างสมเหตุสมผล
ผู้จัดการยังต้องทำให้ลูกค้า ฝ่ายขาย และผู้บริหารระดับบนไม่ปฏิบัติกับเวลาที่วางแผนไว้ว่าจะเสร็จเหมือนเป็น deadline หากจำเป็นต้องให้คำมั่น deadline ที่สื่อสารกับลูกค้าควรอยู่หลังเวลาคาดว่าจะเสร็จจริงพอสมควร
แม้แต่หม้อน้ำไฟฟ้าก็อาจมีผลจริงในทางปฏิบัติ เพราะมันจะไม่ดับทันทีเพียงแค่อากาศใกล้หม้อน้ำอุ่นขึ้น
หลังจากเจอเหตุการณ์ที่ “การประเมินแบบกะ ๆ เอา” มากเกินไปถูกเปลี่ยนเป็น deadline แบบแข็ง ฉันก็ผลักดันแนวทาง No Estimates กับผู้มีส่วนได้ส่วนเสียมาตลอด
ตอนแรกแน่นอนว่ามีแรงต้าน เพื่อคลายความกังวล การอธิบายว่าการประเมินที่แม่นพอจะเอาไปใช้วางแผนอย่างถูกต้องได้นั้น แท้จริงแล้วทำได้แค่สองกรณี มักช่วยได้
A) เมื่องานที่เหลือแทบเป็นการทำซ้ำของงานในอดีต เช่น การ provision ดาต้าเซ็นเตอร์ที่สองของระบบเดียวกัน
B) เมื่อทีมเห็นว่างานฟีเจอร์ใหม่ที่เหลืออยู่เข้าสู่ช่วงควอไทล์สุดท้ายแล้ว และมีการนิยามชัดเจนรวมถึงความเสี่ยงที่ยังเหลือซึ่งอาจขัดขวางความสำเร็จ
micro-estimate เปิดทางให้เกิด micromanagement ได้ ทีมที่แข็งแรงจะหางานที่มีลำดับความสำคัญสูงสุดโดยดูจากความเสี่ยงต่อความสำเร็จของโปรเจกต์ แล้วทำตามลำดับจากสูงไปต่ำ
0 - https://www.youtube.com/watch?v=MhbT7EvYN0c
1 - https://www.goodreads.com/book/show/30650836-noestimates
มีสูตรตลก ๆ ที่เคยเห็นใน HN มาก่อนแล้วสะดุดตา มันดูอลังการและเท่มาก แต่เหมือนวิธีประเมินอื่น ๆ ตรงที่ไม่มีความสมเหตุสมผลเชิงรูปแบบ เป็นแค่ สูตรที่ตั้งขึ้นตามอำเภอใจ จากประสบการณ์ส่วนตัว
https://news.ycombinator.com/item?id=37965582
คณิตศาสตร์การประเมินของฉัน: R = t × [1.1^ln(n+p) + 1.3^X]
R คือเวลาจริงที่ใช้, t คือเวลาสั้นที่สุดที่เป็นไปได้ถ้าไม่ต้องสื่อสาร, n คือจำนวนคนที่เกี่ยวข้องในกระบวนการรวมลูกค้าและองค์กรพัฒนา, p คือระยะทางการสื่อสารที่ยาวที่สุดในโปรเจกต์, X คือจำนวนเครื่องมือ/ไลบรารี/เทคนิคใหม่ที่ใช้ในกระบวนการ
ตัวอย่างเช่น ถ้าโปรเจกต์ที่นักพัฒนาหนึ่งคนเขียนโค้ดใช้เวลา 2 สัปดาห์ (t=2), มีคนเกี่ยวข้องทั้งหมด 5 คน (n=5), มีเครื่องมือใหม่ 1 อย่าง (X=1), และระยะทางการสื่อสารที่ยาวที่สุดคือ 4 ก็จะได้ 2×(1.1^ln(5+4) + 1.3^1) = 4.5 สัปดาห์
ควรบวกปริมาณ X สำหรับทั้งสิ่งที่รู้ว่าไม่รู้ และ สิ่งที่ไม่รู้ว่าไม่รู้ ด้วย
น่าเศร้าที่การประเมินคือการต่อรอง คนที่พูดตัวเลขออกมาก่อนมักจะแพ้เพราะอีกฝ่าย “ทำหน้าบึ้ง”
“ประเมินไว้เท่าไหร่?” “ยังไม่แน่ใจครับ/ค่ะ” “เอาแบบคร่าว ๆ ก็ได้”
“งั้นคุณอยากได้ภายในเมื่อไหร่ล่ะ?”
นี่คือกับดักที่ผู้จัดการมือใหม่ตกกันทุกครั้ง ถ้าคุณให้คำตอบไปก็ bingo เลย จากนั้นอีกฝ่ายก็จะ “ทำหน้าบึ้ง” หายใจเข้าลึก ๆ แล้วพูดพร้อมทำหน้ามุ่ยว่า “อ๋อ นั่นไม่สมจริงเลย ตัวเลขนั้นมาจากไหนกัน?” ก่อนจะเสนอเวลาที่มากกว่านั้นหลายเท่าหรือไม่ก็ลดขอบเขตงาน เช่น “โอ้ ถ้าจะเอาให้ทันเวลานั้นก็คงต้องดวงดีมาก ๆ และต้องตัดฟีเจอร์ Y จากโปรเจ็กต์อื่น ถึงจะทำฟีเจอร์ X ได้อย่างเดียว”
ไม่ว่าคุณจะทำอย่างไร สิ่งสำคัญคืออย่าเป็นฝ่ายให้ตัวเลขก่อน ต้องใช้เวลานิดหน่อยกว่าจะจับจังหวะได้ เหมือนเล่นโป๊กเกอร์หรือซื้อรถ เวลาในบริษัทใหญ่ก็เป็นเงินเหมือนกัน และควรถูกปฏิบัติแบบนั้น เกมผลรวมศูนย์
ที่ที่ฉันทำงานอยู่ การประเมินเวลาถูกกดให้ต่ำลงเรื่อย ๆ ในนามของประสิทธิภาพ และยังไม่อนุญาตให้มีงานค้างยกไปด้วย
ฉันอยู่ในสภาพเกือบ crunch มานานกว่าหนึ่งปีโดยแทบไม่มีเวลาฟื้นตัวเลย เอาแต่หวังว่ามันจะดีขึ้น แต่ดูเหมือนกลับแย่ลงเรื่อย ๆ แถมทุกคนยังถูกสับเปลี่ยนไปยังส่วนอื่นของผลิตภัณฑ์ตลอดเวลาโดยไม่มีทางเลือก ตอนนี้ยังฝืนไปต่อได้อยู่ แต่รู้สึกหมดไฟทางใจอย่างสิ้นเชิง