1. 初創公司作為產品經理怎么有效的進行項目管理，推動項目發展？

問題描述：初創公司一般不設項目管理崗，一般是產品經理或者技術負責人擔當。如果產品經理來進行項目管理，產品經理通常不懂技術，在時間節點的把控上并沒有把握。如果技術負責人來進行項目管理，那么如果產品需求有變動的話通常跟產品經理溝通不暢，導致項目延誤，無法達到實際效果。

答：我個人建議由產品經理來承擔項目管理的角色，這是產品經理未來發展必不可少的技能之一，當然由于目前此前各大公司設置專崗：項目經理，不僅僅是要具備單項目管理的能力，還要具備多項目管理，項目集管理，項目組合管理以及組織級別項目管理的能力，這樣才有益以后更高的進階以及更大的職責和擔當，然后我們回到問題本身，如果在這樣的環境下，首先明確項目團隊的目標是什么？目標是通過大家的通力協作完成項目，達到項目預期的目標，然后才是誰擔任項目負責人的角色更有益于目標的實現，一般來說公司的制度以及規范會定位角色崗位，此問題中已經有兩個傾向了，產品經理或者技術負責人，一旦成為了項目負責人就應該具備基本的項目經理的責任，而不是基于自身已有的立場的屬性，運用專業的方法和工具解決項目過程中的各種沖突和問題。

去哪兒案例：

我剛來去哪兒的時候也面臨著同樣的情況，許多初創公司不會設立項目經理，絕大部分產品、開發leader兼任，以技術leader為主。

為什么要用這種形式？去哪兒至今沒有專職的項目經理。如果有15個項目經理，就會出現一個271法則，20%的人是靠譜的，70%的人差強人意的，10%的人是讓你不放心的，會把項目帶到溝里去。

所以當時我們定了一個原則，我們不設立專職的項目經理，把項目經理的職責轉移到對產品經理的要求中去，尤其是對高級產品經理，對能力的要求比如對項目的培訓、帶重點項目的經驗非常高，我們對整個團隊的項目能力更細化，而不是需要打造一個項目經理的團隊，當項目出現問題時，我們有4個人——產品經理、開發的leader、QA的leader、產品的leader存在，當產品出現問題時，我們有4個可以力挽狂瀾的機會。如果這4個人都出現問題，我們還有專業的PMO，把項目帶向成功。

所以讓產品經理擔任這個角色好還是開發的leader擔任這個角色好？其實沒有什么傾向性。只要他們有項目管理的能力，他們的背景、業務能力只能是溝通的加分項，不是必選項。國際上對項目經理的角色定位是，他不一定需要具備業務的能力，但他要了解項目，這樣有助于他了解業務目標的實現，更好地跟團隊成員進行溝通。

一個有技術背景的人擔任項目經理，有利有弊，好處是他了解技術，能夠跟技術團隊打成一片；壞處是如果他不是專家，沒有專家能力，他就會帶入主觀意見，不能客觀地看待項目和處理問題，就會把項目帶到溝里。

所以更多的業界傾向于非專業的人擔任項目經理這一角色，對項目經理的軟能力要求會很高，對業務背景比如技術背景的要求不是很高。

2. 有出現產品成長期的管理與項目管理沖突打我情況嗎？如果有，可否分享學習下？

問題描述：經常出現產品的需求實現與項目上線進度沖突，一般會根據需求的優先級做取舍，您在這方面都會怎么處理？有沒有具體案例分享下，謝謝！?

答：這個問題要分兩塊來看，第一個是看兩個項目間的優先級問題，還是一個項目的時間的優先級和需求的優先級之間的PK。我們一開始講帶項目管理的時候會講項目管理的策略，一開始的時候會出現項目的一個三角優先級的約束。就是范圍、時間、成本跟質量的三個優先級的一個匹配。

首先我們把項目分成P1-P5。

P1是那些緊急，需要響應的一些項目，這些都是客觀市場變化導致的，必須去做的。這些P1的項目只能影響P2以外的項目。

P2項目是無論出現什么樣的原因，都要保住的一類項目。這類項目用團隊里面的俗話來說“死了老爹老娘都要保住的項目”。這類項目沒有任何借口跟原因，遇到后該加班的加班，必須要搞得定。既然大家確認他是P2，那一定要搞得定。你可以在優先級PK的時候去argue，但是一旦確認，目標一致，那就必須搞得定。這些P2項目是產品跟業務非常核心的項目，定級的時候一定要慎重。

然后再說是P3項，P3項目相對P2項目稍微弱一點。他是有帶line的一些項目，有時間。上面有一個嚴格的要求的。這些要求那就是必須在這某一個確定的時間之前要搞定的。然后P3的項目的可以受P1的影響。

