Deadline-Driven Development
Deadline เป็นเรื่องปกติที่เราจะเจอในการทำงานและหลีกเลี่ยงไม่ได้ซะด้วย ด้วยความที่ธุรกิจมีการแข่งขันสูง ตลาดเปลี่ยนแปลงรวดเร็ว บ่อยครั้งที่เราพบว่าลูกค้าต้องการมากกว่าสิ่งที่เรานำเสนอไป ทุกอย่างมันเร่งไปหมด สิ่งที่ตามมาคืองานเผา งานลวก งานไม่เนียน และมี bug ตามมา แล้วมีแนวทางไหนไหมที่จะใช้รับมือกับ deadline ได้
ช่วงสองสามสัปดาห์ที่ผ่านมา ผมได้มีโอกาสไปเรียน LeSS (Large Scale Scrum) กับ Bas Vodde ซึ่งเป็นเรื่องของการนำ Scrum Framework ไปใช้กับทีมพัฒนาขนาดใหญ่ ได้รับความรู้เพิ่มขึ้นอีกเพียบเลย ถ้าใครเคยเรียนคอร์ส Certified Scrum Master (CSM) กับ Bas จะรู้ว่า Bas เน้นเรื่อง principles มาก เพราะลำพัง process หรือ rules มันช่วยแก้ปัญหาแค่ระดับนึงเท่านั้น แต่ principles จะทำให้เราเข้าใจปัญหา เข้าใจที่มาของกระบวนการอย่างเป็นเหตุเป็นผลว่า process หรือ rules เหล่านั้นถูกคิดขึ้นมาเพราะอะไร
มีหลายเรื่องที่ผมจำได้และถือว่าเป็น key takeaway เลย อย่างเรื่อง “Best Practice” Bas บอกว่ามันไม่มีจริงนะ เพราะ Best Practice มันมาจาก solution ที่ใช้แก้ปัญหาหนึ่ง ณ เวลานั้นแล้วมัน work คนเลยคิดไปว่า เออนี่แหละวิธีที่ดีที่สุดแล้ว แต่ก็ไม่ได้หมายความว่าวิธีการเดียวกันจะเอามาแก้ปัญหาอีกที่นึงได้เสมอไป ที่สำคัญ คำว่า Best Practice มันนำไปสู่ปัญหาอื่นนะ คือ
- ถ้าใครมองหา Best Practice แสดงว่าคุณเป็นผู้ตามที่ยอดเยี่ยม อย่าหวังเลยว่าจะไปชนะใครได้
- เมื่อมันเป็น The Best แล้ว คนจะไม่พยายามทำให้ดีกว่าเดิม ไม่เกิด experiment & learning เพราะไม่กล้าลองของใหม่ กลัวพลาด ไม่เกิด continuous improvement กลายเป็น business as usual … ธุรกิจของคุณก็รอวันโดน disrupt ไป
แต่เรื่องที่สะกิดผมให้เขียน blog ที่คุณกำลังอ่านอยู่เป็นอีกเรื่องนึง นั่นคือเรื่อง Commitment ซึ่ง Bas บอกว่า เคยใช้ System Thinking เพื่อวิเคราะห์ถึงปัญหาที่กำลังเกิดขึ้นในองค์กรแล้วพบว่า Commitment เป็นต้นเหตุ (Root Cause) ของปัญหาทั้งหมดที่เกิดขึ้น เพราะใครซักคนไป commit เอาไว้ว่าได้แน่ๆ แล้วพบว่างานมันมากกว่าที่คิดไว้ พอไม่ได้ก็กำหนด deadline แล้วกระบวนการบี้งานก็ตามมา สุดท้าย Management จึงเลิกใช้ Commitment แล้วพบว่าปัญหาส่วนใหญ่หายไปเกือบหมด ผมเลยนึกถึงเรื่อง เบอร์เกอร์กระรอกที่ Bas เคยสอนใน class CSM ขึ้นมา มันเป็นยังไงเหรอ ผมจะเล่าให้ฟัง…
Squirrel Burger
!!! Spoil Alert !!! เนื้อหาต่อไปนี้จะมีการสปอยล์ class CSM ถ้าใครอยากรอไปเรียนเอง ขอให้ข้ามไปหัวข้อ Developer Secret Toolbox เลยครับ
สมมติว่าคุณเป็นพนักงานของร้านแฮมเบอร์เกอร์พรีเมี่ยมร้านหนึ่ง ตั้งอยู่ย่านใจกลางเมืองในแหล่งผู้มีรายได้สูง ร้านของคุณใช้วัตถุดิบคุณภาพสูง สดใหม่ ราคาก็เลยสูงตามไปด้วย อย่างเช่น แฮมเบอร์เกอร์เนื้อที่ราคาถูกที่สุดอยู่ที่ 259 บาท (ใช้เนื้อหนาคัดเกรดอย่างดี) ถ้าเป็นเมนูที่แพงที่สุดก็เริ่มต้นที่ 599 (ไม่รวมเครื่องดื่มและอื่นๆ)
เช้าวันหนึ่ง มีลูกค้ามีเงินเดินเข้ามาในร้านด้วยอารมณ์ขุ่นๆ สั่งอาหารเสียงดังว่า “ผมต้องการดับเบิ้ลชีสเนื้อ ออสเตรเลียนเบอร์เกอร์ขนาดใหญ่พิเศษ เฟรนช์ฟราย XL และโคล่าแก้วใหญ่ และผมจะจ่ายแค่ร้อยเดียวเท่านั้น” ครับ เซ็ตนี้เป็น custom ซึ่งแพงกว่าเมนูที่แพงที่สุดด้วย ซึ่งไม่ว่าคุณจะพูดยังไงเค้าก็ยืนกรานคำเดิมและไม่ยอมไปไหนจนกว่าจะได้สิ่งที่เค้าต้องการ
… ผมให้เวลาคุณ 3 นาที คุณลองคิดดูครับว่าคุณจะรับมือลูกค้ารายนี้ยังไง …
… ติ๊ง หมดเวลา …
ลองดูทางเลือกที่ผมได้ยินใน class ตอนนั้นกันครับ
- พนง. : “ยังไงก็ไม่ได้ครับ ราคาที่คุณสั่งมันประมาณ 750 ครับ”
ลูกค้า : “มันไม่ใช่ปัญหาของผม ผมต้องการดับเบิ้ลชีสออสเตรเลียนเบอร์เกอร์ขนาดใหญ่พิเศษ เฟรนช์ฟราย XL และโคล่าแก้วใหญ่ และผมจะจ่ายแค่ร้อยเดียวเท่านั้น” - พนง. : “งั้นผมจะจัดชุดเล็กให้นะครับ ได้ทุกอย่างครบ แต่ปริมาณอยู่ภายใต้งบประมาณแน่นอน”
ลูกค้า : “คุณไม่ได้ยินที่ผมพูดรึไง!!! ผมต้องการดับเบิ้ลชีสออสเตรเลียนเบอร์เกอร์ขนาดใหญ่พิเศษ เฟรนช์ฟราย XL และโคล่าแก้วใหญ่ และผมจะจ่ายแค่ร้อยเดียวเท่านั้น” - พนง. : “เปลี่ยนเมนูไหมครับ ทางร้านมีเมนูอื่นที่น่าสนใจ…”
ลูกค้า : “นั่นไม่ใช่สิ่งที่ผมต้องการ!!! ผมต้องการดับเบิ้ลชีสออสเตรเลียนเบอร์เกอร์ขนาดใหญ่พิเศษ เฟรนช์ฟราย XL และโคล่าแก้วใหญ่ และผมจะจ่ายแค่ร้อยเดียวเท่านั้น”
เจอแบบนี้รับมือยากเลย ครับ ลองอ่าน solution ที่ Bas เฉลยกันดีกว่า…
เมื่อลูกค้ายืนกรานไม่ยอมท่าเดียว พนักงานคนนั้นก็บอกลูกค้าว่า “ได้ครับ กรุณารอสักครู่” จากนั้นเค้าก็เดินไปที่โคนต้นไม้หน้าร้าน เพราะตอนเช้าก่อนเปิดร้านเค้าจำได้ว่ามีกระรอกนอนตายอยู่ตรงนั้นพอดี เค้าหยิบขึ้นมาตรวจดูก็พบว่าเพิ่งตาย เนื้อยังไม่เน่า น่าจะกินได้ ก็เลยเอาซากกระรอกตัวนั้นไปลอกหนังออก ตัดเฉพาะส่วนเนื้อแล้วเอาย่างบนเตาอย่างพิถีพิถัน ทาซอสสูตรที่ลูกค้าต้องการ ส่วนขนมปังกับเฟรนซ์ฟรายก็เอาจากของที่เหลือเมื่อวานที่ยังไม่ได้ทิ้งมาอบใหม่ สำหรับโคล่าก็ไม่ยาก พนง. ก็เทเอาจากแก้วที่ลูกค้ากินเหลือไว้ในร้านรวมๆ กันให้เต็มแก้ว แล้วจัดชุดให้ลูกค้าไปในราคา 100 บาท
ในความเป็นจริงคงไม่มีใครทำแบบนั้น เพราะถ้าลูกค้ากินเข้าไปก็อาจจะท้องเสีย เสียชื่อร้าน เผลอๆ ลูกค้าอาจจะตายได้ แต่ขอโทษครับ ในวงการพัฒนาซอฟท์แวร์เราเจอแบบนี้กันบ่อยมาก
Developer Secret Toolbox
ผมลองเปลี่ยนบทบาทจากลูกค้าเป็นเจ้านาย พนักงานคนนั้นเป็นทีมพัฒนาซอฟท์แวร์ดูนะ
… เช้าวันหนึ่ง เจ้านายเดินเข้ามาในแผนกด้วยอารมณ์ขุ่นๆ สั่งงานเสียงดังว่า “ผมต้องการให้ทีมทำ feature @&฿@&#%*^%^ (แทนค่าด้วย feature ยากๆ ใหญ่ๆ เบลอๆ เข้าไป) และลูกค้าของผมต้องได้ใช้วันที่ X เดือน Y เท่านั้น” ครับ feature เหล่านั้นเป็น custom ซึ่งใหญ่กว่า feature ที่ใหญ่ที่สุดเท่าที่เคยทำมาด้วย ซึ่งไม่ว่าคุณจะพูดยังไงเค้าก็ยืนกรานคำเดิมและไม่ยอมไปไหนจนกว่าจะได้สิ่งที่เค้าต้องการ…
แล้วเราทำกันยังไงนะ? ปฏิเสธได้ไหมครับ?
เมื่อทีมพัฒนาซอฟท์แวร์โดนกำหนด deadline และต้องทำงาน OT ด้วย เค้าจะเริ่มหยิบเครื่องมือลับของเค้าออกมาใช้ มีอะไรบ้างเรามาดูกัน
- Google หาวิธีเขียน ไปเจอคำตอบใน StackOverflow จากนั้นก็ copy แล้วแปะลงบน production โดยที่ไม่ได้เข้าใจ logic เลย (ถ้าโชคร้าย เค้าจะ copy คำถามมา ซึ่งได้ bug มาด้วย)
- ไม่เขียน Unit Test ไม่แม้แต่จะ manual test
- Hard code, Duplicate Code
- ไม่ออกแบบ / ไม่ refactor code
- ไม่จัดการกับ Error (กรณีที่เกิด Exception หรือ fail case)
- บอกว่า “เสร็จแล้ว” (แต่ไม่มีข้อ 2–5 เต็มไปหมดเลย)
สุดท้าย องค์กรนั้นก็จะมีเบอร์เกอร์กระรอกอยู่ในระบบเต็มไปหมดเลย ที่สำคัญคนที่เขียน code แบบนี้เอาไว้เค้าไม่อยู่แก้ครับ โดนบี้ deadline + ทำ OT บ่อยๆ เดี๋ยวเค้าก็ลาออก ปล่อยให้ของแย่ๆ อยู่ในระบบ เหมือนกับระเบิดที่รอคนมาเหยียบ (คนที่มาแก้ตอนที่ bug โผล่มานั่นแหละ) จนถึงจุดนึงที่ผู้ใหญ่รู้สึกว่ามันไม่ไหวแล้ว รื้อเขียนใหม่เถอะ แล้วก็วน loop แบบเดิม…
ถ้าเราไม่เปลี่ยนวิธีการทำงาน คุณคิดว่าของใหม่มันจะต่างกับของเดิมไหมครับ?
ผมเคยเข้าไปช่วยองค์กรหนึ่งที่มีเบอร์เกอร์กระรอกแบบนี้เต็มไปหมด วันนั้นไม่มีใครทำอะไรได้แล้วครับ มันเหมือนคนไข้ที่เป็นมะเร็งระยะสุดท้ายที่ลามไปทั่วตัวแล้ว สุดท้ายองค์กรนั้นก็ต้องปิดตัวลงและขายกิจการให้คู่แข่งไป เราคงไม่อยากให้องค์กรของเราเป็นแบบนั้นใช่ไหมครับ?
Software Development Craftsmanship
สำหรับนักพัฒนาซอฟท์แวร์มืออาชีพแล้ว งานพัฒนาซอฟท์แวร์ถือเป็นอาชีพที่ต้องมีจรรยาบรรณ์เหมือนกับหลายๆ วิชาชีพ เช่น หมอ หรือ พยาบาล ในวันที่เราเขียนโปรแกรมแบบชุ่ยๆ เราไม่รู้หรอกว่าในวันข้างหน้ามันจะส่งผลเสียกับอะไรบ้าง แต่ไม่ว่าจะมีเหตุผลใดก็ตาม ก็ไม่ใช่เหตุผลให้เราต้องทำงานแย่ๆ ออกไป
การฝึกฝีมือก็เหมือนกับงานช่างฝีมือแขนงอื่นๆ ที่เราต้องเรียนรู้เทคนิคใหม่ๆ และฝึกฝนตัวเองบ่อยๆ เพื่อให้สามารถ craft งานได้อย่างมืออาชีพ ทุกวันนี้การเรียนเขียนโปรแกรมง่ายขึ้นมาก มีทั้ง blog ฟรี, course online, รวมถึงหนังสืออีกมากมายที่พูดถึงการเพิ่มคุณภาพของการพัฒนาซอฟท์แวร์ ไม่ว่าจะเป็นการเขียน Unit Test, การทำ TDD, การทำ Test Automation, เครื่องมือการทำ Continuous Integration / Continuous Delivery การทำ UX/UI ที่ดีทั้งฟรีทั้ง opensource เต็มไปหมด เราสามารถฝึกฝนตัวเองให้เก่งขึ้นไปได้เรื่อยๆ โดยที่ไม่จำเป็นต้องสร้างเบอร์เกอร์กระรอกก็ได้
Organization
แต่แค่เขียน code ให้ดีมันไม่พอครับ ฝ่ายบริหารเองก็ต้องเข้าใจภาพของการพัฒนาซอฟท์แวร์ด้วย เพราะต่อให้นักพัฒนาคราฟท์งานโดยไม่ทำเบอร์เกอร์กระรอก เค้าจะทนได้นานแค่ไหนกับงานปริมาณมากมายในระยะเวลาที่เป็นไปไม่ได้ สุดท้ายถ้าไม่แพ้ด้านมืดของตัวเองทำงานแบบชุ่ยๆ ออกมาเค้าก็ลาออก กลายเป็นองค์กรต้องเสียคนมีฝีมือไปอีก ความต่อเนื่องในการพัฒนาองค์กรก็เสียไป
มันมีวิธีรับมือกับ Deadline อยู่นะ แต่ต้องเปลี่ยนวิธีคิดก่อน ลองมาดูกันครับ
- Customer-Centric :- วันนี้มีการพูดถึง User Experience (UX) กันอย่างกว้างขวาง หลายคนเข้าใจว่าการออกแบบ UX คือการออกแบบ application เพื่อให้ user ใช้ง่าย แต่มันมากกว่านั้นนะ UX เป็นกระบวนการที่ทำให้เกิดความเข้าใจปัญหาของลูกค้าอย่างแท้จริงว่า การที่เค้าจะมาใช้สินค้าหรือบริการของเราเนี่ยะ เค้ามีปัญหาอะไรในชีวิต แล้วสินค้าและบริการของเราจะช่วยให้ชีวิตเค้าดีขึ้นได้ยังไง ไม่ใช่คิดแค่ว่า app เราควรจะมี feature แบบนั้นแบบนี้แต่ไม่ได้ทำให้ชีวิตลูกค้าดีขึ้นเลย เผลอๆ solution มันจะกลายเป็น problem แทน
ถ้าเข้าใจลูกค้าเราอย่างแท้จริงแล้ว feature ที่เราเคยคิดว่าต้องมีอย่างนั้นอย่างนี้ ต้องมีเยอะๆ จะได้เหนือกว่าคู่แข่ง มันจะกลายเป็นเรื่องไร้สาระทันที และสุดท้ายแล้ว feature ที่มีคุณค่ากับลูกค้า อาจจะเหลือแค่ 5% ของที่คิดเอาไว้ เมื่อถึงตอนนั้น การทำทุก feature ให้ทัน deadline ก็ไม่ใช่เรื่องจำเป็นอีกต่อไป
คุณไม่ต้องเอาคู่แข่งเป็นเป้าหมายในการเอาชนะก็ได้นะ แก้ปัญหาให้ลูกค้าให้เค้ามีชีวิตที่ดีขึ้นดีกว่า
- Prioritized for Outcome — Not Output :- เมื่อมี deadline และมี feature มากกว่าที่ทีมจะสามารถทำได้ สิ่งแรกที่ต้องทำคือจัดลำดับความสำคัญ แต่เราจะรู้ได้ยังไงว่าอันไหนสำคัญกว่ากัน
ในช่วงต้นๆ ของหนังสือชื่อ User Story Mapping ของ Jaff Patton ได้อธิบายคำว่า Output และ Outcome โดยที่ Output หมายถึง feature ของ app ในขณะที่ Outcome คือผลลัพธ์ที่ users/customers/company ได้รับจาก feature นั้นๆ
เพราะฉะนั้น วิธีการประเมินว่า feature ไหนมี priority สูงกว่ากัน ก็ให้ดู feature ที่ลูกค้าและองค์กรจะได้รับ Outcome สูงสุด โดยไม่เน้นที่ Output ว่าจะต้องมี feature เยอะๆ
นอกจากนี้ ยังมี Principle ที่ LeSS นำมาใช้อีกหลายข้อที่น่าสนใจ ตัวอย่างเช่น
- Queueing Theory :- อธิบายถึงตัวแปรต่างๆ ในระบบที่จะทำให้เราเห็นภาพว่า ถ้าเราต้องการความคล่องตัว สิ่งที่เราต้องประเมินคือ “ทำอย่างไร จึงจะทำให้เวลาเฉลี่ยของการพัฒนา 1 feature เสร็จสั้นที่สุด (end-to-end ตาม Definition of Done)” ไม่ใช่ทำอย่างไร จึงจะทำให้ทำ feature ออกมาได้มากที่สุด
เปรียบเทียบได้เหมือนกับการวัดคุณภาพของการจราจร เค้าไม่ได้วัดว่าถนนสามารถรองรับปริมาณรถได้สูงสุดเท่าไหร่ แต่จะวัดว่า ณ เวลาหนึ่งๆ ถนนสามารถระบายรถได้กี่คันต่อชั่วโมง เพราะถ้าวัดที่ความสามารถในการรับปริมาณรถแล้ว ก็ต้องคิดว่า ถนนจะต้องรับรถได้ 100% ของพื้นผิว ซึ่งในความเป็นจริง ความเร็วเฉลี่ยของรถจะลดลงเมื่อถนนมีรถประมาณ 50% ทำให้อัตราการระบายรถลดลงอย่างมาก ยิ่งระบายรถได้ช้ารถยิ่งติด
การพัฒนาซอฟท์แวร์ก็เช่นเดียวกัน ยิ่งใส่ feature ให้ทีมทำเยอะๆ กว่าจะได้ feature นึงไปใช้งานก็นาน พอฝ่ายบริหารเห็นว่าของออกช้า ก็เอา deadline มา challenge ก็ยิ่งทำให้ทีมต้องเผางาน กลายเป็นได้ของคุณภาพแย่ๆ แทน พอขึ้น production งานมี bug ก็ต้องกลับมาแก้ bug ในขณะที่ feature ใหม่ก็เพิ่มเข้ามาเรื่อยๆ กลายเป็นได้เบอร์เกอร์กระรอกเต็มระบบไปหมด คนในวงการพัฒนาซอฟท์แวร์จึงหายากเพราะทำไปซักพักก็ลาออกแล้วไปทำอย่างอื่นแทนเพราะต้องเจอกับเรื่องแบบนี้ตลอดเวลา
- Empirical Process Control :- การพัฒนาซอฟท์แวร์ เป็นปัญหาที่ซับซ้อน (Complex) เราไม่สามารถ fix time/ fix scope กับ software product ได้ (ตรงกันข้ามกับ Defined-Process ที่คิดว่า software สามารถกำหนด scope ที่แน่นอนได้) เราต้องใช้กระบวนการที่วางกรอบไว้กว้างๆ มีรอบการทำงานสั้นๆ เพื่อให้เกิด feedback loop ที่เร็ว แต่ในขณะเดียวกันต้องเห็นรายละเอียดได้แบบโปร่งใสทุกขั้นตอน (Transparency) เพื่อให้เห็นข้อผิดพลาดได้อย่างรวดเร็ว (Inspect) และสามารถปรับปรุงพัฒนาได้อย่างต่อเนื่อง (Adapt) ทั้งตัว product เองและทีมพัฒนา ซึ่งจะช่วยให้องค์กรสามารถปรับเปลี่ยนการทำงานเพื่อรับมือกับความเปลี่ยนแปลงได้อย่างรวดเร็ว
การเข้าใจเรื่อง Empirical Process จะช่วยให้เราเข้าใจว่าการพัฒนาซอฟท์แวร์มันไม่มีสูตรสำเร็จ มันต้องทำไปเรียนรู้ไป เรียนรู้ทั้งตัวลูกค้า เรียนรู้ตัวสินค้า เรียนรู้ตลาด เรียนรู้เทคนิคใหม่ๆ เพื่อให้เกิดการพัฒนาอย่างต่อเนื่องและยั่งยืน
- Human — Not Resources :- เราน่าจะเคยอ่านหรือเคยได้ยินจากหนังสือหรือบทความมาแล้วมากมายว่า บุคลากรคือทรัพย์สินที่มีค่าที่สุดขององค์กร การนิยามว่าคนเป็น resource ก็เหมือนกับกำหนดกลายๆ ว่า คนที่รับเข้ามามี function งานเดียว เหมือนตอนที่รับเข้ามาและไม่สนับสนุนให้คนเกิดการเรียนรู้และพัฒนา และใช้คนที่ถูกจ้างมาให้คุ้มค่าจ้าง เปรียบเทียบเหมือนซื้อ printer ก็คือ print อย่างเดียว หมึกหมดก็โยนทิ้งไป แนวคิดแบบนี้ยิ่งผลักให้คนเก่งลาออกจากองค์กรเร็วขึ้นเรื่อยๆ
Conclusion
ถ้าใครเคยอ่าน หรือเคยได้ยินทฤษฎีเรื่อง Scientific Management ของ Frederick Taylor ก็จะรู้ว่า Taylor ใช้แนวคิด “แยกคนที่คิดวิธีการทำงาน” ออกจาก “คนทำงาน” (เรียกกันว่า Taylorism) เพราะเชื่อว่า ผู้คนในยุค 1900 ที่เข้ามาทำงานในโรงงานอุตสาหกรรมนั้นโง่และไร้การศึกษา จึงออกแบบกระบวนการให้คนเหล่านั้นทำงานง่ายๆ ซ้ำๆ ทำแค่ขั้นตอนเดียว ไม่ต้องคิดมาก ซึ่งมันอาจจะประสบความสำเร็จในช่วงนั้น แต่ลองคิดดูว่า วันนี้ ปี 2018 ในงานพัฒนาซอฟท์แวร์ นักพัฒนาซอฟท์แวร์ไม่ใช่คนโง่ไร้การศึกษาอีกต่อไป การแยกกระบวนการคิดออกจากคนทำงานจะทำให้ทีมไม่มีส่วนในการคิดและตัดสินใจว่าวิธีทำงานแบบไหนที่น่าจะดีกว่า ยิ่งทีมมีส่วนร่วมน้อยเท่าไหร่ ยิ่งมี ownership ต่อ product น้อยลงไปเท่านั้น
ถ้าคุณเห็นองค์กรไหนยังใช้คำว่า “Put the right man to the right job.” นั่นละครับ ผลพวงของ Taylorism มันคงยากที่องค์กรนั้นจะสร้าง self-managing team ขึ้นมาได้
แนวทางของ Agile Software Development จึงเป็นแนวทางที่เน้นให้ผู้บริหารสร้างทีมที่คิดและทำงานได้โดยสมาชิกในทีมเองอย่างมีประสิทธิภาพ (Self-Managed Team) เปิดโอกาสให้ทีมได้ทดลองแนวทางใหม่ๆ (Experiment) และเรียนรู้ (Learn) จากสิ่งที่ได้ทดลอง เพื่อพัฒนาตนเองให้ดีขึ้นเรื่อยๆ (Inspect & Adapt) โดยเปลี่ยนบทบาทไปเป็น Coach, Teacher, Mentor จากความรู้และประสบการณ์ที่ตนเองมีมา ด้วยหลักแนวคิดแบบ GoSee แทนการสั่งงานและควบคุม (Command & Control)
กระบวนการเปลี่ยนแปลงเหล่านี้ต้องใช้เวลานาน อาจจะเป็นปีหรือหลายปีกว่าจะเห็นผลจากการลงมือทำ ยิ่งเป็นองค์กรขนาดใหญ่ยิ่งต้องใช้เวลา แต่สิ่งสำคัญคือต้องเริ่มจากความเข้าใจเรื่องของการพัฒนาซอฟท์แวร์ยุคใหม่ ที่วันนี้ไม่ว่าธุรกิจไหนก็ต้องอาศัยซอฟท์แวร์ทั้งนั้น การสร้างนักพัฒนาก็ทำได้ยาก ยิ่งนักพัฒนามีคุณภาพยิ่งน้อยเข้าไปอีก หากไม่สร้างทีมให้เกิดการพัฒนาที่ยั่งยืนก็ยากที่จะแข่งขันกับคู่แข่งได้ทัน
ทั้งหมดนี้เป็นส่วนหนึ่งจากที่ผมได้เรียนรู้จาก class Certified Scrum Master และ LeSS Practitioner ของ Bas ผมหวังว่าน่าจะมีประโยชน์กับทุกคนที่อ่านมาถึงตรงนี้นะครับ ขอบคุณที่สละเวลาอ่านครับ ^^
