เมื่อเดือนก่อนมีโอกาสได้ให้คำปรึกษาเพื่อนร่วมงานเรื่องการปรับปรุงแนวทางการทำงานของทีมเพื่อตอบโจทย์ฝั่ง business ซึ่งพบว่าสิ่งที่แนะนำไปมีประโยชน์กับเขา (จาก feedback ที่ได้มาอ่ะนะ) ก็เลยคิดว่าน่าจะเป็นเรื่องดีที่จะบันทึกไว้สำหรับอ้างอิงต่อในอนาคต

พูดถึงปัญหาก่อน

ปัญหาของเพื่อนร่วมงานคือลูกค้าของเขา (ตำแหน่ง business stakeholders และ product owner) ไม่พอใจทีมเพราะส่งมอบงานไม่ทันตาม deadline ที่วางไว้หลายครั้ง โจทย์ก็เลยต้องหาวิธีแก้ปัญหาแนวทางการทำงานของทีมเพื่อให้รอดจาก deadline นี้

คำแนะนำ

  1. สอบถามเพื่อเก็บข้อมูลประกอบ เช่น ขนาดของทีม context ของ project ที่ทำ เรื่องที่ลูกค้าเข้ามาเอี่ยว รวมถึง dependencies ของทีม เพื่อเข้าใจ impact และ scale ของปัญหา

  2. เริ่มแนะนำว่าก่อนจะแก้ปัญหา เราต้องเอาทุกปัญหาออกมากางไว้บนโต๊ะให้ทุกคนเห็นตรงกันก่อน ตั้งแต่เริ่มเกิด idea ไปจนถึงส่งมอบ software ให้ลูกค้า ใส่รายละเอียดเพิ่ม เช่น คนหรือทีมที่มีส่วนเกี่ยวข้อง รวมไปถึง ระยะเวลาที่ใช้ในแต่ะขั้นตอน เพื่อเข้าใจ scale ของปัญหา โดยแนวทางปฏิบัติที่สามารถหยิบมาใช้ได้คือ value stream mapping

    Path to production

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

  4. แนะนำวิธีการขุดต้นตอด้วยสาเหตุตัวอย่างจากข้อก่อนหน้าโดยใช้วิธี 5 whys หรือ Socratic method โดยให้เราคุม tone ให้เน้นไปที่ปัญหาที่เกิดขึ้นมากกว่าตัวบุคคลเพราะไม่งั้นจะเสียความเชื่อใจกันและกันเปล่า ๆ เช่น

    • ถาม: ทำไมทีมถึง implement feature ช้า
    • ตอบ: เพราะทีมต้องทำงานกับระบบ third-party จะปรับแก้ทีใช้เวลานาน
    • ถาม: ทำไมทีมปรับแก้งานบนระบบ third-party ได้ช้า
    • ตอบ: เพราะทีมขาดความรู้และทักษะในการปรับแก้งานบนระบบ third-party
    • ถาม: ทำไมทีมขาดความรู้และทักษะในการปรับแก้งานบนระบบ third-party
    • ตอบ: เพราะทีมไม่มีเวลาเรียนรู้ มาถึงก็โยนลงน้ำลุยเลย
    • ถาม: ทำยังไงให้ทีมมีเวลาได้เรียนรู้ระบบ third-party มากขึ้น
    • ตอบ: …
  5. แนะนำต่อว่าความยาก-ง่ายในการลงมือทำ ก็ขึ้นอยู่กับความเชื่อใจที่มีต่อกันระหว่างทีมกันเองและทีมกับลูกค้า ถ้ายังมองหน้ากันไม่ติดก็ต้องหาวิธีสร้างความเชื่อใจก่อน ถ้าไม่ได้จริง ๆ ก็จับแยกแล้วค่อยมารวม input กันทีหลัง
  6. แนะนำต่อให้จัดลำดับความสำคัญของปัญหาที่จะแก้จาก impact และแรงที่ต้องออก เพราะลูกค้าไม่น่าจะพอใจถ้าเราบอกว่า “ขอหยุดส่งมอบก่อนเพื่อแก้ปัญหา X Y Z นะ”
  7. สร้างสมมติฐานว่าหากลงมือแก้ปัญหาแล้วจะทำให้ปัญหานี้ดีขึ้นอย่างไร แล้วเอาอะไรมาวัดว่าสมมติฐานและแนวทางการปรับปรุงของเรามันช่วยทำให้การส่งมอบงานทั้งระบบดีขึ้นหรือไม่
  8. ทำการลงมือแก้ปัญหาและวัดผลต่อไป

ปิดท้ายด้วยการพูดคุยเรื่องทฤษฎีที่เกี่ยวข้อง เช่น