保證失敗的 7 個因素

不要欣賞員工、低估複雜性或依賴神話。 如果考慮到這些和其他因素，您的項目肯定會失敗。

你知道嗎？ 在數周和數月的時間裡，項目經理都會報告他的項目。 當然，經典的狀態燈也不能少。 這一直是綠色的：一切正常。 但是有一天，紅綠燈突然變紅了！ 因此，對於那些負責的人來說，一個非常不愉快的處理過程開始了。 大多數情況下，第一個問題適用於罪魁禍首，第二個問題適用於原因，然後一個僅用於可能的解決方案。

以下是幾乎注定失敗的 7 個典型因素。

因素一：忽視人為因素

作為開發人員、項目經理、教練和危機管理人員多年，我發現人際關係緊張是實施 IT 項目的最大障礙。 相反，員工之間的化學反應是正確的，並且存在開放、容錯的氛圍，可以找到解決所有困難的方法——即使是在危急情況下。

避免衝突是人的本性。 因此，如果人們（例如項目經理）完全忽視或將目光移開太久，這是很自然的。 但衝突通常不會自行化解。 研究是必需的，作為適度和至少對變化或解決方案的看法。

有時是小事產生大影響，例如員工的新工作。 但是往往需要更大的開銷，比如團隊的重組，才能讓項目重新歸於平靜。 然而，最糟糕的選擇是無視人為因素。

因素 2：想太多或做得太小

一些公司接管了一個項目。 他們低估了複雜性、風險以及巨大的人力和物力。 無論成本如何，我的組織是否能夠管理一個擁有 100 名員工的項目？ 我們是否有足夠的工作崗位、會議室、網絡容量、開發服務器等？

公司是否能夠滿足大型敏捷開發團隊對包括持續集成/交付在內的開發和測試軌道的要求？ 預測到此類問題，商業案例應該是經過實際計算的。 我曾多次看到，在一個巨大的項目開始前不久，人們才清楚地意識到，最終的系統實際上並不需要，因為它不適合公司的商業模式。 不幸的是，之前沒有人注意到這一點。

另一個可識別的模式：主角絕對想實現一個 SW，例如出於聲望原因或利用員工，並且計算成本可以忽略不計。 如果後來的項目經理不夠強大，無法在決策機構的背景下提出差異，這就會產生很高的危機潛力。

因素 3：100% 依賴估計和計劃

一個廣為流傳的神話是估計和規劃的可靠性。 該項目的概念由其獨特性定義。 也許已經有類似的項目，但原則上，公司的每一個項目都在進入新的領域。 這意味著估計只能與創作者的經驗和他們對當前項目的適應能力一樣好。

但是，計劃永遠不能包括自發事件、需求、技術方面的變化或非預期風險的進入。 歸根結底，估計和基於估計的計劃無非是對未來的賭注！ 接受這個事實是向前邁出的第一步。 紀律、勇氣和製度有助於預防或緩解可能出現的危機。

因素 4：神奇的 PM 三角形一直被忽視

學習計算機科學，第一學期，第一堂課項目管理： “神奇的 PM 三角形” 。 對管理任務感興趣的人很早就了解了這個三角形的規律。 這些表示三個參數之一的變化不可避免地導致至少一個其他參數的後果。

然而，這些法律在實踐中非常樂意忽視。 正如在估算和規劃的背景下已經提到的，一個項目在某種程度上是獨一無二的，並且計劃外影響的可能性非常高。 這就是為什麼遲早有必要讓負責人對這些影響作出反應的幾乎每個項目。 但是，如果所有參數都是固定的，即客戶繼續要求遵守時間、預算和內容，那麼失敗只是時間問題。

因素 5：一切的文檔

貝肯鮑爾之後免費： “我們稱之為經典！” 儘管越來越多的公司依賴於敏捷程序（主要是 Scrum），但仍然可以找到組織和項目，它們賦予廣泛的文檔比要創建的軟件更重要的意義。 這是一個高風險，尤其是在大型項目中。 通常，顧問和部門專家在數千頁上的搜索通常會工作數月甚至數年，隨後將由 SW 中的另一個團隊翻譯。

文檔越廣泛，實現時間越長，軟件越不可能符合用戶的實際需求。 對市場變化的反應是不可能的，或者只有付出巨大的努力和暫時的讓步才有可能。 文檔提供了可以刪除產品的基礎。 不幸的是，所寫的不一定清楚，結果與最初的想法不同。 多少次我聽到部門人員和最終用戶的一句話： “哦，我想像的很不一樣！” .

因素 6：沒有平衡的項目組織

一個由 20 名開發人員和 1 名技術聯繫人組成的團隊？ 無需專業知識即可認識到此構造遲早會失敗。 在一個項目開始的時候，不管是瀑布式還是敏捷式，都可能還行，因為開發人員忙於框架或搭建環境。 但很快員工就會提出問題——需要密集的專業支持。

一個單一的學科專家永遠無法承受這種時間和情感上的壓力，需要在人員和實施過程中得到支持。 然而，以通信限制來應對人員瓶頸是一個非常糟糕的主意。

這也是一個流行的想法，也是典型管理錯誤規模的最前沿：一名員工收集開發人員的問題，與技術聯繫人討論，然後返回答案。 通過這種方式，您創造了一個卓越的瓶頸，引發了極高的錯誤率，並顯著延遲了開發。

因素 7：慢慢加熱青蛙

你知道這個故事嗎？ 如果你把一隻青蛙放在一個裝有水的平底鍋裡，並不斷地把它加熱到煮熟的程度，青蛙就不會試圖逃跑。 如果你直接把它扔進熱水里，它會立刻跳出來。

我最近幾年對我最重要的了解之一是IT項目的員工隨著盲目性的增加而到期。 一旦建立的流程可能會在回顧中受到質疑，但很少真正是激烈的。 人們對變化做出反應的能力會隨著項目的持續時間而消失。

因此，之前未參與的外部顧問建議（大型）項目進行零星照明（健康檢查），以發現洩漏的潛在非目標路徑。 最遲在認識到全面危機之後，僅靠現有員工幾乎不可能扭轉局面。

所以這是可能的

所描述的典型管理錯誤只是我個人行為模式命中列表中的一小部分，它阻礙甚至阻礙了SW開發項目的順利完成。 從遠處看，可能會產生這樣的印象，即在項目的早期階段很容易發現問題並加以糾正。 但據稱不可動搖的框架條件和提到的盲目性往往使做出正確的決定變得困難。 開頭所說的Standish Group的統計數據表明，這一年是一年又一年。

如果項目遇到麻煩，強烈建議外部危機管理人員能夠客觀地分析和採取行動，不受敏感性和項目歷史的影響。 在項目中聽取人們意見的專家的唯一參與已經可以產生積極的影響。 選擇合適的措施也能實現轉型，最終實現扭虧為盈。