การใช้สเปรดชีต Agile สำหรับการประเมินการค้นพบ

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

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

เข้าสู่สเปรดชีต Agile

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

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

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

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

จัดการวิสัยทัศน์และแผนงานของผลิตภัณฑ์ก่อน

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

ฉันชอบรูปแบบการมองเห็นผลิตภัณฑ์ Scrum.org สำหรับรูปแบบการเล่าเรื่องที่เข้าใจง่าย นี่คือสิ่งที่ดูเหมือน:

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

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

ในการใช้ Microsoft เป็นตัวอย่าง: Windows 8 น่าจะเป็นเวอร์ชันแผนงาน Windows 10 เป็นเวอร์ชันแผนงานอื่นที่มีคุณลักษณะใหม่และเป็นที่ต้องการมากมาย

เมื่อวิสัยทัศน์และแผนงานผลิตภัณฑ์เสร็จสมบูรณ์ ก็ถึงเวลาขอให้ลูกค้ายอมรับ MVP

เจรจาคุณสมบัติ MVP ด้วยแผนภูมิข้อจำกัดสามประการ

นี่คือช่วงเวลาที่จะกำหนดความคาดหวังของลูกค้าของคุณเกี่ยวกับเวลาและค่าใช้จ่ายโดยใช้แผนภูมิ Triple Constraint:

ในแนวทางของ Waterfall คุณลักษณะคงที่กำหนดเวลาและต้นทุน และดำเนินการพัฒนาตามแผนโครงการโดยละเอียด ในทางกลับกัน ต้นทุนคงที่และกำหนดการของ Agile จะกำหนดคุณสมบัติของผลิตภัณฑ์ และคุณลักษณะเหล่านี้จะได้รับการจัดลำดับความสำคัญใหม่อย่างต่อเนื่องตามวิสัยทัศน์ของโครงการที่ยืดหยุ่นมากขึ้น

แผนภูมิ Triple Constraint แสดงให้ลูกค้าเห็นว่าการรวมคุณสมบัติที่ต้องการทั้งหมดในรุ่นแรกจะเพิ่มเวลาในการพัฒนาและต้นทุนบอลลูน ให้ทำงานร่วมกับลูกค้าเพื่อเลือกเฉพาะคุณสมบัติ "ต้องมี" สำหรับ MVP และจัดตารางคุณสมบัติที่เหลืออยู่สำหรับการเปิดตัวในอนาคต

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

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

เริ่มต้นด้วยการปรับขนาดเสื้อยืด

ในการเริ่มต้น Backlog แรก ให้ขอคำอธิบายโดยละเอียดเกี่ยวกับคุณสมบัติของผลิตภัณฑ์จากเจ้าของผลิตภัณฑ์ จากนั้นกำหนดขนาดเสื้อยืดให้กับแต่ละฟีเจอร์ตามระดับความยาก

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

ตัวอย่างเช่น หากลูกค้าของคุณต้องการให้คุณสร้างชุดป๊อปอัปบนเว็บไซต์หาคู่ นั่นอาจใช้เวลานานแต่ตรงไปตรงมา คุณอาจอธิบายลักษณะความซับซ้อนของงานว่า "เล็ก" แต่ความพยายามจะเป็น "ปานกลาง" คุณสามารถย่อสิ่งนี้เป็น “SM” ในทางกลับกัน การพัฒนาการเชื่อมต่อแบ็คเอนด์สำหรับ API ใหม่จะเป็นงานที่ซับซ้อนมากขึ้นเนื่องจากเอกสารและการทดสอบที่จำเป็นทั้งหมด ทักษะและความสนใจที่จำเป็นสำหรับสิ่งนี้อาจทำให้ "ใหญ่" ทั้งในความพยายามและระดับทักษะ: "LL"

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

ตั้งค่าพารามิเตอร์ของคุณ

ตอนนี้คุณพร้อมที่จะนำสเปรดชีตไปใช้และคำนวณค่าประมาณของคุณแล้ว เริ่มต้นด้วยการสร้างแท็บพารามิเตอร์ ซึ่งจะทำหน้าที่เป็นกุญแจสำคัญในการคำนวณของคุณ และค่าที่คุณป้อนที่นี่จะป้อนลงในสูตรที่ใช้ใน Backlog/User Stories และ Estimate Summary ตามแท็บ Release

นี่คือทุกสิ่งที่คุณต้องการในแท็บพารามิเตอร์ของคุณ:

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

วันที่เริ่มต้น. วันที่เริ่มต้นการพัฒนาที่คาดไว้จะถูกใช้เพื่อสร้างไทม์ไลน์ของโครงการ ในแต่ละตัวอย่าง วันที่เริ่มต้นของเราคือ 25 ตุลาคม

งบประมาณเริ่มต้น งบประมาณมีข้อจำกัดที่แสดงว่าคุณลักษณะ MVP ทั้งหมดจะพอดีหรือไม่

