Các dấu hiệu cảnh báo về sự diệt vong sắp xảy ra để theo dõi một dự án là gì? [đóng cửa]

Đã từng làm việc trong một dự án thất bại là một trong số ít những điều mà hầu hết các lập trình viên có điểm chung, bất kể ngôn ngữ được sử dụng, ngành công nghiệp hoặc kinh nghiệm.

Những dự án này có thể là những trải nghiệm học tập tuyệt vời, những thảm họa tan nát tâm hồn (hoặc cả hai!) Và có thể xảy ra vì vô số lý do:

• thay đổi quản lý của trái tim
• đội ngũ có tay nghề thấp / nguồn lực hạn chế
• sự xuất hiện của đối thủ cạnh tranh vượt trội trong chu kỳ dev
• quản lý trên / dưới

Một khi bạn đã làm việc với một vài dự án như vậy, bạn có thể nhận ra ở giai đoạn đầu chính xác khi dự án bị thất bại không?

Đối với tôi, một dấu hiệu lớn là có thời hạn bên ngoài cứng & nhanh kết hợp với tính năng creep . Tôi đã thấy các dự án được lên kế hoạch tốt và đang được tiến hành đúng tiến độ sẽ ra khỏi đường ray một cách khủng khiếp khi các yêu cầu tính năng trễ bắt đầu được đưa vào và được thêm vào "khả năng giao hàng" cuối cùng. Những người đề xuất những yêu cầu này đã nhận được biệt danh của Columbo , do hiếm khi rời khỏi phòng mà không yêu cầu "chỉ một điều nữa".

Những dấu hiệu cảnh báo mà bạn tìm ra đã gióng lên hồi chuông cảnh báo về sự diệt vong sắp xảy ra trong đầu bạn là gì?

Mã hóa anh hùng

Viết mã vào đêm khuya, làm việc nhiều giờ và nhiều giờ làm thêm là một dấu hiệu chắc chắn cho thấy có gì đó không ổn. Hơn nữa, kinh nghiệm của tôi là nếu bạn thấy ai đó làm việc muộn tại bất kỳ thời điểm nào trong dự án, nó chỉ trở nên tồi tệ hơn. Anh ta có thể làm điều đó chỉ để đưa một tính năng của mình trở lại đúng tiến độ, và anh ta có thể thành công; tuy nhiên, mã hóa cao bồi như thế hầu như luôn là kết quả của một thất bại trong kế hoạch chắc chắn sẽ gây ra nhiều điều sớm hơn. Vì vậy, càng sớm trong dự án bạn nhìn thấy nó, cuối cùng nó sẽ trở nên tồi tệ hơn.

Khi các lập trình viên bắt đầu giành chiến thắng với lý lẽ "Mã thật kinh khủng, chúng ta cần bắt đầu lại từ đầu". trên bất kỳ ứng dụng trưởng thành.

Bạn có thể nghĩ rằng bạn có thể xây dựng nó tốt hơn hoặc hiểu vấn đề đầy đủ hơn, nhưng bạn thực sự không. Oh, và tất cả những miếng vá xấu xí? Chúng là các bản sửa lỗi cho các vấn đề trong thế giới thực mà bạn có thể sẽ giới thiệu lại trong phần viết lại.

Thêm vào đó, một ngày nào đó bạn sẽ phải giải thích với người quản lý dự án tại sao sau 6 tháng làm việc, bạn gần như đạt tới 85% khả năng và 150% lỗi mà ứng dụng gặp phải khi bạn bắt đầu.

Một công cụ mới như một người giải quyết vấn đề.

Khi mọi người bắt đầu lên kế hoạch sử dụng các công cụ xa lạ, tôi không bận tâm, nhưng tôi để mắt đến nó. Khi họ bắt đầu lập kế hoạch tất cả các lợi ích được quảng cáo của các công cụ đó vào lịch trình, tôi cảm thấy lo lắng. Ví dụ thú vị:

