ไทม์ไลน์และการกำหนดเวลาที่ จำกัด มีผลต่อ TCO และเวลาส่งมอบอย่างไร


9

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

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

การเชื่อมโยงใด ๆ กับวรรณกรรมวิศวกรรมซอฟต์แวร์จะได้รับการชื่นชม


TCO หมายถึงอะไรในบริบทนี้
Andres F.

ฉันสมมติว่า TCO หมายถึงต้นทุนการเป็นเจ้าของทั้งหมด ถูกต้องหรือไม่
โธมัสโอเวนส์

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

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

@ThomasOwens ตัดสินโดยลิงก์จาก Wikipedia นั่นไม่ใช่ความประทับใจที่ฉันได้รับ ไม่กล่าวถึงการพัฒนาอย่างแน่นอน(ทำการค้นหา!) แม้ว่าเทคโนโลยีและผลิตภัณฑ์ซอฟต์แวร์จะเป็น (และข้อกังวลที่เกี่ยวข้องเช่นการปรับใช้และการบำรุงรักษา) TCO นั้นเกี่ยวข้องกับการเป็นเจ้าของมันบอกไว้ในชื่อด้วย! ความเข้าใจของฉันคือว่า TCO คือการพิจารณาเมื่อเลือกสินค้าที่จะซื้อไม่ได้ซึ่งผลิตภัณฑ์เพื่อสร้าง
Andres F.

คำตอบ:


5

สาเหตุอันดับหนึ่งของการกำหนดตารางเวลาที่เกินกำหนดคือความดันที่กำหนดไว้

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

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

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


+1 นอกจากนี้การตั้งเวลา "กดดัน" บางครั้ง - แต่ไม่เสมอไป - สะท้อนถึงความกังวลทางธุรกิจที่แท้จริง ไม่มีทางหลีกเลี่ยงได้ "เมื่อใดก็ตามที่ทำเสร็จ" ไม่ใช่วันครบกำหนดที่ยอมรับได้สำหรับหลาย ๆ โครงการ ในความเป็นจริงหากสิ่งที่สามารถสัญญาได้ว่าเป็นวันที่เป้าหมายคือ "เมื่อใดก็ตาม" ความเป็นไปได้ที่ยอมรับได้คือการยกเลิกโครงการ
Andres F.

Steve McConnell ระบุว่า "กำหนดการมองโลกในแง่ดีเกินไป" เป็นหนึ่งในข้อผิดพลาดในการฝึกพัฒนาซอฟต์แวร์แบบคลาสสิกและเป็นแหล่งสำคัญของปัญหาโครงการ นี่จะเป็นสาเหตุของการกำหนดตารางเวลาการบุกรุกในครั้งแรก stevemcconnell.com/rdenum.htm
คุณคนเดียวเท่านั้น

2

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

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

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


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

**มีข้อสันนิษฐานที่ชัดเจนว่าการเขียนโปรแกรมคล้ายกับการทำคณิตศาสตร์ ฉันคิดว่าสมมติฐานนี้ยุติธรรม


2

ยิ่งคุณมีกำหนดการกดดันมากเท่าไหร่เวลาส่งมอบนานขึ้นและ TCO มากขึ้นเท่านั้น

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

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


2

ขวาไปซ้ายการตั้งเวลา

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

ปัญหาได้รับรอบในขณะที่ เฟร็ดบรูคส์พูดถึงเกี่ยวกับการประมาณลำไส้น้อยลงในตำนาน Man-เดือน Barry Boehm พูดถึงเรื่องนี้ในข้อเสนอของเขาสำหรับแนวทางการบริหารทฤษฎี เมื่อเร็ว ๆ นี้สตีฟ McConnell (ผู้เขียนรหัสเสร็จสมบูรณ์ ) นำแนวคิดของการเจรจาต่อรองปัญหาจริยธรรมเข้าไปในโฟกัสใน"วิธีการปกป้องกำหนดการไม่เป็นที่นิยม"

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

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

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

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

Scrum diagram - ใบอนุญาตครีเอทีฟคอมมอนส์ดู

ใบอนุญาตครีเอทีฟคอมมอนส์ - ดูhttp://en.wikipedia.org/wiki/File:Scrum_process.svg


+1 สำหรับการเพิ่มไม่ใช่การอ้างอิงเดียว แต่เป็นการอ้างอิงหลายรายการ!
Christos Hayward

1

คุณไม่ต้องการเอกสารทางวิศวกรรมซอฟต์แวร์ ความน่าจะเป็นแนวคิดและสถิติจากปริญญาตรีเป็นสิ่งที่คุณต้องการ

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

ความน่าจะเป็น 101: p (ต่ำกว่าหรือต่ำกว่าเป้า) + p (มากไป) = 100%

กำหนดการที่ยึดตามการประมาณการมีลักษณะเหมือนกันทุกประการ

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

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

แผนกพลศาสตร์ / ฟอร์ตเวิร์ ธ ได้เรียนรู้วิธีนี้อย่างหนัก พวกเขาทำการประเมินเบื้องต้นสำหรับการพัฒนา F-16C / D และส่งมันขึ้นห่วงโซ่อาหาร ใครบางคนที่สูงขึ้นไปโดยพลการตัดออกไปหนึ่งปีโดยพลการและส่งไปยังกองทัพอากาศ เป็นผลโดยตรง GD / FW นั้นล่าช้าไปหนึ่งปีสำหรับการทดสอบการบินและกองทัพอากาศไม่มีความสุข (โปรดทราบว่า "ปลายปีหนึ่ง" เป็นไปตามกำหนดการที่แก้ไขหมายถึงตารางเวลาเดิมคือ RIGHT ON TARGET)


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

1

ฉันคิดว่าจำนวนของความกดดันในโครงการตกลงเพราะช่วยในการรักษาโฟกัส

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

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

มีหลายปัจจัยที่มีอิทธิพลต่อความหมายของคำว่าดีพอ

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

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

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

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


+1: "ไม่มีเวลามากพอที่จะทำอย่างถูกต้องในครั้งแรก แต่มีเพียงพอที่จะแก้ไขได้ในภายหลัง" คำถามนั้นอยู่ในใจของฉันเกี่ยวกับการใช้เวลาสองเท่าในตอนแรกเพื่อให้ถูกต้องรวมถึงการจัดการกับข้อบกพร่องในระดับปานกลางมี TCO ที่ต่ำกว่าอย่างมากจากงานเร่งด่วนที่ใช้เวลาน้อยกว่าครึ่งแรกในเวลานั้น ผลที่ตามมาของงานเร่งด่วนอย่างรวดเร็วในตอนแรก
Christos Hayward

ดังที่ฉันได้ชี้ให้เห็นว่าถ้าคุณมีเพียงรุ่นเดียวและคุณมีแผนกทดสอบที่ดีผลิตภัณฑ์ของคุณสามารถใช้ได้แม้ว่าคุณจะประหยัดเวลาในการเขียนรหัส: รหัสอาจยุ่งเหยิง แต่การทดสอบอย่างละเอียดทำให้มั่นใจได้ว่าทำงานได้อย่างที่คาดไว้ แต่ถ้าคุณมีรุ่นที่วางจำหน่ายในภายหลังบนฐานรหัสเดียวกันคุณอาจต้องเขียนรหัสจำนวนมากสำหรับรุ่นที่สองและสาม ในสถานการณ์หลังคุณอาจประหยัดเวลาในการออกหลาย ๆ ครั้งโดยการออกแบบรหัสของคุณอย่างรอบคอบมากขึ้นในครั้งแรก
Giorgio
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.