Tại sao các dự án CNTT lớn có xu hướng thất bại hoặc vượt quá chi phí / tiến độ lớn? [đóng cửa]

Tôi luôn đọc về dự án chuyển đổi hoặc tích hợp quy mô lớn là thảm họa toàn diện hoặc gần như toàn bộ. Ngay cả khi họ bằng cách nào đó quản lý để thành công, chi phí và lịch trình thổi ra là rất lớn. Lý do thực sự đằng sau các dự án lớn dễ bị thất bại là gì. Có thể nhanh nhẹn được sử dụng trong các loại dự án hoặc phương pháp truyền thống vẫn là tốt nhất.

Một ví dụ từ Úc là dự án Biên chế Queensland , nơi họ đã thay đổi các tiêu chí thành công thử nghiệm để cung cấp dự án.
Xem thêm một số dự án thất bại trong câu hỏi SO này ( trên Wayback Machine )

Bạn đã có bất kỳ kinh nghiệm cá nhân để chia sẻ?

Lý do chính là sự gia tăng phạm vi , mà cuốn sách "Lập trình viên thực dụng" mô tả như sau:

• tính năng phình to
• leo kỳ công
• yêu cầu leo

Đó là một khía cạnh của hội chứng ếch luộc.

Ý tưởng của phương pháp "nhanh nhẹn" khác nhau là tăng tốc phản hồi và - hy vọng - điều chỉnh sự phát triển của dự án kịp thời.

Nhưng lý do khác là quản lý phát hành : nếu bạn không định phát hành dự án (tuy nhiên nó không hoàn hảo), rất có thể nó sẽ thất bại (vì phát hành quá muộn, với quá nhiều tính năng lỗi và khó sửa / cập nhật hơn nâng cấp).

Điều đó không có nghĩa là bạn phải có ngày phát hành cố định, nhưng điều đó có nghĩa là bạn phải có khả năng xây dựng phiên bản đang chạy của chương trình để kiểm tra / đánh giá / phát hành.

Bài đăng trên blog " Các dự án muộn là muộn một ngày tại một thời điểm " chứa nhiều ví dụ khác:

Tôi biết điều 'Bắt ​​thực tế' cần làm là Flex phạm vi và giữ ngày ra mắt cố định, nhưng điều đó không hiệu quả nếu có chức năng theo thỏa thuận không thể hoàn thành kịp thời.

Đó là lý do tại sao chúng tôi không ủng hộ các thông số kỹ thuật hoặc chức năng đã đồng ý với các chức năng. .

Khi bạn dự đoán một tương lai cứng nhắc về một hiện tại linh hoạt, bạn sẽ gặp rắc rối. Tương lai cứng nhắc là một trong những điều nguy hiểm nhất. Họ không rời khỏi phòng để khám phá, xuất hiện và những sai lầm mở ra cánh cửa mới.

Thông thường sự phức tạp của dự án được đánh giá thấp .

Steve McConnell (danh tiếng "Hoàn thành mã") có một danh sách các sai lầm kinh điển .

Một số thực tiễn phát triển không hiệu quả đã được lựa chọn rất thường xuyên, bởi rất nhiều người, với kết quả xấu, có thể dự đoán được đến mức họ đáng bị gọi là "những sai lầm kinh điển" ...

Phần này liệt kê ba chục sai lầm kinh điển. Cá nhân tôi đã thấy từng lỗi trong số đó mắc phải ít nhất một lần và tôi đã tự mình thực hiện nhiều lỗi trong số đó ...

Mẫu số chung trong danh sách này là bạn sẽ không nhất thiết có được sự phát triển nhanh chóng nếu bạn tránh được sai lầm, nhưng bạn chắc chắn sẽ có được sự phát triển chậm nếu bạn không tránh nó ...

Để dễ tham khảo, danh sách đã được chia theo kích thước phát triển của con người, quy trình, sản phẩm và công nghệ.

Những người

# 1: Động lực làm suy yếu ...

# 2: Nhân sự yếu ...

# 3: Nhân viên có vấn đề không được kiểm soát ...

# 4: Anh hùng ...

# 5: Thêm người vào một dự án muộn ...

# 6: Văn phòng ồn ào, đông đúc ...

