ฉันเร่งการพัฒนาอาหารของฉันโดยการปรับเวิร์กโฟลว์การจัดการโครงการยอดนิยมของการพัฒนาซอฟต์แวร์ได้อย่างไร

เมื่อเชฟพูดถึงการพัฒนาสูตรอาหาร พวกเขามักให้ความสำคัญกับเทคนิคหรือศิลปะที่เปี่ยมด้วยจิตวิญญาณของงานฝีมือมากกว่าขั้นตอนการทำงานที่พวกเขาทำตาม ความคิดสร้างสรรค์และพรสวรรค์จะยังคงเป็นดั่งมนต์วิเศษ แต่วิธีที่คุณเข้าใกล้กระบวนการพัฒนาสามารถมีผลกระทบอย่างมากต่อคุณภาพและความเร็วของผลผลิตในเชิงพาณิชย์ โดยเฉพาะอย่างยิ่งเมื่อทำงานในทีม

ในฐานะผู้ประกอบการด้านเทคโนโลยีอาหารที่ผันตัวมาจากเชฟ ฉันมีโอกาสนำทั้งทีมพัฒนาอาหารและผลิตภัณฑ์ดิจิทัลไปพร้อมกัน

การมีเท้าข้างหนึ่งอยู่ในครัวและอีกข้างอยู่ในเทคโนโลยีทำให้ฉันตระหนักว่าทั้งสองสาขานั้นต้องการชุดทักษะการจัดการองค์กรที่คล้ายคลึงกันอย่างน่าทึ่ง และสามารถปฏิบัติตามกรอบเวิร์กโฟลว์ที่คล้ายกันมากได้

การปฏิบัติตาม“ระเบียบวิธีแบบ Agile ”ซึ่งเป็นแนวทางไปสู่การพัฒนาซอฟต์แวร์ ช่วยให้คุณสามารถแบ่งโครงการที่ซับซ้อนออกเป็นขั้นตอนเล็กๆ หลายๆ ขั้น รวมกับเวิร์กโฟลว์ที่มีโครงสร้างซึ่งเกี่ยวข้องกับการทำงานร่วมกันอย่างต่อเนื่อง การแบ่งเวลา (เรียกว่า “Sprints” ซึ่งโดยทั่วไปแล้ว 2 สัปดาห์ที่ผ่านมา) และทำงานซ้ำๆ

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

TL; DR: “Agile for Food” เป็นเวิร์กโฟลว์การจัดการโครงการที่มีโครงสร้างเพื่อการพัฒนาอย่างรวดเร็วในสภาพแวดล้อมของทีม

• ระยะที่ 1:รวบรวมความคิด/งาน จัดลำดับความสำคัญ และกำหนดรายละเอียดของสิ่งที่จะพัฒนา
• ขั้นตอนที่ 2:วางแผนระยะเวลาการทำงาน 2 สัปดาห์ (หรือที่เรียกว่า “Sprint”) ซึ่งจะมีการพัฒนางานที่มีความสำคัญสูงสุด ประเมินความพยายามของแต่ละงานและให้อำนาจแก่ทีมในการตกลงว่าใครทำงานอะไร
• ขั้นตอนที่ 3:ดำเนินการ Sprint 2 สัปดาห์พร้อมการเช็คอินรายวัน (เรียกว่า "ยืนขึ้น") และการอนุมัติประตูเวทีหลัก 2 ครั้ง จบด้วยการประชุมย้อนหลังเกี่ยวกับงานที่ทำสำเร็จและการอภิปรายเกี่ยวกับการปรับปรุงและย้ายเข้าสู่การวางแผนรอบ Sprint 2 สัปดาห์ถัดไปโดยตรง ทำซ้ำไปเรื่อย ๆ

ทำไมต้อง “Agile for Food”?

Agile for Food เป็นการนำระเบียบวิธีแบบ Agile มาปรับใช้ในอุตสาหกรรมอาหารของฉัน มันเป็นไปตามเฟรมเวิร์กพื้นฐานเดียวกันกับเวอร์ชันการพัฒนาซอฟต์แวร์ แต่ฉันได้ทำให้โดยรวมง่ายขึ้นและปรับแต่งคำศัพท์สองสามคำเพื่อให้เหมาะกับอุตสาหกรรมอาหารมากขึ้น

