Prioritization

🐻‍❄️ คิดให้เยอะ แต่อย่ารีบทำให้เยอะ

น้อยที่สุดดีกว่าเสมอ … น้อยไม่ได้แปลว่าแย่หรือมาตรฐานต่ำ น้อยคือการคัดเลือกมาอย่างดี ทั้งลูกค้า ฟีเจอร์ ทีมงาน เทคโนโลยี 🐨

ความจริงในโลกของการพัฒนาซอฟต์แวร์ มันเป็นการเลือกระหว่างการทำงานให้เสร็จตามเดดไลน์กับการส่งมอบงานที่ดีมีคุณภาพที่แท้จริง ✨

ปัญหานี้ไม่มีทางแก้แบบเบ็ดเสร็จ มันแก้ไม่ได้เพราะต้นตอมันอยู่ที่แนวคิดของคนและการเปลี่ยนแปลงคนเป็นเรื่องที่แทบเป็นไปไม่ได้ 👟

กับเวอร์ชั่นแรกที่เรายังไม่มีข้อมูลเรื่องลูกค้า เรื่องผู้ใช้มากนัก เราควรเตรียมการและใช้กระบวนการแบบไหนในการเลือกทำและไม่ทำอะไร 🙋🏻‍♂️

ยุ่งเป็นเหตุผลที่ฟังขึ้น ยุ่งเป็นลักษณะข้ออ้างที่น่าเห็นใจ ยุ่งคือพื้นที่ปลอดภัย ในขณะเดียวกันยุ่งคือปัญหาและยุ่งไม่มีประโยชน์ 🫛

ในหลากหลายองค์ประกอบและบริบท คำตอบนี้ไม่มีขาวและดำ ถูกหรือผิด มันอยู่ที่เราเลือกจะเดินทางไหน อย่างไรก็ตาม ข้อคิดที่น่าสนใจนั้นมีอยู่ 🐙

อย่าสร้างกฎเกณฑ์ที่ว่าถ้าเรามี “แผน” ในอนาคตแล้วจะคิดว่าทุกอย่างระหว่างทางเป็นเรื่องเสียเปล่าทั้งหมด ทำแบบนั้นไม่ได้ 🤨

หลายครั้งหลายครา … คุณภาพเกิดจากข้อจำกัด - เงินทุน เวลา โอกาส ถ้ามีน้อยอาจจะยิ่งส่งผลดี 👋🏼

คำถามที่ควรถามเพื่อเก็บข้อมูลก่อนตัดสินใจว่าจะรับหรือไม่รับ Requirement Changes เหล่านั้นมาฝากให้คิดกันดู 😵

การจัดลำดับความสำคัญของงานคือเรื่องสำคัญมาก … โปรเจกต์ดีเลย์ไม่ใช่เพราะไม่ทำงานแต่ทำผิดงานซะมากกว่า 👋