# 7: Ma sát giữa nhà phát triển và khách hàng ...

# 8: Kỳ vọng không thực tế ...

# 9: Thiếu tài trợ dự án hiệu quả ...

# 10: Thiếu các bên liên quan mua vào ...

# 11: Thiếu đầu vào của người dùng ...

# 12: Chính trị được đặt trên chất ...

# 13: Suy nghĩ mơ ước ...

Quá trình

# 14: Lịch trình quá lạc quan ...

# 15: Quản lý rủi ro không đầy đủ ...

# 16: Nhà thầu thất bại ...

# 17: Lập kế hoạch không đầy đủ ...

# 18: Từ bỏ kế hoạch dưới áp lực ...

# 19: Thời gian lãng phí trong phần đầu mờ. "Mặt trước mờ" là thời gian trước khi dự án bắt đầu, thời gian thường dành cho quá trình phê duyệt và lập ngân sách ...

# 20: Các hoạt động ngược dòng được chuyển đổi ... Còn được gọi là "nhảy vào mã hóa" ...

# 21: Thiết kế không đầy đủ ...

# 22: Đảm bảo chất lượng ngắn hạn ...

# 23: Kiểm soát quản lý không đầy đủ ...

# 24: Hội tụ sớm hoặc quá thường xuyên. Ngay trước khi một sản phẩm dự kiến ​​được phát hành, có một nỗ lực để chuẩn bị phát hành sản phẩm - cải thiện hiệu suất của sản phẩm, in tài liệu cuối cùng, kết hợp các móc hệ thống trợ giúp cuối cùng, đánh bóng chương trình cài đặt, loại bỏ chức năng sẽ không được sẵn sàng đúng giờ, v.v.

# 25: Bỏ các nhiệm vụ cần thiết từ ước tính ...

# 26: Lên kế hoạch để bắt kịp sau ...

# 27: Lập trình mã giống như địa ngục. Một số tổ chức nghĩ rằng mã hóa nhanh, lỏng lẻo, nhanh chóng là một lộ trình để phát triển nhanh chóng ...

Sản phẩm

# 28: Yêu cầu mạ vàng. Một số dự án có nhiều yêu cầu hơn mức cần thiết ngay từ đầu ...

# 29: Tính năng leo ...

# 30: Nhà phát triển mạ vàng. Các nhà phát triển bị mê hoặc bởi công nghệ mới và đôi khi rất lo lắng khi thử các tính năng mới ... - cho dù đó có phải là yêu cầu trong sản phẩm của họ hay không ...

# 31: Đẩy tôi, kéo tôi đàm phán ...

# 32: Phát triển theo định hướng nghiên cứu. Seymour Cray, nhà thiết kế siêu máy tính Cray, nói rằng ông không cố gắng vượt quá giới hạn kỹ thuật ở hơn hai lĩnh vực cùng một lúc vì nguy cơ thất bại quá cao (Gilb 1988). Nhiều dự án phần mềm có thể học một bài học từ Cray ...

Công nghệ

# 33: Hội chứng đạn bạc ...

# 34: Tiết kiệm được đánh giá quá cao từ các công cụ hoặc phương pháp mới ... Một trường hợp đặc biệt về tiết kiệm được đánh giá quá cao phát sinh khi các dự án sử dụng lại mã từ các dự án trước đó ...

# 35: Chuyển đổi công cụ ở giữa dự án ...

# 36: Thiếu kiểm soát mã nguồn tự động ...

Dự án lớn hơn = Phức tạp hơn Phức tạp
hơn = Nhiều điều không chắc chắn
Nhiều điều không chắc chắn hơn = Ước tính
khó hơn Ước tính khó hơn = Ước tính
xấu Ước tính xấu = Chi phí vượt mức

Tôi đổ lỗi cho quá trình đấu thầu. Nó thưởng cho nhóm có thể làm cho giao dịch trông rẻ nhất / nhanh nhất trên giấy.

Những người đặt giá thầu cùng nhau không muốn lãng phí thời gian của họ nếu họ không có cơ hội chiến thắng, vì vậy ước tính bình thường của họ bị trì hoãn. Tôi biết những người đã chỉ định các công tắc bình thường thay vì các công tắc POE để tiết kiệm $ 80. Nhưng dự án cần POE vì nó có camera IP. 80 đô la đó cần phải được chi tiêu, nhưng bây giờ nó nằm ngoài thông số kỹ thuật.