Agile for Food มีข้อได้เปรียบที่สำคัญบางประการ:

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

การทำงานให้เสร็จตามกระบวนการพื้นฐานนี้:

2. ความคล่องตัวสำหรับบทบาทและความรับผิดชอบด้านอาหาร

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

• เจ้าของผลิตภัณฑ์:จัดการ Backlog และเป็นตัวแทนของผู้มีส่วนได้ส่วนเสีย (เช่น การจัดการองค์กร) บทบาทนี้ไม่จำเป็นต้องเป็นผู้ตัดสินใจขั้นสุดท้าย แต่ควรทำหน้าที่เป็นผู้สนับสนุนสิ่งที่ส่งมอบให้กับผู้ตัดสินใจ
• ผู้จัดการโครงการ:ทำหน้าที่เป็นผู้อำนวยความสะดวกในพิธีกรรมของ Agile เพื่อให้มั่นใจว่าทีมปฏิบัติตามแนวทางปฏิบัติของ Agile และปรับปรุงกระบวนการอย่างต่อเนื่อง บทบาทนี้มักถูกเติมเต็มโดยบุคคลที่ใกล้ชิดกับการดำเนินงานประจำวันของกระบวนการพัฒนา และสามารถทำหน้าที่เป็นผู้จัดการโครงการที่ดูแลสถานะของงาน
• ทีมพัฒนาผลิตภัณฑ์:กลุ่มผู้เชี่ยวชาญข้ามสายงานในการส่งมอบผลิตภัณฑ์ที่อาจปล่อยออกได้เมื่อสิ้นสุด Sprint แต่ละครั้ง ทีมนี้อาจประกอบด้วยเชฟ นักวิทยาศาสตร์การอาหาร/นักเทคโนโลยี นักโภชนาการ และนักการตลาดผลิตภัณฑ์ ทั้งนี้ขึ้นอยู่กับองค์กร

แนวคิดเกี่ยวกับผลิตภัณฑ์ควรได้รับการถ่ายทอดอย่างชัดเจนในรูปแบบของ“ เรื่องราวของผลิตภัณฑ์” เรื่องราวคือคำอธิบายสั้น ๆ เกี่ยวกับผลิตภัณฑ์ด้วยภาษาธรรมดา การพัฒนาซอฟต์แวร์เขียนสิ่งเหล่านี้จากมุมมองของผู้ใช้ แต่เนื่องจากการพัฒนาอาหารไม่ได้เกี่ยวข้องกับประสบการณ์มากนัก ฉันขอแนะนำให้ใช้เฟรมเวิร์กที่ตรงไปตรงมามากขึ้นสำหรับสูตร Product Story:

[แนวคิดหลักของผลิตภัณฑ์]ที่[เจาะจงเกี่ยวกับผลิตภัณฑ์ ]

ตัวอย่างเรื่องราวของผลิตภัณฑ์:

• ไก่กรอบแสงและสว่างสำหรับฤดูใบไม้ผลิที่รวมมันฝรั่งทารกและทางลาดที่ได้รับแรงบันดาลใจจาก "X-restaurant"
• รูปแบบที่ปราศจากกลูเตนบนแถบโปรตีนช็อกโกแลตเนยถั่วที่รวมผลเบอร์รี่ที่ทำให้ได้เนื้อสัมผัสเดียวกัน
• แซนด์วิชบรอกโคลีจากพืชที่ผ่อนคลายพร้อมมายองเนสชิโปเติลมะนาวมังสวิรัติสำหรับเมนูอาหารกลางวัน
• ผักใบเขียวที่มีโซเดียมน้อยกว่า 30 มก.

4. การดูแลงานค้าง

“Backlog Grooming”คือกระบวนการจัดลำดับความสำคัญของแนวคิดตามคุณค่าต่อธุรกิจและลูกค้า เพื่อให้แน่ใจว่าทีมงานจะทำงานให้มีมูลค่าสูงสุดเสมอในแต่ละรอบการทำงาน เรายังทำงานร่วมกันเพื่อให้แน่ใจว่าข้อกำหนดสำหรับผลิตภัณฑ์นั้นชัดเจนและเข้าใจได้ง่าย มูลค่าถูกกำหนดโดย:

