เหตุใดโครงการไอทีขนาดใหญ่จึงล้มเหลวหรือมีค่าใช้จ่าย / กำหนดการมากเกินไป [ปิด]

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

ตัวอย่างหนึ่งจากออสเตรเลียคือโครงการเงินเดือนของรัฐควีนส์แลนด์ซึ่งพวกเขาเปลี่ยนเกณฑ์ความสำเร็จในการทดสอบเพื่อส่งมอบโครงการ
ดูโครงการที่ล้มเหลวเพิ่มเติมในคำถาม SO นี้ ( บนเครื่อง Wayback )

คุณมีประสบการณ์ส่วนตัวบ้างไหมที่จะแบ่งปัน?

เหตุผลหลักคือการเพิ่มขึ้นของขอบเขตซึ่งหนังสือ "The Pragmatic Programmer" อธิบายว่า:

• คุณสมบัติ bloats
• กำลังคืบคลาน
• คืบคลาน

มันเป็นลักษณะของโรคกบต้ม

แนวคิดของวิธีการ "ว่องไว" ที่หลากหลายคือการเร่งการป้อนกลับและ - หวังว่า - จะแก้ไขวิวัฒนาการของโครงการได้ทันเวลา

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

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

โพสต์บล็อก " โปรเจ็กต์ล่าช้าจะล่าช้าในแต่ละวัน " มีตัวอย่างอีกมากมาย:

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

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

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

โดยปกติความซับซ้อนของโครงการจะถูกประเมิน

สตีฟแมคคอนเนลล์ (ของ "รหัสสินค้า" ยี่ห้อ) มีรายชื่อของที่ผิดพลาดคลาสสิก

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

ส่วนนี้ระบุข้อผิดพลาดคลาสสิกสามโหล ฉันได้เห็นข้อผิดพลาดเหล่านี้เป็นการส่วนตัวอย่างน้อยหนึ่งครั้งและฉันได้ทำหลายข้อด้วยตนเอง ...

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

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

คน

# 1: แรงจูงใจที่บั่นทอน ...

# 2: บุคลากรที่อ่อนแอ ...

# 3: พนักงานที่มีปัญหาที่ไม่สามารถควบคุมได้ ...

# 4: Heroics ...

# 5: การเพิ่มผู้คนในโครงการล่าช้า ...

# 6: สำนักงานที่มีเสียงดังและแออัด ...

# 7: ความขัดแย้งระหว่างนักพัฒนาและลูกค้า ...

# 8: ความคาดหวังที่ไม่สมจริง ...

# 9: ขาดการสนับสนุนโครงการที่มีประสิทธิภาพ ...

# 10: การขาดการซื้อของผู้มีส่วนได้เสีย ...

# 11: การขาดการป้อนข้อมูลของผู้ใช้ ...

# 12: การเมืองวางอยู่เหนือเนื้อหา ...

# 13: ความคิดที่ปรารถนา ...

กระบวนการ

# 14: กำหนดการมองโลกในแง่ดีเกินไป ...

# 15: การจัดการความเสี่ยงไม่เพียงพอ ...

# 16: ความล้มเหลวของผู้รับเหมา ...

# 17: การวางแผนไม่เพียงพอ ...

# 18: ยกเลิกการวางแผนภายใต้ความกดดัน ...

# 19: เสียเวลาในช่วงปลายด้านหน้าเลือน "ส่วนหน้าเลือน" เป็นเวลาก่อนที่โครงการจะเริ่มเวลาที่ใช้ในกระบวนการอนุมัติและการจัดทำงบประมาณตามปกติ ...

# 20: กิจกรรมต้นน้ำสั้น ๆ ... ยังเป็นที่รู้จักกันในนาม

# 21: การออกแบบไม่เพียงพอ ...

# 22: ประกันคุณภาพแบบสั้น ...

# 23: การควบคุมการจัดการไม่เพียงพอ ...

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

# 25: ละเว้นงานที่จำเป็นจากการประมาณ ...

# 26: วางแผนที่จะติดตามในภายหลัง ...

# 27: การเขียนโปรแกรมรหัสเหมือนนรก บางองค์กรคิดว่าการเขียนโค้ดที่รวดเร็วหลวมทุกการใช้งานเป็นเส้นทางสู่การพัฒนาอย่างรวดเร็ว ...

สินค้า

# 28: ข้อกำหนดการชุบทอง บางโครงการมีความต้องการมากกว่าที่ต้องการตั้งแต่ต้น ...

# 29: คืบคลานคุณลักษณะ ...

# 30: นักพัฒนาทองคำชุบ นักพัฒนาซอฟต์แวร์ต่างหลงใหลในเทคโนโลยีใหม่ ๆ และบางครั้งก็มีความกังวลที่จะลองใช้คุณสมบัติใหม่ ๆ ... - ไม่ว่าจะต้องการในผลิตภัณฑ์ของพวกเขาหรือไม่ก็ตาม ...

# 31: ผลักฉันดึงฉันเจรจา ...

# 32: การพัฒนาที่มุ่งเน้นการวิจัย Seymour Cray นักออกแบบของซูเปอร์คอมพิวเตอร์ Cray กล่าวว่าเขาไม่ได้พยายามที่จะเกินขีด จำกัด ทางวิศวกรรมในมากกว่าสองพื้นที่ในเวลาเดียวกันเพราะความเสี่ยงของความล้มเหลวสูงเกินไป (Gilb 1988) โครงการซอฟต์แวร์จำนวนมากสามารถเรียนรู้บทเรียนจาก Cray ...

