主要功能第一位，滿意的效能，良好的互動性，可維護，可擴充套件，硬體相容性，跨平臺，適應新技術，安全性。到底說的什麼系統什麼專案，俺也不知道，俺就猜著說一說。

對很多產品經理而言，特別是身處創業團隊，往往都是一身挑幾職，產品和專案，理不清理還亂。從本文開始，以產品經理的視角看待專案，以及如何管理專案。

不管你身處大公司大環境，還是小公司創業團隊，相信你一定見過各種專案的問題，也見過很多失敗的案例。所謂成功的專案，一定是在有限的條件下，達成預期的目的。

想要管理好一個專案，必須尊重基本的客觀事實，對專案想要完成的功能範圍、所需要消耗的資源和時間成本，必須有一個清醒的認識；一顆對產品、對技術、對使用者的敬畏之心，是一個專案可能成功的基礎。

一、敬畏之心

對任何專案專案而言：

時間緊迫，活兒就只能湊合了；資源有限，人手不足，就往後拖吧；東西做不完，就只能趕緊砍內容，別弄那麼多。

範圍、時間、成本、質量，環環相扣，任何一個環節都帶來極大的挑戰，都可能引發極大損失。

老闆們都想專案完成的時間要快，完成的成本要低，完成後的質量要好。但能夠完美做到以上三個要素的專案，少之又少，我基本沒有見過。

反倒是，我見過最讓人感到震驚的狀況。

一種是多產品多專案的並行開發，最後發現沒有一個產品可用。還有一種就是引發極大的質量問題，造成重大的損失。而事實上，這都是可以預計和預防的。

有的時候，真是人心不足蛇吞象，想法足夠大膽，但投入捉襟見肘。要知道，任何罔顧基本規律的做法，必然遭受現實的打擊，造成不可估量的損失。

作為PM（專案/產品經理），一定要把這個金三角的關係牢記於心。

為了縮短專案時間，就需要增加專案成本（資源）或減少專案範圍；為了節約專案成本（資源），就需要減少專案範圍或延長專案時間；如果需求變化導致增加專案範圍，就需要增加專案成本（資源）或延長專案時間。

甚至，對質量的追求，都是一個度量的平衡。

不管你用什麼管理的方法方式，都不能繞過這一基本原則。

因此，在做預算的時候，必須面對現實，而且一定要掌握一個原則：預留一定的彈性空間。

PM應該用一種“悲觀”的視角看待專案，用樂觀的途徑去解決問題。

但事實上，PM們最容易犯的錯誤，就是在完工日期的預測上，為了討好客戶或者上司而過於樂觀，或者依據簡單的經驗資料來做出決定。

魚與熊掌之間，是一道三角難題。專案計劃是一個多次反覆的過程，也是一個不斷修正的過程，一定要時刻保持基本的敬畏之心，重複考慮各種因素的相互協調。

想要在三角之間找到一個平衡點，一定要弄清楚什麼是“好”，什麼是“快”，什麼是“便宜”。最忌諱的就是盲目的追求“快”，最可怕的是過於樂觀承諾“好”。

所以，對於產品（專案）經理而言：

第一條規則是：讓你的老闆認可和接受金三角法則；

第二條原則是：你始終在受限的環境下管理你的產品（專案）。

二、產品&專案的異同

“專案”這個概念，其實時刻都在我們身邊發生，火箭上天是一個專案，家庭裝修也是一個專案，他們共同的特性就是都有完全不同的開始、結束時間，也都產生完全不同的結果。

有的專案很長影響很大，甚至流芳百世，比如修建三峽。有的專案僅僅是你的私事，比如追求心中的女（男）神。

1. 產品 vs 專案，兩個世界的追求

隨著“網際網路思維”的遍地開花，我們看到一種現象，專案經理這一角色似乎越來越被削弱，產品經理大有取而代之的趨勢，甚至很多網際網路公司都沒有專職專案經理。

這是錯覺還是必然，兩者之間是否必然會被過渡？

但兩者其實是完全不應該有混淆和爭議。

產品，是指能夠供給市場，被人們使用和消費，並能滿足人們某種需求的任何東西（百科定義）專案，是為創造獨特的產品、服務或成果，而進行的臨時性工作（PMP定義）