• คุ้มค่าสำหรับลูกค้า
• สอดคล้องกับวัตถุประสงค์ทางธุรกิจ (เป้าหมายเชิงกลยุทธ์สำหรับบริษัท เช่น ความพึงพอใจของลูกค้าที่เพิ่มขึ้น AOV ที่เพิ่มขึ้น หรืออัตรากำไรขั้นต้นที่ดีขึ้น)
• คุณค่าสำหรับผู้มีส่วนได้ส่วนเสียอื่นๆ (เช่น แผนกข้ามสายงาน การจัดการองค์กร)

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

ในเซสชันนี้ คุณสามารถเพิ่ม/ลบ/ปรับแต่งเรื่องราว ปรับลำดับความสำคัญ หรือประเมินค่าประมาณใหม่ได้

ฉันไม่สามารถเน้นความสำคัญของการประชุมนี้ได้มากพอในการบรรลุการจัดลำดับความสำคัญข้ามสายงาน ฉันขอแนะนำให้คุณเชิญฝ่ายจัดการองค์กรเข้าร่วมการประชุมเหล่านี้ ความโปร่งใสช่วยได้ในระยะยาวเมื่อมีความสอดคล้องกัน

5. ปรับปรุงข้อกำหนดของผลิตภัณฑ์

“ ข้อกำหนด”คือการรวบรวมองค์ประกอบสำคัญที่จำเป็นสำหรับผลิตภัณฑ์ที่จะประสบความสำเร็จ มักจะรวมถึงการเขียนส่วนผสมหลักที่ครอบคลุมในบางครั้ง โครงร่างหรือส่วนประกอบสำหรับสูตร/สูตร คำอธิบายวิธีการประมวลผล ต้นทุน/ส่วนต่างเป้าหมาย คำแนะนำในการนำเสนอ ฯลฯ พิจารณาว่าเป็นแผนสำหรับวิธีดำเนินการรายการที่ม้านั่ง

6. การวางแผนการวิ่ง

การ ประชุม "Sprint Planning"คือที่ที่ทีมจะตรวจสอบรายการที่มีลำดับความสำคัญสูงสุดใน Backlog และรวมเป็นงานที่สามารถบรรลุได้ภายในกรอบเวลาที่องค์กรของคุณกำหนด

การพัฒนาซอฟต์แวร์สนับสนุนการเร่งความเร็ว 2 สัปดาห์ แต่จากประสบการณ์ของฉัน อาหารมักมีเวลารอคอยและบางครั้งต้องใช้เวลาหลายวันระหว่างการพัฒนา แม้ว่ามันอาจจะดึงดูดใจที่จะขยาย Sprint ให้นานขึ้น แต่ฉันขอแนะนำให้คุณยึดติดกับกรอบ Sprint 2 สัปดาห์

2 สัปดาห์จะอัดฉีดความรู้สึกของระเบียบวินัยและแรงผลักดันเข้าสู่กระบวนการพัฒนา และหากสิ้นสุด Sprint ต้องใช้เวลามากขึ้น เจ้าของผลิตภัณฑ์สามารถวาง Product Story กลับเข้าไปใน Backlog เพื่อแก้ไขระหว่าง Sprint ถัดไป

ขั้นตอนการวางแผน Sprint:

