อ่านบทความจากการทำแบบสำรวจเมื่อปี 2018 (เก่าแล้ว แต่น่าจะมีโยชน์)
เป็นเรื่อง Developer Team Performance :: Why your team slows down and What to do about it
จากการสำรวจได้ข้อมูลที่น่าสนใจมากมาย
เนื่องจากมีสาเหตุมากมายที่ส่งผลให้ทีมช้าลง ทั้งจากภายนอกและภายใน
ล้วนนำไปสู่การส่งมอบงานที่ล่าช้าและไม่ตรงตามที่คาดหวัง
แน่นอนว่า มันเกิดขึ้นบ่อยมาก !!!

คำถามคือ เมื่อเรารู้ต้นเหตุแล้ว เราจะลงมือแก้ไขอย่างไรดี ?
ตรงนี้น่าจะเป็นประเด็นหลักมากกว่า

เริ่มจากอะไรบ้างที่ทำให้ทีมช้าลง ?

แยกออกมาตามตำแหน่ง

  • Manager บอกว่า เปลี่ยน requirement เป็นหลัก ซึ่งเปลี่ยนขณะที่กำลังทำด้วย รองลงมาก็เรื่องการติดต่อสื่อสาร และการประชุมที่เยอะ
  • Developer บอกว่า เรื่องของ technical debt  และ interruption (หลัก ๆ มาจากการประชุมที่เยอะมาก ๆ)
  • Dev Manager บอกว่า เรื่องของ technical debt และ interruption (หลัก ๆ ต้องไปแก้ไขปัญหาเฉพาะหน้าและช่วยคนอื่น)

อีกเรื่องคือ Technology stack ที่ใช้งาน ก็เป็นปัญหาอีก
บางส่วนมีการทำงานแบบอัตโนมัตินะ
แต่ปัญหาคือ ทำงานช้า ได้รับ feeback ช้ามาก ๆ

จากผลการสำรวจ ไม่น่าแปลกใจอะไรเลย
เพราะว่าเป็นปัญหา classic ที่ไม่แก้ไขกันใช่ไหม ?

จากบทความบอกว่า จะทำอะไรหรือแก้ไขปัญหาใด ๆ ต้องใช้ข้อมูลเป็นหลัก

เพื่อจะได้รับรู้ปัญหาที่แท้จริง
ยกตัวอย่างเช่น
การพูดคุยกับทีมงาน ให้ทำการ tracking เวลาที่ใช้จริง ๆ
ในแต่ละวัน เป็นเวลา 2-3 สัปดาห์ 
มันอาจจะเป็นงานที่ยากหรือน่าเบื่อสำหรับทีม
แต่มันเป็นวิธีการที่ให้ได้ข้อมูลที่ง่ายและมาจากคนทำงานจริง
น่าจะเชื่อถือได้ดี

โดยแนะนำให้ใช้เครื่องมือง่าย ๆ 
ยกตัวอย่างเช่น Excel หรือ Google Spreadsheet ไปเลย
กำหนดลงไปเลยว่า แต่ละวันทำงานอะไรบ้าง ใช้เวลาเท่าไร
ให้ลงทั้งเวลาการทำงาน และเวลารอจากคนอื่นด้วย
ข้อมูลอาจจะไม่ถูกต้อง 100% แต่ก็ทำให้เราเห็นปัญหาได้ดี

หรืออีกวิธีการคือ การพูดคุยแบบหนึ่งต่อหนึ่งกับแต่ละคนไปเลย
เพื่อสอบถามว่า อะไรคือต้นเหตุให้ทีมช้าลง
น่าจะทำให้เราเข้าใจปัญหาเชิงลึกมากขึ้น
แต่ก็ใช้เวลานานมากเช่นกัน

เมื่อได้ข้อมูลแล้ว ก็ไปดูว่าการทำงานของทีมเป็นอย่างไร ?

Product หรือ project ที่ทำนั้น มีเป้าหมายอย่างไร ?
ต้องใช้ Technology อะไรบ้าง ที่จะทำให้ไปถึงเป้าหมายที่ตั้งไว้ ?
ก่อนงานที่จะเข้ามานั้น มีการจัดการ prioritize หรือไม่ ?
(ไม่ใช่ด่วนและด่วนมากนะ หรือ จะเอาเดี๋ยวนี้)