這個定義已經很清晰的界定了一個產品是由N個專案組成的，產品輸出實際的東西，而專案對應產生產品的過程。也就是，產品經理對結果負責，專案經理對過程負責。

對一個企業來說，產品經理強調的是做一個什麼東西，透過什麼方式可以賣給誰，賺到多少錢。

專案經理考慮的是：需要多少時間，投入多少資源把東西做出來。

比如對面有一個山頭。

產品經理想的是：把旗幟插到對面山頭上去。插一面大旗還是小旗，是一面綠旗還是紅旗？是不是要用混凝土加固下，啥時候再發起下一個專案。專案經理想的是：怎麼去那個山頭，誰抗旗，抗多久，扛不動怎麼辦？至於旗幟插上去下一步怎麼辦，會不會倒，專案經理並不關心。

2.1.1 關注點不同：

產品經理的側重點向外，關注使用者和市場

市場機會和競爭格局使用者需求和使用者溝通

解決的是做什麼，賣給誰，賺誰的錢的問題。

專案經理的側重點朝內，關注資源和進度

資源調配資源效率專案進度

解決的是如何用有限的資源在限定的時間內，按照質量要求把東西做出來。

2.1.2 交付物不同

產品經理交付的是產品成果，最終交付給使用者的產品，關注產品的成本、質量和體驗，以及產品透過運營後轉化的企業收益。

專案經理交付的是管理成果，最終交付管理層的工作報告， 關注團隊計程車氣、效能、成本，以及企業整體的生產效率的提升。

2. 禍起蕭牆，根源到底在哪

理論上來說，專案經理和產品經理是不應該存在爭議的，但事與願違。

為什麼會出現“我到底是「產品經理」還是「專案經理」”的困惑呢？

首先，產品經理是搶著專案經理的飯碗而復興的。

在2010年前後，技術的普及也帶來了使用者的覺醒，傳統強調時間、進度的軟體工程的思維越來越具有侷限性，“寶潔的故事”事實上在重演，產品經理再次“橫空出世”，一直到後面的“人人都是產品經理”，是一種徹底的思維轉向。

也就是：產品經理試圖分解和分擔過去專案經理的職責和工作，把傳統軟體工程的專案概念，重新迴歸到產品本身來，從強調企業內的專案交付，轉為面向使用者的成果交付。

瞭解目前的“甲乙方專案”就能夠感受得到，交付給甲方的成果，其中之一就是龐大的過程資產，甚至試圖在儘可能的還原過程，“我就是按照你的思路和要求一步步做出來，你就老老實實的簽字畫押”吧。

所以，“甲乙方專案”、“外包專案”極容易脫離使用者需求，因為面向管理過程。

第二，產品經理和專案經理存在難以逾越的鴻溝

事實上，對使用者而言，一個產品是怎麼做出來的，他完全不關心。加了多少班，熬了多少夜他也不感興趣，他只關心這個產品是不是他想要的，有沒有價值則直接決定他是否願意付費。

你說你這個軟體可以約妹子，他就試試能不能約到妹子？你說你這個app買東西便宜，他就試試比別人便宜多少？除此之外“多說無益”。

對使用者來說，當物質豐富，使用者有可選餘地；他一定選擇他喜歡的，滿意的產品。只要他不開心，他除了解除安裝，還是解除安裝。

而傳統軟體工程思維，是與此相背離。

作為專案經理，如果一個東西，能夠按質按量按時的生產出來，是難以評判它的失敗。完美的過程管理，更是能帶來企業管理效率和人員能力的提升。遺憾的是，這些對使用者而言都是無效的。

產品經理來說，“雞飛狗跳”都是次要的，使用者開心比什麼都重要，所以他首要解決的是使用者、市場和競爭性的問題。而把內在的過程放在其次，“需求很簡單，怎麼做我不管”在一定程度上並沒有錯。

子非魚，使用者思維，和我們自己的思維是存在天然的鴻溝的。

站在地球上，我們始終看到的是太陽繞著我們轉；而站在月球，站在太空呢？

這也是以使用者為中心往往很難落地的一個原因——使用者思維是一種反向思維，反人性。