Tôi có niềm tin vững chắc rằng một dự án 2.000.000 đô la trong 2 tháng vẫn sẽ mất 2 tháng 2.000.000 đô la cho dù bạn nhận được bao nhiêu giá thầu. Nếu bạn nghĩ làm đúng thì tốn kém, hãy chờ xem làm thế nào đắt để làm sai.

Một lý do có thể là các ước tính dựa trên các dự án nhỏ hơn, giả sử tăng trưởng tuyến tính chi phí với quy mô dự án, trong khi thực tế tăng trưởng chi phí là ví dụ do tăng độ phức tạp, thời gian dự án dài hơn (thời gian thay đổi yêu cầu nhiều hơn), v.v. khó, và dự án càng lớn, càng khó ước tính chính xác.

Một lý do khác là ước tính thiên vị tối ưu: Để giành được giá thầu, ước tính trường hợp tốt nhất được sử dụng để tính giá. Dự án càng lớn, càng ít có khả năng là một trường hợp tốt nhất. Quy tắc đặt giá thầu khiến người cung cấp lạc quan nhất có thể chấp nhận, vì vậy ngay cả khi 5 nhà cung cấp ước tính thực tế và người thứ 6 quá lạc quan, người lạc quan sẽ thắng thầu và thất bại sau đó. Vì vậy, đây là loại lựa chọn tiêu cực.

Chi phí không loại trừ lịch trình trong con mắt của 'quản lý', đó là một sự khác biệt quan trọng để thực hiện. Như chúng ta đã biết, "chín phụ nữ không thể sinh con trong một tháng" , nhưng bạn sẽ ngạc nhiên khi có nhiều người nghĩ rằng các vấn đề giảm sâu liên quan đến số tiền ném vào họ. Quản lý dự án kém, thường biểu hiện dưới hình thức quản lý vi mô là nguyên nhân hàng đầu của hầu hết các dự án tăng (theo kinh nghiệm của tôi). Quản lý vi mô khởi động khi 'quản lý' nhận ra rằng có thứ gì đó vượt khỏi tầm kiểm soát và họ không biết tại sao.

Khi đó không phải là nguyên nhân, kết quả dự kiến ​​của dự án có lẽ không thể bắt đầu được. Theo kinh nghiệm của tôi, nếu khung thời gian của một dự án quá ngắn, mọi người sẽ rất sợ mắc sai lầm dẫn đến 'công việc kép' mà họ không làm được gì nhiều.

Đây là lý do tại sao quản lý nên được phổ biến với các lập trình viên dày dạn, có lịch sử của các nhóm hàng đầu đã tạo ra các dự án thành công. Một người như vậy có thể nói "Không có cách nào chúng tôi có thể làm điều đó một cách có trách nhiệm" mặc dù doanh thu có thể và sẽ không được quản lý lâu, đó là lý do tại sao nhiều người trong chúng tôi (cuối cùng) trả lời cho MBA thay vì PHD.

Tôi đã mất số lượng công ty mà tôi đã làm việc trong đó một người không phải là lập trình viên phụ trách việc thuê các lập trình viên. Tôi đã có một cuộc phỏng vấn một lần khi người quản lý tuyển dụng không muốn làm gì ngoài việc thảo luận về một sự kiện thể thao gần đây (tôi nghĩ đó là một trận bóng đá). Nếu người mà bạn phụ trách thu hút nhiều cảm hứng từ một huấn luyện viên NFL hơn Knuth, dự án sẽ được triển khai.

Thỉnh thoảng, bạn gặp phải một thứ gì đó được lên kế hoạch rõ ràng, được hiểu rõ, thực tế và dường như thẳng tiến. Vì lý do gì, sáu tháng vào phát triển, mọi thứ tự đảo ngược. Nó xảy ra. Tuy nhiên, hiếm khi đó là nguyên nhân cơ bản của một dự án trở thành một thùng thịt lợn được tôn vinh.

