軟件開發中的項目管理是誰、為什麼和如何

您正在冒險進入軟件開發領域。 你有一個面向未來的想法、詳細的要求、足夠的技術專長和一個熟練的團隊。 你只是缺少一個專業的項目經理。 鑑於上述情況，您完成該項目的機率是多少？

可悲的事實是成功的機會並不高。 各種研究表明，軟件開發失敗的主要原因大多與項目管理不善有關。

管理軟件開發項目中導致失敗的常見錯誤是項目目標的變化、溝通不充分、變更管理不善、成本估算不准確、風險不明等。

因此，為確保您的項目不會失控，您必須將健康的項目管理放在首位。 下面，我們分享我們在企業軟件解決方案開發方面的專業知識，回答有關管理軟件開發項目的尖銳問題。

項目管理對於軟件開發項目的成功有多重要？

簡而言之，非常。

軟件開發項目通常非常複雜。 一個項目要被認為是成功的，它必須滿足要求並保證高執行質量，同時按時並在預算內完成。 這就是項目經理的職責。

因此，僱用專門的人才來管理軟件開發項目的好處包括：

• 降低風險
• 項目經理負責有效的風險管理。 在項目的一開始，他們就規劃、記錄和優先考慮潛在風險，並設計風險應對策略。

應對風險的四種常見方法包括：

• 避免：消除或放棄威脅
• 減輕：降低威脅的可能性或影響
• 轉移：將威脅分配或轉移給第三方
• 接受：承認威脅並選擇不解決、轉移或減輕它。

為了製定適當的風險應對策略，項目經理可能會與團隊進行頭腦風暴會議、訴諸故事板或採訪來自各個運營部門的個人。 有了手頭的風險管理策略，項目團隊就更容易預見風險並及時預防。

• 更好地控制項目成本
• 成本超支在管理軟件開發項目中很常見。 由於它們不僅會影響利潤，還會阻礙項目的執行能力，因此經驗豐富的 PM 會提出最佳的成本管理方法。
• 他們在整個項目生命週期中估算、預算和控製成本，旨在將支出保持在批准的範圍內。 健康的成本管理還有助於為利益相關者設定期望、控制範圍蔓延、提高項目投資回報率並監控長期成本趨勢。
• 資源的最佳利用
• 軟件開發中的健康項目管理有助於確保跨人員、他們的技能、時間、工具、設備和服務的所有項目資源得到協調和有效利用。
• 在項目的發現階段，PM 估計、分配和計劃所需的資源，並根據優先級分配它們。 在開發過程中，PM 跟踪資源利用率並消除可能阻礙項目完成的任何瓶頸。
• 更好地控制項目範圍
• 管理軟件開發項目的一個常見問題是，最好避免範圍蔓延。 不受控制的變更會影響項目進度、預算、成本和資源分配，還會影響里程碑的交付。
• 在軟件開發中進行項目管理時，PM 會設置變更請求程序，並確保每個新需求都遵循該程序。 目的是避免不受控制的範圍蔓延，並確保項目按時交付並在預算範圍內。 一旦新活動獲得批准並添加到範圍中，項目時間表和預算基準就會相應更新。

什麼是軟件開發中的項目管理？

軟件開發中的項目管理是在可用資源和約束條件下規劃、調度和跟踪項目活動的藝術。

如上所述，軟件開發項目非常複雜，包括多個階段。 項目經理計劃並監督這些階段的項目執行。

根據項目管理協會的說法，從 PM 的角度來看，軟件開發生命週期中有五個關鍵階段。

• 項目構想

項目構想階段的主要目標是確定核心項目目標、定義業務需求和起草工作說明書。 後者首先應包括對未來解決方案的要求和項目交付時間表。 項目構想通常需要所有項目利益相關者之間的密切合作，由業務分析師和項目經理帶頭。

• 項目計劃

項目規劃階段是項目經理和項目團隊的合作努力。 項目團隊設計解決方案的技術架構並提出其外觀。 反過來，項目經理制定項目計劃，制定工作分解結構，並準備項目進度表。 該階段的最終目標是清楚地了解項目範圍，並為項目績效監控奠定基礎。

在這個階段，PM 還設置了溝通和進度跟踪工具，以及未來部署的計劃，定義了驗收標準。

• 項目啟動和執行

