有時候我們會突然發現自己的項目正在走向注定的死亡。下面這些跡象可以讓你提早發現項目失敗的趨勢。
在數月內三次更改項目名稱。
項目經理決定，與其寫一個國際化的單一版本還不如針對某個國家寫一個完全獨立的版本。
需求定義發布于開發工作開展 4 個月后。
新聘請的R&D主管紙上談兵地表示，該項目將比計劃提前 6 個月完成，并且自吹自擂地保證無需經過版本測試就可以直接發布給客戶。
如果你是 web 開發人員，你用 HTML 文檔打開客戶發過來的壓縮文件，其網站腳本是需要集成到 web 應用程序中去的。但是你打開 HTML 文檔，得到的竟然是 Microsoft Word 文件，以 HTML 格式保存的 Microsoft Word 文件。
你發現公司之所以聘請你做顧問，是為了當兩個競爭部門在關于使用哪種技術平臺的問題上發生爭執時，讓你去做調解工作的。
備忘錄上面說，你需要在一個 16 位的平臺上開發一個 64 位的應用程序。
開發人員不理解 spec 文檔，反正在做開發工作了就行；QA 團隊不知道如何測試，反正亂搞一通就算測試過了。
關于項目預算，如果你發現超過一半的費用是花在網頁設計師創建主頁的 ps 模型上——而不去考慮這種設計方案是否可行。或者你注意到成千上萬行內容將放在主頁上。
用戶或者客戶要求添加新的功能，而不是集中注意力解決 bug 修復和性能增強的問題。
有一個軟件開發最佳實踐的列表，然而你一條都沒有使用。
項目平臺由 Windows 變為 MS-DOS。
項目經理要求你寫一個關于用戶要求的比較，但是卻沒有咨詢任何潛在用戶。
將筆記存到文件中而不是相互發送，這些筆記成了即將到來的失敗的借口。
狀態報告被視為是在違抗命令。
新的 CIO 用他老東家那里的外行人替換了這里所有了解組織架構知識的人。
這是一個很大的項目，代號冰山。或者為了能順利成功，經過再三研究，項目命名為了鳳凰。不過真的很難說服自己這項目真的能夠鳳凰涅槃——浴火重生。
即使是免費版本，客戶也深表不滿。
關鍵任務項目（掌握了 80％ 的公司收入）的 PM 需要經過三個月的接觸才能確定技術首選，同時還要一次性培訓四個全新的開發人員。而此項目的最后期限則只給了三個月。
你認識到在管理上必須堅持：在第一次代碼凍結后必須審查接口定義，然后放入版本控制。
更換了 PM 并將項目從這個城市挪到了另一個城市。
QA 團隊被告知，“我們只分配到三個星期的測試時間”，或者，“日期已經定死了，我們必須在截止時間之前完成所有功能”。
項目經理決定嘗試敏捷方法“以節省時間”。
手機和互聯網的影響：如果你在 New York 聘請了一位新的 PM，然后去參加了為期三天的 Frankfurt 地區的封閉式 CIO 會議，那么你回來她絕對會直接變成咆哮帝：因為她發過去的 email 你通通沒有回復（實際上你并不知道），也不知道她新的項目規劃。
管理層決定花一百萬美元去建設兩萬元的項目。
首席開發人員告訴你，保存所有數據庫更新的完整歷史記錄是應用程序的要求，但是他還沒有來得及（其實是：不知道如何）去設計一個數據模型。于是他決定等以后再說。
業務領導/項目投資人假惺惺地說，“只要有創意什么支持都有。”再看前面：剛剛裁掉了 20％ 的員工，以及將已經回收的硬件又拿出來使用，然后告訴你這是項目新的托管環境。
上述 27 條來自一些軟件開發人員和 IT 專業人士的口述，可能并不完整，歡迎各位指正。
京公網安備 11010502049343號