ฟีเจอร์ไร้ค่า

ยอมรับเถอะว่าเราทำฟีเจอร์ที่เสียของมาเยอะแล้ว ต่อให้เรามั่นใจแค่ไหนว่ามันต้องเจ๋งและเป็นที่นิยม เราล้มเหลวมานับครั้งไม่ถ้วน

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

“ใช้ยากอะค่ะ ทำแบบนี้แทนดีกว่ามั้ยคะ?” — ลูกค้าบอกผมมาแบบนี้เมื่อวาน …​ ทั้งๆที่ทุกแนวคิดและทางเลือกมาจากการตัดสินใจร่วมกันระหว่างผมและพวกเขา

แต่นี่แหละมนุษย์ ไม่เห็นของจริงไม่ได้ลองของจริงก็มองภาพไม่ออกว่าสุดท้ายแล้วนี่มันใช่สิ่งที่ฉันต้องการจริงๆหรือไม่ และในกรณีนี้คำตอบคือไม่ใช่ 😅

ทีมผมใช้เวลา 1 เดือนในการพัฒนาฟีเจอร์ตัวนี้จนสมบูรณ์ และมันก็ได้รับการพิสูจน์แล้วว่ามันไม่เวิร์คอย่างที่ใจหวัง

ทำยังไงต่อละ?

แก้สิครับ ทำใหม่ ในเมื่อของเดิมมันไม่เวิร์คเราก็ไม่ต้องฝืน ยอมรับความจริงและหาทางแก้กันต่อไป … ตามหลักการอะไจล์ (ใช่มั้ย?)

เราควรตอบสนองต่อความเปลี่ยนแปลงมากกว่ายึดติดกับแผนที่วางไว้ (เมื่อนานแล้ว)

ในกรณีนี้คือบททดสอบที่ดีว่าทีมเราพร้อมจะอะไจล์แค่ไหน เมื่องานนี้ต้องแก้ เราพร้อมรับความเปลี่ยนแปลงมั้ย? แล้วงานนี้ถูกแทรกเข้ามาแบบทันทีหรือว่าไปเข้าคิวตามลำดับความสำคัญ?

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

เราจะเรียนรู้อะไรหลายอย่างจากความผิดพลาด ครั้งนี้ก็เช่นกัน ฟีเจอร์ไร้ค่าให้อะไรกับเราหลายเรื่องรวมถึงแนวทางการทำงานแบบยืดหยุ่นในโลกแห่งความจริงด้วย