Tuy nhiên, tôi phải thừa nhận .. nếu bạn xem tin tức, bạn có thể thấy một tai nạn xe máy thỉnh thoảng hoặc tàu đắm. Bạn không bao giờ nghe về hàng triệu xe máy hoặc xe lửa đến đúng giờ mỗi ngày mà không có sự cố. Các dự án cũng vậy. Chắc chắn, thật thú vị khi xem khám nghiệm tử thi công khai một thứ gì đó thực sự, thực sự tồi tệ, nhưng bạn hầu như không bao giờ nghe về những thứ thực sự rất tốt. Tôi nghĩ rằng các dự án nghiêng vẫn là ngoại lệ, không phải là tiêu chuẩn.

Hầu hết thời gian kết hợp của hai hoặc nhiều hơn sau đây:

• vấn đề hợp tác giữa các bộ phận
• chính trị ... quá nhiều chính trị ...
• đội sai
• lập kế hoạch không thực tế
• thay đổi phạm vi mà không có phương pháp thích hợp
• thiếu thông tin

Cuốn sách hay về chủ đề: Tháng ba chết .

Mọi người có xu hướng nghĩ rằng phát triển phần mềm là một quá trình dự đoán, cố gắng đo lường và ước tính mọi thứ trước một năm. Điều này là không thể! Xây dựng phần mềm không phải là sản xuất bu lông.

Theo cùng một "xu hướng", họ cố gắng thực hiện một phân tích khổng lồ (một năm nữa đi trước) nghĩ rằng họ sẽ bao gồm tất cả các khả năng, và sau đó, biến lập trình viên thành những người đánh máy đơn thuần. Làm thế nào một người nghĩ rằng điều này có thể làm việc? Loại hành vi này chỉ dẫn đến ước tính xấu và rất nhiều quan liêu.

Dự án càng lớn, bạn càng có khả năng làm việc cho một tổ chức lớn. Tổ chức càng lớn, càng nhiều lớp quản lý. Càng nhiều lớp quản lý, càng khó cho tin xấu ("chúng ta không thể có những gì chúng ta muốn cho những gì chúng ta có thể đủ khả năng") để tạo nên chuỗi lệnh. Tin tức xấu ít có khả năng có thể làm cho nó trở thành chuỗi chỉ huy, càng có nhiều khả năng một kế hoạch giả tưởng sẽ được chấp nhận và sau đó được giữ lâu sau khi nó được biết là không thể thực hiện được.

Các dự án phần mềm thuộc mọi quy mô "có xu hướng thất bại" hoặc "có chi phí vượt mức." Bạn không nghe về chi phí vượt trội tại doanh nghiệp quanh góc, nhưng bạn có nghe về những thứ như hệ thống Trường hợp ảo FBI hoặc hệ thống xử lý hành lý của Sân bay Denver. Vì vậy, tôi sẽ đưa ra tuyên bố rằng không phải tất cả các hệ thống lớn đều thất bại, cũng như tất cả các hệ thống lớn đều có chi phí / lịch trình vượt mức.

Tôi đã đi qua các hệ thống lớn được tung ra trong thời gian (lịch trình di chuyển một lần và chỉ một lần trong dự án) và trên spec (Tôi không có quyền truy cập vào thông tin về ngân sách như chúng tôi đã chỉ 1 của nhiều nhà cung cấp). Một điều gây ấn tượng với tôi (và tôi đã viết một chút về nó trên trang web này) là một hệ thống quản lý khách hàng tích hợp lớn cho một khách hàng tài chính lớn (trong 100 đầu tiên trong số 500 tài sản). Tôi ước tính rằng họ đã thổi khoảng 100 nghìn đô la / ngày (trong hơn một năm) vào lương của người dân trong các cuộc gọi hội nghị.

Trong trường hợp hệ thống xử lý hành lý, các nhà quản lý phần mềm cho biết "dựa trên các dự án có quy mô và độ phức tạp này, sẽ mất 4 năm để xây dựng và gỡ lỗi hệ thống này". Các nhà quản lý bán hàng và điều hành cho biết "sân bay mở trong 2 năm, chúng tôi đã nói với khách hàng rằng sẽ mất 2 năm, vì vậy bạn có 2 năm để làm điều đó". Bài kiểm tra để xem bạn là lập trình viên hay người quản lý sai là câu trả lời đơn giản cho câu hỏi sau: "hệ thống xử lý hành lý trễ hay đúng giờ?"

