ทำไมโปรเจกต์ซอฟต์แวร์ถึงล้มเหลว — สิ่งที่ฆ่ามันจริง ๆ

นี่คือตัวเลขที่เจ้าของธุรกิจทุกคนควรหยุดคิดสักครู่ก่อนเซ็นสัญญาจ้างพัฒนาซอฟต์แวร์: ตลอดสามทศวรรษกว่าของงานวิจัย CHAOS โดย Standish Group มีโปรเจกต์ซอฟต์แวร์เพียงราว 31% เท่านั้นที่ส่งมอบได้สำเร็จ ประมาณครึ่งหนึ่งล่าช้า เกินงบ หรือขาดฟีเจอร์ ส่วนที่เหลืออีกราว 19% ถูกยกเลิกไปเลย — จ่ายเงินไปแล้ว แต่ไม่ได้อะไรกลับมา

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

เงินหายไปในแบบที่คาดเดาได้

McKinsey ร่วมกับ BT Centre for Major Programme Management ของ Oxford ศึกษาโปรเจกต์ IT กว่า 5,400 โปรเจกต์ ผลลัพธ์หลัก: โดยเฉลี่ย โปรเจกต์ IT ขนาดใหญ่ใช้งบเกิน 45% และใช้เวลาเกิน 7% ขณะที่ส่งมอบคุณค่าน้อยกว่าที่คาดไว้ถึง 56% อ่านส่วนสุดท้ายอีกครั้ง แม้แต่โปรเจกต์ที่ "เสร็จ" ก็มักส่งมอบคุณค่าได้แค่ครึ่งเดียวของที่สัญญาไว้

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

แทบไม่เคยเป็นปัญหาเรื่องโค้ด

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

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

Scope creep คือปัญหาเรื่องความชัดเจนที่ปลอมตัวมา

ตัวฆ่าที่เชื่อถือได้อีกตัวคือ scope creep และควรพูดให้ชัดว่าทำไมมันถึงแพง ความต้องการที่เปลี่ยนในสัปดาห์แรกใช้เวลาพัฒนาราวหนึ่งชั่วโมง แต่การเปลี่ยนแบบเดียวกันในสัปดาห์ที่แปดอาจแพงกว่าถึงสิบเท่า เพราะทุกอย่างที่สร้างบนสมมติฐานเดิมต้องถูกรื้อออก

แต่ scope creep แทบไม่เคยมาจากความประสงค์ร้ายหรือความลังเล มันมักเป็นอาการของความล้มเหลวที่ต้นน้ำเสมอ: requirements ไม่เคยชัดเจนพอตั้งแต่แรก เป้าหมายที่นิยามไม่ดีติดอันดับสาเหตุความล้มเหลวอันดับต้น ๆ อย่างสม่ำเสมอ — เมื่อไม่มีใครบอกได้ชัด ๆ ว่า "เสร็จ" หน้าตาเป็นอย่างไร เป้าก็เลื่อน และทุกการเลื่อนก็ทบทวีกัน

ข่าวดีที่ซ่อนอยู่ในข้อมูล

นี่คือส่วนที่ให้กำลังใจจริง ๆ requirements ไม่ชัด, scope creep, การสื่อสารที่แย่, ไม่มีเจ้าของที่ชัดเจน — ไม่มีข้อไหนเป็นปัญหาทางเทคนิคที่ยาก ทั้งหมดเป็นปัญหาเรื่อง กระบวนการ และปัญหากระบวนการแก้ไขได้ คุณไม่ต้องใช้อัลกอริทึมล้ำสมัยเพื่อหลบมัน คุณต้องการความชัดเจน จุดตรวจสอบที่ซื่อตรงและบ่อยครั้ง และคนที่รับผิดชอบผลลัพธ์

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

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

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