對產品經理而言，需求確定、功能設計完成之后，最重要的就是開發環節的項目管理。雖然部分公司有專門的項目經理負責，但對于產品來說，自己也需要掌握這一能力，避免被坑。

一直以來，我們看過很多人在講項目管理，講wbs、講甘特圖、講進度管理… 但實踐起來卻總覺得不盡如人意。為什么會出現這樣的問題呢？

筆者在實踐中也和大家有過這樣的疑問，但后來發現，其實我們講的都只是進行項目管理的手段方式，其實并沒有完整談到項目管理的底層邏輯。

那怎樣才是有效項目管理的底層邏輯？

筆者先拋出觀點：其實有效項目管理可以在法家中可以找到靈感。三者：道、勢、術。其中，道為組織的相關制度、規則、流程；勢為公司授予的范圍權力；術為個人的項目管理能力與藝術。如果三個中不能至少滿足兩個，那這個項目管理往往也無法很好地推進及產出成效。

一、項目管理之道：規則

規則用于解決風險，保障最終的底線。

這一點主要體現在對公司制度、流程的利用上。

許多PM（既指產品也指項目）在進行項目管理的時候，一方面會顧忌自己對項目把控太嚴，讓項目成員覺得自己過于兇惡；另一方面又擔心項目成員對項目不上心，導致項目進度、質量等失控。

為什么在公司中有人唱紅臉就一定需要人唱黑臉？正是因為我們需要對成員進行激勵；為什么需要黑臉，也是因為需要讓成員知道懲罰，來解決底線/風險問題。而公司的制度、流程的有效利用，就滿足我們在項目管理中對黑臉的利用需要，由于是公器，大家往往不會有太多異議，從而實現公對公，私對私。

1. 制度

一些公司為了保障項目/日常開發的按計劃進行，會制定一些規章制度，有些是正激勵，有些是負激勵。如通過項目達成率、千行代碼bug率、bug二次打開量、系統穩定性、PRD一次評審不通過率等指標，設置獎懲機制，來保障基礎的質量底線，以支持項目按進度正常進行并如期達成目標。

像是上述的一些指標，都可以作為我們利用的制度規則，來為我們的項目進度與質量兜底。

2. 流程

為了提高效率、方便生產與管理，以前車間工廠會將一項工作拆成幾個步驟節點完成，一則便于員工快速了解上手，二則形成標準化，三則流程的拆解與實現也會提升整體的效率，最后也便于責任分解，解決扯皮問題。

就如那個經典問例：如何將一頭大象塞進冰箱？塞進的方法有很多種，但是也需要列出第一步、第二步、第三步…這其實就是拆解落實這個流程。

在一些規模較大或是管理較好的企業，已經形成了自己的SOP（Standard Operating Procedure標準操作程序），理清一個業務落地或日常工作的SOP，甚至有些還給出了部門、員工個人協作的SOP。

標準的作業流程讓員工減少判斷，以熟悉的方式處理工作，這極大降低了員工對這些工作的思考時間、溝通成本，讓員工可以將更多的時間與精力花在更有價值的事情上，提高整體的效率降低其他無謂成本。

就如哲學家懷特海所說：“隨著不假思索下意識即可操作的事情的增加，人類文明就提高了很大一步?！?/p>

圖為筆者基于boardmix繪制的功能開發流程圖

當然，許多小型公司為了產出效率，往往會忽略流程，這也說不上錯誤，這是因為場景不一樣。

生存與死亡就在一瞬間的小型公司，快就代表了活下去的機率，如果硬是要滿足規范流程則有些本本主義，沒有實事求是；但若公司發展到了一定規模，涉及到了多部門協作時，還沒有建立標準流程，這其中的隱患也帶來的其他成本不可謂不大。

基于以上兩點，我們也可以反過來看看自己的組織，是否形成了相對完備的制度、標準的流程，來為項目的推進保駕護航。正所謂無規矩不成方圓，如果在沒有基礎的規則，那也項目管理也無疑是無根之草，流水浮萍。