隨后就是P4的項目，P4項目是沒有帶line的，但是也是有一定的時間要求的，這個要求那不是那么精確或者嚴格，可能在某一個時間段之內搞定就可以了。然后P4的項目一般定為是說一般排期的項目了。

然后再者就是P5的項目，P5的項目就是沒有任何時間要求。這類項目就是說可以給某些新的團隊成員去練練手，也可以是做到哪算哪的項目。

然后整個業務的核心主要是集中在P2跟p3的項目上。所以說，一般來說P2、P3的項目，必須在排期的時候排進去。如果排不進去了，一兩次還算正常。如果是多次排不進去了，就證明一個問題，你整個業務的發展人員變成了一個瓶頸，缺資源了。這個時候，要么橫向去掉配資源，要么通過HRBP去招聘更多的資源部補充進來。所以說，這個時候你們就很容易根據數據去要人了。

然后P4的項目是為了更好的調節團隊節奏。就是說，我的排期的時候，P4的項目多排一點，我團隊就緊一點，少排點。就松一點。這樣子來把整個團隊的節奏控制在自己的手里。

至于P3類的項目排不進去的話，我們剛剛說了，一方面是證明缺資源了。第二個說也不是完全不可以，那必須有一定的機制保證，假如說排不進去的話，必須經過某個PO老大確認后才可以這樣子，制造一點約束力，是告訴大家不要輕易把某個項目delay了，或者說某個項目因為什么原因排不進去。

優先級控制策略呢，就讓大家的目標非常一致。假說P1來了，我們應該放下所有的項目就把他搞定，除了P2。P2項目來了，也沒有任何借口，必須把它做完，因為這個代表業務的核心。我們的PK優先級的時候基本上就認定他了，而不是在做的過程中說我們的項目不重要。那P3的項目，只是有時間要求的，如果來了P1，受影響的話也是可以的。如果說有問題需要你delay或者需要調整的話，你可以經過某個程序、某個既定的流程去走一遍。但是在走之前你要考慮清楚，這個上升會可能給你帶來一定的負面影響。所以說，盡可能不要走某個流程。

P4項目，那就很簡單了，就變成一個非常正常的項目，是平時一些運營類的修修補補類的這些項目，更多的是為了調節整個團隊的節奏。

所以說我們在嘗試這個優先級策略的時候，覺得是行之有效的，因為這樣子大家都明白，這個項目既然定好優先級以后就應該怎么去辦。這是不同項目優先級的一個策略分享。

然后我再說一下單項目的優先級的確定。我們剛剛前面已經提到了，單項目的優先級有三角優先級的確認，一共有四個緯度，一個是時間緯度、質量緯度、成本緯度和范圍緯度。范圍緯度就是大家通常所說的需求范圍和時間。前面已經提到的說，當需求跟時間遇到問題的時候，我應該怎么去PK？這個時候，其實不應該在過程中遇到分歧了，應該在一開始的時候，一開始項目啟動時，就應該知道這個項目的優先級是什么樣的，是時間優先為主還是范圍優先為主。當然，我們經常遇到一種情況，我們為了趕著上線，會進行需求刪減，或者把核心需求先上線，非核心需求錯開上線，這些都是一種很好的控制策略。

3. 需求方屢屢變方案，導致項目無法按時上線怎么辦？?

問題描述：我現在在做品牌廣告項目，客戶老是在中途改方案，導致排期一變再變，團隊情緒受影響，上線進度也被耽誤。

請問，在這種情況下：

1、怎么才能在確保項目按原定日期上線？

2、如何處理被打亂進度的其他項目呢？

答：這是甲乙雙方的合作項目最棘手的問題，但是有點共性就是大家都希望把項目做成，又沒有十足的信任感，所以項目伊始的策略和約束很重要，其實項目變更的流程必須在雙方合同或者協議里提現和明確，否則會陷入無休止的惡性循環中，這個就是典型的例子，項目團隊為啥懼怕變更，然而客觀的變更后帶來的收益增減或者損失的減少等應該是認同，最怕的是由于人為（主觀）導致的變更的往復，需求分析不到，需求review不到位，需求溝通不到位，需求的傳達或者文檔描述不到位等，本來可以避免而發生的變更，一般來說變更都是正向的，大家樂于接受的，所以變更的評估，審核很重要，評估變更是否影響項目的進度基線，如果影響？是否可以調整？如果需要調整由誰審批？這些都需要體現在變更控制流程里。