Nếu khách hàng biết chính xác những gì họ muốn (và rất ít người làm), họ sẽ đi rất xa trên con đường kiểm soát chi phí và thời gian (và đây là những người có xu hướng làm tốt việc bù đắp). Nếu dự án của bạn phải đáp ứng mọi tính năng có thể có mà khách hàng của bạn có thể mơ ước và mọi bộ phận đều có quyền phủ quyết khi những chú chó vàng thú cưng của họ được thêm vào dự án, thì bạn sẽ phải từ bỏ thất bại ngay từ đầu (như của FBI Dự án VCF).

Nhận thức về thực tế

Dưới đây là mô tả tốt nhất về vấn đề này tôi từng tìm thấy. Cây đu từ businessballs.com

Tôi đã sớm được giới thiệu khái niệm "Nhận thức về thực tế" từ khi tôi là người chăm sóc lập trình. Đối với điều này, tôi thực sự biết ơn. Tôi tin rằng đây là lý do lớn nhất mà bất kỳ dự án nào thất bại, không chỉ các dự án CNTT .

Một lý do cho những thất bại là một dự án lớn thường là một dự án kinh doanh cao cấp, quan trọng. Khi các dự án và nhiệm vụ là cao cấp, nó khuyến khích mọi người nói dối.

Sếp của bạn muốn bạn ước tính tình trạng hoàn thành của bạn ở phía cao. Anh ta muốn ước tính vượt mức và trì hoãn ở phía thấp. Khi bạn gặp phải một vấn đề, anh ta không muốn nghe rằng nó sẽ thêm ba tuần vào nhiệm vụ; anh ấy muốn nghe bạn có thể làm việc trong vài giờ tối nay.

Vân vân và vân vân.

Tôi đã ở một dự án vài năm trước, cho một khách hàng. Tôi đã được đưa vào sau khi đấu thầu và kế hoạch dự án đã hoàn thành. Có áp lực liên tục để đi nhanh hơn, nhanh hơn và quyết định cắt giảm chi phí vô lý, quá tải nặng nề của nhân viên, không có nguồn lực cho họ; không bàn, máy tính, bất cứ thứ gì

Cuối cùng, tôi phát hiện ra dự án đã được đấu thầu lúc 7 tháng và 16 triệu đô la. Tôi ước tính ở mặt sau của một phong bì nên là 24 tháng và 50 đến 100 triệu. Tôi đã thiết lập một cuộc họp với người quản lý của mình và người quản lý của anh ấy, và trình bày trường hợp của tôi, và làm thế nào chúng tôi KHÔNG đến bất cứ nơi nào gần giao hàng đúng hạn hoặc ngân sách; họ xem nhẹ tất cả các vấn đề Vào cuối cuộc họp, CIO đã gọi và nói với cả hai nhà quản lý này về cơ bản những gì tôi đã nói, ngoại trừ lỗ hổng trong giá thầu ban đầu.

Tôi đã có cơ hội triển khai dự án khi họ thay đổi công nghệ thành công nghệ mà tôi không thành thạo. Tôi đã nói chuyện với ai đó nhiều sau đó. Dự án cuối cùng đã bị hủy bỏ khi nó đã hoàn thành một nửa ... lúc 12 tháng và 35 triệu đô la.

Các dự án lớn có cấu hình cao không khuyến khích mọi người nói rằng "đây là một sai lầm". Những sai lầm không được dung thứ.

Xây dựng một chút về câu trả lời của VonC:

Các dự án lớn này có xu hướng có một tâm lý "tất cả hoặc không có gì". Dự án theo định nghĩa phải được phát hành trong một lần - thường là do nó thay đổi so với hệ thống hiện có.

Điều này có nghĩa là các vấn đề về creep tính năng / yêu cầu khó giải quyết hơn nên khi dự án thành hiện thực, nó thường được xem là không còn đáp ứng yêu cầu. Điều này có thể trở nên trầm trọng hơn nếu hệ thống hiện tại đã được cập nhật hoặc công nghệ đã chuyển sang trong thời gian này.