อีกอย่างต้องดู capacity ของทีมด้วย ว่าตอนนี้เป็นอย่างไร ?
ถ้า capacity ของทีมเต็มแล้ว สิ่งที่จะเข้ามาต้องรอในคิวเสมอ !!

การพูดคุยก็เช่นกัน ต้องเป็นการพูดคุยที่มีประสิทธิภาพ

ไม่ใช่การมาตาม progress หรือ รายงาน progress งาน    
แต่ต้องเป็นการพูดคุยแบบสองทาง
เปิดเผยการเปลี่ยนแปลงต่าง ๆ
เปิดเผยปัญหาต่าง ๆ ที่พบเจอ
เพื่อให้ทีมรับทราบ และช่วยกันแก้ไข

ต่อมาก็เรื่องของ feedback loop หรือการ review performance แบบเป็นระยะ

หรือเป็นช่วงระยะเวลาแบบต่อเนื่องเป็น feedback
แบบ 2 ทางคือ ทั้งให้และรับ
รวมถึงการพูดคุยแบบหนึ่งต่อหนึ่งมันช่วยทำให้เราเห็นผลการปรับปรุงที่ดีขึ้น

เรื่องของการประชุมก็เช่นกัน ควรมีการเพิ่มหรือลดให้เหมาะสม

ประชุมอะไรที่เข้าไปแล้วไปนั่งฟังเฉย ๆ ก็ไม่ควรเข้า
ประชุมอะไรที่ไม่มี objective และ agenda เลย ก็ควรยกเลิกไป
ประชุมควรมี objective และขอบเขตเวลาที่ชัดเจน
ทุกการประชุมต้องมี action plan เสมอ
รวมทั้งมีการกำหนดให้เลยว่า ใครต้องไปทำมาบ้าง
มิฉะนั้น มันจะเป็นการประชุมเพื่อประชุมครั้งต่อไป ซึ่งเปลืองมาก ๆ !!

The Golden Rule of meetings, says Cohen, is to “make sure you have a clearly defined purpose for each one.”

เรื่องสุดท้ายคือ Technology ที่ใช้งาน

ในส่วนนี้ควรมีการ update เรื่องนี้กันบ่อย ๆ
ทั้งเรื่องความรู้ความเข้าใจ
ทั้งเรื่องสิ่งที่ใช้งานมีปัญหาหรือไม่ อย่างไร
ทั้งเรื่องสิ่งที่ใช้มัน out-of-date หรือยัง ควรทำงาน upgrade ไหม
ทั้งเรื่องควรเปลี่ยนไปใช้ technology ใหม่ ๆ หรือไม่
เพราะว่า มันอาจจะเป็นสิ่งที่ทำให้ช้าลง
หรือเป็น technical debt ก็ได้
หรือของใหม่ ๆ อาจจะก่อให้เกิดปัญหาก็ได้เช่นกัน

ดังนั้นการเลือกก็สำคัญ เช่น

  • มีอะไรที่จะนำมาแทนที่ได้บ้าง ?
  • สิ่งที่เลือกมาใช้งานนั้น มีความซับซ้อนเกินไปหรือไม่ ? ลดความซับซ้อนได้หรือไม่ ?
  • สิ่งที่เลือกมานั้น ช่วยทำให้ระบบการทำงานเป้นแบบอัตโนมัติ หรือ ง่ายขึ้นหรือไม่ ?
  • มีความรู้ความเข้าใจหรือไม่ ถ้ายังไม่มีก็ควรต้องทำการศึกษาและทดลองดูก่อน

สุดท้ายแล้ว เราควรต้องรู้และยอมรับก่อนว่า เรามีปัญหาอะไรบ้าง ?

ที่ทำเราให้ช้าลง จากนั้นแนะนำให้ค่อย ๆ แก้ทีละปัญหา
ดูผลการแก้ไข และ ปรับปรุงอย่างต่อเนื่อง