變更控制的核心是要搞定所有利益相關者，避免溝通補充帶來后果，最怕的是變更商務知曉，沒有或者沒有及時正確的傳達到產品研發團隊。

然后評估后需要審批了，就是我們選擇增加+調整進度基線，還是可以增加成本+趕回進度了

這個基于項目的本身狀況以及合同條約來進行選擇，可以跟之前項目優先級進行對照。

如果是deadline類的項目就應該想方設法去搞定了，所以評估內容和審批過程很重要，要去權衡一些東西，如成本，時間和風險等。

4. 多個項目并行PRD來不及的處理方式？

問題描述：正常情況下prd走在rd前面，在多個項目并行時，如何協調prd未出，rd處于空檔期情況？?

答：該問題反映在一個團隊上，團隊里多項目，尤其是某個產品線，我們知道產品的輸出是開發的輸入，而現在存在產品的輸出跟不上開發的輸出這個問題，

RD走在PRD之前存在的問題出現可能是：①產品團隊輸出能力有問題；②產品團隊資源不足；

短時間的處理方式：①鼓勵開發團隊做系統架構的升級，為更好響應產品的項目打好基礎去做一些技術類的項目；②提升產品輸出能力，或者適當在PRD與工期之間做個妥協，使得輸出能力跟得上開發能力；

反過來的話產品輸出有很多項目，是開發團隊消耗不了的，嚴格按照優先級控制，挑選應該立馬被響應的項目，利用有限的資源做有價值的項目，反映了團隊可能組織架構設計不合理，或者團隊的拼配能力有問題，所以這個時候團隊LEADER根據情況去調整，缺資源補資源，如果能力不足置換資源或者培養，我們最好的狀態為產品輸出的20-30%是開發團隊消化不掉的，這樣的可以在整個隊列里面挑選最有價值的項目，使得產品得到很好的發展。

如果長時間研發跟不上產品了，就有可能代表我們并不需要那么多的資源，或者說我們的業務發展沒有找到一個很好的發展方向，需要不同時期不同的團隊去觀察做調整。由于某些項目因為某些時間要求，PRD也有相對應的質量要求，當如果我們產出一份100%質量的PRD的時候可能開發的時間就被縮短了，這樣子對于項目的如期上線也是不利的，那我們在制定策略的時候也要反推，比如說我們我們PRD需要3天，但是產出高質量的PRD需要5天，如果5天的話有可能對項目會有2天的推遲，那我們可以按照3天的節奏出PRD，在一定范圍內降低PRD的質量，降低不代表沒有要求，RD/Q&A/PD/UI/UE等要站在一起，要質量的輸出是大家可以接受，所有的妥協都是為了項目能達到預期的目標來制定某些策略，包括PRD的產出策略，正常的項目有正常標準，不正常的項目按照特殊的要求來對待，盡管是特殊要求，但有最起碼的基礎是團隊成員達成一致，對于項目的推進是沒有問題的，對于風險是可控的。

5. 需求不明確情況下的項目不斷延期問題如何處理？

問題描述：創業團隊很容易遇到需求不明確的情況下立項執行，也往往導致項目不斷出現延期，這種情況下應該如何做好項目管理？? ? ?

?

答：項目管理里有種項目管理方式叫做極端項目管理，也就是目標和需求全部不明確的情況下推進項目，這個時候我覺得將核心需求（拆小的情況下）快速上線更重要，這個時候可以將流程無限的簡化，等到一定的時機的時候恢復正常節奏，這在去哪兒早起我們經常如此的做，約束團隊，人，范圍，讓團隊不受約束快速迭代往前走，定期reivew的形式來規避問題和風險，從而進行策略的調整。這個review周期基本1周，特殊的嘗試可以1-3個月，一般都是一個月，這樣團隊既有了自由度也有了約束，這是不能簡單按照延期與否來考量了，有的時候需要團隊leader拍著胸脯去對賭下，這類項目有個特殊的名稱-戰略或者戰術項目，一旦成功即納入正常軌道。

追問：但如果分拆需求，最小化需求快速上線往往會遇到老板評審需求不充分、考慮不全而被否定的情況，怎么辦？

答：老板本身是沒有足夠精力去了解整個項目的，建議你申請更高的自由度，以一個小組一個固定時間周期，按照自己的方式推進項目執行，定期跟老板溝通一些基本情況即可。

6. 什么階段的公司需要項目管理，項目經理一定要懂研發么，如何排期？

問題描述：之前有專職項目管理崗的互聯網公司并不多，而如今這個崗位越來越火，是整體行業發展趨勢造成的么，那么公司進入到什么階段開始需要專職的項目管理人才，他們的價值體現在哪？項目經理要對項目進行整體把控，那么項目經理來排期么？研發自排期的話，如何確認真實度？? ?