• เจ้าของผลิตภัณฑ์ระบุรายการที่ไม่เสร็จสมบูรณ์ใน Sprint ก่อนหน้า และรายการที่ด้านบนของงานในมือ
• เจ้าของผลิตภัณฑ์จะคำนวณความเร็วปัจจุบันของทีม โดยอิงตามค่าประมาณของ Sprint ก่อนหน้าและงานที่เสร็จสมบูรณ์
• สมาชิกในทีมเริ่มต้นด้วยการระบุว่าเหตุใดเรื่องราวของผลิตภัณฑ์ (ถ้ามี) จึงไม่ถูกทำเครื่องหมายว่าเสร็จสิ้นจากการวิ่งครั้งก่อน
• สมาชิกในทีมตรวจสอบเรื่องราวของผลิตภัณฑ์ใน Backlog เพื่อทำความเข้าใจข้อกำหนด มีการระบุงานสำหรับการดำเนินเรื่อง สิ่งเหล่านี้อาจเป็นงานง่ายๆ เช่น "หั่นกุ้ยช่ายฝรั่ง" หรืองานที่ซับซ้อน เช่น "กำหนดโปรแกรมเวลา/อุณหภูมิ/เดลต้าที่เหมาะสมที่สุดสำหรับอกเป็ดรมควัน 6.2 ออนซ์"
• สมาชิกในทีมกำหนด Story Points ให้กับเรื่องราวที่พวกเขาได้รับมอบหมาย

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

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

กรอบการทำงานทั่วไปใน Agile สำหรับค่า Point คือ Fibonacci Sequence

ใน Fibonacci Sequence แต่ละหมายเลขคือผลรวมของสองตัวก่อนหน้าในซีรีส์: 1, 2, 3, 5, 8, 13, 21, 34, 55... และอื่นๆ กรอบนี้ใช้เพื่อรับรู้การกระโดดที่ดีขึ้นเมื่อตัวเลขมีขนาดใหญ่ขึ้น เป้าหมายของประเด็นเรื่องราวคือการทำหน้าที่เป็นเพียงแนวทางเพื่อช่วยให้ทีมของคุณประเมินว่างานหนึ่งๆ จะใช้เวลาเท่าใดและทรัพยากรเท่าใดที่คุณจะต้องทุ่มเทให้กับงานนั้น

ตัวอย่างเช่น งานในการพัฒนารูปแบบง่ายๆ ให้กับรายการที่มีอยู่ เช่น การสร้างน้ำสลัดแบบเผ็ดสำหรับแนวคิดสลัดกับผลิตภัณฑ์อื่นๆ ที่คล้ายคลึงกัน อาจเป็น 2 หรือ 3

แต่ถ้างานมีความซับซ้อนมากขึ้น เช่น การสร้างรายการด้วยอุปกรณ์ชิ้นใหม่ทั้งหมดหรือกรอบการประมวลผลที่ต้องผ่านความซับซ้อนทางเทคนิค อาจได้รับมอบหมายให้เป็น 21

การวัดความเร็วส่วนบุคคลและทีม:

“ความเร็ว”ใช้ในการหาปริมาณและวิเคราะห์ผลลัพธ์ของทีมในระหว่างการวิ่งหนึ่งครั้ง หาก Story Points ได้รับการประเมินอย่างมีประสิทธิภาพ นี่เป็นวิธีง่ายๆ ในการวัดผลงานโดยพิจารณาจากจำนวนงานที่ทำสำเร็จ

เป้าหมายของ Velocity ไม่ใช่แค่การบอกปริมาณความแตกต่างของผลลัพธ์ของ Developer 1 กับ Developer 2 เท่านั้น แต่ยังเป็นการทำนายอย่างแม่นยำว่าควรกำหนดเวลางานเท่าใดใน Sprint ที่กำหนดโดยพิจารณาจากทรัพยากรของทีมปัจจุบัน

เคล็ดลับและคำแนะนำเพื่อเพิ่มความเร็ว:

• หลีกเลี่ยงการสลับบริบท — พยายามให้ Product Developers จดจ่อกับงานช่วงแคบๆ (เช่น การโฟกัสที่หมวดหมู่ผลิตภัณฑ์เดียวจะมีประสิทธิภาพมากกว่าหลายหมวดหมู่)
• ฝึกข้ามทุกคน — ถ้าทุกคนรู้ทุกอย่างและฝึกฝนอย่างต่อเนื่อง คุณจะทำได้มากขึ้น ต้องมีผู้เชี่ยวชาญอยู่เสมอ แต่ด้วย Agile นั้นเหมาะเป็นอย่างยิ่งหากทุกคนสามารถมอบหมายงานประเภทใดก็ได้
• มุ่งเน้นไปที่การกำจัดสิ่งกีดขวาง — สิ่งที่ฉันเห็นมากคือไม่สามารถพัฒนาได้เนื่องจากผลิตภัณฑ์ไม่ได้อยู่ในการทดสอบ — ตัวบล็อกหลักที่มักหลีกเลี่ยงได้
• ทดลองทำงานคู่ — บางครั้ง 1+1=3 ลองหาวิธีจับคู่ผู้คนเข้าด้วยกันเพื่อให้ได้ผลลัพธ์ที่ดียิ่งขึ้น