產品和專案在這個維度上存在對立關係。任何一個產品，越強悍越完美，越有可能讓使用者開心，但對企業來說就可能是災難，專案過程必須採取折衷的辦法。打造完美的產品，意味著投入更多的額外資源，形成事實上不必要的光環。

第三，產品經理和專案經理剪不斷，理還亂

對一個將軍來說，我只知道要拿不下這個山頭，留多少血我不感興趣。

但你並不能這麼做。

軟體開發過程中，就必須遵循基本的規則和規律，一個媽媽生一個寶寶要10個月，不能直接換算為10個媽媽生一個寶寶只要一個月。

當一個東西，決定要做的時候，就開始牽涉到複雜的資源、進度、質量和範圍的問題，而這四個形成一個互相角力。比如範圍擴大，就勢必引發進度和資源問題：

很多時候常能聽到並行，同步的字眼，多想想10個媽媽生寶寶的故事。

專案的過程有其複雜的機制和邏輯，同一個專案，在不同的模式下，極可能消耗的資源，進度，質量都會完全不一樣，專案的過程管理有科學的依據和成熟的體系。比如工作任務的分解、關鍵路徑的跟蹤等等。

產品經理其實非常的依賴專案過程的管理，不管這個角色被定義為專案經理還是自身的兼顧，都會對產品的工作帶來影響。

所以我們常常見到兩種產品經理，一種是以市場、使用者為天職的產品經理，看上去牛皮轟轟響，可東西沒出來，還有一種是事無鉅細過程很完美，但市場反饋差一點。

3. 相輔相成，方能互相成就

專案經理和產品經理的爭議嚴格來說並沒有意義。

個人的主張是，理應各司其事，特別是更加複雜的競爭環境下，想要真正的以使用者為中心，勢必進一步加強使用者的溝通和研發，把更多的精力放在對市場的靈敏反饋上。

同時，產品的過程管理也極為重要，它反過來反作用於使用者。清晰的業務方向，準確的市場反饋，以及完善的專案過程管理，才是真正無望而不利的。

對企業來說，小團隊可以產品經理兼任專案精力，在一定程度上需要分設不同的角色，應對更為激烈的市場競爭。

對產品經理和專案經理而言，彼此之間有清晰的定義，但從來都只有模糊的邊界。

三、專案環境決定成敗

作為一個產品經理，我們都曾心懷改變世界的夢想，期望一己之力為使用者帶來“無上”的價值。

現在的情況是，夢想談完了，模式說清了，想要搞出一個什麼東西也明白了，是要真正見到“產品”的時候了。

可是，你可能就那麼幾桿槍，怎麼辦？

磨刀不誤砍柴工，在真正親自下戰場操刀之前，關於專案的幾個核心概念一定要搞清楚。

你的身份現在應該切換到專案的角色。

不要再談理想，也不要再說體驗故事，先把東西做出來再說。

1. 專案生命週期

談產品和專案的時候有一個清晰的定義——專案一定要有開始和結束的時間。

所以，任何一個專案一定都一個生命週期，或長或短。任何一個專案，規模、複雜度都不同，但無論大小，都一定具備一個通用的生命週期結構：

啟動專案；組織和準備；推進具體的工作；結束專案。

也就是任何一個專案，都有一個通用的專案階段：

啟動——計劃&執行&控制——收尾

任何一個專案，最輕鬆的開始階段，反正啥都好說；最難受的是推進的過程，不是甩鍋就是撕逼，打架都正常；最尷尬的是收尾，對方不簽字的時候想要跪下去叫爺爺，收了錢老子就是天下第一。

這是一句玩笑話，但在“甲乙方”的專案過程中，司空見慣。

所以，專案開始的時候，醜話要說在前頭，開弓沒有回頭箭，開始沒講清楚的事情，到了後面就講不清楚。先做惡人，才可能有機會做好人。

不能實現的功能一定要拒絕，當前不能滿足的需求一定要明確，能達成什麼樣的指標一定清晰。

這個叫專案目標，所有後續的功能只能圍繞這個目標來執行，任何要推翻目標的專案行為，都不能被直接接手，必須啟動相應的機制和流程。

無數的專案證明，這是基本的定律。

專案目標和範圍是兩位一體的事情，只打30層樓的地基，就絕對不能去蓋50層的樓。

想要修改目標和範圍，一定要“重啟全新”的專案。

