公司在想生存的同時擁有自己的產品，往往都會想到做一個自己的產品。希望把自己在行業積累的經驗融入到產品裡去，想象這樣的一個產品能夠在專案實施過程中減少實施週期增強企業自身的行業競爭力。然而事實是“多少公司在這麼做之後又費了很大力氣從專案成果中拉出一個產品來”，這句話是不是有點繞？簡而言之是：產品不是專案過程中重疊（即產品開發團隊與專案開發團隊二合一）完成的，而是專案完成後總結經驗重新設計出來的。

下面來談談我的理由：

1、“專案”的定義導致不允許這麼做

專案是在規定時間內在不超出預算範圍的情況下，保質保量的完成客戶方需要的專案成果。在實際的專案執行過程中，專案資源往往都是有限的，在不超出預算範圍和時間要求的情況下，一般都會選擇犧牲一點點專案質量，這也是“60分原則”出現的原因。但是我們想想，在不犧牲專案質量的情況下，專案實施過程中在實施方法的選擇上都會是“怎麼簡單怎麼來”，這個邏輯就和產品設計邏輯相悖了。

你可以反駁我說：“由於要做產品，這是公司戰略性專案，我們不計成本也要完成產品的研發”。

專案管理鐵三角，三控物件：時間、成本、質量。在時間、質量固定的情況下，成本不計，這麼分析再複雜的工作應該都可以完成。實際上是這樣嗎？做這種假設的前提是專案需求沒有變化。然而，在實際實施過程中，客戶的需求千奇百怪，很多時候是專案經理與客戶方長期溝通妥協的結果，你在做這個專案之前是不可能100%預料到的。遇到這種情況，專案上的解決思路是用最簡單、最快速的方法解決；產品上的解決思路是，這類問題如果再出現還會有多少種可能，採用何種方法何種技術可以適應這種變化。孰難孰易很容易想到。我以前遇到過同類事情，為了專案驗收，到最後誰都抵不過這個目標，產品研發的同事先按最簡單的方式開發交付，程式碼庫拉分支，到了最後發現每個專案都有一個分支，那還是做產品嗎？為什麼會這樣呢？因為公司專案不會只有一個，但產品研發團隊只有一支。產品研發團隊哪裡還有精力沉下心來研發產品，都跑去專案組當專案開發人員去了。這是不是和開始想象的結果不一樣呢？

2、產品的持續迭代依賴於專案的檢驗結果

前面提到，產品是在專案的基礎上提煉的結果，專案上驗證，產品中加入。產品的設計考慮更多的不是使用什麼高深的技術，而是業務的表現形式和操作流程。一個功能該如何設計，是否好用，只有用了才知道，用的過程中不斷調整，直到最後定型才會放到產品中去，否則只會跟著“每一個專案”不停的修改。

同一個產品給不同的使用者使用必然會遇到同類型的問題。客戶懂業務、專案組懂軟體開發，初次或者說是前幾次與客戶的溝通可能在解決同一問題的方法上會不一樣，而作為專案經理在經歷過多個專案後，在同類問題的業務處理邏輯應該也會形成自己的判斷，融入到產品，推向客戶試錯，這就會形成產品迭代。這裡需要注意的是，產品的迭代不是需求不清的迭代，而是最佳化業務處理邏輯的迭代。否則，產品團隊將失去產品研發的思考能力。

什麼時候做產品合適？做產品要做那些提前的考慮呢？

做產品一定不要讓產品定義缺位，哪怕是使用者需求爛熟於心也必須寫出來。

那什麼時候做合適呢？做產品要做那些提前的考慮呢？這裡提出4點：

1、開始著手產品研發時間

完成了至少3個以上專案之後才可以開始著手產品研發，產品研發不是對之前專案做顛覆性的修改，是在以前專案的基礎上，在實現方式上的改進。

2、專案交付後再更新產品

專案中的需求變化是必然的，一定要在專案完成後並得到“使用者”的反饋後，記得是“使用者”而不是客戶。新的需求合併進產品一定要做評估，業務上的評估和技術上的評估，評估確認後再合併入產品。

3、產品研發團隊獨立於專案之外，產品經理跟隨專案實施團隊

產品研發團隊一定要和專案開發團隊分離。一方面，融合的最大弊端是對需求理解的不統一造成最終決策難；其次是產品開發思路於專案開發思路不同，讓產品開發團隊看到無序的需求，不利於產品的提煉。產品的提煉還是讓專案經理和開發負責人來接觸。

4、專案完成後的覆盤一定做

當公司專案多了以後，每個專案經理只會負責自己的專案，而產品的提煉是公司級的，所以每一個專案經理在實施專案前一定要安排覆盤任務，要求專案經理關注業務需求和專案實施的重要過程，覆盤時重點敘述。

專案覆盤會議除了專案組成員外，產品經理和開發負責人必須參與，當然其他專案經理也參與會是提升全員實施能力的一個辦法。

最後重提“在專案過程中完善產品不現實”，會導致：

1、不計成本不會促進產品形成，只會是資源浪費；

2、專案與產品的開發存在於不同的維度上，強行拉在一起只會是專案照常實施，產品從頭再來。