• Chúng tôi có thể cạo một tháng trong lịch trình vì chúng tôi sẽ thử sử dụng ngôn ngữ hướng đối tượng (mặc dù tất cả những gì chúng tôi có là nhà phát triển c).
• Chúng tôi sẽ thử điều mới này - nó sẽ khắc phục tất cả các vấn đề về quy trình của chúng tôi!
• Tôi biết đó là một nửa dự án, nhưng nếu chúng ta thay đổi ORM thành một cái gì đó mới thì sao?

Các công nghệ và thực tiễn mới là tuyệt vời, nhưng bạn hầu như không bao giờ nhận được tất cả các lợi ích ngoài cổng.

Đối với tôi, vấn đề lớn nhất và một vấn đề bạn có thể nhận ra ngay lập tức là khi doanh nghiệp coi các yêu cầu bằng văn bản là một sự lãng phí thời gian.

Nên về cơ bản; Không có yêu cầu bằng văn bản

Đó là nụ hôn của thần chết.

Ngắt kết nối quản lý

Khi những người chịu trách nhiệm về thời hạn, tính năng, nhân sự, vv bị ngắt kết nối với những người chịu trách nhiệm phân phối dự án. Điều này có thể dẫn đến:

• Tính năng leo trèo khi khách hàng đang nói chuyện với ai đó không hiểu chi phí tính năng
• Hội chứng Man-tháng, nơi các nhà phát triển mới bị ném vào một dự án đủ muộn để gây trở ngại hơn là giúp đỡ
• Thời hạn không thực tế, được tạo ra bởi những người phải giải quyết hậu quả kinh doanh của các quyết định thời hạn nhưng không phải là hậu quả thực hiện.
• Các sản phẩm không giải quyết được vấn đề khi giao tiếp giữa khách hàng bị cản trở bởi quản lý ở giữa.
• Quản lý rủi ro kém, nơi các vấn đề tiềm ẩn không được truyền đạt đủ sớm giữa các nhà phát triển và quản lý.

Vì vậy, khi có vẻ như quản lý không quan tâm đến dự án, giao tiếp kém, không lắng nghe khách hàng hoặc không lắng nghe nhóm phát triển, chạy lên đồi.

1. Khi các nhà phát triển chính rời đi và quản lý không quan tâm

2. Khi các nhà phát triển chính rời đi và không ai trong số các nhà phát triển khác quan tâm

Số một thường là dấu hiệu của những người quản lý mất liên lạc nghiêm trọng với sự năng động của nhóm (là "siêu sao 10 x", là những lập trình viên đàng hoàng và cách họ tương tác với nhau, v.v.).

Số hai thường cho thấy sự thiếu quan tâm nghiêm trọng đối với các nhà phát triển còn lại.

Lần đầu tiên một người nào đó, thường là quản lý nói rằng "chúng ta không có thời gian để .."

Thông thường trước một cái gì đó mà chúng ta không có thời gian không thích, như đánh giá tài liệu hoặc mã (theo thống kê tìm và sửa nhiều lỗi hơn bất cứ thứ gì khác, bao gồm tất cả các hình thức kiểm tra)

Hãy để khách hàng, tiếp thị hoặc quản lý chọn một ngày và sau đó cố gắng làm việc ngược với lịch trình tưởng tượng

Khi quản lý quá yếu để nói "Không" với doanh nghiệp.

Nó dẫn đến thời hạn sẽ không bao giờ được đáp ứng, dẫn đến sự thiếu tin tưởng vào bộ phận CNTT dẫn đến các nhà phát triển tạo ra các bản hack (tức là truy cập db chạy trên máy của ai đó ... ở đâu đó) dẫn đến cơn ác mộng cho CNTT khi ' hệ thống quan trọng 'phải được di chuyển dẫn đến ...

