ว่าด้วยเรื่องของ Project ที่ล้มเหลว

นั่งอ่านหนังสือเกี่ยวกับการพัฒนา software มีเรื่องที่น่าสนใจคือ สาเหตุที่ทำให้ project มันล้มเหลวหรือ fail มาจากหลายสาเหตุมาก ๆ เลยสรุปไว้นิดหน่อย บางครั้งมีงานออกมาดีมาก แต่ทีมแตกกระจาย บางครั้งไม่มีงานออกมา แต่ทีมดีมาก บางครั้งทีมแย่และงานก็แย่ คำถามคือ คำว่าล้มเหลววัดจากอะไร ?

ปล. ปกติเราน่าจะทำ product มากกว่า project กันอยู่แล้ว ดังนั้นไม่น่าจะ fail กันมากหรอก ใช่ไหมนะ

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

สาเหตุแรกคือ ขอบเขตของงานไม่ชัดเจน หนักกว่านั้นคือไม่มีเลย

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

หรือทำไปสักครึ่งทาง แล้วมาบอกว่าเปลี่ยนใหม่เถอะ !! เปลี่ยนอีกแล้วหรอ ? เพิ่งเปลี่ยนไปเมื่อเช้าเองนะ !!

สาเหตุที่สองคือ แก้ไขปัญหาผิดเรื่อง

ถ้างานที่ทำนั้นชัดเจนมาก ๆ แต่สิ่งที่กำลังทำนั้น ดันไปแก้ไขปัญหาผิดเรื่อง นั่นคือ คนใช้งานน้อยหรือไม่มีคนใช้งานนั่นเอง คำถามคือ งานที่ทำน่าจะล้มเหลวใช่ไหม ?  

สาเหตุที่สามคือ มีการสื่อสารที่แย่

ยิ่งองค์กรที่มีความซับซ้อนมาก ๆ ยิ่งต้องมีการพูดคุยกับหลายฝ่าย ทั้งภายในและภายนอก ส่งผลให้เกิดข้อผิดพลาดหรือเข้าใจผิดมากมาย

สาเหตุที่สี่คือ แต่ละคนไม่สนใจงานอื่น ๆ นอกจากงานของตัวเอง

เมื่อเกิดปัญหาขึ้นมา แต่ละคนจะโทษกันไปกันมา เช่น Backend team จะไปโทษ frontend team Frontend team จะไปโทษคนออกแบบ คนออกแบบจะไปโทษคนให้ requirement คนให้ requirement จะไปโทษ business Business จะไปโทษ .... คำถามคือ ใครผิด ? เมื่อเป็นเช่นนี้ก็ทำให้ไม่มีใครอยากจำทำอะไร เสียทั้งเวลาและความรู้สึก

สาเหตุที่ห้าคือ เอกสารแย่มาก ๆ

เอกสารที่มีไม่สามารถ tracking อะไรได้เลย ว่า requirement เป็นอย่างไร ตรวจรับอย่างไร ออกแบบอย่างไร พัฒนาอย่างไร ทดสอบอย่างไร Deploy อย่างไร เมื่อเกิดปัญหาขึ้นมาแล้ว กระทบอะไรส่วนไหนบ้าง หนักกว่านั้น ไม่ทำการ update ให้เป็นล่าสุดเลย แต่ต้องทำ เพราะอะไรกันนะ ถ้าให้เลือกระหว่าง code กับเอกสาร คุณจะเชื่อหรือเลือกอะไร ?

สาเหตุที่หกคือ เตรียมการแย่มาก ๆ

ทั้งเรื่องของ requirement ทั้งเรื่องของ system ทั้งเรื่องของการวางแผน ทั้งเรื่องของ infrastructure ทั้งเรื่องของ environment หนักกว่านั้นคือ เรื่องของทีม ที่ไม่มี skill ตามที่ต้องการ โยกคนไปมาตามใจต้องการ ใครว่างก็เอาเข้ามาทำไป เน้นแต่จำนวน แต่ไร้คุณภาพ

เอาเท่านี้ดีกว่า ยังมีเรื่องอะไรอีกนะ !!