答：“首先我來回答下，為什么這個崗位會越來越火？因為最主要的原因是：互聯網跟傳統行業不一樣，但是傳統行業都有專職的項目經理，因為整個傳統行業里面都是靠項目來區分整個自己公司的發展的，他需要以項目的形式進行推進，那互聯網公司的項目都是非常小的，我們叫小步快跑的，很快的一個節奏，所以說有的時候反而不需要專業的項目經理。但是為什么后面對這個角色需要的越來越多呢，或這個職位越來越重要呢，更多的是因為市場的變化和互聯網這樣的背景，導致我們的團隊或公司有這樣的一個狀況，我們有越來越多的項目，沒有足夠的資源去消化他，去很快的實現他。

所以說，大家都寄望于更好的排期，或者更好的資源配置，來把更有價值或者說把絕大部分最好的所有項目給消化掉。各大互聯網公司對項目經理單一的專職的崗位的要求不是那么高了，絕大部分要求項目經理這要角色的要求都是團隊成員偷懶導致的，因為有專業的人幫他做專業的事當然最好了，我覺得兼任就可以了，但是更多的需要有自己的項目管理，像類似于PMO這樣的專業團隊，幫助大家具備項目管理的能力，把組織的項目管理能力給提上去，而不是某一個人或者是一個小的團隊。另外我在說一下排期，排期指的是什么，狹義上指的是一個schedule。

排期其實就是項目計劃，做schedule，項目規劃中一小部分，排期其實不是某個人的排期，排期最忌諱的是部分人的計劃或者一個人的計劃，這都是閉門造車的表現，項目計劃是所有相關人的計劃整合而成的schedule，是大家公共共同對于項目時間是的承諾，由項目經理組織并且優化schedule，不能角色的項目成員對于時間計劃的承諾很重要，只有共同努力按期完成才能讓項目如期完成，至于如何趕進度，壓縮工期那是有很多方法的，這里就不追贅述了。這里面有一個問題是說開發的排期如何保持真實度，所以說每個團隊成員之間如果缺乏最起碼的信任那就玩蛋了。

但有一點，里面有一個問題是，信任和約束是兩碼事，就是項目的排期你可能需要10天，但據我的理解是要不了10天，可能是你留了一個buffer2天，也可能是你把一個簡單的事情做復雜了，可能需要5天結果你干了10天，所以只要坐下來看，你為什么需要10天，你10天的wbs是什么，每個WBS需要的工期是什么，對應的資源是什么，這些WBS拆分的越細的話，我們對每一個細的wbs工作包的時間的認知基本是一致的，如果你還不放心的話，可以對比下這個開發的工作量的估時和另一個工程師的估時看有多大的差異，差異太大的話那就坐下來看一下，差異的原因是什么，得出一個相對合理的工作量的估時。但是我覺得產品和不同的人去argue和chanllage別人說為什么你需要10日,你要能說出原因，然后你能夠說的清楚這個也ok了，不要被別人說10你就嗯是10日不能接受，沒有這回事。你只要能拆分到一個簡單的工作包，最小可控單元的工作包，每個人都可以估工時，包括開發包括產品。所以說不用擔心這個問題。

我覺得大家在團隊協作的過程中，既要有合作，也要有信任，更多的需要約束。我需要10天，結果你需要12天，為什么，我們能不能相辦法把工作效率從12天提到10天，其實有很多很多的方法的。你對他約束，他也會對你約束，都是相互的，我們只有一個共同的目標，就是把項目給搞定。

追問：之前遇到過產品經理拆分產品需求，研發拆分工作包，這兩個可能不完全對應。

答：這兩個是有一定的對應關系的，產品的一些工作包的拆分和研發的工作包的拆分其實是有一定的聯系的，但不是完全一致的，你可能說一個產品的功能可以拆分到一個很小的單元，但是開發去實現的話可能需要若干的功能去實現，是有一定的對應關系的，不是完全一一對應的。也有很多的一些歷史的項目進行對比，假如做一個登錄，在別的項目里需要2人日，為什么這個項目要需要5人日，他告訴你各方面的原因是什么，那我們有沒有辦法跟他做一樣2人日，甚至更短，或者有沒有現成的功能可以直接拿來用，有些問題有些argue是非常必要的，你argue兩次，下次就不會這樣了。