เมื่อประเมินรายการได้เพียงพอแล้วที่จะทำให้ความเร็วของทีมเสร็จสมบูรณ์ (ทั้งจากการพกพาและรายการใหม่จากงานในมือ) ทีมจะถูกถามว่าพวกเขา

“ ความมุ่งมั่นในการวิ่ง”คือความมุ่งมั่นทางวาจาของทีมที่จะดำเนินงานโดยประมาณสำหรับระยะเวลาการวิ่ง 2 สัปดาห์ถัดไป ความมุ่งมั่นหมายถึงความตั้งใจที่จะทำงานให้เสร็จทั้งหมดและทำโดยฉันทามติ

เป็นขั้นตอนที่สำคัญสำหรับการยอมรับและความรับผิดชอบของสมาชิกในทีม

• หาก “ใช่” แสดงว่า Sprint นั้นถูกผูกมัดและไม่สามารถเปลี่ยนแปลงได้
• หาก “ไม่” จะมีการเจรจาและวิเคราะห์เพื่อแบ่งงานออกเป็นข้อผูกพันที่ทีมพึงพอใจ
• หมายเหตุเกี่ยวกับความเร็ว; หากสปรินต์ล่าสุดอยู่ภายใต้ความมุ่งมั่น (หมายถึงเสร็จก่อนกำหนด) ทีมอาจเลือกที่จะพยายามใช้ความเร็วที่สูงขึ้นสำหรับสปรินต์ที่กำลังจะมาถึง (หรือกลับกัน)

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

1. เมื่อวานคุณทำอะไรสำเร็จบ้าง?
2. สิ่งที่คุณวางแผนที่จะทำให้สำเร็จในวันนี้?
3. คุณติดอยู่ตรงไหน?

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

8. รีวิวชิมเฉพาะกิจ

อาหารเป็นเรื่องส่วนตัว และในฐานะนักพัฒนาผลิตภัณฑ์อาหาร คุณมักจะรู้สึก "เมื่อยเพดานปาก" เมื่อคุณกินอะไรซ้ำๆ การเรียกร้องความคิดเห็นของผู้อื่นผ่าน “ รีวิวชิมเฉพาะกิจ”เป็นขั้นตอนสำคัญในการรวบรวมข้อมูลเชิงคุณภาพว่าผลิตภัณฑ์ของคุณดีเพียงใด และหากจำเป็นต้องมีการปรับเปลี่ยน

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

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

9. การยอมรับการชิม — รีวิวช่วงกลางวิ่ง

“ การชิมการยอมรับ”คือการตรวจสอบความคืบหน้าที่ดำเนินการสัปดาห์ละครั้งในวันและเวลาที่เกิดซ้ำ สมาชิกในทีมประชุมกันเพื่อหารือและจัดแนวความคืบหน้าของ Sprint ปัจจุบันโดยนำเสนอรายการอย่างเป็นทางการต่อเจ้าของผลิตภัณฑ์

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

คำเตือน: ไม่ควรละทิ้งผลิตภัณฑ์ ณ จุดนี้ ไม่ว่าผลของการชิมจะเป็นอย่างไร - ควรเก็บรอบ Sprint 2 สัปดาห์เต็มไว้เหมือนเดิมเสมอ จะมีโอกาสปรับลำดับความสำคัญและลบ Product Stories ในระหว่างเซสชัน Sprint Planning ถัดไป

10. การชิมการอนุมัติ — การทบทวน Sprint ขั้นสุดท้าย