Giải pháp cho vấn đề này là gì?

Tôi thực sự không biết vì không ai muốn có hai hệ thống chạy song song với một bộ chức năng thay đổi được phân chia giữa hai hệ thống.

Sự phức tạp của dự án lớn có thể bị làm trầm trọng thêm bởi những áp lực chính trị bên ngoài. Một bộ phận có thể có một ý tưởng rất rõ ràng, tập trung vào những gì họ muốn trong hệ thống mới, nhưng sau đó các bộ phận liên quan nhảy vào với hàng tá yêu cầu dọc theo dòng chữ "Chà, miễn là bạn đang làm điều đó, tại sao bạn không làm vậy làm nhiệm vụ phụ nhỏ này cho chúng tôi quá? " Bạn có thể bắt đầu bằng cách nói "Không, điều đó nằm ngoài phạm vi.", Nhưng sau đó, cuộc đấu tranh chính trị giữa các thủ thuật bắt đầu, và ngân sách cho dự án bị đe dọa trừ khi mọi người có miếng bánh.

Trong nhiều năm, cảnh sát địa phương của chúng tôi không thể tìm kiếm các tấm một phần thông qua hệ thống xe cơ giới, một tính năng có vẻ đơn giản đến mức vô lý. Tôi đã hỏi một người bạn rằng điều gì trên trái đất rất khó khăn khi thêm tính năng này và họ nói rằng mỗi lần họ đề xuất chuyển sang cơ sở dữ liệu hiện đại, mọi bộ phận khác trong bang có bất kỳ tương tác nào với hệ thống xe cơ giới đều muốn có được phần của họ Hệ thống cố định quá. Kết quả là khóa hoàn toàn trong hiện đại hóa CNTT. Cuối cùng, nhà nước tập hợp đủ vốn để thực hiện một nỗ lực hiện đại hóa toàn hệ thống, sau đó đã bối rối vì nó quá phức tạp.

Một yếu tố đã được chạm vào nhưng chưa được giải quyết:

Tất cả những thất bại kịch tính là những hợp đồng được trả giá. Điều gì xảy ra với một công ty có thẩm quyền trong tình huống như vậy? Họ đưa ra một ước tính thực tế và do đó gần như chắc chắn được trả giá bởi một người ước tính xấu.

Nếu công ty không thể ước tính đúng thì có đáng ngạc nhiên không, họ cũng không thể xây dựng một hệ thống đúng cách?

Michael Krigsman trên ZDNet có một blog dành cho " Thất bại của Dự án CNTT ", có thể được quan tâm ở đây.

Một điểm khác là với các dự án dài kéo dài hàng năm, nhìn chung sẽ có những nâng cấp để xem xét hoặc giải pháp thay thế, ví dụ như một dự án hiện có thể được thực hiện trên đám mây so với tại chỗ cho một thứ gì đó bắt đầu xuất hiện ngày càng nhiều, khi xem xét những điều này không được đưa ra khi dự án được bắt đầu. Ví dụ, trong khi người ta có thể bắt đầu trong khi một cái gì đó ở mức 6.0, vào thời điểm giai đoạn đầu tiên được thực hiện, có thể sẽ có 6,3 hoặc 6,4 và câu hỏi khi nào cần nâng cấp. Các thay đổi về phạm vi và chức năng mong muốn, vì các yêu cầu không được thu thập chính xác hoặc ai đó đã thay đổi ý định, là một vài điểm khác đã được đề cập khá nhiều.

Có thể nhanh nhẹn được sử dụng trong các loại dự án hoặc phương pháp truyền thống vẫn là tốt nhất.

Lý do tại sao các quy trình nhanh được áp dụng tốt dường như không gặp phải vấn đề này vì nhiều lý do đơn giản. Bạn không thể bắt đầu một dự án lớn một cách nhanh nhẹn. Bạn có thể chọn cái này hay cái khác