Dấu hiệu xấu đầu tiên tôi có thể nghĩ đến là khi quản lý không sẵn sàng truyền thông tin xấu lên chuỗi hoặc cho khách hàng với hy vọng rằng nó sẽ biến mất - tức là quản lý bằng suy nghĩ mong muốn. Tôi không thể nghĩ được bao nhiêu lần, các nhà phát triển đã chứng minh rằng họ không thể đáp ứng thời hạn cuối tuần hoặc thậm chí vài tháng trước đó và không ai muốn nói với khách hàng. Tôi hiếm khi thấy một khách hàng sẽ không đưa ra thời hạn khi có lý do thực sự khi nhu cầu được giải thích trước; Tôi thường thấy một khách hàng bực mình khi nói vào ngày hết hạn rằng nó sẽ không được đáp ứng và nó sẽ không được đáp ứng vào ngày hôm sau, nhưng hai tháng sau. Tại thời điểm này, đúng ra tôi có thể thêm vào, đặt câu hỏi cho các quy trình của bạn - tại sao bạn không biết điều này sớm hơn.

Một dấu hiệu chắc chắn khác cho thấy thất bại đang đến là phân công các nhà phát triển mới vào phần khó nhất, phức tạp nhất của quy trình hơn là những người hiểu hệ thống hiện tại. Sau đó, đừng theo dõi họ cẩn thận để xem họ có thực sự hoàn thành công việc đúng cách hay có câu hỏi không (BIG BIG RED FLAG nếu không có câu hỏi nào). Nhân viên mới cần được theo dõi cho đến khi bạn biết họ thực sự có những kỹ năng mà họ tuyên bố là có. Tôi vẫn có thể nhớ rằng đã trải qua một mùa hè đau đớn để làm lại công việc (đã quá thời hạn khi tôi nhận được nó) của một nhân viên mới nhận được một phần quan trọng của dự án và nói với mọi người rằng mọi thứ đều ổn trong nhiều tháng và sau đó nghỉ việc mà không cần thông báo trước một tuần. và không có gì anh làm là có thể sử dụng được.

Một dấu hiệu chắc chắn khác của sự thất bại là khi các nhà phát triển đang làm việc trên các phần phụ thuộc vào những thứ khác được thực hiện trước và những điều đó không được thực hiện hoặc thậm chí bắt đầu. Nếu quản lý không thể có được công việc được giao theo đúng thứ tự, bạn sẽ đi xuống.

Tất nhiên tính năng creep mà không đẩy thời hạn trở lại mỗi lần là một trong những dấu hiệu phổ biến nhất mọi thứ sẽ trở nên tồi tệ. Bạn thêm 20 giờ làm việc vào đĩa của tôi, thời hạn sẽ được di chuyển thêm 20 giờ. Nếu không thì dự án sẽ thất bại, đảm bảo.

Một dấu hiệu chắc chắn mà tôi đã thấy trong sự nghiệp của mình là khi quản lý bắt đầu nói về việc mang lại nhiều cơ thể hơn để sắp xếp thời gian trong lịch trình. Tôi chưa bao giờ thực sự thấy nhiều cơ thể hơn trong một dự án giúp đỡ.

Khi các nhà quản lý phi kỹ thuật bắt đầu khăng khăng đưa ra các quyết định kỹ thuật mà họ không đủ điều kiện để đưa ra. Lớn, cờ đỏ lớn!

Dấu hiệu rõ ràng nhất là một doanh thu nhân viên cao. Khi mọi người đang tìm kiếm một công việc mới, có lẽ bạn cũng nên như vậy.

Dấu hiệu rõ ràng khác là thiếu tiến bộ. Nếu một năm đã trôi qua và dường như bạn không ở gần mục tiêu hơn, bạn sẽ phải chịu số phận. Điều này đặc biệt xảy ra khi các yêu cầu thay đổi nhanh hơn bạn có thể thực hiện chúng.

Chán các thành viên trong nhóm.

Bạn đã "hoàn thành 90%", giao hàng vào tuần tới, nhưng không sao vì tất cả những gì bạn còn lại là "thử nghiệm".

