對產(chǎn)品經(jīng)理而言，需求確定、功能設(shè)計完成之后，最重要的就是開發(fā)環(huán)節(jié)的項目管理。雖然部分公司有專門的項目經(jīng)理負責(zé)，但對于產(chǎn)品來說，自己也需要掌握這一能力，避免被坑。

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

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

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

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

一、項目管理之道：規(guī)則

規(guī)則用于解決風(fēng)險，保障最終的底線。

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

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

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

1. 制度

一些公司為了保障項目/日常開發(fā)的按計劃進行，會制定一些規(guī)章制度，有些是正激勵，有些是負激勵。如通過項目達成率、千行代碼bug率、bug二次打開量、系統(tǒng)穩(wěn)定性、PRD一次評審不通過率等指標(biāo)，設(shè)置獎懲機制，來保障基礎(chǔ)的質(zhì)量底線，以支持項目按進度正常進行并如期達成目標(biāo)。

像是上述的一些指標(biāo)，都可以作為我們利用的制度規(guī)則，來為我們的項目進度與質(zhì)量兜底。

2. 流程

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

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

在一些規(guī)模較大或是管理較好的企業(yè)，已經(jīng)形成了自己的SOP（Standard Operating Procedure標(biāo)準(zhǔn)操作程序），理清一個業(yè)務(wù)落地或日常工作的SOP，甚至有些還給出了部門、員工個人協(xié)作的SOP。

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

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

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

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

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

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

二、項目管理之勢：權(quán)力

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

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

1. 方向

一直以來，我們經(jīng)常聽人說：做項目/產(chǎn)品，最重要的不是做什么，而是不做什么。但在實際落地中，受領(lǐng)導(dǎo)、業(yè)務(wù)方、甲方等影響，使得項目的方向搖擺不定，逐漸加碼，不僅給開發(fā)團隊上強度，還讓項目的進度與完成目標(biāo)變得風(fēng)雨飄搖。

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

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

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

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

要是能重來，我要選…啊不是，如果在深入調(diào)研的基礎(chǔ)上，PM能夠有一定決定方向的權(quán)力，對不合理的需求說不，那也不會如此被動，隨風(fēng)飄搖。

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

2. 人力

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

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

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

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

3. 財物

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

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

4. 政治

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

總而言之，如果沒有授予負責(zé)人相應(yīng)的權(quán)力，項目也易如風(fēng)中凌亂的小草、無舵之船，隨風(fēng)飄蕩。

三、項目管理之術(shù)：手段

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

1. 項目人力

成事在人。項目成員的人員狀態(tài)與關(guān)系如何，對于項目的戰(zhàn)斗力有極大的影響

1.1 團隊情緒

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

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

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

當(dāng)然，PM自己也要做好自己的情緒建設(shè)，擺正心態(tài)與位置。

1.2 成員關(guān)系

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

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

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

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

2. 項目范圍

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

2.1 范圍內(nèi)容確定

項目的開發(fā)范圍，依賴于對項目需求的深度調(diào)研，發(fā)現(xiàn)真實需求，以便在范圍內(nèi)用最低成本實現(xiàn)最大價值。避免需求調(diào)研不清，導(dǎo)致項目范圍變動，需求反復(fù)建起又推翻。

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

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

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

2.2 文檔記錄同步

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

2.3 實施內(nèi)容拆解

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

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

3. 項目時間

項目最重要的就是在項目工期內(nèi)完成達標(biāo)交付，因此項目時間管理和預(yù)估就十分重要。

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

3.1 項目燃盡圖

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

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

3.2 甘特圖

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

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

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

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

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

4. 項目質(zhì)量

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

4.1 計劃與目標(biāo)

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

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

4.2 測試與檢查

在這個階段主要是對開發(fā)結(jié)果進行測試，以及驗收是否達到設(shè)計目標(biāo)。在這個節(jié)點主要留足測試時間，進行相應(yīng)測試。

在測試前最好先再梳理一次功能的業(yè)務(wù)流程、權(quán)限情況，及其他一些功能的細節(jié)內(nèi)容，并抓緊與各方確認功能內(nèi)容，方便及時調(diào)整。以下是測試環(huán)節(jié)可能包括的方式：

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

4.3 結(jié)果價值分析

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

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

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

二來對開發(fā)的質(zhì)量、系統(tǒng)穩(wěn)定性進行再次驗證。

三來基于對功能的上線數(shù)據(jù)分析，我們也可以思考是否可以有更好的優(yōu)化。

5. 項目溝通

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

5.1 聊對人

要和涉及項目業(yè)務(wù)的KP聊（key person，關(guān)鍵人物）。包括我們的領(lǐng)導(dǎo)、項目開發(fā)的主要推進人以及需求方（也會是甲方）。

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

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

有幾個小招：

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

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

5.2 聊得及時

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

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

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

5.3 留下痕跡

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

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

6. 項目風(fēng)險

6.1 需求變更風(fēng)險

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

6.2 項目技術(shù)風(fēng)險

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

6.3 合同條款風(fēng)險

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

筆者朋友曾經(jīng)就吃過一個虧。

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

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

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

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

當(dāng)然還有項目范圍風(fēng)險、溝通不良風(fēng)險、項目成員素質(zhì)及流動風(fēng)險、需求不明風(fēng)險、項目進度風(fēng)險、領(lǐng)導(dǎo)支持授權(quán)少風(fēng)險、項目質(zhì)量風(fēng)險、系統(tǒng)環(huán)境風(fēng)險等，這些在上文中都有提到相應(yīng)一些方法與注意，故而不再贅述。

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

四、寫在最后

在項目管理的道、勢、術(shù)三者，如果缺了道，沒有規(guī)則的約束，會讓項目容易混亂，更易發(fā)生風(fēng)險。

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

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

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