專案的坑往往就是在這個時候挖下來而不自知。

而後期接手的人，根本沒有任何辦法理清楚過去的糾葛矛盾，它會演變成一出N角戀——二手專案很容易爛尾。

失敗在所難免。

也就是：專案在開始和執行以及收尾的過程中，一定會要投入不同的資源，並催生各種需要控制管理的風險。越是早前不確定性最高，甚至隨時都可以關閉，但損失可能小，越後後期越難控制，損失往往無法估量。

在專案的早期，一定要儘可能的預知風險，比如做硬體的，一定要明白，可能結構不行，材料不能準時到位，做軟體的也一定要知道技術的瓶頸在哪裡，而且，軟硬體要及時同步。

遺憾的是，我們常能見到硬體裝置已經出來，軟體工程師還沒有入場，然後就發現各種“貨不對板”，彼此埋怨。

而硬體專案是不能像軟體一樣快速迭代甚至推倒重來。

3. 專案治理環境

專案早期的坑，最多是一個開胃菜，進入到專案之後，每個雷一旦引爆都可以逼停一個專案，這個環節最大的不可控因素就是人的因素——專案的環節因素。

沒有人可以逃過環境的影響，也沒有一種專案管理的方式可以超脫於外。

一個專案能否管好，不一定取決於你的努力，更多的是裁剪一個恰當的方式，符合這個環節的一種節制，和你所把控的那個節奏。

這是非常難的一件事，越是大的專案越難，在這種大專案裡面，對事不對人是絕對錯的，搞不定人一定搞不定這個專案。

環境因為包括組織的文化、結構、區域位置、行業標準、人事制度、授權機制，甚至法律法規等，任何一個專案都受其中的一些因素所影響。

在其中最具有直接影響力（殺傷力）的就是人，在專案裡面叫做干係人。

有的人對專案有積極影響，有的是消極影響。

比如拆遷經常會釘子戶，也有的時候，只要張三同意，李四就一定反對，諸如此類的情況比比皆是，所以搞清楚一個專案會涉及倒那些人以及什麼利益關係，比啥都重要，否則誰都可以是專案經理了，都可以發號施令了。

老實說，這個圖一定用都沒有，所謂分析專案干係人，其實就是找出那些對專案施加影響的人，特別是那些負面影響的人，背後捅刀子的人，得了便宜還賣乖的人，那些不按常理出牌的人，作為專案經理你可以給一個大家都可見的關係圖，但自己私下還要再準備一個。

所有的人和事，往往都是利益的事情。

搞清楚了關係，就要真正開始組織團隊了，這個叫專案團隊。

組成一個專案的人，都是各有所長（各懷鬼胎）的，作為專案經理就一定要分清楚職責職權，這裡面又會涉及團隊內部人的溝通，分享問題，以及各種獎勵懲罰機制。

這個圖是不是看著很官僚的樣子。

官僚就對了，這種結構的設計，就是為了保證專案組內的有序可控，對外有統一的出口，對內有穩定的次序。

不要隨便誇海口，更不要隨便瞎承諾，只有專案經理才可以享有足夠的權力，才能保證團隊內部的健康，和專案的健康，否則就變成一鍋粥。

每個人都有自己清晰的職責和許可權，“按部就班才可保平安”。

3. 專案過程資產

說完了，人和事。下一步就是物了。

如果說專案的環境因素可以讓一個專案萬劫不復。一旦管不好過程資產，那就一定黃土加身了。

這個資產，指的是一個專案在它整個生命週期裡面所有產生的，使用到的全文檔案文件，包括來自任何人，任何組織所涉及到的知識，檔案，記錄的。

為什麼常說專案裡面那麼坑，有一部分原因就是沒有管理好這些“資產”，比如產品經理輸出的原型，業務流程不清晰，還沒有存檔。所以，寫好一份文件的極為關鍵的，管理好這些文件是第二重要的是，詳見 ” 如何用Axure輸出高質量的PRD？”

在過程資產裡面還有一些特殊的內容需要特別投入精力：專案本身的文件。

專案計劃書、里程碑節點、變更控制流程、財務控制程式、缺陷管理程式等等，任何一個環節都足夠展開一個宏大的篇幅細說它的故事。