Product

✍🏼 Usability Testing จะได้ผลดีที่สุดเมื่อทำกับผู้ใช้ไม่เกิน 5 คน

การทดสอบการใช้งานซอฟต์แวร์ตัวใหม่ของเราไม่จำเป็นต้องลงทุนทดสอบและสัมภาษณ์คนเป็นสิบเป็นร้อย … ตัวเลขจากสถิติบอกเราว่าแค่ห้าคนก็พอแล้ว เหตุผลคือ …

✍🏼 ความต้องการ vs. ความต้องการ

ถ้ามีคนบอกว่า “ขยายฟ้อนท์ให้หน่อย” เราจะมองว่ามันคือความต้องการ (Requirement) หรือความต้องการ (Need)? การทำซอฟต์แวร์ที่ดีไม่ใช่การขยายขนาดฟ้อนท์แต่มันคือการแก้ปัญหาที่ว่า “รายงานตอนนี้อ่านยาก” มากกว่า

✍🏼 อะเมซอนกับการทำงานย้อนหลัง

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

✍🏼 โปรดักส์ต้องสร้างจากบนลงล่าง

กลยุทธ์การพัฒนาโปรดักท์แบบบนลงล่างคือแนวทางที่ถูกต้อง บนคือภาพใหญ่ ล่างคือรายละเอียด การโฟกัสที่แบ็กล็อกคือการลืมภาพใหญ่ ลืมวิชชั่นที่ตั้งไว้ … อย่าทำแบบล่างขึ้นบน

✍🏼 ความพอดีในการสร้างซอฟต์แวร์

เราไม่ได้ต้องการลูกค้า 100 คน แต่เราต้องการลูกค้า 10 คนที่พร้อมใช้งานระบบเดียวกันที่เราสร้างขึ้น ระบบเดิมที่เราจะพัฒนาต่อไปในอนาคต … ลูกค้า 100 คนที่ต่างคนต่างมีระบบของตัวเองคือปัญหาไม่ใช่โอกาส

✍🏼 การล้มละลายของซอฟต์แวร์

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