二、項目管理之勢：權力

權力，代表我們可以影響到的范圍、可以使用到的資源。

一個失勢之人，就如喪家之犬，無法被重視，無法很好地把控自己的項目，也無法高效調動相關資源進行支持。如果一個想要做好自己的項目，則一定要在項目開始之前，為自己推進項目爭取到充足的權力。同樣，想要自己的下屬的項目可以良好推進，也要對下屬給到充足的權力支持。

1. 方向

一直以來，我們經常聽人說：做項目/產品，最重要的不是做什么，而是不做什么。但在實際落地中，受領導、業務方、甲方等影響，使得項目的方向搖擺不定，逐漸加碼，不僅給開發團隊上強度，還讓項目的進度與完成目標變得風雨飄搖。

吾有一友，當年負責給某事業單位做一個功能，原需求是一個審批功能，滿足單位內的流程審批。一聽挺正常的，朋友輸出一般通用的審批功能交互原型方案后，客戶提出說他們單位的（原來系統的）審批是沒有工作流的，為了讓審批流程更有“空間”，審批節點的人只能傳給自己能傳范圍內的人來進行下一審批，怎么知道流程到哪了呢？不知道。怎么知道流程結束了審批通過了呢？不知道。

朋友覺得離譜，而且公司底層支持的工作流不支持這種逆天操作啊，但畢竟領導、商務、客戶都這樣說做了，就硬著頭皮做完了，并配置了一些加簽、回退等審批操作，開發們雖然也不理解，但也支持著弄完了。

開發完后的演示，客戶看過后整體比較滿意，但又提出單位的領導有些年紀比較大，這么多操作不知道點哪個，要將這些加簽、回退操作全部移除，只保留同意和拒絕操作。開發們覺得無語，做了又刪，但看在平時和朋友的關系不錯的份上，還是沒有多說什么，給改完了。

開發完后第三次給客戶演示的時候，一個級別比較高的客戶來了，說怎么沒有那些加簽、回退的操作，而且還要支持評論的時候發文件、表情包。領導和商務還是答應下來了，這下朋友和開發們一起爆炸了，這發現根本不是原來簡單的審批，而是一個滿足了單位內部交流兼審批的功能，然而當時定下的交付時間…

要是能重來，我要選…啊不是，如果在深入調研的基礎上，PM能夠有一定決定方向的權力，對不合理的需求說不，那也不會如此被動，隨風飄搖。

不過做G端項目、定制化項目時，那確實客戶是爹，還是得看客戶的需求，畢竟，甲方爸爸有沒有付錢才是衡量這類交付型項目的唯一標準。但如果經常加碼又改動需求，項目的負責人或高層沒有出面插手的話，那項目團隊和進度都得崩。

2. 人力

事在人為，沒有充足的人力支持，項目是起不來的。但有人了，沒有名，人也是調動不起來的。

所謂君權神授、尚方寶劍，講的就是權力的名正言順，其他人在這個名下服從于這個人的安排。項目的開踢也離不開每位成員的支持，但如果項目的人員調動沒有經過授權的過程，也就沒有這個名。

如果想項目順利開始和推進，最好拉個會議，由領導出面，向所有需要參與項目的人員打聲招呼，讓所有需要參與項目的成員知道將參與這個項目、配合支持你，了解你是項目的負責人，這樣項目的開頭與推進會輕松很多，同時配置充足的人員，完美。

筆者曾經在跟進一個項目時，又因項目推進支持原因，同時接下領導提的一個需要跨團隊協作的項目。由于開發資源資源已經在推進筆者負責中的項目，所以需要外地部門的來支持另外一個項目的開發推進。當時筆者認為領導已經和筆者說過項目由筆者來負責，于是直接找外地部門的開發leader和開發們來開會支持，但結果可想而知，我們的項目和人家的kpi又不相關，人家也不太情愿的樣子，項目進度推進出現了許多問題?，F在想來，如果能重來，一定得先拉個會，拉上相關參與得成員，讓領導講兩句給一把尚方寶劍…