“ การชิมเพื่ออนุมัติ”เป็นการประชุมระหว่างทีมพัฒนาและผู้มีส่วนได้ส่วนเสีย (รวมถึงเจ้าของผลิตภัณฑ์ ผู้มีอำนาจตัดสินใจ/ผู้บริหารองค์กร และบุคคลทางเลือกอื่นๆ ที่ได้รับเชิญจากทีม) เพื่อตรวจสอบผลิตภัณฑ์ที่เสร็จสมบูรณ์ก่อนการอนุมัติขั้นสุดท้ายและการขาย

การประชุมนี้ประกอบด้วยการนำเสนอรายการที่เสร็จสมบูรณ์โดยสมาชิกในทีมสำหรับผู้มีส่วนได้ส่วนเสีย ผู้มีส่วนได้ส่วนเสียควรให้ข้อเสนอแนะที่ชัดเจน

ณ จุดนี้ จำเป็นต้องมีการตรวจสอบวัสดุเสริมของผลิตภัณฑ์ สิ่งนี้อาจแตกต่างกันไปตามองค์กร แต่โดยทั่วไปรวมถึง:

• สูตร/สูตรพร้อมคำแนะนำกระบวนการ
• ประมาณการ COGs (ค่าอาหาร ค่าแรง ค่าบรรจุภัณฑ์)
• โภชนาการ
• หมายเหตุทางประสาทสัมผัส
• ชื่อทางการตลาด / รายละเอียดสินค้า

หมายเหตุจากการชิมการอนุมัติจะถูกบันทึกอย่างเป็นทางการและแบ่งปันในการประชุม Sprint Retrospective ที่ตามมา

โปรดทราบ:เป็นเรื่องปกติที่จะมีการอนุมัติหลายชั้นในองค์กรต่างๆ ซึ่งอาจเกิดขึ้นก่อนหรือหลังการชิมการอนุมัติ ตัวอย่างเช่น ค่าใช้จ่ายอาจต้องได้รับการอนุมัติอย่างเป็นทางการจากทีมการเงิน หรือหมายเหตุทางประสาทสัมผัสโดยทีม QA เป็นต้น และอาจมีการส่งต่ออย่างเป็นทางการให้กับทีมการตลาด ซัพพลายเชน และทีมปฏิบัติการก่อนที่จะเริ่มกระบวนการเชิงพาณิชย์และ เปิดตัวน้ำตก

การอนุมัติระหว่างการชิมการอนุมัติสามารถปรับเปลี่ยนได้และไม่ควรลบล้างข้อกำหนดกระบวนการที่มีอยู่ขององค์กรของคุณ

11. วิ่งย้อนหลัง

“ Sprint Retrospective”คือการประชุมที่เกิดขึ้นโดยตรงหลังจากการชิมการอนุมัติ มันทำหน้าที่เป็นหลังตายจาก Sprint ที่สมบูรณ์ มีการหยิบยกหัวข้อสำคัญ 3 หัวข้อเพื่ออภิปราย:

1. ทบทวนบทเรียนที่ได้เรียนรู้ในการวิ่งครั้งก่อน (การวิ่งก่อนการวิ่งที่เพิ่งเสร็จสิ้น) เพื่อวิเคราะห์ว่าพวกเขาได้รับการบรรเทาลงอย่างน่าพอใจหรือไม่ในการวิ่งสรุป
2. ระบุบทเรียนใหม่ที่ได้เรียนรู้ระหว่างการวิ่งโดยทีม (บทเรียนเชิงลบที่ได้รับ)
3. เน้นสิ่งที่ทำงานได้ดีมากและควรรวมเข้ากับการวิ่งในอนาคต (บทเรียนเชิงบวกที่ได้รับ)

การแก้ไขปัญหาผลิตภัณฑ์สดที่มีอยู่ควรจัดการแยกกัน

เช่นเดียวกับการแก้ไขจุดบกพร่องในเทคโนโลยี การแก้ไขปัญหาผลิตภัณฑ์ที่ใช้งานอยู่ควรได้รับการพิจารณาว่าอยู่นอกเหนือไปจาก Sprint ทีมต้องรักษาแบนด์วิธไว้เป็นเปอร์เซ็นต์เพื่อให้แน่ใจว่ามีเวลาแก้ไขปัญหาเกี่ยวกับผลิตภัณฑ์ที่มีอยู่ (เช่น กำหนดการเพียง 70% ของความจุ Story Point Velocity)

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

