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