เวลาผ่านไปเกือบ 10 ปี ที่ได้เริ่มตั้งไข่ และค่อย ๆ เดิน ในวงการ “พัฒนาซอฟแวร์”
เริ่มตั้งแต่หัดเขียนโปรแกรม VB.net จนมาถึง C# และจบลงที่ค่าย JavaScript ตลอดเวลาที่เริ่มทำงานมา ก็ทำตามคำสั่งที่ได้รับมอบหมายมาตลอด ไม่แม้แต่จะรู้จัก UX/UI (ก็แหมม มันก็เพิ่งมาบูมเอาช่วงหลังๆ เองนี่หน่า)
จนช่วง 4–5 ปีหลัง ก็ได้มีโอกาสเริ่มเข้าไปเก็บ Requirement ได้ข้องเกี่ยวกับ Business มากขึ้น จนเพิ่งรู้ตัวว่า นี่แหละคือ งานที่ชอบ!
เริ่มสนุกกับการวิเคราะห์ ออกแบบระบบ จนกระทั่งออกแบบ UI และลามปามมายัง UX
ช่วงนี้ก็เก็บ Requirement ไป ออกแบบไป coding ไป ผ่านมาผ่านไปเรื่อย ๆ (ชีวิตก็ออกจะดีนะแก)
สนุกไปวัน ๆ จนเมื่อ “ราว ๆ ต้นปี 2017” ชีวิตก็เปลี่ยนไป เมื่อได้เข้าร่วมอบรม Agile Software Development กับทีมสยามชำนาญกิจ และเปลี่ยน (จากหลังเท้าเป็นหน้ามือ) จนถึงทุกวันนี้……
ด้วยความเบื่อนั่งประเมิน man-day, man-hour จากตัวเลขที่…..ก็มั่ว(อย่างมีหลักการ) ขึ้นมาเนี่ยแหละ ประกอบกับ เมื่อทำงานมาจนอายุประมาณนึง ก็พอจะทราบว่า…..ราคาของการพัฒนา ที่แจ้ง User เกิด จากการคาดคะเน man-day, man-hour จากขอบเขตงาน + ความเสี่ยงที่อาจจะเกิดขึ้น + ค่า commission ของพนักงานขาย + กำไรที่อยากจะได้ จากนั้นทีมพัฒนาจึงดำเนินตามขอบเขตที่ว่านั้น……และแน่นอนเมื่อมีความเบื่อ….จึงมีความคิดที่จะอยากเปลี่ยนแปลงเรื่องของการคิดค่าใช้จ่ายขั้นสุด!!
และนี่คือหลักการ ที่ได้มาจากการอบรม และนำไปล้างสมอง คนหลายกลุ่ม ล้างได้บ้าง ล้างไม่ได้บ้าง…..แต่ก็ยังดีกว่า “ไม่ได้เริ่มทำ”
โดยปกติโครงการพัฒนาซอฟแวร์ส่วนใหญ่จะมีรูปแบบดังรูป
อาจจะเป็นเพราะความไม่เชื่อใจ ไม่ไว้ใจ ระหว่างผู้รับจ้าง และผู้จ้างหรืออย่างไร การพัฒนาซอฟแวร์ในประเทศไทย (ส่วนใหญ่) จะร่างขอบเขตของงาน (TOR) ขึ้นมาก่อน โดยบางทีมันไม่ใช่แค่ร่าง มันมีรายละเอียด ที่แทบจะเปลี่ยนแปลงได้ยาก และนี่แหละคือ “SCOPE” ที่ถูก Fix มาแล้ว……และเมื่อเริ่มพัฒนาซอฟแวร์ ก็เข้าสู่วงจรของน้ำตก (waterfall) ที่ก็ทำตาม “TOR” จนมาแจ๊คพ๊อตแตกเมื่อวัน UAT วันที่ส่งงานให้กับ user เพื่อให้ user ยอมรับ หึหึ…….ยังจำได้ชิแมะ ว่า
“USER คือผู้ไม่เคยรู้ว่าตัวเองต้องการอะไร” ก็ขอเปลี่ยนแปลงเพื่อให้เป็นดังสิ่งที่เขาคิดว่าเขาต้องการในเวลานั้น…..CR (Change Request) ก็มีตามมา บางหน่วยงาน ยอมที่จะจ่ายเงิน และยอมเสียเวลาเพิ่ม เพื่อให้ได้ในสิ่งที่เขาคิดว่า “เขาต้องการ”
เนี่ยแหละ การ “Fix Scope, Flexible Time and Budget” เสียทั้งเงิน เสียทั้งเวลา
แต่โครงการพัฒนาซอฟแวร์ ในรูปแบบของ Agile จะมีรูปแบบดังรูป
การพัฒนาซอฟแวร์ในรูปแบบของ Agile จะเป็นการเน้นการทำงานเป็นช่วงสั้น ๆ เพื่อให้ USER (ผู้ไม่เคยรู้ว่าตัวเองต้องการอะไร) ได้เห็นของและทราบในสิ่งที่เขาต้องการได้เร็วขึ้น ดังนั้นการที่ user fix เวลาและงบประมาณที่ต้องการ และจัดลำดับ (prioritize) งานที่เขาอยากเห็น/สำคัญ มากที่สุดก่อน ทีมพัฒนาก็จะดำเนินการส่งของเหล่านี้ให้กับ user ได้เห็น ได้จับ ได้สัมผัส และตัดสินใจได้ว่าควรจะดำเนินการต่อ หรือจะหยุดเพียงเท่านี้……
ไม่เสียทั้งเงิน ไม่เสียทั้งเวลา แถมยังได้ในสิ่งที่ต้องการ และสำคัญมากที่สุด….
น่าเสียดาย ที่การ fix time and budget, flexible scope ที่ดูแล้วเหมือนไม่น่ามีอะไรยาก กลับเป็นสิ่งที่ยากที่สุด…. หากถามว่าเป็นเพราะอะไร ก็อาจจะสรุปเป็นข้อ ๆ (ตามสิ่งที่ตนเองประสบพบเจอมา) ได้ดังนี้
- ) เพราะ User อยากทราบงบประมาณคร่าว ๆ เพื่อตั้งของบประมาณ
- ) เพราะ ผู้รับจ้าง ติดอยู่กับการทำงานรูปแบบเดิม และเมื่อประกอบกับข้อ 1 จึงกลับไปเขียน TOR ขึ้นมาเหมือนเดิม โดยยังมิได้ถ่ายทอดความรู้ หรืออธิบายใด ๆ แก่ User และดำเนินการตามรูปแบบเดิม (เพราะมันก็ไม่ได้เสียหายอะไร หากเกิด CR และผู้จ้างยอมรับ ผู้รับจ้างก็ได้เงินในส่วนนี้) — ซึ่งมันไม่ได้หมายถึงการได้ซอฟแวร์ที่ใช้งานได้จริง และผู้จ้างก็เสียทั้งเงิน และเวลา
- ) (อาจ)เพราะความไม่ไว้เนื้อเชื่อใจกัน และกลัวจะมีปัญหาการฟ้องร้อง จึงต้องมีสัญญาที่ชัดเจน
- ) เพราะ User ก็ไม่ทราบว่าตัวเองต้องการอะไร และคาดหวังให้ผู้รับจ้างทำงานให้ทั้งหมด
- ) เพราะ User กลัวว่าจะไม่ได้งานทั้งหมดที่ตนเองอยากได้ (แต่ไม่กลัวว่างานที่ได้ จะไม่ใช่สิ่งที่ต้องการ)
- ) เพราะผู้รับจ้าง ไม่รู้จะเขียนสัญญาอย่างไร และอธิบายอย่างไรให้กับ User เข้าใจ
========================================
สิ่งเหล่านี้ก็เป็นเพียงส่วนนึง ที่ทำให้การ Fix Time and Budget, Flexible scope ทำยาก แต่บอกได้เลยว่า
“ไม่ใช่ทำไม่ได้”
Eunhye
(2017–08–27)
ปอลิง. ไว้จะมาเล่าถึงความหวาน ความขม หัวเราะ ร้องไห้ ดั่งคนบ้า เมื่อเริ่มสถาปนาตัวเองเป็น Agile coach และ Scrum Master (อีกงานที่ชอบ และแมร่งโครตท้าทาย!)
