การวางแผนโปรเจกต์โดยทั่วไปแล้วมักจะมีรูปร่างหน้าตาประมาณนี้
- รวบรวมความต้องการ
- ออกแบบระบบ
- พัฒนาระบบ
- ทดสอบระบบ
- ส่งมอบระบบ
ถ้าดั้งเดิมหน่อยก็กำหนดระยะเวลาในการทำงานแต่ละงานให้ยาว — วอเตอฟอลล์
ถ้าร่วมสมัยหน่อยก็ทำแบบสั้นๆถี่ในลักษณะสปริ้นท์ — สกรัม/อะไจล์
ไม่ว่าจะแบบไหนงานทั้งหมดมีจุดมุ่งหมายเพื่อสร้างและส่งมอบตามสเปค เวลาถูกใช้ไปเพื่อสร้างและส่งมอบให้ทันกำหนด …
เพื่อมารู้ตัวตอนสายว่าที่ทำมาทั้งหมดตั้งแต่วันแรกมันไม่เวิร์ค มันขายไม่ได้ มันไม่ตรงกับความต้องการของตลาด
แผนประเภทนี้จะมีโอกาสใช้การได้ก็ต่อเมื่อเรารู้แจ้งเห็นจริงอย่างแน่ชัดในเรื่องเหล่านี้
- กลุ่มผู้ใช้
- พฤติกรรมและลักษณะการใช้งาน
- เทรนด์
- เทคโนโลยี
- คู่แข่ง
- ต้นทุน
ไม่เพียงรู้จริง … เราต้องมั่นใจด้วยว่าข้อมูลเหล่านั้นจะไม่เปลี่ยนแปลงตลอดระยะเวลาที่เราทำโปรเจกต์ซึ่งมันเป็นเรื่องยากถึงเป็นไปไม่ได้เลย
การวางแผนที่เน้นแต่การพัฒนาเพื่อส่งมอบจึงตั้งอยู่บนสมมติฐานที่ผิดตั้งแต่วันแรก เพราะในสถานการณ์ที่ไม่มีอะไรแน่นอนและเราไม่รู้ว่าเราไม่รู้เรื่องอะไรบ้างแบบนี้ สิ่งที่สำคัญยิ่งกว่าผลผลิตคือข้อมูลความจริง สิ่งที่ขาดไปจากแผนของเราคือแนวทางและกลุ่มงานที่มุ่งเป้าในการค้นคว้าสืบหาข้อมูลสำคัญเพื่อพิสูจน์สมมติฐานที่เราตั้งไว้
- นักเรียนมัธยมคือกลุ่มเป้าหมาย … จริงหรือไม่ที่พวกเค้ากำลังมองหาโปรดักท์ประเภทนี้อยู่?
- นักเรียนมัธยมชอบฟังเพลงระหว่างกินข้าวเย็น … จริงหรือไม่ที่พวกเค้ามีพฤติกรรมแบบนี้
- และอื่นๆ
ถ้าเรามองว่าโจทย์คือหาคำตอบไม่ใช่แค่หลับหูหลับตาสร้างโปรดักท์ตามสเปค ลักษณะงานในแผนของเราจะต่างไปจากเดิมมาก
เราจะมีงานที่ทำรีเซิร์จ เราจะมีงานที่เป็นการออกนอกสถานที่เพื่อเก็บข้อมูล เราจะเตรียมเวลาไว้เพื่อการรีวิวข้อมูลความจริงที่เก็บรวบรวมมา เราจะเริ่มต้นด้วยโปรโตไทป์ เราจะให้ความสำคัญกับการทดสอบกับผู้ใช้มากขึ้น เราจะมีเดดไลน์สำหรับการตัดสินใจไปต่อหรือหยุดโปรเจกต์นี้อย่างชัดเจน
เราจะไม่หมกมุ่นกับผลผลิตและการส่งมอบ เราจะให้ความสำคัญกับการหาคำตอบที่ใกล้เคียงความจริงที่สุดมากกว่า นั่นคือเส้นทางที่ถูกต้องในการพัฒนาซอฟต์แวร์ในยุคปัจจุบัน
และเราต้องจำไว้ว่า … เราต้องวางแผนเพื่อเรียนรู้และปรับตัว ไม่ใช่แค่วางแผนเพื่อลงมือปฏิบัติ 💭🤔