วิธีการหยุดการพัฒนาสเปคจากการเปลี่ยนแปลงในการพัฒนากลาง?

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

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

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

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

1. สร้างความแตกต่างที่ชัดเจนว่าอะไรที่สามารถเปลี่ยนแปลงได้และอะไรที่ไม่สามารถทำได้ สื่อสารอย่างชัดเจนกับผู้มีส่วนได้ส่วนเสียทำให้พวกเขาลงชื่ออย่างชัดเจนในสิ่งที่ไม่สามารถเปลี่ยนแปลงได้โดยเร็วที่สุด
2. เตรียมความพร้อมสำหรับการเปลี่ยนแปลงล่วงหน้า ใช้วิธีการรหัสที่อนุญาตให้เปลี่ยนชิ้นส่วนที่เปลี่ยนแปลงได้ง่ายขึ้นลงทุนในการกำหนดค่าการห่อหุ้มและโปรโตคอลที่ชัดเจนซึ่งจะช่วยให้ชิ้นส่วนมีการเปลี่ยนแปลงและแทนที่โดยอิสระ
3. พูดคุยกับผู้มีส่วนได้ส่วนเสียบ่อยครั้งชักชวนความคิดเห็นและการอนุมัติ ทั้งสองนี้จะทำให้คุณซิงค์และหลีกเลี่ยงการอ้างว่า "โอ้นั่นไม่ใช่สิ่งที่เราต้องการ" เมื่อมันสายเกินไป ดังที่ได้กล่าวไว้ในคำตอบอื่น ๆ วิธีการที่คล่องตัวและการเผยแพร่มินิบ่อย ๆ จะช่วยคุณได้
4. ใส่ลงในตารางเวลาเพื่อรองรับการเปลี่ยนแปลงที่หลีกเลี่ยงไม่ได้ อย่ากลัวที่จะพูดว่า "เราจะต้องใช้เวลามากขึ้น" ในช่วงต้นถ้าคุณคิดว่าคุณจะ - ถ้าตารางที่คุณได้รับไม่สมจริงจะดีกว่าที่จะรู้ว่ามัน (และมีคุณในบันทึกบอกว่า) ที่เริ่มต้นกว่าที่ ตอนจบ.
5. หากการเปลี่ยนแปลงนั้นกว้างขวางเกินไปและคุกคามกำหนดเวลา - ส่งกลับและพูดบางอย่างเช่น "การเปลี่ยนแปลงนี้เป็นไปได้ แต่จะผลักดันกำหนดเวลาภายในเวลา X เลือกตัวเลือกของคุณ"
6. ดำเนินการอย่างเป็นทางการในการร้องขอการเปลี่ยนแปลงจัดลำดับความสำคัญการเปลี่ยนแปลงและกำหนดการเปลี่ยนแปลงให้กับเวอร์ชันหรือรีลีส หากคุณสามารถบอกคนอื่นว่า "ฉันไม่สามารถทำได้ในรุ่นนี้ แต่จะมีความสุขที่จะวางกำหนดการสำหรับรุ่นต่อไป" ดีกว่าพูดพวกเขาว่า "คุณสายเกินไปการเปลี่ยนแปลงของคุณไม่สามารถทำได้ ลาก่อน "และจะทำให้พวกเขาเป็นเพื่อนของคุณ - พวกเขายินดีที่คุณจะปล่อยทันเวลาเพื่อให้คุณสามารถเป็นอิสระได้เร็วขึ้นที่จะได้รับการปล่อยตัวครั้งต่อไปซึ่งจะมีการเปลี่ยนแปลง - ไม่ใช่ศัตรูของคุณ

ส่งบางสิ่ง (ฉันลังเลที่จะใช้คำอะไรก็ได้) แต่เนิ่น ๆ และส่งบ่อย นั่นคือ - ใช้วิธีการพัฒนาแบบวนซ้ำ

นี่คือพื้นฐานของการพัฒนาแบบ Agile แต่สามารถใช้ได้กับ (เกือบ) วิธีการใด ๆ

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

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

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

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

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

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

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

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

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

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

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

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

การเปลี่ยนแปลงเป็นเพียงความประหลาดใจ ... ถ้ามันแปลกใจ!

