เราสนุกกับการแก้ปัญหา ผ่านการพัฒนาซอฟท์แวร์
จากที่มีน้องใน ODDS ตั้งหัวข้อถามใน BaseCamp ว่า “ร่วมแสดงความคิดเห็น “software development should be joyful” ในมุมมองคุณเป็นอย่างไร” แล้วก็นึกขึ้นมาได้ว่าผมดองบทความนี้ไว้ เลยมาเขียนต่อให้จบครับ
ช่วง Q4 ปี 2023 ผมมีโอกาสพูดคุยกับผู้ใหญ่ท่านหนึ่งซึ่งเป็นผู้บริหารของลูกค้า ในระหว่างนั้นบทสนทนาก็พาไปถึงเรื่องราวความเป็นอยู่ของ ODDS วิธีการทำงานแบบไม่มีสวัสดิการ และอีกหลายๆอย่าง ซึ่งท่านสนใจถึงขนาดถามว่า วิธีที่พวกเราอยู่กันเนี่ยะ มันมีในวงการอื่นไหมนะ ซึ่งผมก็ไม่รู้เหมือนกัน 😄
อย่างไรก็ดี หัวข้อการพูดสนทนาก็ไหลไปจนถึงรูปแบบการทำงานแบบ co-creation ของพวกเราที่แตกต่างจากการจ้างทำ software กับ vendor เจ้าอื่นๆ ที่เค้าจะมารับบรีฟงานแล้วตีเป็น project จากนั้นก็ทำสัญญาและเก็บเงินกันเป็นงวดๆ (ศัพท์ในวงการจะเรียกว่า turn-key คือ มองการ replace ระบบ เป็นการเปลี่ยนกุญแจ ทั้งแม่กุญแจและลูกกุญแจเลย) พอถึงตรงนี้ ท่านมองว่าทางลูกค้าจะเสียเปรียบรึเปล่า เพราะถ้าเป็นแบบ turn-key จะมีสัญญาชัดเจน ถ้าทาง vendor พัฒนาช้า ลูกค้าก็จ่ายเท่าเดิม เพราะงานเหมือนเดิมตามที่ออกแบบไว้ แต่ vendor ทำงานล่าช้าเอง ถึงจุดนั้นผมก็ขออนุญาตอธิบายท่านไปว่า…
สิ่งที่เราต่างจาก vendor เจ้าอื่นก็คือ เราไม่ได้แค่มาทำ software ให้ แต่เราช่วยลูกค้าแก้ปัญหาระหว่างทาง ผ่านกระบวนการทำซอฟท์แวร์และเครื่องมือต่างๆที่เรามี เพื่อให้ลูกค้าได้รับประโยนช์มากที่สุด
ประโยคนี้อาจจะฟังดูหล่อเว่อร์ แต่จากประสบการณ์ที่ทำ software มา ผมพบว่าคำพูดนี้ไม่ได้เกินจริง ผมขออ้างถึงเนื้อหาส่วนนึงของ class Certified LeSS Practitioner ที่ได้ไปเรียนกับ Bas Vodde มาเล่าประกอบ เพื่อจะได้เห็นภาพที่ชัดเจนขึ้นครับ
The Lake and Rocks Metaphor
ภาพด้านบน 2 ภาพ เป็นภาพแม่น้ำโขงในบริเวณใกล้ๆกัน ภาพแรกด้านซ้ายเป็นช่วงน้ำหลาก ภาพขวาเป็นช่วงหน้าแล้ง จะเห็นว่าช่วงหน้าแล้งเราจะมองเห็นโขดหินใต้น้ำชัดเจน ในขณะที่ช่วงน้ำหลากนั้นเราแทบจะไม่รู้เลยว่าใต้น้ำนั้นมีหินมากมายขนาดนี้
ให้ลองอุปมาอุปมัยว่า…
- ความกว้างและลึกของแม่น้ำช่วงระยะทาง 500 เมตร เป็นความสามารถที่ทีมงานทำได้ใน 1 ช่วงเวลา เช่น 1 สัปดาห์
- น้ำที่ไหลในแม่น้ำคือ งาน ที่ไหลผ่านทีมนี้ จากเริ่มต้นที่ต้นน้ำ จนเสร็จคือผ่านช่วง 500 เมตรไป
โดยปกติแล้ว งานที่เกิดขึ้นในทีมพัฒนาก็จะเยอะตลอด เปรียบเสมือนกับปริมาณน้ำที่เต็มแม่น้ำ คนทำงานจะรู้สึกว่างานมันมีปัญหาเยอะแยะเต็มไปหมดเลย บอกไม่ได้ว่า root cause คืออะไรกันแน่ บางคนมองว่าเป็นเรื่องเกี่ยวกับ communication ไม่ดี บางคนบอกว่าฝ่าย code ไม่มีคุณภาพ เปรียบเสมือนแม่น้ำที่มีน้ำเต็มเลยมองไม่เห็นก้อนหินที่อยู่ใต้น้ำ
คราวนี้ลองเปลี่ยนใหม่ เราลองกำหนดเวลาทำงานเป็น 1 sprint (ยาว 2 week ละกัน) และให้ทีมงานทำแค่หน้าจอ login แบบง่ายๆ หน้าเดียวก็พอ แต่เมื่อทำเสร็จแล้วขอขึ้น production ให้ user ใช้ได้เลยนะ ตอนนี้แหละเราจะเห็นปัญหาเต็มไปหมดเลย เปรียบเสมือนว่าในแม่น้ำเดิม ตำแหน่งเดิม แต่เมื่อน้ำลดต่ำลง ก็จะมองเห็นโขดหินเต็มไปหมด ถ้าแก้ปัญหาเหล่านั้นไม่ได้ ก็คงจะยากที่จะเกิดความคล่องตัวจากการทำ Agile อย่างที่หวังไว้
Feedback loop
เมื่อเราทำงานกับลูกค้าแบบ co-creation เราจะใช้ Scrum เป็นหลัก ซึ่ง Scrum จะมีรอบการทำงานที่ช่วยให้เกิด feedback loop ทุกๆ 1 - 2 สัปดาห์ จังหวะนี้แหละที่จะช่วยให้ลูกค้าเห็นปัญหา ที่ไม่ได้มีแค่ปัญหาของตัว software ที่ทำเท่านั้น แต่จะเห็นปัญหาอื่นๆด้วย เช่น goal หรือ direction ของ product ไม่ชัด, ทีมเข้าใจไม่ตรงกัน, งานมี defect เยอะ, ตารางงานของทีมเรากับทีมอื่นไม่ตรงกัน ต้องรอกันไปกันมา, ขั้นตอนการขออนุมัติเพื่อ deploy วุ่นวาย เป็นต้น ซึ่งปัญหาเหล่านี้มันมีอยู่แล้วในองค์กร แต่ในการทำงานแบบเดิมๆ รอบการทำงานมันยาวกว่าจะได้ขึ้น production (และเราก็จะมาเห็นปัญหาเยอะๆ แถวๆตอนเตรียมจะ production นี่แหละ) ก็เลยเหมือนกับว่าพอเป็น Scrum แล้วปัญหาเยอะ เสมือนว่าหินใต้น้ำ (ปัญหา) มันเยอะอยู่แล้ว แต่งาน (น้ำ) มันกลบปัญหา แต่พองานน้อยๆ แต่ flow ไปตั้งแต่ requirement ถึง production ให้ได้ใน 1-2 สัปดาห์ ก็เลยเห็นปัญหาเต็มไปหมดเลย
สนุกกับการแก้ปัญหา
เพราะฉะนั้น เมื่อเราเข้าไปทำงานกับลูกค้า และใช้ Agile Methodology เราจึงไม่ได้แค่ทำ software แต่เราจะทำงานร่วมกับลูกค้าเพื่อช่วยแก้ปัญหาระหว่างทางให้มากที่สุด ด้วยเครื่องมือที่ได้เรียนรู้มา ไม่ว่าจะเป็น User Story Mapping, Impact Mapping, Service Design / Thinking, Scrum, LeSS, Domain-Driven Design, Event Storming และอื่นๆอีกมากมาย เพื่อให้เราสามารถส่งมอบคุณค่าให้กับลูกค้าให้ได้มากที่สุด
แล้วถามว่า ทำไมสนุกนะ ก็ถ้าเจอปัญหาและแก้ปัญหาได้ เราก็จะเก่งขึ้น นั่นแหละคือความสนุกของพวกเรา :)
ขอให้สนุกกับการแก้ปัญหา ผ่านการทำ software ครับ