在項目團隊參與設計和測試未來解決方案時，項目經理會監控團隊的績效，消除可能阻礙項目工作的瓶頸，促進團隊成員和項目利益相關者之間的溝通，記錄項目進度，跟踪風險觸發因素並報告給客戶或高級管理人員。

• 項目驗收

在項目驗收階段，解決方案或一組可交付成果被推出到暫存環境，並在其中進行 beta 測試。 如果需要，開發團隊會提供必要的狐狸。 PM 確保解決方案按時完整交付，並保證交付的軟件符合商定的驗收標準。 在項目驗收階段的軟件開發項目管理的另一部分涉及準備用戶指南、安裝說明和其他項目文檔。

• 項目完成

項目完成後，項目經理會進行回顧性審查，評估並記錄整個項目的起起落落。 他們還確保將所有可交付成果移交給客戶/產品所有者，包括所有源代碼、軟件文檔、開發環境等。

這些基本階段可以線性地相互跟隨，也可以允許更多的重疊——這取決於所選擇的管理軟件開發項目的方法。

軟件開發中的項目管理：流行的方法

最廣泛使用的軟件項目管理方法包括 Scrum、看板（都屬於敏捷家族）和瀑布。

軟件開發跨度中其他不太流行的項目管理方法：增量開發模型、螺旋模型、PRINCE2 和 Rational 統一過程 (RUP)。

Scrum

作為軟件開發中最流行的項目管理方法之一，Scrum 將開發過程分解為多個 sprint，每個 2 到 4 週。 通常在衝刺之前進行徹底的計劃。 Scrum 非常適合具有高度不確定性的項目，它依賴於跨職能、自組織的團隊，並接受基於觀察和實驗的增量開發理念。

軟件開發中基於 Scrum 的項目管理與傳統管理有點不同，因為沒有這樣的 PM。 相反，一個人的責任由產品負責人和 Scrum Master 分擔。

看板

看板的特點是沒有明確定義的迭代。 這是一種管理軟件開發項目的精益方法，有助於可視化項目範圍、限制正在進行的工作並確保工作順利進行。 該方法使用代表團隊獨特工作流程的物理或數字看板。

由於其性質，該模型非常適合支持和維護項目。

看板的另一個特點是對正在進行的工作量實施限制。 該方法旨在平衡範圍和資源。 任務在可用容量允許時被拉出，而不是在請求時被推入流程。

管理軟件開發項目的職責通常由看板的兩個基本角色分擔：服務交付經理和服務請求經理。 前者負責提高工作流程的效率，而後者主要負責解釋客戶的需求和期望。

然而，沒有必要雇傭額外的團隊成員來適應看板規則。 實際上，經驗豐富的 PM 通常同時兼任這兩個角色。

瀑布

與敏捷系列相比，基於瀑布的項目管理將項目分解為不同的、連續的階段。

傳統上，一旦前一個階段完全完成，新階段就會開始。 然而，現代瀑布項目允許一定程度的重疊。 例如，測試團隊在開發過程中開始驗證單個功能是很常見的。

管理軟件開發項目的瀑布式方法非常適用於範圍可預測的項目，但它仍然會使開發團隊措手不及，無法比競爭對手更快地進行調整。

由於瀑布和敏捷的項目管理有其特殊性，讓我們深入了解主要區別。

瀑布和敏捷項目管理有什麼區別？

現在讓我們更詳細地了解一下瀑布和敏捷項目中管理實踐的不同之處。 我們正在比較這兩者，因為它們比其他項目管理方法更常見，並且兩者在項目工作的組織方式上存在顯著差異。 後者影響項目經理（或敏捷中的相應角色）的角色和職責。

項目計劃

在瀑布中，如果不徹底了解您正在構建的內容和原因，就不可能繼續前進。 這就是為什麼制定詳盡的軟件需求規範是瀑布項目中的第一要務。 通常，SRS 由業務分析師編寫。 但是如果沒有一個，項目經理可以接任。

另一方面，敏捷允許更大的靈活性。 隨時隨地引入產品和流程改進是敏捷方法的本質。 計劃活動通常提前一個衝刺進行。 積壓是在所謂的 sprint zero 期間創建的。

在 sprint 0 期間，團隊提出了最少數量的用戶故事，以將其轉變為可行的產品，並且可以選擇設置用於開發的基礎架構。 衝刺通常保持輕量級和高級別的。

項目範圍管理和預算

