軟件項目將死的27個征兆

jopen 9年前發布 | 4K 次閱讀 軟件

有時候我們會突然發現自己的項目正在走向注定的死亡。下面這些跡象可以讓你提早發現項目失敗的趨勢。

軟件項目將死的27個征兆

  • 在數月內三次更改項目名稱。
  • 項目經理決定,與其寫一個國際化的單一版本還不如針對某個國家寫一個完全獨立的版本。
  • 需求定義發布于開發工作開展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專業人士的口述,可能并不完整,歡迎各位指正。

譯文鏈接:http://www.codeceo.com/article/27-project-doomed.html
英文原文:26 Ways To Know Your Software Development Project Is Doomed
翻譯作者:碼農網 – 小峰

 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!