ขนาดเสื้อยืด. ป้อนขนาดเสื้อยืดของคุณเป็นตาราง และกำหนดประเด็นเรื่องและช่วงชั่วโมงให้กับแต่ละขนาดรวมกัน ในตัวอย่างนี้ เราใช้หนึ่งถึงสองชั่วโมงสำหรับ SS และ 33 ถึง 48 ชั่วโมงสำหรับ LL

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

อัตราต่อชั่วโมง ใช้ตารางนี้เพื่อบันทึกอัตราการจ่ายสำหรับแต่ละบทบาท หากนักพัฒนาส่วนหลังของคุณมีอัตราต่างกัน ให้ใช้ค่าเฉลี่ยของทั้งสอง

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

ฉุกเฉิน สิ่งนี้บ่งชี้ความแปรปรวนที่อาจเกิดขึ้นในการประมาณการของคุณ การเริ่มต้นด้วยเหตุการณ์ฉุกเฉินที่ 0% จะแสดงให้คุณเห็นกรณีที่ดีที่สุด (เช่น ไม่น่าเป็นไปได้) งบประมาณและเส้นเวลาตามค่าที่คุณป้อนลงในสเปรดชีต ต่อมาในตัวอย่างของเรา เราจะเพิ่มความบังเอิญเป็นลำดับคร่าวๆ ของความแปรปรวนของขนาด (ROM) ที่ 50% เพื่อแสดงจุดสิ้นสุดของต้นทุนที่สูงและระยะเวลาของโครงการที่อาจเกิดขึ้น สถานการณ์ฉุกเฉินจะลดลงเมื่อคุณได้ตัวเลขที่แม่นยำยิ่งขึ้น

ขนาดแต่ละรุ่นด้วย Epics

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

อันดับแรก เลือกคอลัมน์ “EPIC?” และตรวจสอบให้แน่ใจว่าได้เลือกเฉพาะ “Epic” เท่านั้น

ถัดไป ให้เขียนคำอธิบายที่ยิ่งใหญ่และป้อนจำนวนชั่วโมงสำหรับแต่ละคอลัมน์ของสแต็กการพัฒนา ตัวอย่างเช่น มหากาพย์ “การเชื่อมต่อและการเข้าสู่ระบบที่ปลอดภัย” จะใช้เวลาประมาณแปดชั่วโมงในการพัฒนา UI, 40 สำหรับแบ็กเอนด์ และอื่นๆ

สังเกตว่าในกรณีส่วนใหญ่ เซลล์ในคอลัมน์ "Point" จะแสดง "34*" หากคุณกลับไปที่แท็บพารามิเตอร์ คุณจะเห็นว่า 34 คะแนนตรงกับช่วงรายชั่วโมงระหว่าง 33 ถึง 48 ชั่วโมง จำนวนชั่วโมงนั้นมากเกินไปหากระยะเวลาการวิ่งของเราเพียงสัปดาห์เดียว

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

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

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

คุณสามารถดูค่าใช้จ่ายและระยะเวลาคร่าวๆ สำหรับ MVP และฟีเจอร์และการอัปเดตที่ไม่ค่อยเร่งด่วนในรุ่นต่อๆ ไป (R3 และ R4) ได้แล้ว ในตัวอย่างนี้ รีลีสที่สอง (R2) ว่างเปล่าเนื่องจากลูกค้าร้องขอให้เปิดตัวมหากาพย์ MVP ทั้งหมดในเวอร์ชันแรก

ตอนนี้คุณสามารถเห็นต้นทุนรวมในแง่ดีที่สุด: 28,810 ดอลลาร์ ตัวเลขนี้เป็นผลรวมของค่าใช้จ่ายของแต่ละรุ่นตั้งแต่ MVP ถึง R4

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

ในกรณีนี้ เส้นทางที่สำคัญคือการพัฒนาส่วนหน้า โดยจะเสร็จสิ้นในวันที่ 31 มกราคม

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

ปรับสถานการณ์ฉุกเฉินเป็น 50%

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

อีกครั้ง นี่คือการประมาณการโครงการทั้งหมดที่เกิดเหตุฉุกเฉิน 0%

และนี่คือสถานการณ์ฉุกเฉิน 50%

นั่นหมายความว่าค่า ROM โดยประมาณสำหรับโครงการทั้งหมดอยู่ระหว่าง 28,810 ถึง 41,860 ดอลลาร์ ในกรณีที่ดีที่สุดและแย่ที่สุด งบประมาณ $20,000 ของลูกค้าจะไม่เพียงพอที่จะรวมคุณสมบัติทั้งหมดไว้ในรายการสิ่งที่อยากได้

วันที่เสร็จสมบูรณ์ของโครงการโดยบังเอิญ 50% ในขณะนี้ตรงกับวันที่ 14 มีนาคม หกสัปดาห์หลังจากวันที่เสร็จสมบูรณ์โดยบังเอิญ 0%

ในขณะเดียวกัน MVP จะพร้อมในวันที่ 10 มกราคม

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

