เกือบ 1 ใน 5 ของโปรเจกต์ซอฟต์แวร์ หรือ 19 เปอร์เซ็นต์ ถูกยกเลิกทิ้งก่อนที่จะได้ส่งมอบเสียด้วยซ้ำ ตัวเลขนี้มาจากงานวิจัย CHAOS ของ Standish Group ที่ติดตามโปรเจกต์นับหมื่นมานานสามทศวรรษ และแทบไม่เปลี่ยนแปลงเลยตั้งแต่ยุค 1990 หากรวมโปรเจกต์ที่คลานเข้าเส้นชัยช้ากว่ากำหนด เกินงบ และฟีเจอร์หายไปครึ่งหนึ่งด้วย ภาพยิ่งหดหู่ขึ้น การวิเคราะห์ CHAOS ปี 2020 ของโปรเจกต์ราว 50,000 โปรเจกต์พบว่า 66 เปอร์เซ็นต์จบลงด้วยความล้มเหลวบางส่วนหรือทั้งหมด
ดังนั้นถ้าคุณกำลังนั่งมองโปรเจกต์ที่ค้างอยู่ ที่เงินหมด หรือที่นักพัฒนาคนเดิมเดินจากไปเฉยๆ สิ่งแรกที่ควรรู้คือ คุณไม่ใช่ข้อยกเว้น คุณคือค่าปกติทางสถิติ และสิ่งที่สองที่ควรรู้คือ ความล้มเหลวแทบไม่เคยหมายความว่าไร้ค่า
## ตัวเลขที่ไม่มีใครใส่ในสไลด์ขายงาน
เม็ดเงินที่เกี่ยวข้องนั้นน่าตกใจจริงๆ Consortium for Information and Software Quality ประเมินว่าความล้มเหลวในการพัฒนาซอฟต์แวร์ทำให้สหรัฐฯ เสียหายถึง 260 พันล้านดอลลาร์เฉพาะปี 2022 ปีเดียว โดยมีความล้มเหลวด้านการใช้งานซอฟต์แวร์เพิ่มอีก 1.81 ล้านล้านดอลลาร์ซ้อนเข้าไป เพื่อให้เห็นภาพ ตัวเลขรวมนี้มากกว่างบกลาโหมทั้งหมดของสหรัฐฯ ในปีเดียวกันเสียอีก
อีกตัวเลขที่สำคัญสำหรับทุกคนที่อยู่กลางทางของการพัฒนาคืออัตราการลาออก บริษัท outsourcing มีอัตราการลาออกของพนักงานเฉลี่ยราว 20 เปอร์เซ็นต์ต่อปี และการหมุนเวียนนี้ส่งผลกระทบต่อโปรเจกต์ที่กำลังดำเนินอยู่ราว 40 เปอร์เซ็นต์ แปลง่ายๆ คือ นักพัฒนาที่เริ่มโปรเจกต์ของคุณ มีโอกาสน้อยทางสถิติที่จะเป็นคนเดียวกับที่ปิดงาน แม้ว่าจะไม่มีการเปลี่ยนผู้รับเหมาก็ตาม การเปลี่ยนนักพัฒนากลางคันไม่ใช่เรื่องโชคร้ายที่เกิดขึ้นนานๆ ครั้ง แต่มันถูกฝังอยู่ในวิธีที่อุตสาหกรรมนี้ทำงาน
## อะไรกู้ได้ และอะไรกู้ไม่ได้
นี่คือส่วนที่ทำให้หลายคนประหลาดใจ เมื่อเราเปิดฝากระโปรงดูโปรเจกต์ที่ล้มเหลว คำตัดสินแทบไม่เคยเป็นแบบ "ทั้งหมดหรือไม่มีเลย"
Database schema และ business logic มักเป็นส่วนที่รอดและมีค่าที่สุด มีคนใช้เวลาหลายเดือนเรียนรู้โดเมนของคุณ เคสพิเศษของคุณ กฎการตั้งราคาของคุณ และความรู้นั้นถูกเข้ารหัสไว้ในตารางและฟังก์ชัน ไม่ว่าโค้ดรอบๆ จะเรียบร้อยหรือไม่ ส่วนที่ยากที่สุดของทุกโปรเจกต์ คือการเข้าใจว่าซอฟต์แวร์ควรทำอะไรจริงๆ มักจ่ายเงินไปแล้ว
สิ่งที่มักรอดได้ไม่ดีนัก คือ UI ที่ทำค้างไว้บน framework ที่ถูกทิ้งไปแล้ว ระบบ authentication และ payment ที่ต่อเชื่อมแบบไม่ปลอดภัย และอะไรก็ตามที่ยึดไว้ด้วยสมมติฐานในหัวของคนคนเดียวที่ไม่มีเอกสารบันทึก กฎคร่าวๆ ที่ตรงไปตรงมาคือ ยิ่งสิ่งใดอยู่ใกล้ข้อมูลและโดเมนของคุณ ยิ่งมีโอกาสคุ้มที่จะเก็บไว้ ยิ่งใกล้กับเทรนด์และตัวเลือก framework ยิ่งมีโอกาสถูกแทนที่
## การรับช่วงต่ออย่างตรงไปตรงมาเป็นอย่างไร
สัญชาตญาณเมื่อโปรเจกต์ล้มเหลว คือเรียกร้องให้สร้างใหม่ตั้งแต่ศูนย์ มันรู้สึกสะอาดดี แต่ก็มักเป็นการตัดสินใจที่ผิด เพราะมันทิ้งความรู้โดเมนที่รอดมาได้ และรีเซ็ตนาฬิกากลับไปที่ศูนย์
การกู้ที่แท้จริงเริ่มจากการตรวจสอบ ไม่ใช่การรื้อทิ้ง เราอ่านโค้ด รันมัน เทียบสิ่งที่ทำงานได้จริงกับสิ่งที่อ้างว่าทำงานได้ และตรวจความปลอดภัยของทุกอย่างที่เกี่ยวกับเงินหรือข้อมูลส่วนบุคคล จากนั้นเท่านั้นจึงจะบอกคุณได้อย่างตรงไปตรงมาว่ากู้ได้กี่เปอร์เซ็นต์ บางครั้งคือ 70 เปอร์เซ็นต์ และโปรเจกต์กลับเข้าที่ภายในไม่กี่สัปดาห์ บางครั้งคือ 20 เปอร์เซ็นต์ และสิ่งที่ใจดีที่สุดที่เราพูดได้คือ ความต้องการของโปรเจกต์นั้นมีค่า แม้โค้ดจะไม่มี ไม่ว่าทางใด คำตอบมาจากการดูจริง ไม่ใช่จากสัญชาตญาณการขาย
## มุมมองของ True Dev
เราสร้างซอฟต์แวร์มาตั้งแต่ปี 1997 และงานส่วนสำคัญของเราคือการรับช่วงต่อโปรเจกต์ที่นักพัฒนาคนอื่นทิ้งไว้ เราเรียนรู้ที่จะต้านสัญชาตญาณการสร้างใหม่ เพราะลูกค้าที่เสียเงินไปกับงานที่ล้มเหลวแล้วครั้งหนึ่ง ไม่จำเป็นต้องเสียเพิ่มเพื่อพิสูจน์อะไร
ดังนั้นคำสัญญาของเราในการกู้โปรเจกต์จึงไม่หรูหรา คือการตรวจสอบอย่างตรงไปตรงมาก่อน เราจะบอกคุณว่าอะไรคุ้มที่จะกู้และอะไรไม่คุ้ม แม้ในเวลาที่ "เก็บไว้" จะเป็นคำตอบที่ทำกำไรให้เราน้อยกว่า โปรเจกต์ที่ล้มเหลวเป็นเรื่องปกติ แทบไม่เคยถึงตาย และเกือบทุกครั้งสมควรได้รับความเห็นที่สองก่อนที่ใครจะเอื้อมไปกดปุ่มลบ
ถ้าคุณกำลังจ้องมองโปรเจกต์ที่ค้างอยู่ [เริ่มคุยกับเรา](/th/เริ่มโปรเจกต์) แล้วเราจะให้คำอ่านที่ตรงไปตรงมา คุณยังดู [บริการทั้งหมดของเรา](/th/บริการ) ได้ ตั้งแต่การกู้โปรเจกต์ไปจนถึงการสร้างจากศูนย์
เกือบ 1 ใน 5 ของโปรเจกต์ถูกยกเลิก แต่ของคุณไม่จำเป็นต้องเป็นหนึ่งในนั้น
แบ่งปันบทความนี้:
