Feature

🐡 แก้กับแก้

คนทำซอฟต์แวร์ต้องกล้าที่จะปฏิเสธการแก้ให้ทุกคน เพื่อการสร้างระบบที่พร้อมจะให้ทุกคนแก้ 🐖

เพราะการซื้อหรือไม่ซื้อซอฟต์แวร์สักโครงการมันไม่เคยถูกตัดสินที่จำนวนฟีเจอร์ ไม่เคยถูกชี้เป็นชี้ตายด้วยฟีเจอร์เพียงฟีเจอร์เดียว 🥨

คำถามเหล่านี้ต้องการคำตอบ … ก่อนที่เราจะตอบ “ตกลง” ในการเพิ่มอะไรสักอย่างเข้ามาในซอฟต์แวร์ 🐚

ไม่ว่าจะทางไหน “แล้วไงต่อ?” ก็จำเป็นอย่างยิ่งที่จะช่วยให้เราสร้างระบบที่ดีขึ้นมาได้ … ยิ่งถามมากก็ยิ่งได้มุมมองที่ลึกซึ้งมากขึ้น 🍞

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

มันคืออะไรที่คนส่วนใหญ่ไม่โฟกัสในตอนแรก แต่มันเป็นปัจจัยที่ไม่เคยมีใครมองข้ามเมื่อต้องจรดปากกาเซ็นสัญญาซื้อขาย 🐤

มันง่ายที่จะมองหาคนที่ตอบ “เยส” แต่มันน่าตื่นเต้นกว่าเมื่อเจอคนที่กล้าถามกลับไปว่า “วาย” - และโปรดักท์ที่ดีสร้างได้ด้วยคำว่า “วาย” 👽

สิ่งที่ยากคือการทำเรื่องยากให้เป็นเรื่องง่าย มันคือพลังแฝงที่ดีที่สุดที่จะสร้างจุดแตกต่างให้เราและทีมงานที่ยากจะมีใครเลียนแบบได้ ✅

บางอย่างที่ทำงานได้ดีอยู่ไม่ได้แปลว่ามันดีที่สุด การมองหาจุดที่ขาดหายไปเป็นทักษะที่สำคัญอย่างยิ่งในการทำงานสมัยใหม่ 🎩

เราต้องให้ความสำคัญกับการแก้ปัญหาอย่างมีกลยุทธ์และทิศทาง เราต้องให้ความสำคัญกับงานที่จำเป็นสำหรับการสร้างโปรดักท์ที่ดีด้วย 👶🏼