เงินทุนโครงการเปรียว

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

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

ฉันต้องการฟังความคิดและประสบการณ์ของผู้คนในการให้ทุนโครงการ Agile

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

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

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

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

โปรเจ็กต์ Agile จะไม่ทำงานตามแนวของ "มันจะพร้อมเมื่อพร้อมแล้ว" นั่นคือเส้นคลาสสิคจากวิศวกรรมน้ำตก

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

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

อาจมีมากกว่านี้ แต่ข้างต้นควรจะเพียงพอที่จะทำให้พนักงานขายของคุณไปในทิศทางที่ถูกต้อง

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

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

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

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

ฉันไม่เคยเห็นลูกค้าพูดว่า "เราต้องการคุณลักษณะนี้และเราต้องการรอ 8 เดือนเพื่อให้มีฟีเจอร์อื่น ๆ ที่เราไม่สนใจ"

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

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

แนวคิดของ Agile ก็คือคุณวนซ้ำอย่างรวดเร็วและกำหนดสิ่งที่คุณจะส่งมอบในตอนท้ายของการวิ่งแต่ละครั้งดังนั้นเมื่อ 2/3/4 สัปดาห์ของการวิ่งของคุณหมดลงคุณมีคุณสมบัติที่เป็นรูปธรรมในแอปพลิเคชัน / โครงการของคุณ ที่คุณสามารถนำเสนอให้กับลูกค้าของคุณและรับข้อเสนอแนะ

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

ฉันเองไม่เชื่อว่าคุณควรขายโครงการที่แก้ไขแล้วจัดการกับ Agile ที่อยู่ข้างคุณ แต่ขายให้กับลูกค้าของคุณแทน

การทำซ้ำมีความชัดเจนที่จะเข้าใจและคุณไม่ได้ผสมผสานสองแนวคิด

เอกสารสองฉบับต่อไปนี้จะให้ข้อมูลบางอย่างเกี่ยวกับการจัดการ Agile และการโต้ตอบกระบวนการขาย:

http://www.nayima.be/html/fixedpriceprojects.pdf & http://www.nayima.be/html/agilefixedprice.pdf