在 Waterfall 中，解決方案範圍必須在整個項目中保持不變。 變更請求通過變更管理程序進行管理，並單獨計費。 敏捷軟件開發中的項目管理在範圍管理方面提供了更大的靈活性，但很難評估範圍變更對最終軟件成本的影響。 這會影響項目預算的方法。

在 Waterfall 中，預算編制是自上而下的、受控的並基於詳細的業務案例。 一旦提出和分析了需求，這種方法就可以給出現實的成本估算。 主要的缺點是這種方法在軟件開發項目經常出現的多變、不確定和模棱兩可的環境中不起作用。

敏捷管理軟件開發項目成本的方式是響應變化的。 這既是優勢，也是複雜性。 敏捷預算與項目的結構和時間表保持一致。 由於它也遵循 sprint 結構，因此團隊更容易適應不斷變化的環境——而不會影響整個項目預算。 項目經理只是在下一輪計劃中重新校準支出。

項目交付

通過走敏捷路線，公司在每次迭代後都會獲得新功能或其他可交付成果的增量——無論是技術願景、工作特性還是 MVP。

另一方面，在經典的瀑布中，客戶直到項目結束才真正得到任何連貫的、有效的解決方案。 全面的測試活動也在開發過程的後期進行，這可能會影響上市時間。

項目文件

根據 Waterfall 的說法，在管理軟件開發項目時，必須進行適當的、記錄在案的計劃。 項目要求必須事先明確，每個團隊成員都應該了解它們。 每個團隊成員還應該了解他們在項目中的角色以及對他們的期望。 這些信息通常也被記錄在案，並在項目團隊中分發。

瀑布團隊在整個開發過程中經常參考文檔，以便更容易跟踪進度。 這是唯一的方法——考慮到通常根據 Waterfall 管理的項目的長度和復雜性。 文檔在每個階段進行，確保每個人都在同一頁面上了解項目的進展，儘管模型的順序性質。

雖然大量的文檔有助於降低瀑布中的風險，但它降低了敏捷中對變化的適應性。 因此，在敏捷項目中生成較少的文檔是很常見的。 如果它被生產出來，文件就會保持簡潔。

但是，儘管有一個普遍的誤解，敏捷方法論中並沒有任何東西可以從本質上阻止團隊創建他們需要的盡可能多的文檔。 事實上，有些文件是絕對必要的。 必須將用戶故事添加到積壓工作、起草線框圖和記錄客戶會議。 敏捷的建議是在文檔過程中更聰明，並避免太長的文檔。

項目經理的職責是什麼？

根據管理軟件開發項目的方法，項目經理的職責也會有所不同。 讓我們看看 PM 或相應的敏捷角色在項目的每個階段都做了什麼。

在瀑布

項目經理是每個瀑布團隊中最重要的角色。 他們對可交付成果的質量和按時完成的項目負責。 他們的主要職責包括監督項目活動和為團隊成員指定任務。

現在讓我們將 PM 的工作範圍分解為多個階段。

在敏捷中

敏捷項目經理為每個 sprint 確定待辦事項的優先級，監控開發進度，並在團隊內部以及團隊與利益相關者之間建立有效的溝通。 他們還監控項目每個階段的風險，並確保開發過程遵守敏捷原則。

這是項目經理在敏捷項目的每個階段專門做的事情：

項目經理需要注意哪些陷阱？

管理軟件開發項目成功的關鍵是能夠預防和避免風險。 一個好的 PM 應該注意的常見陷阱：

無法控制範圍

尤其是在敏捷中，客戶經常在旅途中請求額外的功能，這常常使項目出錯。 因此，項目經理需要製定明確的變更管理程序，以防止範圍蔓延。 他們還需要確保利益相關者就變更對項目時間表和資源的影響達成共識。

不專注於滿足交貨日期

開發具有嚴格上市時間要求的產品，例如需要在學年開始之前發布的教育應用程序或必須及時推出的零售應用程序以進行聖誕節銷售，PM需要罷工在準時和確保高質量之間取得適當的平衡。

他們需要投入額外的精力來確定功能的優先級並為要交付的每個功能設置截止日期。 質量要求也必須預先定義，以避免在推出後出現問題。

未能建立有效的溝通

軟件開發中的有效項目管理需要有效和透明的溝通。 建立一個是 PM 的主要職責。 他們需要讓團隊了解利益相關者的決定，並定期向利益相關者通報所有項目活動、瓶頸和挑戰。

未能建立清晰的流程

