✍🏼 โปรดักส์ต้องสร้างจากบนลงล่าง

การวางแผนแทบทุกเรื่องสามารถทำได้ในสองแนวทาง (1) จากบนลงล่าง/ใหญ่ไปเล็กที่เรียกว่า Top-Down Approach และ (2) จากล่างขึ้นบน/เล็กไปใหญ่ที่เรียกว่า Bottom-Up Approach กับการวางแผนพัฒนาโปรดักส์และซอฟต์แวร์ก็หนีไม่พ้นสองแนวทางนี้ แต่ที่แปลกนิดนึงสำหรับประสบการณ์ที่ผมเห็นมาคือหลายครั้งเราหยิบเอาทั้งสองแนวทางนี้มาใช้ปนกัน … จนมั่วไปหมด

เริ่มแรกเราหยิบ Top-Down Approach มาใช้ เราวางแผนโดยมองภาพรวมของโปรดักส์ที่เราจะสร้างก่อน ทำอะไร ให้ใครใช้ มีส่วนประกอบอะไรบ้าง อื่นๆ ข้อมูลเหล่านี้มักจะถูกเขียนออกมาในรูปแบบของเอกสารความต้องการทางธุรกิจ (Business Requirement Document) จากนั้นก็ค่อยคิดลงลึกในรายละเอียดว่ามีงานอะไรต้องทำบ้าง … นั่นคือการเริ่มต้นเขียน Product Backlog

พอมี Product Backlog แล้วเราก็แทบจะเลิกสนใจ Business Requirement Document ไปเลย เราหมกมุ่นอยู่แค่การทำงานตามที่ Product Backlog เขียนไว้ แทบไม่เคยหันกลับไปมองภาพรวมภาพใหญ่เลยว่าเรากำลังเดินมาในแนวทางที่ถูกต้องหรือไม่ … ความเป็น Top-Down เริ่มหายไป

แค่นั้นยังไม่พอ หลายครั้งเมื่อเริ่มรู้ตัวว่าเราทำงานออกนอกเส้นทางที่กำหนดไว้เราดันเลือกจะหันกลับไปเปลี่ยนแผนภาพใหญ่โดยยึด Product Backlog เป็นหลัก … ความเป็น Bottom-Up เริ่มเข้ามามีบทบาท … อะไรกันวะ งง ฮ่าๆ

เมื่อเป็นแบบนี้มันก็ไม่ใช่เรื่องแปลกอะไรที่คนทำงานจะรู้สึกมึนๆ ตอบไม่ได้ว่ากำลังทำอะไรอยู่ในภาพรวม ประโยชน์ของงานที่ทำคืออะไร ทั้งหมดที่ทำนี้เพื่ออะไร … ความรู้สึกเป็นเจ้าข้าวเจ้าของ (Sense of Ownership) เริ่มจางหายไป แย่นะ

สำหรับผมไม่ว่าอย่างไรก็ตามการวางแผนการพัฒนาโปรดักส์หรือซอฟต์แวร์ควรเป็นจากบนลงล่างเสมอ คำว่าบนลงล่างคือ

• การยึดถือประโยชน์ที่ลูกค้าจะได้รับเป็นสำคัญ
• การมี Product Vision ที่ชัดเจนเป็นที่ยึดเหนี่ยวและไม่เปลี่ยนแปลงโดยง่าย
• การลืมความคิดที่ว่า Product Backlog คือสิ่งที่สำคัญที่สุดที่ทุกคนมีหน้าที่ทำตาม

ผมเชื่อมั่นอย่างมากว่าการใช้ Top-Down Approach จะช่วยทำให้ทุกคนมีความรู้สึกเป็นเจ้าข้าวเจ้าของในการทำงานมากขึ้น เข้าใจและเข้าถึงวัตถุประสงค์และเป้าหมายอันยิ่งใหญ่ร่วมกัน … ซึ่งเป็นเรื่องสำคัญที่หลายคนมองข้ามไป