เทคโนโลยี

# 33: ซินโดรมกระสุนเงิน ...

# 34: การประหยัดแบบ overestimated จากเครื่องมือหรือวิธีการใหม่ ... กรณีพิเศษของการประหยัดแบบ overestimated เกิดขึ้นเมื่อโครงการใช้รหัสจากโครงการก่อนหน้านี้ ...

# 35: การสลับเครื่องมือกลางโครงการ ...

# 36: การขาดการควบคุมซอร์สโค้ดอัตโนมัติ ...

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

ฉันตำหนิกระบวนการเสนอราคา มันให้รางวัลแก่กลุ่มที่สามารถทำให้ดีลนั้นดูถูก / เร็วที่สุดบนกระดาษ

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

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

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

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

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

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

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

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

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

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

ส่วนใหญ่แล้วเป็นการรวมกันของสองอย่างหรือมากกว่าต่อไปนี้:

• ปัญหาความร่วมมือระหว่างหน่วยงาน
• การเมือง ... การเมืองมากเกินไป ...
• ทีมผิด
• การตั้งเวลาที่ไม่สมจริง
• การเปลี่ยนขอบเขตโดยไม่มีวิธีการที่เหมาะสม
• ข้อมูลที่ขาดหายไป

หนังสือที่ดีในเรื่อง: ตายมีนาคม

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

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

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

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

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

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

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

การรับรู้ของความจริง

นี่คือคำอธิบายที่ดีที่สุดของปัญหานี้ที่ฉันเคยพบ Tree Swing จาก businessballs.com

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

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

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

และอื่น ๆ และอื่น ๆ.

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

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

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

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

อธิบายเพิ่มเติมเกี่ยวกับคำตอบของ VonC:

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

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

อะไรคือทางออกของปัญหานี้?

ฉันไม่รู้จริง ๆ ว่าไม่มีใครอยากให้ทั้งสองระบบทำงานพร้อมกันโดยมีการเปลี่ยนชุดฟังก์ชั่นที่แยกระหว่างสองระบบ

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

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

ปัจจัยที่ได้รับการสัมผัส แต่ยังไม่ได้แก้ไข:

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

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

Michael Krigsman บน ZDNet มีบล็อกที่อุทิศให้กับ " IT Project Failures " ซึ่งอาจเป็นที่สนใจของที่นี่

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

สามารถใช้เปรียวในโครงการประเภทนี้หรือวิธีการดั้งเดิมยังคงดีที่สุด

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

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

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

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

• ล้มเหลวในการจัดส่งไปยังผู้ใช้งานจริง

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

• ไม่สามารถประมาณการต้นทุนได้อย่างถูกต้อง

หากโครงการดูเหมือนว่าพวกเขาจะโตเร็วกว่าผลตอบแทนจากการลงทุนพวกเขาจะถูกยกเลิก

• ความล้มเหลวในการควบคุมคุณภาพ

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

พวกเขาลืมกฎของ Hofstadter: มันใช้เวลานานกว่าที่คุณคาดไว้แม้ว่าคุณจะคำนึงถึงกฎหมายของ Hofstadter

สิ่งที่ฉันเคยเห็นในการพัฒนาเว็บ:

• มีพ่อครัวมากเกินไป - ร้านค้าปลีก B&M รายใหญ่ซึ่งเน้นไปที่เว็บในทันที ทันใดนั้นหัวหน้าแผนก 20 คนกำลังจับใจทุกความคิดริเริ่มที่จะสร้างความประทับใจให้กับชีสหัวใหม่ ฉันเคยต้องใช้ไอคอนใหม่เพราะกฎหมายไม่ชอบหน้าตาเก่า ๆ

• มุ่งเน้นที่รายละเอียดการจับคู่ที่มากเกินไปเพื่อให้บรรลุเป้าหมาย - "ไอคอนของ IE6 จางลงเล็กน้อยเมื่อเทียบกับของ IE7 โปรดวางงานวันที่เปิดตัวที่สำคัญที่คุณกำลังทำและเข้าร่วมกับ. 05% ของฐานลูกค้าของเรา เพื่อนำไปใช้และลดประสบการณ์ IE ให้มากยิ่งขึ้น "

• เครื่องมือที่ไม่ดีถูกเลือกโดยผู้ที่ไม่ใช่ผู้ที่ไม่สามารถแม้แต่จะขอคำแนะนำจากผู้พัฒนาเอง

• เครื่องมือที่ไม่ดีได้รับเลือก - "ทำไมต้องจ่าย Java ที่มีความสามารถ 20 คนให้เงินเดือนที่เหมาะสมเมื่อเราสามารถจ้างคนรู้หนังสือที่รู้รหัสน้อยกว่า 200 คนที่รู้ว่าน้อยเกินไปที่จะใช้การควบคุมเวอร์ชัน" ขณะที่พวกเขาพร้อมกันและกับผู้คนในประเทศต่าง ๆ ทำงานบน back-end เป็นหลักสำหรับ 3 แอพขนาดใหญ่

• สถาปัตยกรรมที่ไม่ดี / แตก - เลเยอร์ตามเลเยอร์ของรหัสที่ตื่นตระหนกทำให้เสร็จเมื่อวานนี้โดยคนที่ถูกไล่ออกหรือตอนนี้เป็นผู้จัดการ