เบื้องหลังการประเมินราคาซอฟต์แวร์ และทำไมส่วนใหญ่ถึงคลาดเคลื่อน

จากการศึกษาโปรเจกต์ IT จำนวน 1,471 โปรเจกต์โดย Bent Flyvbjerg และ Alexander Budzier แห่ง Oxford ค่าเฉลี่ยงบบานปลายอยู่ที่ 27% ฟังดูพอรับได้ แต่ตัวเลขที่ซ่อนอยู่ข้างใต้นั้นน่ากลัวกว่ามาก คือ 1 ใน 6 ของโปรเจกต์เหล่านั้นเป็น "Black Swan" ที่งบบานปลายถึง 200% และเลยกำหนดเวลาเกือบ 70% ใบเสนอราคาไม่ได้แค่คลาดเคลื่อนเล็กน้อย แต่จำนวนไม่น้อยถึงขั้นระเบิด

ดังนั้นเมื่อมีคนยื่นตัวเลขสำหรับโปรเจกต์ซอฟต์แวร์ให้คุณ คำถามที่ตรงไปตรงมาไม่ใช่ "ราคานี้เหมาะสมไหม" แต่คือ "ตัวเลขนี้สร้างขึ้นมาอย่างไร และจะยังอยู่รอดเมื่อเจอความเป็นจริงหรือไม่" มาเปิดม่านดูกัน

ใบเสนอราคาส่วนใหญ่คลาดเคลื่อน และข้อมูลก็โหดร้าย

งานวิจัย CHAOS ของ Standish Group พบว่ามีเพียงราว 16% ของโปรเจกต์ซอฟต์แวร์ที่ส่งมอบตรงเวลา ไม่เกินงบ และครบตามขอบเขตที่ตกลงไว้ ราวครึ่งหนึ่งตกอยู่ในกลุ่ม "challenged" คือล่าช้า เกินงบ หรือแอบขาดฟีเจอร์ ส่วนที่เหลือถูกยกเลิกไปเลย

ลองอ่านอีกครั้ง โอกาสที่ใบเสนอราคาซอฟต์แวร์จะแม่นยำนั้นใกล้เคียงกับการโยนเหรียญให้ตั้งบนขอบมากกว่าจะเป็นเรื่องแน่นอน ไม่ใช่เพราะนักพัฒนาสะเพร่า แต่เพราะการประเมินสิ่งที่ยังไม่รู้นั้นยากจริง และสมองมนุษย์ถูกออกแบบมาให้ทำเรื่องนี้ได้ไม่ดี

Planning Fallacy: สมองของคุณคือบั๊ก

ในปี 1979 Daniel Kahneman และ Amos Tversky ตั้งชื่อให้กับต้นเหตุนี้ว่า planning fallacy คือแนวโน้มเชิงระบบที่จะประเมินเวลา ต้นทุน และความเสี่ยงต่ำเกินไป ขณะเดียวกันก็ประเมินผลประโยชน์สูงเกินไป ที่โหดร้ายคือมันสลัดทิ้งได้ยาก อคตินี้เกิดขึ้นข้ามวัฒนธรรม ข้ามระดับประสบการณ์ และข้ามบุคลิกภาพ และยังคงอยู่แม้คุณจะรู้ตัวแล้วก็ตาม การถามนักพัฒนาที่มองโลกในแง่ดีว่า "แน่ใจนะ" ไม่ได้ช่วยอะไร เพราะเขามั่นใจตั้งแต่ครั้งแรกแล้ว

ทำไมถึงเป็นเช่นนั้น เพราะเราประเมินจากโปรเจกต์ในจินตนาการ ที่ความต้องการชัดเจน ไม่มีใครป่วย API มีเอกสารถูกต้อง และลูกค้าอนุมัติร่างแรกทันที แต่ความเป็นจริงส่งมอบโปรเจกต์คนละแบบ ทีมงานเปลี่ยน ลำดับความสำคัญเปลี่ยน การเชื่อมต่อที่ "ง่าย ๆ" กลับมี edge case ที่ไม่มีในเอกสารถึงสามจุด ใบเสนอราคาอธิบายโปรเจกต์ที่ไม่มีอยู่อีกแล้วตั้งแต่สัปดาห์ที่สอง