จากมุมมองของการจัดการโครงการ สามารถวาง Live Product Issues ไว้ในเฟรมเวิร์กการจัดการโครงการเดียวกันกับโครงการใน Sprint แต่ควรแท็กให้แตกต่างกันเพื่อแยกความแตกต่างอย่างชัดเจน (อาจง่ายเหมือนแท็กสีแดงกับสีน้ำเงิน)

เครื่องมือการจัดการโครงการที่ฉันอยากจะแนะนำ:

ฉันพบว่าเครื่องมือการจัดการโครงการดิจิทัลจำเป็นสำหรับการจัดการและแสดงภาพการพัฒนาผลิตภัณฑ์ งาน และลำดับความสำคัญ

การมีความสามารถในการจัดเก็บข้อมูลหลายๆ ชิ้น (เช่น ไฟล์แนบ รูปภาพ ลิงก์ ความคิดเห็น ฯลฯ) และแปลมุมมองของคุณให้เป็นแผนงาน/ไทม์ไลน์สไตล์ GANTT ในทันทีก็มีประโยชน์เช่นกัน ฉันรับประกันว่างานของคุณจะง่ายกว่าการพยายามจัดการสิ่งนี้ใน Google ชีต

ฉันได้ลองและสามารถแนะนำ:

• อาสนะ
• เทรลโล
• มันเดย์ดอทคอม
• เบสแคมป์

ความคิดสุดท้าย:

Agile ไม่ใช่กรอบการทำงานที่สมบูรณ์แบบสำหรับทุกทีม

องค์กรของคุณอาจไม่ต้องการการพัฒนาผลิตภัณฑ์ใหม่ๆ มากนัก หรืออาจทำงานตามกำหนดการที่ช้ากว่าปกติ

นอกจากนี้ยังอาจใช้งานไม่ได้หากคุณมีแผนกที่มีคนเดียว ดังนั้นอย่าลังเลที่จะปรับเปลี่ยนให้เหมาะกับธุรกิจของคุณ (เช่น ไม่จำเป็นต้องสแตนด์อัพรายวัน)

สำหรับสถานการณ์เหล่านั้นที่ดูเหมือนว่า Agile จะไม่เหมาะสม ฉันยังคงแนะนำให้ทำตามกรอบลำดับเหตุการณ์บางอย่าง เช่นWaterfallซึ่งเป็นไปตามเสาหลักที่คล้ายกัน แต่ค่อนข้างอนุรักษ์นิยมกว่าเล็กน้อยด้วยประตูเวทีเชิงเส้นที่มากขึ้น ซึ่งอาจเป็นตัวเลือกที่ดีกว่าหากการพัฒนาของคุณไม่ใช่ - เกิดซ้ำ ฉันจะกล่าวถึง Waterfall for Food โดยละเอียดในบทความในอนาคต

อย่าละสายตาจากสิ่งที่สำคัญที่สุด

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

ฉันมักจะแนะนำให้เลือกคุณภาพมากกว่าปริมาณของอาหาร ดังนั้นปัจจัยต่างๆ เช่น ความเร็วควรนำมาพิจารณาด้วยเกลือเม็ดหนึ่ง

เตรียมพร้อมด้วยว่าคุณจะเพิ่มปริมาณความล้มเหลวนอกเหนือจากความสำเร็จ แต่เช่นเดียวกับคำพูดของ John C Maxwell ที่กล่าวว่า:

“ล้มเหลวก่อน ล้มเหลวบ่อย แต่ล้มเหลวไปข้างหน้าเสมอ”

การพัฒนาผลิตภัณฑ์ที่ยอดเยี่ยมโดยพื้นฐานแล้วเป็นเรื่องของความก้าวหน้าและความยืดหยุ่นมากกว่าความเฉลียวฉลาดเพียงอย่างเดียว

ฉันพบว่าเฟรมเวิร์กนี้เป็นตัวเร่งปฏิกิริยาที่น่าทึ่งสำหรับความก้าวหน้า ซึ่งหวังว่าจะช่วยยกระดับโปรแกรมอาหารของคุณ (หากใช่สำหรับคุณ)