✍🏼 วางแผนเพื่อการเรียนรู้
เราจะไม่หมกมุ่นกับผลผลิตและการส่งมอบ เราจะให้ความสำคัญกับการหาคำตอบที่ดีที่สุดมากกว่า นั่นคือเส้นทางที่ถูกต้องในการพัฒนาซอฟต์แวร์ 😎
Planning
✍🏼 ความมึนในสองรูปแบบ
ชัดเจนในขั้นตอน แต่มั่วมึนในเป้าหมาย 🍭 มั่วมึนในขั้นตอน แต่ชัดเจนในเป้าหมาย 🌀เรา “เลือก” ที่จะเป็นแบบไหน? 🙆🏼♂️
✍🏼 สามปี
วางแผนละเอียดสำหรับสามเดือน … ไม่ใช่สามปี … เพราะสามปีในโลกเทคโนโลยีเปรียบเหมือน 30 ปีในโลกทั่วไป ☝🏼✌🏼🤟🏼
✍🏼 เค้กคละรส 🎂
ถ้าเราต้องทำเค้ก 1 ปอนด์เพื่อขายแค่ 1 ชิ้นเล็ก 🍰 ที่เหลือคือเสียทิ้ง เหมือนฟีเจอร์ซอฟต์แวร์ที่เราต้องพยายามทำให้มันคุ้มค่าที่สุด ให้มีคนใช้เยอะที่สุด
✍🏼 การสร้างโปรดักท์ด้วยขอบเขต, จุดสำคัญ และเส้นทาง
โปรดักท์ที่ดีจะมีขอบเขตที่ชัดเจน มีจุดสำคัญที่มองเห็นง่าย และมีเส้นทางเชื่อมระหว่างจุดเหล่านั้นที่หลากหลาย – ความยืดหยุ่นคือสิ่งที่เราต้องค้นหาให้เจอ 🕵🏼♂️
✍🏼 การทดสอบแนวคิด (Proof of Concept)
Proof of Concept ที่ดีควรต้องเริ่มต้นจากสมมติฐานและเป้าหมายเสมอ ไม่ใช่ลุยแหลก ไม่ใช่เร่งรีบ และไม่ใช่เรื่องของเทคนิคเพียงอย่างเดียว 👩🏻🔬🧫
✍🏼 ทำงานทีละชิ้น
ในขณะที่ใครคนอื่นพยายามสร้างภาพที่ใหญ่เกินตัวด้วยการรับงานทับซ้อน ข้อได้เปรียบของเราคือการทำงานทีละชิ้น สร้างผลงานคุณภาพไปทีละเรื่อง 🥇
✍🏼 เมื่อโปรเจกต์มันยาวเกินไป
เราวางแผนระยะยาวได้แต่เราไม่ควรทำให้โปรเจกต์ยาวเกินไป เพราะความเบื่อ 😩 สามารถทำลายอะไรหลายอย่างได้อย่างรวดเร็ว
✍🏼 โปรโตไทป์กับโปรดักท์
เมื่อโปรโตไทป์มีไว้แค่การเรียนรู้ เมื่อโปรโตไทป์ไม่ควรเป็นโปรดักท์จริง … และเมื่อโปรดักท์จริงคือสิ่งที่เราต้องรีลิสได้ด้วยความมั่นใจจริงๆ 🧑🏽💻
✍🏼 โปรดักท์ เมเนเจอร์กับการสร้างความได้เปรียบที่ไม่เป็นธรรม
เมื่อข้อได้เปรียบทางการแข่งขัน (Competitive Advantage) นั้นกำลังจะไม่มีตัวตนอีกต่อไปเพราะมันถูกก๊อบปี้ไปหมดแล้ว เราจะทำอย่างไรดี? 🥊