ใบเสนอราคาที่แท้จริงสร้างขึ้นมาอย่างไร

ใบเสนอราคาที่เชื่อถือได้ไม่ใช่ตัวเลขเดียวที่มั่นใจแล้วหยิบมาจากอากาศ แต่คือกระบวนการที่แปลงปัจจัยตั้งต้นที่ยุ่งเหยิงสี่อย่างให้กลายเป็นตัวเลขที่อธิบายได้:

• ขอบเขต (Scope) ทุกหน้าจอ ทุก endpoint และทุก flow ของแอดมินถูกเขียนลงไว้ ขอบเขตที่คลุมเครือคือต้นเหตุใหญ่ที่สุดของงบบานปลาย เพราะทุกอย่างที่ไม่ได้เขียนไว้จะถูกสมมติว่าไม่มี
• สิ่งที่ยังไม่รู้ (Unknowns) รายการตามตรงของสิ่งที่เรายังไม่รู้ ผู้ประเมินที่ดีตีราคาสิ่งที่ยังไม่รู้อย่างชัดเจน แทนที่จะแกล้งทำเป็นว่ามันเท่ากับศูนย์
• ความซับซ้อน (Complexity) ฟอร์มล็อกอินกับระบบ billing หลายสกุลเงินแบบเรียลไทม์ไม่ใช่รายการเดียวกัน แม้ทั้งคู่จะเรียกว่า "ฟีเจอร์"
• ความเสี่ยง (Risk) API ของบุคคลที่สาม ความต้องการที่ไม่ชัดเจน และกำหนดส่งที่ตึง ต่างก็มี buffer ของตัวเอง ปรับขนาดตามความเสี่ยงจริง ไม่ใช่เปอร์เซ็นต์คงที่ที่ตั้งบนความหวัง

แต่ละฟีเจอร์จะได้ช่วงราคาของตัวเอง ไม่ใช่จุดเดียว นำช่วงเหล่านั้นมารวมกัน รายการที่เสี่ยงแบกสำรองของตัวเอง และผลลัพธ์ถูกแจกแจงให้คุณเห็นว่าทุกชั่วโมงไปอยู่ที่ไหน เมื่อตัวเลขสร้างมาแบบนี้ คุณตรวจสอบมันได้ แต่ถ้ามันเป็นตัวเลขกลม ๆ ตัวเดียวที่ไม่มีรายละเอียด คุณตรวจไม่ได้ และนั่นมักเป็นสัญญาณเตือน

ที่ True Dev เราทำอย่างไร

เราสร้างซอฟต์แวร์มาตั้งแต่ปี 1997 และรูปแบบเบื้องหลังใบเสนอราคาที่บานปลายทุกครั้งก็เหมือนกัน คือมีคนเดาแทนที่จะแยกย่อยงานออกมา เราจึงปฏิเสธที่จะเดา ทุกใบเสนอราคาที่เราส่งจะแจกแจงตามฟีเจอร์ มีขอบเขตเขียนไว้ มีสิ่งที่ยังไม่รู้พูดออกมาตรง ๆ และตีราคาความเสี่ยงตรงจุดที่มันอยู่จริง จากนั้นเราผูกมัดด้วยใบเสนอราคาแบบ fixed price เพื่อให้สำรองเป็นเรื่องที่เราต้องบริหารเอง ไม่ใช่เซอร์ไพรส์ที่ส่งต่อให้คุณภายหลัง

นั่นคือเหตุผลที่ขั้นตอน เริ่มโปรเจกต์ ของเราถามคำถามที่อาจน่ารำคาญเล็กน้อยตั้งแต่ต้น ทุกสิ่งที่ยังไม่รู้ที่เราคลี่คลายก่อนเสนอราคา คือสิ่งที่จะไม่กลายเป็น Black Swan 200% กลางทาง ใบเสนอราคาที่ดีไม่ใช่คำสัญญาว่าจะไม่มีอะไรผิดพลาด แต่คือหลักฐานว่าเราคิดถึงสิ่งที่อาจผิดพลาดไว้แล้ว คุณเห็นได้ว่าสิ่งนี้ทำงานอย่างไรใน บริการ ของเรา ที่งานถูกกำหนดขอบเขต โปร่งใส และตีราคาแบบเป็นกระบวนการ ไม่ใช่การภาวนา