จัดลำดับความสำคัญเพื่อตอบสนองกำหนดเวลา

สมมติว่าลูกค้ากำหนดวันเป้าหมายเป็นวันที่ 25 ธันวาคมสำหรับ MVP สองเดือนนับจากวันที่ 25 ตุลาคม

เพื่อเลื่อนวันที่เสร็จสิ้น MVP 10 มกราคมปัจจุบัน ลูกค้าตกลงที่จะเลื่อนมหากาพย์ MVP สองรายการออกไปจนกว่าจะมีการเปิดตัวครั้งต่อไป (R2)

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

จากข้อมูลนี้ คุณอาจตัดสินใจเพิ่มนักพัฒนาอีกสองคนเพื่อจัดวันที่เสร็จสมบูรณ์ส่วนหน้าและส่วนหลังให้สอดคล้องกับกองการพัฒนาอื่นๆ ในการทำเช่นนี้ ให้เพิ่มชั่วโมงจาก 40 เป็น 80 ในแถว MVP “ชั่วโมงต่อสัปดาห์”

ตอนนี้ทั้ง front- และ back-end development stacks จะเสร็จสิ้นในเดือนพฤศจิกายน และ QA กลายเป็นเส้นทางวิกฤติใหม่ (โดยจะเสร็จสิ้นในวันที่ 20 ธันวาคม) โปรดทราบว่าค่าใช้จ่ายจะไม่เปลี่ยนแปลง นั่นเป็นเพราะว่าจำนวนชั่วโมงทำงานในแต่ละกองยังคงเท่าเดิม แทนที่จะเป็นนักพัฒนาคนหนึ่งที่ทำงานเป็นเวลาสองสัปดาห์ (80 ชั่วโมง) นักพัฒนาสองคนกำลังทำงานเป็นเวลาหนึ่งสัปดาห์ (80 ชั่วโมง)

สเปรดชีตยังพิจารณาถึงความแตกต่างระหว่างงานเต็มเวลาและนอกเวลา สมมติว่านักพัฒนา UI จะทำงานนอกเวลา เราสามารถเปลี่ยน UI “ชั่วโมงออกแบบต่อสัปดาห์” เป็น 20 เพื่อจำลองความล่าช้าในการจัดส่ง

ตามกำหนดการเต็มเวลา UX/UI จะเสร็จสมบูรณ์ในวันที่ 29 พฤศจิกายน

สำหรับกำหนดการนอกเวลา UX/UI จะแล้วเสร็จในวันที่ 27 ธันวาคม

เป็นอีกครั้งที่ค่าใช้จ่ายไม่เปลี่ยนแปลง แต่ UX/UI กลายเป็นเส้นทางวิกฤติใหม่ โดยขยายไทม์ไลน์สำหรับ MVP จนถึงวันที่ 27 ธันวาคม

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

ปรับแต่งค่าประมาณของคุณด้วยเรื่องราวของผู้ใช้

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

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

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

มาดูกันว่าเราแบ่งมหากาพย์ออกเป็นเรื่องราวของผู้ใช้ที่มีขนาดเล็กลงและมีรายละเอียดมากขึ้นได้อย่างไร:

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

ใต้ “T-shirt Sizing” ในแท็บ Backlog/User Stories ให้ป้อนขนาดรวมของนักพัฒนาและ SME ของคุณที่กำหนดให้กับกองของพวกเขาสำหรับแต่ละเรื่องราว จากนั้น สูตรสเปรดชีตจะเติมชั่วโมงที่เกี่ยวข้องโดยอัตโนมัติจากแท็บพารามิเตอร์ โปรดจำไว้ว่า LL ที่ใหญ่ที่สุดจะต้องอยู่ต่ำกว่า 34 คะแนนเพื่อให้แน่ใจว่าจะเสร็จสมบูรณ์ภายในระยะเวลาการวิ่งที่คุณตกลงไว้ เรื่องราวใด ๆ ที่ยังให้คะแนน 34 คะแนนขึ้นไปจะต้องถูกแบ่งย่อย

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

ตอนนี้คุณจะเห็นชุดตัวเลขใหม่:

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

ทำให้เป็นของคุณ

สเปรดชีตใช้งานง่าย และด้วยความรู้พื้นฐานเกี่ยวกับสูตรบางอย่าง (ไม่จำเป็นต้องใช้มาโคร) คุณสามารถปรับสูตรเหล่านี้ให้เข้ากับความต้องการได้แทบทุกประเภท หากความรู้เกี่ยวกับ Excel ของคุณเป็นสนิม หลักสูตรออนไลน์บน Udemy และ edX จะช่วยคุณปัดฝุ่นทักษะเหล่านี้

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

คุณชอบสเปรดชีตที่กำหนดเองมากกว่าเครื่องมือการจัดการโครงการนอกชั้นวางหรือไม่? บอกเราว่าทำไมหรือทำไมไม่ในความคิดเห็น