3. 財物

財物，一個是財，一個是物。

大家出來工作，除了職業發展空間等因素外，其中還有重要的因素就是收入。如果負責人在權力范圍內可以為項目成員爭取到較好的項目完成激勵，必然會激勵成員去推進項目，但若爭取到了且項目如期完成后，卻沒有許諾的激勵，則會激起成員的負面情緒。其次就是物料支持，滿足項目在推進所需要用到的軟硬件物料，在合理范圍內錢能解決的都不是問題。

4. 政治

這是一個比較隱蔽且少人提到的點，一般很少有人會認為政治也會影響項目進度，但實際上在項目的推進中，政治因素的影響無處不在，站隊、辦公室政治都會影響整個項目的推進乃至存活，在一些大公司中也要考慮這些微妙且敏感的點。

總而言之，如果沒有授予負責人相應的權力，項目也易如風中凌亂的小草、無舵之船，隨風飄蕩。

三、項目管理之術：手段

許多人提及項目管理的時候，主要提的都是這個維度的方法，這些方法的巧妙運用往往讓項目管理變得事半功倍。筆者將這個維度分為六個部分，并在其中提一些常用方法，用來拋磚引玉

1. 項目人力

成事在人。項目成員的人員狀態與關系如何，對于項目的戰斗力有極大的影響

1.1 團隊情緒

照顧團隊情緒，主要是對團隊的保護。在項目團體的協作中，由于項目往往帶有時間進度、業績的壓力，盡管PM在項目中承擔的上層、外部壓力也很大，但這些壓力也只能盡量先由PM進行承擔，不將這些壓力下放到項目成員。

同時關注項目成員的情緒變化，一旦成員的情緒出現異常需要及時介入，避免由于成員情緒的影響導致實施進度受影響，甚至是出現團隊成員異動。因此在這個臨時的項目小家庭，PM只能當好這個家長的角色，維護好團隊內的氛圍，充分相信自己的團隊，讓團隊成員的積極情緒始終在線。

但有個小tip：PM在為對團隊進行保護和爭取權益的時候，也可以讓團隊成員感知到你的動作，這樣他們不僅知道自己的目標實現會有回報，也知道你的努力付出，這對提升成員關系、團隊情緒與你在團隊中的個人形象與魅力都有較大幫助。

當然，PM自己也要做好自己的情緒建設，擺正心態與位置。

1.2 成員關系

成員間關系不錯有時候可以解決很多問題，像是一些問題咨詢、支持，關系好的話刷個臉就可以輕松搞定。

在團隊成員關系中，筆者認為主要分為五類：a.友誼型；b.和諧型；c.利益型；d.保守型；f.競爭型。

1. 在友誼型中，由于性格特質、興趣愛好等關系使然，與這些成員的關系往往非常不錯，也有較深的私交，這類的成員可遇不可得，做好關系維護即可。
2. 和諧型在公司中比較常見，他們一般對所有人都不冷不熱，干好自己的活，對和諧型成員加強聯系，多幫小忙，積攢人品，建立良好的關系。
3. 利益型在公司中也比較常見，他們往往關心實現的結果是否對自己有益，無益則不關心，對利益型成員需要做好認知同步，讓他清楚你們的利益一致，同時也要盡量為項目爭取到較好的預期收益。
4. 保守型算是公司中的壞分子，往往趨利避活，是個老油子，對于這種成員我們需要注意他對團隊的影響，避免一顆老鼠屎壞了一鍋粥，如果可以將這類成員從團隊中移除最好，如果不能的話則要充分利用制度與流程，明確個人責任，至少保證他負責的任務能如期完成。
5. 競爭型的成員的利益一般與自己存在競爭關系，往往會出現明面和諧背地暗斗情況，我們可以通過利益方式，盡量形成利益一致情況，爭取將競爭型成員往利益型成員轉變。如果實在不行則使用保守型的對待方式，保障項目正常進行。

