ยอมรับเถอะว่าเราทำฟีเจอร์ที่เสียของมาเยอะแล้ว ต่อให้เรามั่นใจแค่ไหนว่ามันต้องเจ๋งและเป็นที่นิยม เราล้มเหลวมานับครั้งไม่ถ้วน
เรื่องนี้ไม่มีข้อยกเว้น … ขนาดว่าเราทำงานร่วมกับลูกค้าอย่างใกล้ชิดเพื่อกำหนดรูปแบบและขอบเขตของฟีเจอร์ร่วมกันอย่างละเอียด
“ใช้ยากอะค่ะ ทำแบบนี้แทนดีกว่ามั้ยคะ?” — ลูกค้าบอกมาแบบนี้ … ทั้งๆที่ทุกแนวคิดและทางเลือกมาจากการตัดสินใจร่วมกันระหว่างเราและพวกเขา
แต่นี่แหละมนุษย์ ไม่เห็นของจริงไม่ได้ลองของจริงก็มองภาพไม่ออกว่าสุดท้ายแล้วนี่มันใช่สิ่งที่ฉันต้องการจริงๆหรือไม่ และในกรณีนี้คำตอบคือไม่ใช่
เวลา 1 เดือนที่เสียไปในการพัฒนาฟีเจอร์ตัวนี้จนสมบูรณ์ และมันก็ได้รับการพิสูจน์แล้วว่ามันไม่เวิร์คอย่างที่ใจหวัง
ทำยังไงต่อละ?
แก้สิ ทำใหม่ ในเมื่อของเดิมมันไม่เวิร์คเราก็ไม่ต้องฝืน ยอมรับความจริงและหาทางแก้กันต่อไป
เราควรตอบสนองต่อความเปลี่ยนแปลงมากกว่ายึดติดกับแผนที่วางไว้ (เมื่อนานแล้ว)
ในกรณีนี้คือบททดสอบที่ดีว่าทีมเรายืดหยุ่นได้แค่ไหน เมื่องานนี้ต้องแก้ เราพร้อมรับความเปลี่ยนแปลงมั้ย? แล้วงานนี้ถูกแทรกเข้ามาแบบทันทีหรือว่าไปเข้าคิวตามลำดับความสำคัญ?
หลักการในการทำงานที่เราออกแบบไว้จะได้ใช้ประโยชน์ก็ตรงนี้ เมื่อการทำงานร่วมกับลูกค้าอย่างใกล้ชิด ยอมรับและเคารพซึ่งกันและกัน ฟีเจอร์ที่ไร้ค่าจะได้รับการจัดการอย่างทันท่วงทีและมีประสิทธิภาพ ฟีเจอร์ที่ตรงใจจะถูกสร้างขึ้นมาแทนที่โดยไม่มีการถกเถียงที่ไร้สาระ
เราจะเรียนรู้อะไรหลายอย่างจากความผิดพลาด ครั้งนี้ก็เช่นกัน ฟีเจอร์ไร้ค่าให้อะไรกับเราหลายเรื่องรวมถึงแนวทางการทำงานแบบยืดหยุ่นในโลกแห่งความจริงด้วย