🐯 เร็ว … แค่ไหน?
ปัญหานี้ไม่มีทางแก้แบบเบ็ดเสร็จ มันแก้ไม่ได้เพราะต้นตอมันอยู่ที่แนวคิดของคนและการเปลี่ยนแปลงคนเป็นเรื่องที่แทบเป็นไปไม่ได้ 👟
ปัญหานี้ไม่มีทางแก้แบบเบ็ดเสร็จ มันแก้ไม่ได้เพราะต้นตอมันอยู่ที่แนวคิดของคนและการเปลี่ยนแปลงคนเป็นเรื่องที่แทบเป็นไปไม่ได้ 👟
กับเวอร์ชั่นแรกที่เรายังไม่มีข้อมูลเรื่องลูกค้า เรื่องผู้ใช้มากนัก เราควรเตรียมการและใช้กระบวนการแบบไหนในการเลือกทำและไม่ทำอะไร 🙋🏻♂️
ยุ่งเป็นเหตุผลที่ฟังขึ้น ยุ่งเป็นลักษณะข้ออ้างที่น่าเห็นใจ ยุ่งคือพื้นที่ปลอดภัย ในขณะเดียวกันยุ่งคือปัญหาและยุ่งไม่มีประโยชน์ 🫛
ในหลากหลายองค์ประกอบและบริบท คำตอบนี้ไม่มีขาวและดำ ถูกหรือผิด มันอยู่ที่เราเลือกจะเดินทางไหน อย่างไรก็ตาม ข้อคิดที่น่าสนใจนั้นมีอยู่ 🐙
อย่าสร้างกฎเกณฑ์ที่ว่าถ้าเรามี “แผน” ในอนาคตแล้วจะคิดว่าทุกอย่างระหว่างทางเป็นเรื่องเสียเปล่าทั้งหมด ทำแบบนั้นไม่ได้ 🤨
หลายครั้งหลายครา … คุณภาพเกิดจากข้อจำกัด - เงินทุน เวลา โอกาส ถ้ามีน้อยอาจจะยิ่งส่งผลดี 👋🏼
คำถามที่ควรถามเพื่อเก็บข้อมูลก่อนตัดสินใจว่าจะรับหรือไม่รับ Requirement Changes เหล่านั้นมาฝากให้คิดกันดู 😵
การจัดลำดับความสำคัญของงานคือเรื่องสำคัญมาก … โปรเจกต์ดีเลย์ไม่ใช่เพราะไม่ทำงานแต่ทำผิดงานซะมากกว่า 👋
บางครั้งเราเลี่ยงงานน่าเบื่อเพื่อทำงานที่น่าสนุก บางครั้งเราเลือกทำงานเรียงตามลำดับกลุ่มฟีเจอร์ แต่ไม่ได้เรียงตามลำดับความสำคัญ 👎🏽
จำนวนต้องมาตามหลัง เวลาและคุณภาพต้องมาก่อน … ต้องเรียงลำดับแบบนี้เท่านั้น 💁🏼♂️