การมีวันที่ส่งมอบคงที่สำหรับองค์ประกอบเป็นวิธีการทำงานแบบ "เปรียว" หรือไม่?

เราได้รับการบอกต่อไปว่าเราจะทำงานอย่างคล่องตัวในโครงการใหม่โดยผู้บริหารระดับสูง พวกเขาได้ตั้งค่าสแตนอัพการวางแผนการวิ่งการหวนรำลึก ฯลฯ ฯลฯ อย่างไรก็ตามตอนนี้พวกเขาได้วางแผนรายละเอียดงานทั้งหมดที่พวกเขาต้องการให้เราจัดส่งพร้อมกับวันที่กับแต่ละองค์ประกอบและวันที่แสดงอีกครั้ง หนึ่ง. แผนนี้ออกไปในไตรมาสที่ 2 ปี 2560

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

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

นี่เป็นการตัดสินที่ยุติธรรมหรือฉันทำเกินจริงต่อแผนนี้หรือไม่?

มีความแตกต่างระหว่างการประชุมกำหนดเวลาและตอบสนองความต้องการทั้งหมด มันเหมือนสุภาษิตโบราณ "เร็วดีหรือถูกเลือกสอง"

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

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

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

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

มาดูจุดต่าง ๆ ที่นี่:

เราได้รับการบอกต่อไปว่าเราจะทำงานอย่างคล่องตัวในโครงการใหม่โดยผู้บริหารระดับสูง

หากคุณเป็น Agile คุณจะต้องมีทีมที่จัดระเบียบตัวเองไม่ได้รับการบอกกล่าวว่าจะทำงานอย่างไรโดยฝ่ายบริหาร

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

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

ทีม dev นั้นไม่ได้ถูกประมาณไว้

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

สำหรับฉันนี่ดูเหมือนว่าผู้มีส่วนได้ส่วนเสียอาวุโสยังไม่ได้ซื้อเข้าสู่ Agile ดังนั้นเราจึงต้องล้มเหลวในการนำไปใช้ในระดับที่ต่ำกว่า

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

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

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

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

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

หากคุณสามารถให้ทีมผู้พัฒนานำเสนอแนวร่วมได้คุณควรผลักดันและรักษาคุณภาพเอาไว้ ประสบการณ์ของฉันคือผู้จัดการโครงการมักคิดว่าผลลัพธ์ของซอฟต์แวร์เป็นแบบเส้นตรง นั่นคือในแต่ละช่วงเวลา X จะสร้าง Y 'precentage complete' นั่นคือถ้าคุณยังไม่ "สมบูรณ์ 50%" โดยครึ่งหนึ่งของเวลาที่อนุญาต klaxons เริ่มส่งเสียงดัง ในความเป็นจริงหากคุณทำถูกต้องคุณลักษณะแรกมีแนวโน้มที่จะใช้เวลานานกว่าฟีเจอร์ที่ 50 (ขนาดใกล้เคียงกัน) หากคุณสามารถผ่านช่วงวิกฤตวิกฤตครั้งแรก ("เกิดอะไรขึ้น", "ฉันไม่ได้" ไม่เห็นสิ่งที่จะทำ! ") คุณอาจจะโอเค

ยินดีต้อนรับสู่ธุรกิจจริง

มีรูปแบบธุรกิจที่เก่ากว่าซึ่งฉันมักจะเรียกว่า "การพัฒนาแบบดั้งเดิม" อย่างเย้ยหยันแล้วก็มีรูปแบบใหม่ "การพัฒนาที่คล่องตัว" ถ้าฉันพยายามที่จะปฏิบัติต่อสิ่งเหล่านี้ในฐานะที่เป็นปฏิปักษ์ต่ออุดมคติเราจะเห็นการแบ่งแยกที่ตรงไปตรงมาตรงกลาง: แผนและข้อกำหนดต่าง ๆ อยู่ในคอลัมน์ดั้งเดิมการค้นพบและวิวัฒนาการไปในคอลัมน์ที่ว่องไว มันเป็นระเบียบเรียบร้อยและไม่ถูกต้อง

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

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

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

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

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

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

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

Agile ไม่ได้ป้องกันคุณจากการวางแผนเหตุการณ์สำคัญ (เช่นเราจะปล่อย V 1.0 ใน 3 เดือน) แต่สิ่งที่เข้าสู่แต่ละเหตุการณ์สำคัญไม่สามารถแก้ไขได้

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

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

ทุกโครงการที่เกี่ยวข้องกับธุรกิจมีข้อ จำกัด :

• เวลา
• ทรัพยากร
• ชุดคุณลักษณะขั้นต่ำที่คาดหวัง

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

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

ทั้งหมดนี้ไม่ได้ต่อต้านการพัฒนาที่คล่องตัว คุณจะยังคงมี sprints พัฒนาคุณสมบัติของคุณในกรอบเวลาของคุณเอง คุณจะได้รับลำดับความสำคัญของฟีเจอร์จากไคลเอนต์ - และคุณจะพยายามส่งมอบฟีเจอร์เหล่านี้ให้มากที่สุดเท่าที่จะทำได้จนกว่าจะถึงกำหนด

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

อย่างที่ใครบางคนชี้ไปแล้วก่อนที่แถลงจะพูดว่า:

บุคคลและการมีปฏิสัมพันธ์ในกระบวนการ

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

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

นี่คือจุดที่มันสามารถไปได้สองทาง

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

2. พวกเขายังอาจต้องการยึดติดกับเวอร์ชั่นของตัวเองกับความเห็นโดยรวมของทีม

หากผลลัพธ์เป็น # 2 แสดงว่าไม่ใช่ Agile

หากคุณจบลงด้วยอันดับที่ 1 ฉันจะบอกว่าทีมนั้นอยู่ในเส้นทางที่ถูกต้องเพราะ Agile ไม่ได้เป็นเพียงแค่ Devs "การตอบสนองต่อการเปลี่ยนแปลง" แต่ยังเกี่ยวกับธุรกิจที่สามารถตอบสนองต่อการเปลี่ยนแปลงได้

ลองนึกภาพการขอให้ใครสักคนทาสีกำแพงบ้านและจากนั้นก็เป็นถนนทั้งสายสำหรับคุณคุณจะให้เวลาคนนั้นทำเวลาเท่าไหร่?

ไม่ว่าคำตอบของคุณคืออะไรคุณจะผิด แค่นั้นแหละ.

ไม่มีทางที่พวกเขาจะพูดถูกถ้าไม่ถามคนที่ต้องการทำงานอย่างที่คิด

อย่างไรก็ตามถ้าคุณ (ในฐานะทีม) ยอมรับวันที่เหล่านี้แสดงว่าคุณผิดที่นั่น

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

ตัวอย่างเช่นงานสุดท้ายอาจใช้เวลานานกว่าที่คิดไว้สองเท่า แต่พวกเขาสามารถใช้เบต้าเร็วกว่าที่คาดไว้

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

มันไม่ได้ aglie การวางแผนหมายเลข

แต่ถ้าคุณ prentend คุณก็ไม่รู้แผนการและแค่วิ่งด้วยการวิ่ง มันอาจจะเป็นการทำงานที่วุ่นวาย

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

หากคุณทำงานอย่างว่องไวดังนั้นแผน B ก็คือการสาธิตการวิ่งครั้งสุดท้าย