遵循軟件開發過程對團隊成員來說似乎是一種負擔。 儘管如此，仍然有必要建立一個針對項目具體情況量身定制的清晰工作流程。 它將組織工作並明確期望。

依賴不熟悉的技術

項目經理需要確保工程團隊在進行技術選擇時專注於解決客戶的業務問題。 他們還需要驗證所選的技術堆棧是否符合工程最佳實踐。

另一個與技術相關的陷阱是未能在產品開發的早期階段規劃可擴展性。 因此，我們建議預先定義可擴展性要求以及其他非功能性要求。

未能提前考慮推出過程

在開發的早期階段，部署過程經常被忽視，這會導致部署過程中出現嚴重的延遲。 軟件開發中的健康項目管理需要 PM 以確保在開發過程的早期就考慮到部署和安裝問題。

如何在軟件開發中進行項目管理：ITRex 的觀點

我們與 ITRex 的首席 PM Alexander Belkavets 坐下來，就我們在 ITRex 如何處理軟件項目管理問題採訪了他。 這是我們學到的。

在為我們的客戶選擇合適的項目管理模型時，您依賴哪些因素？

Alexander：選擇這樣或那樣的項目管理方法背後有很多因素。 最重要的是項目範圍、預算和上市時間。

如果我們正在開發需要定期更新以持續為最終用戶創造價值的產品，例如游戲應用程序，我們自然會選擇 Scrum 或類似 Scrum 的方法。

另一方面，如果我們正在開發由政府實體委託的軟件解決方案，這通常意味著預算是固定的，我們寧願選擇類似瀑布的方法來確保所需的可預測性。 但是，將開發階段拆分為較小的迭代並不少見。 因此，我們經常採用混合方法，使我們能夠從 Waterfall 的可預測性和敏捷的持續改進和交付速度中受益。

是否有其他因素影響項目管理方法的選擇？

亞歷山大：當然。 未來解決方案將用於的領域、認證需求、客戶參與流程的意願以及許多其他因素也會影響項目。

例如，在開發醫療保健解決方案時，通常會選擇瀑布。 在美國，在銷售一種新型醫療設備之前，他們必須獲得 FDA 的批准； 這需要大量的文檔，這不可能確保遵循敏捷。

您作為項目經理的角色究竟需要什麼？ 您管理客戶項目的主要目標是什麼？

Alexander：我從兩個角度看待我作為項目經理的角色。

第一個是：管理項目就是管理風險。 軟件開發項目容易出現許多風險——從固有的錯誤需求到採購不足，再到不斷變化的技術環境等等。 項目經理在這方面的主要目標是盡量減少風險對項目的影響，從而最大限度地提高軟件成功交付的可能性。

第二個觀點是：管理項目正在成為一種集成器，它使許多項目子系統（如開發、測試和部署）能夠和諧地結合在一起。 PM 的主要目標是以觸發更少風險並確保最大程度地利用資源的方式協調項目內的所有流程。

你能回想一個項目，其中選擇的項目管理方法被證明是確保產品成功的決定性因素嗎？

Alexander：我們正在為我們的客戶開發一個移動應用程序，並且我們使用 Scrum 啟動了這個項目。 一旦我們發布了應用程序的第一個版本並獲得了第一個產品指標，我們決定切換到看板。

為了留住第一批用戶，我們需要繼續定期提供新功能，儘管不再需要兩週的衝刺。 看板使我們能夠根據新功能的複雜性調整 sprint 長度，平均 sprint 為 3 到 4 週，因此我們在不給開發團隊帶來額外壓力的情況下保持交付速度。 結果，我們的客戶設法留住並吸引了新用戶。

因為敏捷團隊的定位是自我管理，所以很容易相信一個項目也可以在沒有專門的項目經理的情況下完成。 是這樣嗎？

Alexander：如果沒有專門的 PM，那麼一個人的職責就必須分散到所有團隊成員身上。 人們仍然需要花時間來確定積壓的優先級、採購資源、報告和執行其他基本管理任務。 但是在沒有 PM 的情況下，這些任務將被委派給沒有專業知識的人。 這無助於最大限度地利用人才。

無 PM 方法可能適用於 3-4 人的小團隊，但當這個數字變得更大時，擁有一個專門的項目經理變得至關重要。

如果您對管理軟件開發項目仍有疑問或願意將指導您的項目的責任交給經驗豐富的合作夥伴，請聯繫 ITRex。

最初於 2022 年 10 月 24 日在 https://itrexgroup.com 上發布。