คำถามคือว่าจริงๆ เราต้องการเวลาสำหรับ test อย่างเดียวเท่าไหร่? 10 วัน? 15 วัน?

10 วันที่คาดหวังไว้ จริงๆ เป็นเวลาสำหรับ test ทั้ง 10 วันจริงๆ หรือ?

หรือว่าเป็นการ test จริงๆ แค่ 3 วันที่เหลือคือการแก้บั๊กกันแน่?

คำถามจะย้อนกลับมาถามว่า แล้วทำไมถึงปล่อยให้ test เป็นเรื่องสุดท้าย ทำไม quality ไม่ถูก built-in เข้าไปตลอด process การพัฒนา

เราเริ่มต้น test ช้ากันเกินไปหรือเปล่า?

ผมพูดอย่างนี้ ไม่ได้หมายความว่าทุกคนต้องทำ TDD, BDD กันนะ

แต่เรื่อง quality ต่างๆ เป็น cross cutting concern ที่ลากผ่านระบบ + process อยู่แล้ว

ทำไมหลายที่กลับไม่ได้เลือกที่จะแทรกคุณภาพเข้าไปในทุกกระบวนการละ?

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

ผมกำลังจะบอกว่า ตราบใดที่แก้ปัญหาที่ปลายเหต ตราบใดที่คุณสมบัติ stop-the-line ไม่ได้ถูกนำมาประยุกต์ใช้ในองค์กรณ์ ก็ยากที่จะ improve quality อย่างมีนัยสำคัญ

การ stop-the-line คือการหยุดสายพานการพัฒนาเมื่อเจอปัญหาร้ายแรงทันที และแก้ไขในทันที + ออกแบบป้องกันไม่ให้ปัญหาเดิมเกิดซ้ำขึ้นอีกเป็นครั้งที่สอง

เราจะต้องการวัน test สักกี่วันกันหากทุกอย่างผ่านการ QC ในขั้นตอนของตัวเอง แล้วมีการส่งมอบเป็นระยะอยู่แล้ว?

จง Fixed Resource, Fixed Deadline, Fixed Quality แล้วปรับ Scope เอา คือกุญแจสำคัญ

เลือกสิ่งที่จำเป็นที่สุด ถามลูกค้าให้ตัดสิ่งที่ยังไม่จำเป็นออกหากรู้ตัวว่าไม่ทันแล้ว แล้วทำสิ่งที่ต้องทำให้มีคุณภาพ

สุดท้าย product ที่ได้ นอกจากจะส่งมอบทันกำหนด พอเพียง มันยัง maintain ได้ง่ายกว่าด้วย

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

เรื่องนี้ต้องอาศัยการร่วมมือกัน สื่อสาร และสอดรับกันหลายฝ่าย เป็นปัญหาเกี่ยวกับกระบวนการการพัฒนาที่ต้องถูกปรับปรุง ไม่ใช่เรื่องที่แผนกหนึ่งหรือคนเพียงส่วนหนึ่งสามารถแก้ไขได้ด้วยตัวเองฝ่ายเดียว แต่จะต้องร่วมมือกันเพื่อให้สอดคล้องไปด้วยกันถึงจะทำได้ครับ

ผมอยู่แถวลาดพร้าวครับ ส่วนมากแล้วเสาร์บ่ายไม่ว่างครับ ถ้าเป็นวันอาทิตย์น่าจะได้ฮะ