ช่วงหลังผมเจองานหลายเรื่องที่แต่ละคนบอกว่าเสร็จแล้ว และเมื่อเข้าไปดู ผมพบว่าเขาไม่ได้รายงานผิด งานในขอบเขตที่เขารับผิดชอบอาจเสร็จจริง เพียงแต่คำว่า “เสร็จ” ของแต่ละคนไม่ได้หมายถึงปลายทางเดียวกัน
สำหรับ Engineer งานอาจเสร็จเมื่อเขียน code ครบ test ผ่าน และ merge เรียบร้อย สำหรับทีม Operations งานอาจเสร็จเมื่อระบบถูก deploy มี monitoring มี runbook และมีคนรับ alert ส่วน Program Director อาจยังไม่มองว่างานเสร็จจนกว่าผลลัพธ์จะถูกส่งมอบ ผู้เกี่ยวข้องยอมรับ ทีมปลายทางใช้งานได้ ความเสี่ยงที่เหลือมี owner และไม่มีงานสำคัญตกค้างอยู่ระหว่างทีม
ทุกคนอาจถูกในมุมของตัวเอง แต่ Program ยังไม่เสร็จ
ปัญหาจึงไม่ได้อยู่ที่ใครเข้าใจคำว่า done ผิด แต่อยู่ที่เราไม่ได้ตกลง Definition of Done หรือ DoD ร่วมกันตั้งแต่ก่อนเริ่มงาน เมื่อไม่มี DoD คนแต่ละบทบาทจะเติมความหมายของคำว่าเสร็จจากประสบการณ์ ขอบเขตงาน และสิ่งที่ตัวเองควบคุมได้ Engineer จะหยุดตรงจุดที่งาน Engineering สมบูรณ์ Project Manager อาจหยุดตรงจุดที่ task ทั้งหมดถูกปิด ขณะที่ Program Director กำลังมองไปถึงผลกระทบต่อหลายทีม การนำไปใช้จริง การส่งมอบ และผลลัพธ์ทางธุรกิจ
นี่ไม่ใช่ความผิดของคนทำงาน ถ้าองค์กรปล่อยให้แต่ละคนคิด DoD เอง เราก็ควรคาดหวังว่าจะได้ DoD คนละแบบ
DoD ไม่ได้มีเพียงชั้นเดียว
ผมเริ่มมอง Definition of Done เป็นหลายชั้นที่เชื่อมต่อกัน มากกว่าจะใช้ checklist เดียวครอบทุกบทบาท
| มุมมอง | งานอาจถือว่าเสร็จเมื่อ | สิ่งที่ยังอาจไม่เสร็จ |
|---|---|---|
| Engineer DoD | code ครบ, review แล้ว, test ผ่าน, artifact พร้อม | deployment, monitoring, adoption, customer acceptance |
| Operations DoD | deploy แล้ว, service health ปกติ, alert และ runbook พร้อม | business acceptance, handover, program outcome |
| Project DoD | scope และ task ตามแผนส่งครบ, issue ถูกจัดการ | dependency ข้ามทีม, adoption และผลลัพธ์ระดับ Program |
| Program DoD | ผลลัพธ์ end-to-end เกิดขึ้น, ผู้รับใช้ต่อได้, risk และ dependency มี owner | commercial closure หรือผลลัพธ์ระยะยาวที่ต้องติดตามต่อ |
| Commercial DoD | หลักฐานส่งมอบครบ, accepted, billing-ready, invoice และ payment ถูกติดตาม | benefit realization หลังส่งมอบ |
DoD ของ Engineer ไม่ได้ด้อยกว่า DoD ของ Program Director และไม่ควรถูกขยายจน Engineer ต้องรับผิดชอบทุกอย่างตั้งแต่ code ไปจนถึงเงินเข้าบัญชี แต่ Engineer ต้องรู้ว่างานของเขาเป็นเพียงชั้นใดของ Definition of Done ทั้งหมด และต้องส่งหลักฐานหรือผลลัพธ์อะไรให้คนที่รับไม้ต่อ
ในทางกลับกัน Program Director ไม่ควรรับคำว่า “Engineer ทำเสร็จแล้ว” แล้วตีความเองว่า Program พร้อมส่งมอบ เพราะหน้าที่ของ Program Director คือมองสิ่งที่อยู่ระหว่างขอบเขตของแต่ละคน เช่น dependency ที่ยังไม่ต่อกัน ระบบที่ deploy แล้วแต่ยังไม่มีคนดูแล ผู้ใช้ที่ยังไม่ได้รับการเตรียม ความเสี่ยงที่ไม่มี owner หรือหลักฐานที่ยังไม่พอสำหรับการยอมรับ
Engineer จะคิดอีกแบบ ถ้าเราไม่กำหนดไว้ตั้งแต่ต้น
สมมติเรามอบหมายให้ Engineer ย้าย service หนึ่งชุดไปยัง environment ใหม่ แล้วเขาสามารถ build, deploy และทดสอบ endpoint ได้สำเร็จ ถ้า requirement บอกเพียงว่า “ย้ายระบบ” Engineer อาจถือว่างานเสร็จตรงนั้นอย่างสมเหตุสมผล เพราะสิ่งที่ได้รับมอบหมายในมุมเทคนิคทำงานแล้ว
แต่คนที่ดู Program อาจคาดหวังเพิ่มเติมว่า pipeline ต้องชี้มายังที่ใหม่ monitoring ต้องมองเห็น log และ metric, credential เก่าต้องถูกยกเลิก, rollback ต้องถูกทดสอบ, owner ต้องยืนยันการรับช่วง และผู้ใช้งานต้องเริ่มใช้ปลายทางใหม่จริง ความคาดหวังเหล่านี้ไม่ควรถูกนำมาถามหาในวันส่งงาน หากมันเป็นส่วนหนึ่งของคำว่าเสร็จ มันควรถูกเขียนอยู่ใน DoD ตั้งแต่วันเริ่มต้น
การควบคุม DoD จึงไม่ใช่การลงรายละเอียดเพื่อ micromanage วิธีทำงานของ Engineer แต่เป็นการกำหนดขอบเขตของผลลัพธ์ หลักฐาน และจุดส่งต่อให้ตรงกัน Engineer ยังมีอิสระในการออกแบบวิธีแก้ปัญหา แต่ไม่ต้องเดาว่าอะไรคือเงื่อนไขสุดท้ายที่ Program ต้องการ
DoD ที่ดีต้องเขียนก่อนเริ่ม ไม่ใช่เขียนเพิ่มตอนจะปิดงาน
หลายทีมเพิ่งเริ่มถามหา acceptance evidence, monitoring, runbook หรือ handover ตอนงานกำลังจะปิด ผลคือคนทำรู้สึกว่า scope ถูกเพิ่มในนาทีสุดท้าย ส่วนคนรับรู้สึกว่างานส่งมาไม่ครบ ทั้งสองฝ่ายอาจพูดถูก เพราะสิ่งที่ขาดจริง ๆ คือข้อตกลงตั้งแต่ต้น
ก่อนเริ่มงาน ผมคิดว่า DoD ควรตอบอย่างน้อยหกข้อ
- ผลลัพธ์ที่ต้องเกิดคืออะไร ไม่ใช่เพียงกิจกรรมที่ต้องทำ
- ขอบเขตของ DoD ในแต่ละบทบาทสิ้นสุดตรงไหน
- ต้องใช้หลักฐานอะไรเพื่อยืนยันว่างานผ่านแต่ละชั้นแล้ว
- ใครเป็นผู้ review, approve หรือ accept ผลลัพธ์
- งานต้องถูกส่งต่อให้ใคร และคนรับต้องพร้อมอย่างไร
- มี dependency, risk หรือ commercial condition อะไรที่ต้องปิดหรือตั้ง owner ก่อน
DoD ไม่จำเป็นต้องยาว ถ้าเป็นงานเล็กอาจมี checklist เพียงไม่กี่ข้อ แต่ยิ่งงานข้ามทีม กระทบ production เกี่ยวข้องกับลูกค้า compliance หรือรายได้ Definition of Done ยิ่งต้องมองไกลกว่า task ของคนคนเดียว
Reviewed, Released และ Accepted เป็นหลักฐานของ DoD คนละชั้น
เมื่อเราเห็น DoD เป็นหลายชั้น คำที่เคยสับสนก็เริ่มอยู่ในตำแหน่งของมันเอง
Draft → Reviewed → Approved → Released → Effective
Built → Verified → Delivered → Accepted → Billing-ready → Paid
Reviewed อาจเป็น DoD ของคนเตรียมเนื้อหา แต่ยังไม่ใช่ DoD ของการนำ policy ไปใช้ Released อาจเป็น DoD ของ Document Control แต่ยังไม่ใช่ Effective จนกว่าคนและกระบวนการจะเริ่มทำตาม Sent อาจเป็น DoD ของผู้ส่ง แต่ยังไม่ใช่ Accepted สำหรับผู้รับ และ Invoiced อาจเป็น milestone ของฝ่ายการเงิน แต่ยังไม่ใช่ Paid ในมุม cashflow
สิ่งสำคัญคือเราไม่ควรใช้ state ของชั้นหนึ่งไปประกาศความสำเร็จแทนอีกชั้นหนึ่ง
Program Director ต้องทำให้ DoD ของทุกคนต่อกันได้
สำหรับผม งานของ Program Director ไม่ใช่การเขียน checklist แทนทุกทีม และไม่ใช่การตามจี้ว่า task เล็กทุกชิ้นปิดหรือยัง หน้าที่สำคัญกว่าคือการทำให้ Definition of Done ของแต่ละบทบาทต่อกันเป็นเส้นทางเดียว ตั้งแต่คนสร้าง คนตรวจ คน deploy คนรับช่วง คนใช้ คนยอมรับ ไปจนถึงผลลัพธ์ที่ Program ถูกสร้างขึ้นมาเพื่อให้เกิด
Program Director จึงต้องถามมากกว่าว่า “งานเสร็จหรือยัง” เขาต้องถามว่า “เสร็จใน DoD ของใคร ตอนนี้อยู่ชั้นไหน หลักฐานคืออะไร และใครกำลังรับไม้ต่อ”
คำถามนี้ช่วยให้เรามองเห็นงานที่หายอยู่ระหว่างทีม เพราะงานจำนวนมากไม่ได้ล้มเหลวภายในขอบเขตของใคร มันล้มเหลวตรงรอยต่อ Engineer ทำของตัวเองครบ Operations ยังไม่ได้รับ context, Project Manager ปิด task ตามแผน แต่ผู้ใช้ยังใช้งานไม่ได้ หรือส่งมอบแล้วแต่ไม่มี acceptance ที่ทำให้เรียกเก็บและปิดความเสี่ยงได้
เมื่อ DoD ถูกกำหนดร่วมกันตั้งแต่ต้น Engineer จะรู้ว่าต้องสร้างและส่งหลักฐานอะไร Operations จะรู้ว่าต้องรับช่วงเมื่อไร Project Manager จะรู้ว่า task closure ยังขาด dependency ใด และ Program Director จะเห็นว่าผลลัพธ์ end-to-end ไปถึงปลายทางจริงหรือยัง
สุดท้าย Definition of Done ไม่ได้มีไว้เพื่อทำให้ทุกคนมองงานเหมือนกันทั้งหมด แต่มีไว้เพื่อให้ทุกคนรู้ว่าความสำเร็จในมุมของตัวเองเชื่อมต่อกับความสำเร็จของคนถัดไปอย่างไร
ถ้าเราไม่ตกลง DoD ไว้ก่อน ทุกคนจะทำงานเสร็จคนละแบบ และตอนท้ายเราจะเสียเวลาเถียงกันว่าใครเข้าใจผิด
แต่ถ้า DoD ชัดตั้งแต่ต้น ทุกคนยังทำหน้าที่ในขอบเขตของตัวเองได้ เพียงแต่ไม่มีใครเผลอเข้าใจว่างานของตัวเองเสร็จ เท่ากับทั้ง Program เสร็จแล้ว