Với một quy trình nhanh, bạn không bao giờ thực sự nhìn qua một hoặc hai lần lặp lại trong tương lai của dự án. không có "kế hoạch" trong 2 năm tới, chỉ hai tuần tới. Khi quan điểm của bạn ngắn đến mức đó, bạn phải thực hiện một vài thỏa hiệp. Bạn không bao giờ có thể bắt đầu với một kế hoạch để tạo ra "Từ cuối cùng trong các vật dụng", cho bất kỳ loại tiện ích nào bạn đang thiết kế. Nhiều nhất, bạn có thể bắt đầu với "Một tiện ích có thể chạy nhanh", bởi vì đó là về hầu hết các công việc bạn có thể hoàn thành trong một hoặc hai lần lặp.

Điều tốt về điều này, là sau một vài lần lặp lại, bạn đã có một sản phẩm hoàn thành, hoạt động mà ai đó có thể thấy hữu ích, đặc biệt là một khách hàng rất cần một tiện ích có thể frob và zort .

Về cơ bản, các dự án lớn có thể thất bại vì chúng nhằm giải quyết tất cả các vấn đề của tất cả các khách hàng tiềm năng. Một dự án nhanh không bao giờ có mục tiêu này, thay vào đó, việc giải quyết trong mỗi phiên bản chỉ là một vấn đề quan trọng mà một khách hàng có thể có. Tuy nhiên, sau một thời gian dài, một dự án nhanh nhẹn có thể giải quyết được rất nhiều vấn đề quan trọng cho rất nhiều khách hàng.

• Không gửi được cho người dùng thực tế

Các dự án lớn có xu hướng khó chịu khi vào chế độ "cơ sở hạ tầng" trong nhiều năm và quên đi việc xây dựng các tính năng của người dùng cuối thực sự và vận chuyển chúng. Vào thời điểm nó xuất xưởng, nó rất tốn kém để thay đổi, và thường thì những thay đổi khái niệm lớn nhất cuối cùng sẽ được hỏi sau khi thử nghiệm beta thực sự đầu tiên xảy ra.

• Không ước tính chính xác chi phí

Nếu các dự án có vẻ như sẽ vượt quá lợi tức đầu tư, họ sẽ bị hủy bỏ.

• Không kiểm soát chất lượng

Với đủ khuyết điểm, động lượng về phía trước có thể giảm xuống 0 hoặc thấp hơn. Không có bất kỳ tiến triển nào, thật khó để tranh luận về sự tồn tại liên tục.

Họ đã quên Luật của Hofstadter: Nó luôn mất nhiều thời gian hơn bạn mong đợi, ngay cả khi bạn tính đến Luật của Hofstadter.

Những điều tôi đã thấy trong phát triển web:

• Quá nhiều đầu bếp - Nhà bán lẻ B & M lớn, nơi sự nhấn mạnh đột nhiên chuyển sang web. Đột nhiên, 20 người đứng đầu Bộ đang điều khiển mọi sáng kiến ​​để gây ấn tượng với pho mát đầu mới. Tôi đã từng phải thực hiện các biểu tượng mới bởi vì pháp lý không thích giao diện của các biểu tượng cũ.

• Quá tập trung vào thông số kỹ thuật phù hợp để đạt được mục tiêu - "Các biểu tượng của IE6 hơi mờ so với IE7. Vui lòng bỏ công việc quan trọng vào ngày ra mắt mà bạn đang làm và tham dự tới 0,05% cơ sở khách hàng của chúng tôi để làm những việc khủng khiếp sẽ mất nhiều ngày để thực hiện và làm chậm trải nghiệm IE hơn nữa. "

• Công cụ xấu được chọn bởi những người không phải là nhà phát triển, những người thậm chí không thể bận tâm để hỏi các nhà phát triển nội bộ của họ để được tư vấn.

• Các nhà phát triển xấu được chọn bởi các công cụ - "Tại sao phải trả cho 20 nhà phát triển Java có thẩm quyền một mức lương xứng đáng khi chúng tôi có thể thuê ngoài 200 người hầu như không biết chữ, những người biết quá ít để sử dụng kiểm soát phiên bản?" vì họ đồng thời và với mọi người ở các quốc gia khác nhau, làm việc chủ yếu cho 3 ứng dụng lớn.

• Kiến trúc xấu / bị hỏng - Các lớp dựa trên các lớp mã hoảng loạn, hoàn thành ngày hôm qua, bởi những người bị sa thải hoặc hiện là người quản lý.