ทีมที่งานที่เสร็จแล้วใช้งานได้
ในหลายๆอุตสาหกรรม จะมีวิธีการจัดการในการผลิตผลงานออกมาแตกต่างกัน แม้แต่ในอุตสาหกรรมซอฟท์แวร์เอง ซึ่งในหลายกรณีมันจะสะท้อนออกมาอยู่ในรูปแบบการจัดการองค์กรนั้นด้วย
ผมยกตัวอย่างการจัดการทีมแบบแยกตาม function เช่นทีม Dev ที่มีการแยกเป็น ทีม Backend ทีม Frontend Web ทีม Frontend iOS ทีม Frontend Android ทีม DevOps ทีม Operations Support
การแบ่งทีมตาม function จะช่วยให้แต่ละทีมมี skillset เฉพาะชัดเจน และทีมจะชำนาญงานนั้นๆมาก โดยส่วนตัวผมมักจะเห็นการแบ่งทีมแบบนี้ กับการใส่งานลงไปแบบที่มองทีมเป็น pool โดยไม่ว่าใครจะอยากได้งานแบบไหน ก็จะมีทีม PM/BA/Architect ไปคุยกันมาจนเสร็จ เหลือแค่เขียนโค้ด ก็จะแยกงานตาม function แล้วโยนใส่ pool ลงไป เดี๋ยวก็เสร็จ
ปัญหาของการมีทีมลักษณะนี้คือ แต่ละทีมจะมี Lead Time ไม่เท่ากันซึ่งถ้าเราใช้ทีมแบบนี้มาทำงานแบบ Agile เราจะเจอปัญหาว่า เมื่อเรามี story เข้ามา เราจะไม่สามารถคาดเดาได้ว่า story นี้จะเสร็จได้หรือไม่ เนื่องจากเราต้องใช้บริการของ pool ซึ่งอาจจะมีงานล้นมืออยู่แล้ว และ story นี้ก็จะต้องไปต่อคิว
หรือแม้แต่เราจะสามารถ stop the world ทุกงาน แล้วให้ทุกทีมทำงานเดียวกัน เราก็จะได้งานที่เสร็จสมบูรณ์ เร็วที่สุด เท่าที่ทีมที่ช้าที่สุดจะทำเสร็จ
เพราะโดยปกติแล้ว งานที่เป็น Story เราจะคาดหวังจะได้ potentially shippable product หรือก็คือ งานที่เสร็จแล้วพร้อมเอาไปใช้งานได้จริง นั่นเป็นสาเหตุที่ เวลาเราจัดทีม Dev ให้เหมาะกับ Story เรามักจะจัดทีมที่เป็น Cross Functional Team หรือก็คือ ทีมที่ทำทุกอย่างไปด้วยกัน ซึ่งบางคนอาจจะสงสัยว่า ทำยังไง
ยกตัวอย่างว่ามีงาน dev ที่มีหน้าจอดึงข้อมูลสมาชิกลูกค้า และหลังบ้านต้องไปยิง service อื่น รวมกับ database ของตัวเองมาแสดงผล แบบนี้เวลาทำ story ให้ทีม มันจะมาในมุมมองของผู้ใช้งาน ว่าเขาต้องการจะทำงานอย่างไร พฤติกรรมอย่างไร เมื่องานเข้าทีม ในทีมอาจจะมีคนที่ถนัด FE บางคนถนัด BE บางคนถนัดเรื่อง Non-Functional มารวมกัน เวลาทำงานจริงในทีมลักษณะนี้ อาจจะใช้วิธี Pair-Programming เช่น ให้คนถนัด FE เขียนคู่กับคนที่ถนัดน้อยกว่า และงานมันจะค่อยๆเสร็จไปแบบแนวตั้ง คือพร้อมใช้งานได้จริงทีละส่วนไปเรื่อยๆ และบางครั้ง ก็อาจจะเจอว่ามีบางงานที่ BE อาจจะทำเสร็จก่อน งานที่เหลือ คนที่ถนัด BE ก็ยังสามารถเข้าไป Pair กับคนอื่น เพื่อช่วยกันทำต่อได้ หรือแม้แต่ไปช่วยเตรียม test script หรือ grooming งานใน sprint หน้าได้อีกด้วย
เรื่องยากๆในองค์กรอีกแบบหนึ่งคือ การที่บางทีมทำงานแบบ Functional team และต้องไปทำงานร่วมกันทีมที่เป็น Cross Functional แบบนี้เวลารับงานเข้ามาก็จะเก้ๆกังๆ เพราะแม้แต่ทีมที่เป็น Functional Team ก็อาจจะบอกได้ว่าตัวเองก็ทำ Agile เหมือนกัน แต่พอมาทำ planning ร่วมกัน เราก็จะเห็นความแปลกตรงที่ งานอาจจะเสร็จแต่ใช้ไม่ได้จริง ต้องรออีกหลาย sprint ข้างหน้าให้งานคนอื่นเสร็จก่อน แล้วค่อยมารวมร่างกันอีกรอบ
เรื่องที่เล่ามาทั้งหมด เราคนอ่าน อาจจะบอกได้ว่า ก็จัดทีมกันใหม่สิ ก็น่าจะแก้ปัญหาได้ แต่ในความจริง มันมีความยากอยู่หลายส่วน เอาง่ายๆเลยคือ skillset ของแต่ละทีมเช่น การเขียน unit testing หรือวิธีแบ่งงานให้เป็น MVP หรืออื่นๆ ไปจนถึงการที่ต้อง dedicate คนเข้าไปในงานและสลาย pool ทิ้ง จะดูเป็นเรื่องใหญ่ในหลายๆองค์กร
สุดท้าย อาจจะต้องนั่งคิดให้ดีๆว่า รูปแบบองค์กรเรา มันถูกออกแบบมาให้เหมาะกับวิธีที่เราจะใช้ทำงานกันจริง หรือไม่ ถ้าไม่ แล้วเราจะยังแข็งขืนไม่ให้มันปรับเปลี่ยนไปในแนวทางที่เหมาะสมอยู่ทำไม สุดท้าย อาจจะส่งผลกระทบกันการไหลออกของพนักงานแบบที่หาเหตุผลไม่ได้ก็เป็นได้
