พลังของ Inspect & Adapt
ช่วงก่อนหน้านี้มี class “Introduction to Agile & Scrum” ที่สอนโดย Roof 44, Chokchai,และ Jane.Makub ที่ กกบ.(เป็น public class ครั้งแรกด้วย ปกติสอน onsite เท่านั้นนะ — ขายของ) พอดีวันนั้นคุยงานเสร็จเร็ว ก็เลยแอบแว่บไปนั่งฟังแป๊บนึง ฟังกี่รอบก็ไม่เบื่อเลย
จังหวะที่เข้าไปแอบฟัง เป็นช่วงที่พูดถึง DoD พอดี จู่ๆ “ความรู้สึกไม่สอดคล้องในใจ” เกี่ยวกับเรื่อง DoD ตั้งแต่ตอนเรียน Intro Agile & Scrum ครั้งแรกก็ผุดขึ้นมา และนึกขึ้นมาได้ว่า เออ เรามีประสบการณ์ปลดล็อคความไม่สอดคล้องนั้นมาแล้วนี่ ก็เลยเล่าให้รูฟฟัง รูฟก็ทักว่า “พี่น่าจะเล่าให้คนอื่นฟังด้วยนะ” เลยได้มาเป็น blog นี้ครับ (แต่ดองไว้นานเลย ^^)
Note: เรื่องนี้เป็นความคิดส่วนตัวที่มัน “work” ภายใต้บริบทและสถานะการณ์ที่ผมพบเจอ มันอาจจะ “ไม่ work” ในความคิดของคนอื่น ถ้าคุณคิดว่า “ทำไมไม่ทำแบบนี้ แบบนั้นนะ” ก็ยินดีรับฟังครับ และมันจะ ok มากเลยที่จะแบ่งปันความไม่เห็นด้วยนั้นต่อไปครับ :)
ความรู้สึกไม่สอดคล้องในใจ — เกี่ยวกับเรื่อง DoD
ตอนที่เรียนถึงเรื่อง DoD คนสอนก็จะเล่าถึงเทคนิคหรือแนวทางที่จะได้มาซึ่ง DoD แนวทางที่มักจะใช้ก็คือ “software จะอยู่บน Production ได้ ต้องทำอะไรบ้าง?” คนเรียนก็จะ list หัวข้อต่างๆ ขึ้นมาแล้วมันก็จะ apply ไปเป็น PSPI และ DoD หัวข้อที่ได้ก็มักจะมาจาก Process เดิมที่เคยทำมา เช่น Requirement Spec., Design Document, Test Cases, Test Results, Unit Test, Automation และอื่นๆ ซึ่งก็ไม่ได้ผิดอะไรนะ แต่ตรงนี้แหละที่ “ความรู้สึกไม่สอดคล้อง” ของผมมันลอยขึ้นมา
เสียงในหัวของผมมันดังขึ้นมาว่า “มันได้ทำจริงๆเหรอ” ไม่ใช่ทำไม่ได้นะ แต่ในความเป็นจริงหลายๆอย่างเราทำกันด้วยเหรอ เช่น document ที่บอกว่าสำคัญๆ นี่คือเคยทำด้วยเหรอ (ไม่นับเรื่องที่ทำไปแล้วไม่มีคนอ่านนะ) ที่ผ่านมาก็ไม่มีนะ ก็ขึ้น production ได้ แล้วก็บอกว่าจะกลับมาทำทีหลัง ซึ่งไม่เคยเกิดขึ้นเพราะงานใหม่มาจ่อรออยู่แล้ว จะทำใน sprint ก็ไม่ได้ทำอยู่ดีเพราะต้องรีบเข็น feature ก่อน แต่สุดท้ายก็เอา list นั้นไปใช้ แล้วค่อยว่ากันอีกที เพราะผมยังไม่มีความรู้ที่ดีกว่านี้
จังหวะอ๋อ!!!
เมื่อไม่นานมานี้เองมีเหตุการณ์ที่ทีมกับ PO ที่ผมทำงานด้วย เริ่มเห็นพ้องตรงกันว่า “คำว่า Done ของเราไม่ makesense แล้ว” เพราะความเข้าใจว่า “งานเสร็จ” มันไม่ใช่แบบนั้นแล้ว (ทั้งๆ ที่ตอนแรกมันดู makesense) ก็เลยกลับมานั่งคุยกันเรื่อง DoD ใหม่ และพบว่า DoD เวอร์ชั่นใหม่ค่อนข้างเฉพาะทางมาก คือมันเป็น DoD ที่เฉพาะเจาะจงกับบริบทของที่นั่นเท่านั้น เอาไปใช้ที่อื่นไม่ได้ (ยกเว้นพวก tech. practices) แต่มันสอดคล้องกับงานที่นั่นจริงๆ แบบที่ใครมาอ่านก็จะงงๆ ว่านี่แปลว่าอะไรนะ
ผมก็เลยพบว่า อ๋อ คำตอบของรู้สึกความไม่สอดคล้องมันถูกปลดล็อคตอนนี้นี่เอง คือ ภายใต้สภาวะแวดล้อมของการทำงานที่เหมาะสม เมื่อทีมเกิดกระบวนการ inspect & adapt บ่อยๆ ความรู้และประสบการณ์ของทีมจะเริ่มออกแบบวิธีการที่เป็นแนวทางของทีมเองได้จริงๆ มันไม่ได้ผิดนะที่วันแรกเราจะกำหนดอะไรที่ดู “ไม่สอดคล้อง” กับความรู้สึก เพราะวันที่เริ่ม “ความรู้เรามีแค่นี้ “ (ถ้าไม่เริ่มก็ไม่ได้ทำซะที — start with something) แต่เมื่อได้ทำไปหลายๆรอบ ได้ลอง ได้ลงมือทำ พอความรู้มันก็จะถูกบ่มเพาะมากพอ เดี๋ยววิธีการที่ดีกว่ามันจะออกมาเอง
ผลลัพธ์ของมัน (หมายถึง DoD) อาจจะไม่ได้ดีหรือ makesense กับที่อื่น แต่สำหรับที่นี่ตอนนี้ มัน ok มาก ดีพอแล้วที่จะไปต่อและขึ้น production ได้ เดี๋ยวถ้าต่อไปทีมมีความรู้มากขึ้น มันก็จะดีกว่านี้ได้อีก และที่มันเกิดได้ ก็เพราะทีมมีจังหวะได้หยุด และ inspect งานที่ทำไป และ adapt ไปในแนวทางที่ดีกว่าเดิม
แต่สิ่งที่ดีกว่ามากๆเลยก็คือ มันออกมาจากทีมเองโดยที่ไม่มีใครมาสั่งให้ทีมทำ มันสัมผัสได้ว่าทีมเก่งขึ้นกว่าเดิมไปอีกก้าวนึง
สรุป
การเริ่มโดยที่ยังไม่แน่ใจมันก็ไม่ได้ผิดอะไรนะ ถ้าวัตถุประสงค์ของมันยังถูกต้องอยู่ เมื่อถึงจุดนึงที่ความรู้เรามากขึ้น สิ่งที่เริ่มไว้ก็จะถูกปรับให้เหมาะกับการนำไปใช้งาน สำหรับผมแล้ว “ความรู้สึกไม่สอดคล้องในใจ” จึงเป็นเรื่องดีนะที่จะทำให้เราไม่เชื่อหรือไว้ใจมันมากเกินไป ขอแค่ยังคง inspect & adapt ต่อไป มันจะเกิดการเรียนรู้และพัฒนาไปเรื่อยๆ ไม่งั้นของที่กำหนดไว้ตอนแรกมันจะกลายเป็นของศักดิ์สิทธิ์ที่เรายึดไว้จนไม่ยอมพัฒนาไปไหนเลย
ขอบคุณที่เข้ามาอ่านกัน และหวังว่าจะได้ประโยชน์จากสิ่งที่ผมเล่าให้ฟังครับ