• Mọi người đều kiệt sức về thể chất và tinh thần
• Khách hàng / người dùng rõ ràng không hài lòng về thời gian hoặc những gì họ đang thấy
• Thiết kế ban đầu đẹp bây giờ cảm thấy bị xâm phạm
• Bạn đã từ chức để vận chuyển với một số lỗi tương đối quan trọng mà bạn thực sự muốn sửa nhưng sẽ không thể
• Niềm tự hào còn lại của bạn là ở hành động vận chuyển hơn là những gì bạn đang vận chuyển - gần với tâm lý sống sót hơn là niềm tự hào nghề nghiệp
• Nhóm nghiên cứu sợ rằng có những thứ nhất định không hoạt động và đang bỏ qua những phần đó và hy vọng điều tốt nhất bởi vì họ sợ những gì có thể có trong đó
• Mọi người đều tin rằng họ đã vượt lên và vượt lên (và họ đúng)
• Mọi người đang có dấu hiệu kiệt sức (bi quan chung, không quan tâm, tức giận)

(Nôi từ Động lực phát triển phần mềm của Jim McCarthy ).

Các lập trình viên cao bồi, bản ngã lớn, và sự chấp nhận của ban quản lý

Nếu kế hoạch dự án yêu cầu một lần lặp duy nhất về thiết kế, phát triển, thử nghiệm và triển khai - thác nước cổ điển - cho một dự án dài hơn 1 tháng, tôi sẽ chạy một dặm.

Bạn không cần phải hoàn toàn nhanh nhẹn, nhưng có chu kỳ phát triển ngắn cho phép bạn chứng minh sự tiến bộ với mọi người (khách hàng, quản lý và nhà phát triển) và đối phó với các yêu cầu thay đổi khi điều không thể tránh khỏi xảy ra.

Nhà phát triển Running Wild on the Range

Điều này đã xảy ra khi bạn nhận ra rằng các nhà phát triển khác (hoặc, không may là bạn) đã phát triển một thành phần thay đổi đáng kể so với thiết kế và điều này không được chọn cho đến khi thử nghiệm hệ thống / UAT. Tôi không nói về lỗi; Tôi đang nói về các thành phần hệ thống quan trọng đang thiếu các tính năng hoặc không được hỗ trợ cho chức năng và sẽ không bao giờ vượt qua UAT mà không cần làm lại đáng kể. Vấn đề này chỉ ra rằng:

• Hệ thống chất lượng của bạn bị hỏng; tại sao nhà phát triển không quan tâm đến vấn đề trong giai đoạn thiết kế / triển khai. Không phải là mã cho mỗi đánh giá / kiểm tra? Tại sao các bài kiểm tra đơn vị và tích hợp không nhận về điều này? Nếu bạn không có một số loại thử nghiệm tích hợp / đơn vị nhất quán, bạn sẽ bị lừa.
• Người quản lý dự án / lãnh đạo kỹ thuật của bạn không kiểm soát nhóm phát triển của họ. Nếu họ không thể khiến các nhà phát triển cung cấp những gì được yêu cầu, họ sẽ không bao giờ có thể cung cấp một giải pháp hoàn chỉnh.

Khi một nhà phát triển chính trong một dự án đã không kiểm tra bất kỳ mã nào trong nhiều tuần và một cột mốc nghiêm trọng sắp xuất hiện.

Đó là một công việc hợp đồng và nhà phát triển cao cấp hơn và PM trong công việc đã quyết định họ muốn hợp tác để cố gắng cắt giảm lớn hơn để nhà phát triển khác giữ 3 tuần làm con tin mã quan trọng. Cuối cùng, chúng tôi đã sa thải Thủ tướng bất tài (người đã dành 6 tháng để đưa dự án vào một khóa học bị hủy hoại) và nói chuyện với nhà phát triển.