總而言之，對于友誼型、和諧型、利益型成員，我們要努力維護；對于競爭型我們要努力爭取；對于保守型我們要在保障項目進度的基礎上盡早移除。做到朋友多多的，敵人少少的。

2. 項目范圍

劃定項目實施的范圍是開始項目的前提，如果范圍沒有劃定清楚就開始，那要吃的苦頭還在后頭咧。在項目范圍的管理中，筆者將之拆解為三個部分：調研時的范圍內容確定，溝通時的文檔記錄確定，實施時的內容拆解確定。

2.1 范圍內容確定

項目的開發范圍，依賴于對項目需求的深度調研，發現真實需求，以便在范圍內用最低成本實現最大價值。避免需求調研不清，導致項目范圍變動，需求反復建起又推翻。

在調研時，需要注意的是需求的提出人并非是需求的使用人，并且需求上線后影響的人也不一定是需求的使用人與提出人。

如何確定真實需求，只有到需求產生的場景中和相關的人員聊一聊，并且詢問在這種情況下，他們原來的解決措施是怎么樣的，對于一個說起來比較重要緊急，但是實際上又沒有相應的應對措施的（哪怕是簡單的），那極大可能是一個偽需求。

關于場景的記錄與還原，楊堃老師曾提過一個公式：基本場景=人物 時間 地點 起因 經過 結果。這個公式可以很好幫助我們還原場景，去除提出人的主觀因素，感受原始需求的原汁原味。

2.2 文檔記錄同步

無論甲方項目也好，內部項目也罷，在調研、需求溝通等涉及溝通與輸出內容的，一定要做好文檔記錄及同步涉及到的所有人員。沒有及時記錄及同步的，要么是懶要么是沒有經過毒打。文檔的形成及@所有相關成員，可以定下內容，有效避免相關人員的扯皮，而且做到有據可依。基于這份記錄來實施的項目內容，哪怕項目實施中或完成后有人提出異議，只要這份文檔在，我們就是有理的一方。

2.3 實施內容拆解

為了方便項目的實施，我們也需要對項目內容進行拆解，以便后續梳理功能框架、數據建模等，同時也是為了對整體項目難度有個基礎的判斷，并且項目的內容拆解越細，就越方便我們對后續項目時間的把控。

在內容拆解中，有個項目管理的工具推薦給大家——WBS（Work Breakdown Structure 的簡稱，意為工作分解結構），將復雜的項目或任務拆分成一系列具體、可操作的組成部分。下面就是一個將大象塞進冰箱的WBS示例。

3. 項目時間

項目最重要的就是在項目工期內完成達標交付，因此項目時間管理和預估就十分重要。

現在許多團隊已經在使用項目協作工具，比如asana、PingCode、Worktile、teambition等，其中的功能就支持對項目時間的查看與管理。在平常也有些常用的項目實踐管理工具：項目燃盡圖、甘特圖。

3.1 項目燃盡圖

它的好處就在于結合了項目的計劃工期（參考線）以及實際的完成實踐（實際線），將工期數據可視化，讓我們看到項目進度的更新狀態報告，使每個成員都能了解到最新的項目進度信息。

但燃盡圖缺點在于只顯示已完成的故事點數，對于其他的內容情況（如：哪些故事已經也在開始中？還有哪些故事沒完成？是不是同時有幾個故事都在進行？等等）都不知道。而如果燃盡圖出現與預估不一樣的變化，我們也比較難判斷是已完成的故事的影響還是又增減了什么故事。

3.2 甘特圖

甘特圖可以通過條狀圖來顯示項目、進度和其他時間相關的系統進展的內在關系隨著時間進展的情況，在一般的項目管理中應用最多的也是這個工具。

在甘特圖中，滿足這幾個關鍵要素：任務列表（知道要干什么）、任務順序（知道要先干哪個后干哪個）、任務時間（知道要干多久）、任務人員（知道負責人是誰、參與人是誰）。其次還可根據情況注明任務需要什么支持，任務/項目的里程碑在哪。

