มีคำถามที่น่าสนใจจาก Product Owner คนนึงมาฝากครับ
“พี่ๆ เราควรมีหลักการในการคิด Feature…
Amazon.com เวปไซต์อีคอมเมิร์สระดับยักษ์ใหญ่ของโลกให้คุณค่าและความสำคัญกับลูกค้ามาก … Core Value ข้อแรกของบริษัทนี้พูดถึงลูกค้าไว้ว่า
ข้อแรกผมไม่ชอบ Business Requirement Document อย่างที่เคยเล่าให้ฟังเต็มๆในบทความนี้…
เคยเอ่ยถึงไปหลายครั้งเรื่องการพัฒนาโปรดักส์ด้วยแนวคิด Less Is More สิ่งแรกที่เราต้องทำคือขุดคุ้ยค้นหาปัญหาที่ลูกค้าเจออยู่ (Pain Points) และความต้องการที่แท้จริง (Needs) ไม่ใช่เอาแต่ทำตามคำสั่งหรือคำพูดของพวกเค้า…
“ทำไมเราไม่ควรทำ Feature เพื่อสนองนีดลูกค้าแค่คนเดียว?” เป็นคำถามที่น่าสนใจ …
มุมมองที่ผมมีต่อการเลือกใช้ซอฟต์แวร์อะไรสักอย่างคือซอฟต์แวร์นั้นต้องมีความสามารถ (Feature)…
การวางแผนแทบทุกเรื่องสามารถทำได้ในสองแนวทาง (1) จากบนลงล่าง/ใหญ่ไปเล็กที่เรียกว่า Top-Down Approach และ (2) จากล่างขึ้นบน/เล็กไปใหญ่ที่เรียกว่า Bottom-Up…
สำหรับคนที่พัฒนาซอฟต์แวร์ด้วยหลักการ “Less Is More” นั้น หน้าที่ของพวกเค้าไม่ใช่การทำซอฟต์แวร์ให้ได้ตามที่ Product…
เรื่องราวแบบหนึ่งที่เจอมากับตัวเองเป็นประจำเวลาพูดคุยกับผู้ใช้ระบบเพื่อเข้าใจถึงปัญหาและความต้องการของพวกเค้า…