Feature

✍🏼 เร็วไปที่จะซื้อ

สาเหตุที่ทำให้ซอฟต์แวร์ของเรามีฟีเจอร์มากเกินความจำเป็นเพราะเราตัดสินใจสร้างมันเร็วเกินไป 🏎🚤

✍🏼 แล้วยังไงต่อ?

“แล้วไงต่อ?” เป็นคำถามสำคัญที่เราในฐานะคนสร้างระบบต้องถามตัวเองบ่อยๆ เพื่อป้องกันไม่ให้เกิดการสร้างฟีเจอร์แบบครึ่งๆกลางๆ 🖖🏾

✍🏼 ฟีเจอร์แรกที่ต้องทำ

เวลามีจำกัด เราจำเป็นต้องทำอะไรที่มันเป็นจุดเป็นจุดตายของงานซะก่อน อะไรที่เป็นปัจจัยที่ส่งผลโดยตรงต่อความสำเร็จหรือล้มเหลวของโปรเจกต์ 🚧

✍🏼 ผู้ใช้ 5 คน

ผมนึกไม่ออกว่าเคยเห็นซอฟต์แวร์ไหนที่มีผู้ใช้แค่กลุ่มเดียวใครๆก็ใช้ 5-Why กัน …เราขอลองทฤษฎีใหม่ 5-Who 🧑🏻👨🏻‍🦱👩🏼‍🦰🧕🏻👨🏿

✍🏼 คุณค่ากับฟีเจอร์

เราขายอะไร? คุณค่าที่ลูกค้าจะได้รับจากสิ่งที่เราทำ (เพิ่มกำไร ลดต้นทุน) หรือเราพูดแค่ว่าฟีเจอร์ของเราดีกว่าคู่แข่งอย่างไร? 👹

✍🏼 ฉันตัดสิ่งนี้ออกได้ง่ายแค่ไหน?

เป็นไปได้มั้ยที่เราจะคิดว่าการใส่เข้าไปและการเพิ่มคือทางเลือกสุดท้ายจริงๆในการแก้ปัญหาและจัดการกับความท้าทายที่อยู่ตรงหน้าเราวันนี้? ✂️🗡🪓

✍🏼 ห้ามเลี้ยวซ้าย

กลยุทธ์ “ห้ามเลี้ยวซ้าย” ของยูพีเอสชี้ให้เห็นว่าการพัฒนาเกิดขึ้นได้เสมอ แม้แต่ในสภาวะที่เราคิดว่ามันดีที่สุดอยู่แล้ว 🚚🛻