โปรเจกต์ที่พังสอนเราแพงกว่าโปรเจกต์ที่รอด: การชันสูตรสี่ความล้มเหลวของเราเอง และกระบวนการที่เปลี่ยนไปเพราะมัน

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

เคสหนึ่ง: ระบบที่สมบูรณ์แบบสำหรับกระบวนการที่กำลังจะตาย

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

โปรเจกต์ระบบขายและสต๊อกของธุรกิจค้าส่งรายหนึ่งเดินสวยมากในครึ่งแรก เพราะผู้จัดการทั่วไปของลูกค้าเป็นแชมป์เปี้ยนตัวจริง: ตอบไว ตัดสินใจได้ ผลักทีมตัวเองให้ร่วมทดสอบ แล้ววันหนึ่งเขายื่นใบลาออก สิ่งที่เราค้นพบในสัปดาห์ถัดมาน่ากลัวกว่าการเสียผู้ประสานงาน: ความรู้เรื่องโปรเจกต์ทั้งหมดของฝั่งลูกค้าอยู่ในหัวเขาคนเดียว ข้อตกลงหลายเรื่องเกิดในแชทส่วนตัวระหว่างเขากับเรา ทีมที่เหลือไม่รู้แม้แต่ว่าทำไมบางฟีเจอร์ถึงถูกออกแบบแบบนั้น เจ้าของธุรกิจซึ่งไม่เคยเข้าประชุมเลยตั้งแต่ต้น มองโปรเจกต์นี้เป็นของคนที่เพิ่งลาออก ระบบเสร็จ ถูกใช้แบบครึ่ง ๆ กลาง ๆ อยู่พักหนึ่ง แล้วค่อย ๆ ถูกลืม ความผิดของเราในเคสนี้ชัดเจนเมื่อมองย้อน: เราปล่อยให้โปรเจกต์มีจุดพังจุดเดียว (single point of failure) ทั้งที่เราเขียนเรื่องนี้เตือนลูกค้าคนอื่นอยู่บ่อย ๆ วันนี้เรามีกติกาที่ไม่ยอมข้ามอีกแล้ว: ทุกโปรเจกต์ต้องมีคนของลูกค้าอย่างน้อยสองคนในทุกการประชุมสำคัญ เจ้าของหรือผู้มีอำนาจตัดสินใจต้องปรากฏตัวอย่างน้อยตอนเริ่ม กลางทาง และก่อนส่งมอบ และข้อตกลงทุกข้อถูกสรุปในที่ที่ทีมทั้งสองฝั่งเห็น ไม่ใช่ในแชทของใครคนใดคนหนึ่ง

เคสสาม: ประเมินการย้ายข้อมูลต่ำไปสี่เท่า

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

เคสสี่: เราเก่งเกินไปในห้องประชุม

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