Có thể nói, phần còn lại của dự án là một cuộc diễu hành chết chóc, đóng băng thông số bị trì hoãn, khách hàng đã được cung cấp một loạt các tính năng nhượng bộ để bù đắp cho lịch trình khủng khiếp mà Thủ tướng rời khỏi dự án, và chất lượng của dự án phải chịu Tất cả xung quanh vì nó.

Thủ tướng thậm chí có can đảm bay xuống CDR (Đánh giá thiết kế quan trọng) chỉ để từ bỏ cuộc họp với khách hàng và đưa ra một sự phù hợp rít lên. Khi anh ta yêu cầu rằng chi phí đi lại của anh ta được trả theo dự án, anh ta đã lịch sự nói rằng hãy tự mình đi tìm chính mình.

Tôi có thể dễ dàng xác định với ít nhất 5 câu trả lời khác được tìm thấy ở đây đã ảnh hưởng đến dự án đó. Nói tóm lại, tôi đã học được rất nhiều bài học khó về dự án mã hóa nghiêm túc đầu tiên của mình.

Dấu hiệu đầu tiên của tôi về một người là khi họ hỏi mỗi giờ chúng tôi sẽ làm thêm bao nhiêu giờ trong mười tuần tới và tặng cho những người làm công ăn lương một phần thưởng cho việc làm thêm giờ dựa trên sự thành công của dự án và đáp ứng thời hạn.

Các dấu hiệu chính khác mà tôi đã thấy: Khiếm khuyết yêu cầu vượt quá lịch trình và ngày kết thúc không được di chuyển. Chúng tôi đã ở phía trước trước khi chúng tôi thậm chí có thể bắt đầu. Họ đã mất thời gian từ thiết kế, vì vậy chúng tôi bắt đầu không có thiết kế cơ sở dữ liệu và không thiết kế trang web nhưng dự kiến ​​sẽ giao hàng đúng hạn, trong số những thứ khác, thực hiện nhập khẩu vào các bảng chưa được thiết kế và tạo.

Khi các mục trên đường dẫn quan trọng đang được thực hiện đồng thời thay vì theo thứ tự. (Nếu tôi bắt buộc phải sử dụng công cụ X và lập trình viên A mới bắt đầu xây dựng nó, nó sẽ trì hoãn nhiệm vụ của tôi.)

Khi các nhà quản lý đang cam kết mã vào Lễ Tạ ơn.

Khi bạn bắt đầu nhận email có tem datetime muộn hơn 11 giờ tối và sớm hơn 6 giờ sáng.

Khi mọi câu hỏi về cách xử lý một số phức tạp đều được đáp ứng với cùng một câu trả lời, "Đừng lo lắng về điều đó."

Khi họ vẫn đang thực hiện các yêu cầu thay đổi vào ngày đặt cược, bạn hãy đến QA hoặc phát trực tiếp.

Khi bạn bắt đầu có các cuộc họp hàng ngày mất vài giờ để thảo luận về sự thiếu tiến bộ của bạn. Ồ, đó là bởi vì tôi đang họp cả ngày. Cuộc họp hàng ngày 5 phút tốt, cuộc họp hàng ngày kéo dài hơn một giờ, không tốt.

Khi nhóm cơ sở dữ liệu và nhóm ứng dụng không nói chuyện với nhau.

Khi khách hàng không thể cung cấp thông tin đã hứa đúng hạn. Đặc biệt khi đó là các tệp nhập dữ liệu và bạn cần dữ liệu đó trong cơ sở dữ liệu để kiểm tra xem mã đang hoạt động như thế nào.

Khi bạn xem xét việc lắp đặt đèn dừng bên ngoài văn phòng của một số người quản lý để cho bạn biết liệu có an toàn để tiếp cận anh ta vào ngày hôm đó không.

Tôi nghĩ rằng nói chung dễ dàng phát hiện ra một dự án thất bại khi thời hạn đang đến gần. Giống như bạn đã nói, tính năng creep kết hợp với thời hạn hoàn thành là một cách chắc chắn để giết chết một dự án.

