จากการแบ่งปันเรื่องการพัฒนา software นั้น
มีเทคนิคหนึ่งที่ใช้งานบ่อย ๆ และแนะนำไป คือ
การแก้ไขปัญหาใหญ่ ๆ ด้วยการแบ่งเป็นปัญหาเล็ก ๆ ออกมา
เพื่อแก้ไขทีละปัญหา และเมื่อแก้ไขจนครบ
จะช่วยให้เราแก้ไขปัญหาใหญ่ ๆ ได้
หรืออาจจะเรียกว่าการทำ work break down นั่นเอง
โดยในการพัฒนา software นั้น เรามักจะมีข้อมูลในระบ feature มาก่อน
ว่าต้องการที่จะทำอะไรบ้าง ทำไปเพื่ออะไร แก้ไขปัญหาอะไร
และได้มาซึ่ง business value อย่างไรบ้าง
จากนั้นก็ทำการแบ่ง feature นั้น ๆ ออกมาเป็น story หรือ flow แบบ end-to-end
ในมุมมองของผู้ใช้งาน ทั้ง customer, admin หรือแม้แต่ system ก็ตาม
เพื่อให้เห็นว่าเกิดอะไรขึ้นบ้าง
เพื่อทำให้เห็นภาพใหญ่ และไม่หลุดกรอบของการทำงานนั้น ๆ
ยกตัวอย่างเช่น เราจะคุยในแง่ของ
- Success flow มีกี่ flow ?
- Failure flow มีกี่ flow ?
จากนั้นก็พูดคุยในรายละเอียดของแต่ละ flow
แน่นอนว่า flow มีจำนวนเยอะมาก ๆ
ดังนั้นจึงต้องมีการจัดลำดับความสำคัญว่า จะพูดคุยหรือทำอะไรก่อนหลัง
เนื่องด้วยเวลาที่มีอย่างจำกัด จึงต้องให้ความสำคัญอย่างมาก
ลองคิดดูว่า ถ้าใช้เวลาคุยกันนานมาก ๆ แล้วจะเหลือเวลาทำไหม
ในการพูดคุยเราจะทำความเข้าใจ ด้วยการแตกงานหรือ task ย่อย ๆ ออกมา
ว่าในการสร้างหรือพัฒนา flow นั้น ๆ จะต้องมี task อะไรบ้าง
โดยแต่ละ task ควรมีกำหนดด้วยว่า คำว่าเสร็จคืออะไร
เพื่อช่วยให้เราเข้าใจว่า สิ่งที่กำลังจะทำเป็นอย่างไร
ค่อย ๆ แก้ไขไปทีละเรื่อง แต่เราเห็นภาพรวมของเป้าหมายนะ
แต่ถ้าไม่สามารถแตก task ออกมาได้
นั่นก็หมายความว่า เรายังไม่เข้าใจในสิ่งที่กำลังจะทำหรือไม่ ?
หรือบางคนอาจจะบอกว่า ต้องลองทำก่อนถึงจะรู้ว่า ต้องทำอะไรบ้าง !!
ฟังแล้วดูแปลก ๆ ไหมนะ
ยิ่งเราเห็นและเข้าใจว่าต้องทำอะไร ก่อนที่จะลงมือทำ
มันน่าจะทำให้เราใช้เวลาทำน้อยลงไหม
แยกกันระหว่างการคิด วางแผน ออกแบบ ลงมือทำ
น่าจะทำให้เรา focus มากยิ่งขึ้น หรือไม่ ?