ว่าด้วยเรื่องของการแบ่งปัญหาออกมาแก้ไข

จากการแบ่งปันเรื่องการพัฒนา 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 มากยิ่งขึ้น หรือไม่ ?