這是基于信任的基礎上了，有些團隊的leader為了保護自己的團隊或成員會留過多的buffer，如果這個項目不需要buffer，你就要把buffer擠出去或者撐握在自己的手里。更重要的點是，我們要根據這個項目目標，由其是那些有時間要求的，我需要你2人日，結果改成4人日，我們就坐下來聊聊，有沒有可能2人日搞定，然后想辦法，更多的是為這個項目本身的目標服務的。如果說這個項目在一定時間要求的基礎上，某個項目成員的工作不在關鍵路徑上，可能5天的活讓他干10天，那沒有關系，就讓他干10天。如果是在關鍵路徑上就需要去agrue了，他需要2天還是3天，可能對整個項目的工期是有影響的。第一反應是要根據項目的整體目標走。

7. 在沒有項目經理也沒有pmo的公司，項目推動和進度把控該由誰承擔？

問題描述：我們公司即沒有項目經理也沒有pmo，項目進度該由哪個角色負責？現在項目進度由測試經理監管，所以項目前期的風險要等提測的時候才暴露出來！? ?

? ?

答：當公司沒有項目管理方面的專業人員時，那現在有測試經理來監控項目流程總比沒有強，但如何規避他的監管不足導致的一些問題呢？我們前面也有提到，當這個團隊有幾個核心的角色，當每個角色都具備一定項目管理能力時，如果測試經理的項目管理有問題，那開發經理可以補上，產品經理也可以補上。

其實主要問題是你們公司對項目經理的定位還不是很明確，那可以各個角色坐到一起來探討某個項目該由誰來負責。可能每個人所需擅長的方向不同，也許某個項目可以由產品經理來擔任，也許某個項目適合開發經理來擔任。但每個負責人擔任項目經理就有一個弊端，因為每個人也許更多的去關注自己熟悉的一塊，沒有一個項目管理整體的意識和觀念，比如問題描述中所述的，測試經理可能更關注他測試的計劃和上下游的關系，沒有從項目一開始kickoff時開始管理，這也和他的專業能力有關系，所以說更多的需要大家坐一起來規劃某個項目，只作為項目中某一塊的項目負責人而已。

然而就用這樣的方式也可能引發問題，假如說很多項目每次的負責人都不同，比如一個項目的負責人是開發經理，一個項目的負責人是產品經理，那如何對這些項目進行一個約束呢？就需要項目定期review，由項目負責人進行匯報整個項目的進展，大家一起來共同探討問題該怎么處理會更好。

最好的方式是把項目經理的職責定位到某個角色上去，建議產品兼顧這個角色，當團隊發展到一定規模時再考慮設置項目經理崗。一般超過30人的團隊是需要有項目經理的，可以是兼職的；但當團隊達100人，就需要專門的項目經理崗幫助管理團隊。

項目經理有一個很重要的特點是他比較中立，是代表整個項目的。如果是某個角色的人來擔任的話，可能在某些方面能力或經驗不足，可能整體相對缺乏一點，需要在實踐中不斷積累。

8. 創業團隊，產品和設計在北京，技術和測試在廣州，通過什么流程才能更好的溝通？

問題描述：如題，之前在大公司每天開站會面對面同步進展很方便，現在在這樣的環境下進展同步是個問題，遠程溝通產品需求、驗收設計圖等都有障礙。

答：項目管理里有個核心就是干系人管理，干系人管理的核心是需要有溝通規劃，尤其是對于跨區域合作更為重要。

在互聯網爆發之前，有一些典型的公司，尤其是美國的一些IT公司，通過全球外包的形式來做項目，他們選的很重要的人力資源輸出地一個是在中國一個是印度，他們采用24小時配合機制，所以說他們遇到的問題更加復雜。他們是怎么解決的呢？其中最重要的一點是做好溝通規劃，我應該在什么時候、和誰、用什么樣的方式、溝通什么內容、達到什么樣的要求、如何形成及時的反饋、有問題該怎么辦、沒問題該怎么辦。

趙云老師的經驗：首先要做的第一件事情是將所有干系人找出來（項目發起人是誰，產品是誰，項目經理是誰，設計是誰，每個配合的角色的是誰，他的職責是什么，他的老板是誰，聯系方式是，如果出現問題該怎么辦怎么才能聯系到正確的人，他需要在什么時候獲取什么信息），都需要在項目一開始就規劃清晰，當遇到問題時拿到溝通規劃就能知道該找誰，他能決策還是不能決策，他需要給予反饋還是接受信息就好等等。

對項目的各個階段所需的溝通媒介、溝通方式，對于那些需要臨時發起的也都需要在一開始就規劃好告知團隊所有成員，避免遇到問題找不到人或找到人沒有用的情況。

總結

以上是生活随笔為你收集整理的去哪儿PMO Head赵云：项目管理背后有哪些生存之道？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。