fixed time และ fixed scope
ในฐานะ developer คนหนึ่ง ผมเคยสงสัยมาก ว่าใครเป็นคนปักวัน release ให้งานที่ผมทำ และเขารู้ได้อย่างไร ว่าผมจะทำทัน
สิ่งที่น่าเหลือเชื่อคือ ผมทำทันทุกครั้ง 😅 แต่ไม่ต้องห่วง ผมมี bug ให้ไม่น้อยอยู่แล้ว แต่ bug ก็ไม่ใช่เรื่องที่ผมสนใจที่สุด สิ่งที่ผมให้ความสำคัญคือการทำงานให้เสร็จอยู่แล้ว
fixed time คือการจำกัดเวลาทำงาน เช่นงานนี้เรามีเวลา 1 เดือน หรือ 6 เดือน
fixed scope คือเรามีฟีเจอร์ที่ต้อง release ให้ได้ตามที่สัญญาไว้
ปกติเราจะ fixed ได้อย่างใดอย่างหนึ่ง
ยกตัวอย่างเช่น ถ้าผมจะเดินทางจาก เพชรบุรีกลับ กทม สมมุติระยะทาง 180km ถ้าผม fixed time ไว้ที่ 30 นาที นั่นแปลว่า ผม fixed scope และ time ในเวลาเดียวกัน เพราะ scope ของผมคือต้องเดินทางให้ได้ 180km ซึ่งโดยปกติ มันเป็นไปได้ยาก เพราะไม่งั้น เราอาจจะต้องลงเอยที่งานไม่เสร็จ และอาจจะต้อง delay หรือต้องยอมลด scope ลง
ลองคิดดูว่า ถ้าผมต้องเดินทาง 180km ให้ได้ใน 30 นาที ผมต้องใช้ความเร็ว 360km/h ซึ่งในความเป็นจริง ความเร็วระดับนั้น ระดับ shinkansen ยังได้ราวๆ 320km/h ถ้าเราจะขับรถ ความสามารถของรถน่าจะทำความเร็วระดับนั้นไม่ได้จริง เพราะปัจจัยแวดล้อมเช่น ถนน และกฏจราจร
และส่วนมาก ถ้าเจอโจทย์แบบนี้ ในชีวิตจริงเราก็มักจะได้ยินคำคุ้นหูเช่น
เพิ่มคนสิ
เราลองมาสมมุติเหตุการณ์เดิม แล้วเพิ่มอะไรสักอย่างเข้าไปดูเช่น เพิ่มผู้โดยสาร 😅 เพิ่มรถอีกคัน เพิ่มเชื้อเพลิง เพิ่มล้อ ซึ่งไม่ว่าจะเพิ่มอะไรเข้าไป ก็ไม่ช่วยให้เราไปถึง กทม ได้ในครึ่งชั่วโมงแน่ๆ
เรื่องนี้บอกให้รู้ว่า ถ้าจะ fixed scope เราจะสามารถไปถึง กทม ได้แน่นอน แต่เวลาอาจจะต้องยืดหยุ่น เพราะปัจจัยในการเดินทางก็มีส่วนทำให้เวลาคลาดเคลื่อน เช่น ผู้โดยสาร อยากเข้าห้องน้ำ หรือหิวข้าวระหว่างทาง หรืออยากแวะซื้อของฝาก ไปจนน้ำมันหมด หม้อน้ำรั่ว หรือแม้แต่อุบัติเหตุ และอาจจะต้องเผื่อใจไว้ส่วนหนึ่งว่า อาจจะมีโอกาสที่จะไปไม่ถึงด้วยนะ
แต่ถ้าจะ fixed time เช่นมีเวลาเดินทางแค่ 30นาที ก็ต้องยอมรับว่า เราอาจจะไปได้ 0–60 km จากจุดเริ่มต้นโดยประมาณ ซึ่งอาจจะไปไหนไม่ได้เลยด้วยซ้ำถ้ามีปัจจัยภายนอกเข้ามาเกี่ยวข้องเหมือนข้างต้น
เรื่องนี้ก็เป็นการยกตัวอย่างง่ายๆว่าทำไมเราถึงไม่ควร fixed time และ fixed scope ในงานเดียวกัน และขออภัยหากตัวอย่างไม่ได้สร้างความเข้าใจมากเพียงพอนะครับ