以上基本滿足了對整體項目任務計劃及進度的基本了解與安排。

由億圖項目管理軟件Edraw Project提供的甘特圖模板圖

但以上的都只是工具的使用，核心還是需要形成一個團隊內溝通機制（將會在5.項目溝通中說明），讓自己對項目過程有整體的把控?？梢宰岉椖砍蓡T定期（如一日、一周）匯報個人的進度情況，保證自己可以及時掌握項目進度信息，做好情況的應對與調整。

4. 項目質量

在PM圈中流傳著一個經久不衰的笑話：客戶想要的和最后實現的，并搞出了許多梗圖。事實上確實也經常出現這樣的搞笑情況，除了客戶不斷疊加的新想法，還有我們自己開發的效果等原因，這就不得不讓我們重視起項目質量管理。筆者將項目質量管理分為前中后三個階段——前：計劃與目標；中：測試與檢查；后：結果價值分析。三個階段的側重點各有不一。

4.1 計劃與目標

這點與2.項目范圍、3.項目時間相關，主要是在項目開始先確定要做的內容，以及后續的計劃形成與計劃跟進。側重的是對項目計劃進度的把控，但需要注意的是，需要為項目留出充足的冗余時間，這個時間一般用于對完成的結果的測試，以及測試后的優化時間。

如果為了討好高層、客戶而一昧地擠壓這塊地冗余時間，項目出現問題的時候就缺少了靈活處理的空間。同時可以在原計劃的任務完成時間前設置一個“預定完成時間”，團隊盡量在預定完成時間點完成需要開發的內容，這樣也有利于處理這個任務可能會發生的事情。有時慢即是快，為了追逐所謂的快，反而容易變慢。

4.2 測試與檢查

在這個階段主要是對開發結果進行測試，以及驗收是否達到設計目標。在這個節點主要留足測試時間，進行相應測試。

在測試前最好先再梳理一次功能的業務流程、權限情況，及其他一些功能的細節內容，并抓緊與各方確認功能內容，方便及時調整。以下是測試環節可能包括的方式：

• 黑盒測試：不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。
• 白盒測試：確保應用程序或網頁在加載時能夠正常顯示，同時沒有出現任何錯誤或異常的測試。
• 灰盒測試：介于白盒測試與黑盒測試之間的一種測試，多用于集成測試階段，不僅關注輸出、輸入的正確性，同時也關注程序內部的情況。
• 單元測試：對軟件中的最小可測試單元進行檢查和驗證。
• 冒煙測試：確認代碼中的更改會按預期運行，且不會破壞整個版本的穩定性。
• 容量測試：測試軟件系統在最大負載量下的容量和性能，及其在超負荷情況下的表現和穩定性。
• 回歸測試：修改了舊代碼后，重新測試之前已經測試過的測試用例，以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤。
• 越權測試：針對是否存在越權漏洞或越權訪問進行測試。
• 模糊測試：通過提供隨機的非預期的輸入來檢測程序中的錯誤、漏洞等，可以幫助發現程序中的邊界條件錯誤、內存泄漏、緩沖區溢出等問題。
• 集成測試：將程序或硬件配置中的多個單元或模塊被組合在一起并進行測試。
• 壓力測試：針對特定系統或者組件所做的測試，目的是確認其穩定性。
• 用戶接受度測試：在“真實環境”中由特定的用戶（如用戶、需求方）進行測試，確認功能是否滿足預期。

4.3 結果價值分析

這個階段一般在項目上線后，主要是對項目功能的使用、穩定性等數據進行回收分析。

一些團隊會忽略這個階段，上線就上線了，但是如果情況允許的話，最好還是走完這個流程。

一來檢驗需求質量，如果上線后發現這個功能使用情況與預期差距較大，也可以讓我們自己反思在提出/接收需求時，是否有對需求進行深入理解、判斷？是否有更好的處理方法？是否這個需求可以拒絕/不做？方便后續可以更好處理需求；

