นั่งอ่านหนังสือเกี่ยวกับการพัฒนา 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 ตามที่ต้องการ
โยกคนไปมาตามใจต้องการ
ใครว่างก็เอาเข้ามาทำไป
เน้นแต่จำนวน แต่ไร้คุณภาพ

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