Tuy nhiên, điều quan trọng là phát hiện ra một cách dự án thất bại trước. Tôi nghĩ rằng "dấu hiệu cam chịu" thực sự duy nhất trong trường hợp này sẽ là sự thiếu hoàn toàn định nghĩa về "khi nào chúng ta kết thúc". Trừ khi chúng ta biết điều này ở phần bù, chúng ta sẽ cam chịu thất bại IMO.

Tôi đã trải qua ba cuộc hành quân chết chóc trong năm năm qua. Dưới đây là một vài điều góp phần vào cảm giác ruột thịt của tôi sắp xảy ra.

• Công ty quyết định để các nhà phát triển cơ sở thiết kế và phát triển các tính năng mới và chỉ định các nhà phát triển cao cấp đắt tiền hơn để sửa lỗi của họ.
• Công ty thuê ngoài các thành phần phần mềm quan trọng cho các công ty thuộc thế giới thứ ba không có chuyên môn về miền cần thiết.
• Các chu kỳ giòn giã đến gần nhau đến nỗi sức khỏe của mọi người đang bị phá vỡ.
• Các viên thuốc mà nhóm của bạn dùng để tự ngủ mỗi đêm bỏ thuốc.
• Khách hàng gửi đơn đặt hàng thay đổi nhanh hơn bạn có thể phân tích chúng.
• Bạn được yêu cầu giao công việc vài năm trong một vài tuần, nhưng ban quản lý từ chối thực hiện đóng băng tính năng.
• Các nhà cung cấp phần cứng của bạn rõ ràng đang gặp khó khăn trong việc cung cấp một sản phẩm hoàn toàn khả thi theo lịch trình và những người ra quyết định trong công ty của bạn sẽ không xem xét bất kỳ giải pháp thay thế nào.
• Các nhà phát triển thiết bị nguyên mẫu cần có để họ có cơ hội đáp ứng lịch trình có lẽ không thực tế được lấy đi và trao cho các nhà điều hành hàng đầu để khiến họ cảm thấy tốt.
• Tuần thứ nhất: "Ồ, tào lao, mã bị lỗi. Mọi người bỏ việc làm các tính năng mới và sửa lỗi." Tuần thứ hai: "Ồ, tào lao, chúng tôi sẽ không đáp ứng lịch trình tính năng. Mọi người hãy bỏ sửa lỗi và viết các tính năng mới." Lặp lại vô thời hạn.
• Sự phát triển được thực hiện ở một quốc gia và QA hoàn toàn được thực hiện ở một quốc gia khác cách nửa vòng trái đất, vì vậy một cuộc trao đổi khứ hồi về một lỗi luôn cần 24 giờ và ít nhất một trong số những người liên quan đang thảo luận về các vấn đề kỹ thuật phức tạp trong một ngôn ngữ họ không thành thạo.

Đối với tôi, đó là khi những người chịu trách nhiệm về bộ tính năng (còn gọi là người quản lý, chủ sở hữu sản phẩm, khách hàng ...) ngừng quan tâm hoặc dường như có một không khí vô vọng về câu trả lời của họ. Các câu hỏi về các tính năng được đáp ứng với sự thờ ơ và chán nản. Rõ ràng là họ đã mất đầu tư hoặc niềm tin vào dự án.

Điều này xảy ra với tôi khi một dự án tôi đang thực hiện có "sự thay đổi quản lý cấp trên của trái tim" đã đánh trúng nó. Tôi đã đặt câu hỏi về cách nó nên hoạt động và đột nhiên không ai có ý kiến ​​thực sự.

Một lát sau dự án đã bị hủy và tất cả các mã đẹp mà tôi đã viết đã bị loại bỏ.

Paul Vick đã viết một bài viết xuất sắc vài năm trước về các dự án lỗ đen . Tôi nghĩ rằng tất cả các lời khuyên có liên quan. (Tôi đã chỉnh sửa các mục và tóm tắt cho chiều dài.)