二來對開發的質量、系統穩定性進行再次驗證。

三來基于對功能的上線數據分析，我們也可以思考是否可以有更好的優化。

5. 項目溝通

項目的溝通需要注意聊對人、聊得及時，并且要留下溝通痕跡。

5.1 聊對人

要和涉及項目業務的KP聊（key person，關鍵人物）。包括我們的領導、項目開發的主要推進人以及需求方（也會是甲方）。

• 對于我們的領導，我們主要及時做好信息的同步（向上管理），這不僅方便上級對項目進度的了解，也更熟悉項目團隊情況，也方便我們申請資源支持及項目完成后為團隊爭取更多的權益，畢竟酒香也怕巷子深，會哭的孩子有奶喝；
• 對于項目開發的主要推進人，比如主要的開發負責人，業務支持方。我們主要多提醒、溝通，及時了解他們的進度情況、需要的支持，確保項目需求沒跑偏，并及時為他們提供支持；
• 對于需求方，如果是內部需求，除了需求的提出人，我們更重要的是到需求的來源處，找到需求的使用人和被影響人聊一下，確認需求（也許不一定要做呢？而是有其他非項目的原因導致大家認為需要做這個東西），實施完成后再同步相關的需求方。如果是外部需求（如甲方客戶），除了需求的對接人，最好也要和客戶中可以拍板的話事人搭上關系，避免對接人的單方面想法以及需求無法拍板導致的推進困難。

同時也要注意維護關系，這種維護依賴于信任的建立，信任來源于兩點：1.響應；2.主動幫助。核心就在于是讓客戶感受到你不是為了拿到項目錢而已，而是真心地站在客戶一方，從他們的角度出發，及時響應、做好反饋，幫忙出謀劃策、解決煩惱。

有幾個小招：

• 比如在一些無關重要的功能上，可以幫忙提出自己的優化想法，讓客戶覺得你也主動幫他想；比如客戶有緊急運營支持/bug處理時，能調動資源及時支持（需求的話一般盡量不接）；
• 比如項目的進度要定期同步，如果完不成時要提前告知讓對接人可以留有匯報余地；
• 再比如項目里程碑或發版時，給到一些好看的成果介紹圖（例如項目這一期實現多少個功能、用時多少一些數據展示圖；
• 再例如版本迭代做個海報，這也方便對接人匯報，領導最喜歡看這種數據很好的樣子內容了）。

這些微妙的客戶關系運營手段都能幫你在與客戶建立很好的信任關系。

5.2 聊得及時

聊并不一定是對話，也可以是信息的同步。

項目團隊內的話，主要是做好定期同步即可，例如項目成員的日報、周報，讓自己可以把握住情況。但最好還是每周開個短時間的周會，大家在這個時間段內同步完成情況、是否需要支持協調。有些團隊會使用站會的方式（由于站著累，大家也想快點結束，一般匯報的內容也比較集中不容易分散，時間一般10分鐘左右），效果也挺不錯的（如果既站會又講得久，那當我沒說，那可遭老罪了）

對于領導與需求方，我們做好定期匯報即可，如果需要資源支持或是臨時發生變動、項目由于某些原因無法如期完成時，一定一定要及時同步。

5.3 留下痕跡

不論是項目成員、甲方還是內部需求提出方，盡量對應有一個溝通平臺（群），里面需要有高層領導，每次的需求確認結果、項目進度等等，最好都在群內溝通，可以的話也@相關KP，避免私聊導致出問題時的死無對證。最好可以形成相關的會議紀要、需求溝通書（尤其是面對甲方時更要注意這類文檔的留痕）。

在溝通的技巧方面，推薦大家看科里? 帕特森的《關鍵對話：如何高效能溝通》。要在溝通中分清主次矛盾，并緊抓主要矛盾——我們對話的目的。并且為了這個目的，要時刻關注對話走向，建立共享觀點庫、關注情緒來維護對話的安全感，在包容他人觀點的同時也要堅定正確的觀點。

