ในขณะที่เป็นผู้เรียนที่ Apple Developer Academy @ BINUS ฉันมีโอกาสเป็นผู้จัดการโครงการและผลิตภัณฑ์ในช่วง 4 เดือนที่ผ่านมาในการสร้าง KOBAR ซึ่งเป็นแอปพลิเคชันเพื่อการศึกษาเกี่ยวกับเกม

การสนับสนุนทีมของฉันในฐานะผู้จัดการโครงการและผลิตภัณฑ์ การจัดการโครงการมีเครื่องมือมากมายที่สามารถใช้ได้ ทั้งในวิธีการทำงานและในซอฟต์แวร์ของตัวเอง เป็นเวลา 4 เดือนที่ทีมของฉันใช้วิธีการ SCRUM ซึ่งกลายเป็นกิจวัตรสำหรับทีมในการประชุม Sprint, Scrum รายวัน, Sprint Review และ Sprint Retrospectives

• Sprintควบคุมกลไกการลากที่จำกัดการไหลเข้ามากเกินไป
• การวางแผน Sprintอนุญาตให้มีการประเมินตนเองของแต่ละงานที่เริ่มต้นความชัดเจนและการเติบโตโดยคำนึงถึง DoD (คำจำกัดความของ Done)
• การพัฒนา Daily Scrumช่วยเพิ่มการประสานงานระหว่างทีมเพื่อแสดงและแสดงความคิดเห็น
• การตรวจสอบ Sprintรวมถึงทีมการต่อสู้พร้อมกับผู้ถือหุ้นรายอื่น ซึ่งนำข้อเสนอแนะจากทีมการต่อสู้และการตรวจสอบมาไว้ที่นี่
• Sprint retrospectiveให้โอกาสในการตรวจสอบสิ่งกีดขวางสำหรับช่วงเวลานั้น และรับอาหารเสริมสำหรับ Sprint ที่กำลังจะมาถึง

เราใช้ความช่วยเหลือของ JIRA สำหรับการจัดการโครงการ เพราะในซอฟต์แวร์นี้ เราช่วยให้สามารถมอบหมายงานให้กับแต่ละคนได้อย่างง่ายดาย ช่วยเหลือหากมีปัญหาย่อยใน Backlog

“ผู้ที่วางแผนจะทำได้ดีกว่าผู้ที่ไม่วางแผน แม้ว่าพวกเขาจะไม่ค่อยทำตามแผนก็ตาม” — วินสตัน เชอร์ชิลล์

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

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

แต่เป็นที่ทราบกันดีว่าปัญหาหลักคือ

มีงานค้างมากเกินไปในการวิ่งหนึ่งครั้ง ซึ่งเราไม่สามารถจัดความคาดหวังให้ตรงกับความเป็นจริงได้

แล้วทำไมปัญหานี้เกิดขึ้น?

• เราประเมินค่าสูงเกินจริงในสิ่งที่เราสามารถทำได้ในการทำซ้ำครั้งเดียว
• รายการงานชิ้นหนึ่งมีขนาดใหญ่กว่าที่เราคาดไว้มาก
• การฉีดบริการ/งานที่ไม่ได้วางแผนเข้ามาซ้ำแล้วซ้ำอีก

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

หารือเกี่ยวกับอนาคตของงานในมือแต่ละรายการ

• หากงานค้างมีลำดับความสำคัญสูง การย้ายงานค้างเดิมไปยัง sprint ถัดไปน่าจะมีประโยชน์ บางทีเวลาที่ให้มาไม่พอกับขนาดของชิ้นงานก็ยังพอไหว
• ถ้างานค้างมีลำดับความสำคัญต่ำ ให้พิจารณาว่าสามารถแบ่งงานค้างและย้ายงานที่ค้างอยู่ในงานค้างของผลิตภัณฑ์ได้หรือไม่

ทั้งหมดนี้ขึ้นอยู่กับประสบการณ์ของฉันและได้รับการสนับสนุนโดยแหล่งข้อมูลจาก:

ข้อเสนอแนะใด ๆ ที่ได้รับความนิยมอย่างสูง! กรุณาตีฉันที่นี่ !

© 2022 นาธาเนีย จอยซ์ ไอรีน สงวนลิขสิทธิ์.