• Mục tiêu hoành tráng vô lý . Giống như "về cơ bản mô phỏng lại cách mọi người làm việc với máy tính."
• Thời hạn hoàn toàn không thực tế . Thông thường điều này là do họ tin rằng họ có thể viết lại cơ sở mã gốc trong thời gian ngắn hơn nhiều so với thời gian ban đầu.
• Niềm tin không thực tế về khả năng tương thích . Giống như tin rằng bạn có thể viết lại và bảo tồn tất cả các quirks nhỏ mà không cần bất kỳ nỗ lực thêm.
• Luôn luôn "sáu tháng" từ thời hạn chính mà dường như không bao giờ đến . Hoặc, nếu nó đến, một cột mốc khác được thêm vào cuối dự án để bù đắp.
• Phải tiêu thụ một lượng lớn tài nguyên . Thông thường bằng cách hút huyết mạch ra khỏi một hoặc nhiều sản phẩm đã được thiết lập.
• Tham gia sử dụng công nghệ hoàn toàn mới chưa được chứng minh . Như vậy, họ có thể giải quyết tất cả các vấn đề về khả năng mở rộng với công nghệ mới.

Tôi tinh thần dịch "Mọi thứ đều ổn. Chúng tôi không có gì phải lo lắng." thành "Tất cả chúng ta đều bị lừa" mỗi khi tôi nghe quản lý nói điều đó. Bạn thường nghe thấy các nhà quản lý ném nó một cách tình cờ trong các cuộc họp không liên quan ("Ồ và nhân tiện, mọi thứ đều ổn. Không có lý do gì để lo lắng!"), Nhưng đó là một lá cờ đỏ thậm chí còn lớn hơn để có một cuộc họp được gọi cụ thể để nói rằng.

Tôi chưa nghe một người quản lý nói điều gì đó dọc theo những dòng này và hóa ra nó không phải là một lời nói dối.

một vài điểm từ một dự án đã chết tôi là một phần của:

• Ban quản lý nhân đôi để hoàn thành nhanh hơn.
• các nhà phát triển bắt đầu "chôn vùi" các lỗi để đáp ứng thời hạn, và mặc dù rõ ràng, nó đã bị bỏ qua trong quá trình xem xét mã.

Khi ban quản lý kéo dự án sang các hướng khác nhau đồng thời và cỗ xe vẫn còn.

Tôi đã từng tham gia vào một dự án được quản lý bởi hai người. Hoặc là họ đã không nói chuyện với nhau hoặc mỗi người đều có một số bản ngã để giải quyết, nhưng họ đã chỉ huy công việc của chúng tôi đi ngược lại mỗi tuần hoặc lâu hơn. Không mất nhiều thời gian để nhận ra sẽ không bao giờ có kết quả. Rất vui khi sự tham gia của tôi chỉ kéo dài một vài tháng.

Xem bài viết ngắn gọn này: Khi các dự án CNTT đi đúng .

Việc không có bất kỳ yếu tố nào được nêu trong bài viết sẽ gióng lên hồi chuông cảnh báo:

Vì vậy, hãy chắc chắn rằng dự án của bạn có tất cả những điều sau đây, nếu không thì bạn nên quan tâm:

(để trích dẫn bài viết trên :)

1. "Đầu tiên là họ dựa trên một tầm nhìn rõ ràng về những gì sẽ đạt được."

2. "Đặc điểm thứ hai liên quan đến sự hỗ trợ và cam kết của các bên khác nhau có liên quan trên toàn doanh nghiệp, đặc biệt là quản lý cấp cao."

3. "Thứ ba là một sự hiểu biết về các vấn đề cần giải quyết."

4. "Đặc điểm chung cuối cùng là có đủ nguồn lực và kỹ năng."

Theo thống kê, một dự án phần mềm bắt đầu là một dấu hiệu công bằng rằng nó sẽ thất bại, vì phần lớn trong số họ làm ...