6. 項目風險

6.1 需求變更風險

一般內部需求的話，需求變更風險還是比較低的，并且可以通過調整優先級及排期處理。而外部需求（甲方）的話，則比較容易出現這類風險。但應對的話同2.項目范圍，調研及確定好需求范圍；以及5.項目溝通，及時同步并留痕。

6.2 項目技術風險

由于一些需求的提出會涉及到一些新技術應用，這就為項目的實施帶來技術風險。如果判斷需求會有新技術應用情況的話，就要及時考慮安排人員進行提前學習，并了解是否還有其他的替代方案，做好二手準備。

6.3 合同條款風險

這點往往被許多人忽略掉。這點很重要！這點很重要！這點很重要！??！重要的事情說三遍！不會有人以為簽在合同上的東西不重要吧？不會吧？不會吧？在合同條款出來的時候，領導、商務、項目就要全面、仔細、準確地了解合同條款的全部內容！對于一些沒定的、模糊的內容要盡快明確、調整或補充協議。

筆者朋友曾經就吃過一個虧。

曾經在做一個項目的時候，領導和商務為了吸引客戶，在需求溝通書上自己填寫了一個當時還剛開始開發的功能。但在與客戶溝通階段時，客戶的對接人明確說當前暫不需要這個功能（由于客戶不要，這個功能的開發資源就調到其他功能上了，功能還沒開發完），朋友當時和領導及商務說，既然客戶不需要，我們就將這塊需求從溝通書中移除吧，但是領導說沒關系，留著就留著唄。

誰知道后面領導和商務做合同的時候居然還直接用了最終需求溝通書的內容，這個功能理所當然地也寫進了合同！后面項目開發完成，領導和商務在給客戶做UAT的時候，客戶的領導就問合同中有這個功能，怎么現在又沒有了，要立刻加上。

還記得那是周二下午的六點，領導和商務對朋友說真的真的為項目團隊向客戶盡最大努力爭取時間了，然后要周五保質保量完成這個功能的開發并上線。好家伙，當時勸你們別加到需求溝通書和合同上的時候你們怎么不聽呢？現在反過來將壓力全給到了項目團隊。

一個還開發內容還沒過半的功能，三天時間，那三天項目團隊披星戴月，一臺電腦、一雙手、一個夢想，終于是完成了，團隊也爆炸了。

當然還有項目范圍風險、溝通不良風險、項目成員素質及流動風險、需求不明風險、項目進度風險、領導支持授權少風險、項目質量風險、系統環境風險等，這些在上文中都有提到相應一些方法與注意，故而不再贅述。

手段在于細節，如果沒有手段耕耘，項目管理只能是一片荒田

四、寫在最后

在項目管理的道、勢、術三者，如果缺了道，沒有規則的約束，會讓項目容易混亂，更易發生風險。

在小公司的項目還可以依賴于PM的勢與術來帶好一個又一個項目，但畢竟不是長久之法，如果后面PM離開了，那后面的就再起不能了；如果缺了勢，依賴于公司的道和PM的術，也能讓項目勉強走完，但由于缺少勢來為團隊穩定方向，爭取人、錢，團隊也容易對公司形成負面情緒，久之也不利于團隊穩定；如果缺了術，依賴公司已有的道和高層授予的勢，項目是可以跑下去的，但PM還有什么用呢？這種情況誰都可以當PM了。沒有術的運用，也就無法更好的發揮對所有資源的利用，調動各方的配合，在一些細節的控制上也不能很好實現。

當然，項目管理涉及到的范圍與內容很大，筆者提出的觀點也只是九牛一毛，在實際的落地中也會因為情況不同產生對應變化。盡管本篇講的是項目管理，但筆者認為在公司的協作管理中，依然離不開以上三個方面。

歡迎大家留下自己的想法，一起交流。

本文由 @Hank 原創發布于人人都是產品經理。未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。