ฉันขอแนะนำให้คิดเกี่ยวกับ:

• การเปลี่ยนแปลงเหล่านี้มาจากไหน?
• ทำไมคุณไม่ทราบก่อนหน้านี้
• เหตุใดคุณจึงไม่สนับสนุนการเปลี่ยนแปลงเหล่านี้ (และอาจทำให้มีมากขึ้น)

การเปลี่ยนแปลงคือลักษณะของสิ่งที่เราทำ ตั้งแต่เมื่อไหร่ที่คุณรหัสอัลกอริทึมตรงตามที่จินตนาการไว้ในวันที่ 1

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

ลูกค้าโทรอยากได้มากขึ้น แต่นี่คือจุดที่คุณควรพิจารณา:

HTML Mock-ups:สร้าง HTML mock ups ขึ้นเพื่อกำหนดส่วน UI ของแอปพลิเคชันแสดงให้พวกเขาเห็นว่าหน้าตามันจะเป็นอย่างไรและขอความคิดเห็นจากพวกเขา หากคุณพบว่ามีสิ่งใดที่สมควรเปลี่ยนให้เกิดขึ้นในต้นแบบ HTML เมื่อใช้สิ่งนี้คุณจะพบกับสิ่งต่างๆมากมายเช่นปัญหา UI, โฟลว์พื้นฐานและส่วนเสริม (เช่นการเรียงลำดับ, การแบ่งหน้า, จำนวนระเบียนที่จะแสดงเป็นต้น)

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

การปล่อยแบบแยกส่วน:ปล่อยรหัสของคุณในแบบแยกส่วนการทดสอบการใช้ข้อเสนอแนะและปล่อยอีกครั้ง

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

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

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

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

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

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

ps ถ้าไม่ใช่ "PO"ฉันจะบอกว่าอย่าคุยกับฉันผ่าน "PO"

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

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

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

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

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

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

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

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

http://teddziuba.com/2010/05/why-engineers-hop-jobs.html

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

ตรงไปตรงมาฉันต้องการโปรแกรมเมอร์โดยทั่วไปมีลูกบอลเพิ่มขึ้น ลองดูที่:

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

หากคุณกำลังติดต่อกับลูกค้า $ -paying และหากคุณครอบคลุม ass ของคุณโดยมีสัญญา (http://vimeo.com/22053820?utm_source=swissmiss) การเปลี่ยนแปลงข้อมูลจำเพาะจะทำให้ลูกค้ารายนี้เสียเวลามากขึ้นและมีเงินมากขึ้น ( หรืออาจใช้เวลาเดียวกันหรือน้อยกว่าก็ได้ บริษัท ของคุณพยายามหลีกเลี่ยงการเปลี่ยนข้อมูลจำเพาะโดยไม่ต้องเสียเวลาและค่าใช้จ่ายมากขึ้น

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

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

จากนั้นยังมีคำมั่นสัญญาว่าด้วยการพัฒนาที่คล่องตัวซึ่งไม่ได้กำหนดเส้นตายอย่างหนัก

ฉันยังไม่เห็นว่าโปรแกรมเมอร์หยุดงาน แต่สิ่งนี้จะเป็นอะไรบางอย่าง ผู้จัดการที่ไม่มีความสามารถมีมากเกินไปใน บริษัท ซอฟต์แวร์ วิธีที่ผู้คนจำนวนมากเกินไปต้องการได้รับสิ่งใดสิ่งหนึ่งที่ Craigslist หรือภายใน บริษัท จริง http://teddziuba.com/2011/07/the-craigslist-reverse-programmer-troll.html

โปรแกรมเมอร์จำเป็นต้องมีลูกเพิ่ม

วิธีการที่ฉันพบว่าทำงานเรียงลำดับของ OK (ไม่ใช่กับผู้จัดการทั้งหมดอย่างชัดเจน) คือ "ฉันคิดว่าฉันสามารถทำเช่นนั้นได้ใช่ขึ้นอยู่กับ - คุณมีเวลาพิเศษที่กำหนดให้กับโครงการนี้มากน้อยเพียงใด ขอ."