วันก่อนพี่พฤกษ์ ได้มาแชร์เกี่ยวกับการทำ report สำหรับรายงานสรุปผลการ Transformation (ในระดับผู้บริหารและ Management ขึ้นไป) ผมเลยจดไว้เพื่อเป็น template / idea ในการทำรายงานสรุปผลการทำงาน
ในบทความนี้เป็นการแชร์ประสบการณ์ในการทำ report สำหรับส่งให้แก่ลูกค้าหลังจากที่เราได้ Transformation แล้ว
เป้าหมาย
เริ่มต้นที่เราต้องรู้ก่อนว่าเป้าหมายของการทำรายงานนี้คืออะไร เราต้องการบอกอะไรแก่ผู้ที่เกี่ยวข้องบาง ผู้บริหาร ผู้จัดการ ทีม หรือผู้ที่มารับช่วงต่อ เป็นต้น
กลุ่มเป้าหมายของเรา คือ ใคร
ตัวอย่าง เช่น เราต้องการทำรายงานสำหรับผู้บริหารและผู้จัดการ
จากนั้นเราต้องมาลง scope กันต่อ ว่า เขาอยากรู้เรื่องอะไร หรือ เราอยากจะเสนอเรื่องอะไรให้แก่กลุ่มเป้าหมายเหล่านั้น
เช่น เพื่อรายงานผลการ Transformation ตามกรอบระยะเวลาที่วางกันไว้ ว่าเราอยากจะรายงานเกี่ยวกับเรื่องพวกนี้
- เราได้ทำอะไรไปบ้าง
- มีอะไรบ้างที่เราทำได้
- อะไรที่อยู่ระหว่างทำ
- อะไรที่เรายังทำไม่ได้ หรือยังไม่ได้ทำ
- คำแนะนำเพิ่มเติม
บทสรุปผู้บริหาร
หากรายงานนั้น เป็นรายงานที่ส่งให้ในระดับของผู้บริหาร เราอาจจะต้องนำเอาบทสรุปการทำงานขึ้นมาก่อน เพื่อให้ผู้บริหารได้รับทราบข้อมูลที่เข้าสนใจก่อนที่จะไปลงรายละเอียดในแต่ละเรื่อง ซึ่งได้รับความสนใจน้อยกว่า
บทสรุปสำหรับผู้บริหารนั้น จะเป็นการบอกถึง ผลลัพธ์จากการทำ Transformation ว่า ผลเป็นยังไง โดยสรุปจากสิ่งที่บริษัทหรือผู้บริหารสนใจและให้ความสำคัญ ซึ่งส่วนนี้จะต้องถูกคุยและกำหนดไว้ตั้งแต่ก่อนเริ่ม transformation แล้ว
เช่น ลูกค้าสนใจเรื่องอะไร เช่น Velocity, Quality เป็นต้น
โดยเราอาจจะใช้การอธิบายด้วยกราฟ และข้อความประกอบ เพื่ออธิบายเพิ่มเติม
แน่นอนว่า เราจะบอกข้อมูลเหล่านี้ได้ ก็ต่อเมื่อ เราได้มีการเก็บข้อมูลไว้ตั้งแต่เริ่มจนถึงวันที่สิ้นสุด
เราอาจจะเพิ่มข้อความเพื่ออธิบายบางสถานการณ์เด่นๆ ที่เกิดขึ้น ไว้ด้วยก็ได้ (ทั้งดีและไม่ดี) ว่าเกิดอะไรขึ้น พร้อมแนวทางการแก้ปัญหา (ระวังอย่าให้เยอะเกินไป)
รวมถึงผลประโยชน์ที่ได้รับจากการ transformation นั้น และอาจจะกล่าวถึงสิ่งที่ได้ทำให้ดีขึ้นว่ามีอะไรไปบ้าง ที่อยู่นอกเหนือจากเป้าหมายหลักของทีมบริหาร เช่น
Benefits
• Communication and Feedback
• Quality Assurance
• Teamwork collaboration and colocation
• Development Planning
• Customer (Marketing) Satisfaction
Improvements
• People and Knowledge
• Productivity
• Over All Project Management Direction and Visibility
• Development Environment, Processes
• More Time and Slowdown the Adoption
• Budgeting
Key Success Factors
เป็นตัวบอกว่าอะไรที่เป็นปัจจัยสำคัญที่ทำให้มันสำเร็จ เช่น
- การได้รับการ support จากระดับ Executive / Management
- การมีส่วนจาก Customer / User
- การทำงานร่วมกันของทีม
- ความร่วมมือและสื่อสาร
พร้อมทั้งอธิบายด้วยว่ามันช่วยการ transformation สำเร็จได้อย่างไร
Assessment
ต่อมาเป็นส่วนของการรายงานผลการประเมินของแต่ละทีมพัฒนาหรือทีมภายใน product นั้นๆ ขึ้นอยู่กับว่าเราอยากจะลงรายละเอียดแค่ไหน หากมีหลายๆ ทีมภายอยู่ใน product เดียวกัน
ในกรณีที่เข้า transform กันทั้งเกือบทุกทีม เราอาจจะรายงานเป็นภาพรวมของทีมใหญ่ก็ได้ แต่ถ้าหากว่าทีมที่เข้า transform มีแค่ทีมไม่กี่ทีม เราสามารถลงรายละเอียดของทุกทีมเลยก็ได้เช่นกัน
ในการรายงานผลการประเมินนั้นเราจะพูดถึง
Assessment Introduction
เป็นการพูดถึงรายละเอียดภาพรวมของการเข้า transform เช่น
- มีทีมกี่ทีม
- โปรเจคอะไรบ้าง
- จำนวนคนที่อยู่ในทีมนั้นๆ
- ระยะเวลาในการ transform
- กิจกรรมที่อื่นๆ เช่น workshop
- สิ่งที่จะส่งมอบ
Assessment Approach
บอกถึงวิธีการประเมิน ว่าเราได้ประเมินด้วยวิธีไหนบ้าง
เช่น เราใช้วิธีการประเมิน 2 แบบ คือ
- face-to-face: การรวบรวมข้อมูลจากการสัมภาษณ์ โดยการถามคำตอบ การรวบรวมข้อมูลในระหว่างการประเมิน จากการทำ workshop และการทำกิจกรรม retrospective
- Observations: การสังเกต ทีมพัฒนา และตำแหน่งอื่นๆ ในระหว่างการทำงาน หรือการ transform
Conclusion and Recommendations
เมื่อได้ข้อมูลเหล่านั้นแล้ว เราก็จะมาลงรายละเอียดเพิ่มเติมเกี่ยวกับ บทสรุปและข้อเสนอแนะ ของแต่ละทีม อาจจะลงรายละเอียดแต่ละตำแหน่งเลยว่าเป็นยังไง และต้องเพิ่มเติมอะไรบ้าง รวมถึง technical practice ต่างๆ สำหรับเครื่องมือที่ทีมกำลังใช้อยู่ และแนะนำเพิ่มเติมสำหรับ practice ต่างๆ ควรจะเป็นด้วย
ส่วนนี้ขึ้นอยู่กับเราเลยว่า เราจะลงรายละเอียดอะไรบ้าง ซึ่งถ้าเป็นที่สยามชำนาญกิจก็ลงรายละเอียดในทุกๆ ส่วนเลย ตั้งแต่ Agile Practise, Project Management, CI/CD Pipeline, Git Strategy, Technical Dept
Appendix
ส่วนสุดท้าย เป็น ผลของการประเมินในแต่ละส่วนที่ทางทีมโค๊ชได้พบเจอ โดยจะลงรายละเอียดในแต่ละเรื่องเลย ว่า สิ่งที่เราพบเจอนั้นเป็นยังไง อะไรดี อะไรไม่ดี พร้อมคำแนะนำในการปรับปรุงให้ดีขึ้น รวมถึง ความเสี่ยงที่จะเกิดขึ้น หากไม่ได้รับการปรับปรุงในส่วนนั้นๆ
ตัวอย่างหัวข้อที่มีการกล่าวถึงเช่น
หัวข้อของ Managements Practices จะเป็นการลงรายละเอียดในส่วนของการบริหารจัดการต่างๆ เช่น Requirements Analysis, Project Management, Communication and Collaborate เป็นต้น
หัวข้อของ Development Practices จะบอกถึงรายละเอียดของการพัฒนา software รวมถึงการบริหารจัดการ code และ practices ต่างๆ เช่น Sources Code Management, Build Management, Configuration Management, Testing & Quality Assurance, Engineering Practices เป็นต้น
ทั้งนี้หากเรามีการประเมินหรือโค๊ชในเรื่องอื่นก็สามารถใส่เพิ่มเข้ามาได้ตามความเหมาะสมได้เลย
ทั้งหมดนี้เป็น scope คร่าวๆ ในการทำรายงานสรุปการ transformations ซึ่งเวลาลงมือทำจริงๆ จะค่อนข้างใช้เวลาและมีการลงรายละเอียดเยอะ ผมจรึงไม่นำเอามาใส่ในบทความนี้