編輯導讀：產(chǎn)品人的工作，就是在一個一個項目中度過的。不同的產(chǎn)品人，對項目的認知程度不同。本文作者身為一個有10年工作經(jīng)驗的產(chǎn)品人，對產(chǎn)品和項目有自己的思考，從七個方面進行了深入的分析，希望對你有幫助。

筆者09年開始實習至今，分別經(jīng)歷了互聯(lián)網(wǎng)產(chǎn)品→定制化項目→項目型產(chǎn)品三個階段，在第一次轉(zhuǎn)型時由于只是開發(fā)人員，對于轉(zhuǎn)型的理解并沒有那么深刻；在第二次轉(zhuǎn)型時，由于已是負責人，需要站在更高的層面上思考以及轉(zhuǎn)變，對于轉(zhuǎn)型之痛深有感觸，對于轉(zhuǎn)型過程中所走的彎路也印象尤深，故以此文來記錄自己的理解，敘述的內(nèi)容帶有工作領(lǐng)域的局限性，也希望與大家共同探討。

前言：

在開始撰文之前，先以福特創(chuàng)始人Henry Ford的一句話（真實性存疑）作為開頭，此句也成了我在產(chǎn)品設(shè)計時的座右銘，“If I had asked people what they wanted, they would have said faster horses.”。

短短一句話，其實已經(jīng)道盡產(chǎn)品思維的特性，產(chǎn)品越深入，對其越是感同身受。接下來，筆者將從定義、思維方式、團隊構(gòu)成、需求來源、商業(yè)模式、版本分支、配套工具等方面分享筆者認知中產(chǎn)品與項目之間區(qū)別和聯(lián)系。

01 定義

1. 項目是什么

有學習過PMP或者高項的人，應(yīng)該對于項目的定義是再熟悉不過了——項目是為創(chuàng)造某種獨特的產(chǎn)品或服務(wù)所做出的一次性的努力，其具備的幾個特征： 目標性；獨特性； 臨時性；漸進明細。

落到我們實際的工作中，軟件項目的本質(zhì)就是為了實現(xiàn)合同約定的建設(shè)內(nèi)容或用戶方的需求，通過程序開發(fā)\部署的方式將其以軟件的形式實現(xiàn)，并將其與交付物一并提交給用戶。

2. 產(chǎn)品是什么

對于產(chǎn)品的定義，百科中給出一段相對繞口的描述——產(chǎn)品是指能夠提供給市場，被人們使用和消費，并能滿足人們某種需求的任何東西，包括有形的物品、無形的服務(wù)、組織、觀念或它們的組合。

如果用更加貼近于軟件開發(fā)方式來描述的話，那么軟件產(chǎn)品是面向解決業(yè)務(wù)場景需求，持續(xù)迭代，并可在多個項目中被復(fù)用的一類具有通用性的軟件形態(tài)。

筆者所在的公司中，存在著兩種不同形態(tài)的產(chǎn)品，一種為業(yè)務(wù)應(yīng)用類產(chǎn)品，其專注于解決業(yè)務(wù)場景方面的需求，并可在多個項目中進行應(yīng)用，如電子證照、政務(wù)服務(wù)辦理等；另外一種為底層組件類產(chǎn)品，其業(yè)務(wù)屬性較弱，對于通用屬性進行高度提煉并對業(yè)務(wù)進行拆解，如用戶中心、表單中心等。

舉一種實際生活中的例子描述這兩者的區(qū)別：項目就是一次性杯子，目的是為了解決單次喝水的需求，目標明確且一次性；而產(chǎn)品就是陶瓷杯或者水杯，面向的場景是解決多次喝水場景的需求，而且還會根據(jù)喝水、喝咖啡、喝酒等不同場景衍生出不同的子產(chǎn)品。

02 思維方式

在筆者從項目負責人轉(zhuǎn)變成產(chǎn)品負責人時，把思維方式從項目級別提升到產(chǎn)品級別是最大的挑戰(zhàn)，兩者之間的區(qū)別與聯(lián)系很容易能讓人感覺到迷惑與無從選擇，就其內(nèi)容而言，兩者沒有高下之分，但如果應(yīng)用錯了場景，就容易把簡單的事情復(fù)雜化，而把多層次的內(nèi)容應(yīng)付了之。下面談?wù)勴椖克季S與產(chǎn)品思維之間的差異。

1. 項目思維

在大多數(shù)傳統(tǒng)軟件開發(fā)公司中，基本上都是秉持著項目型思維在進行著公司的日常工作及軟件的研發(fā)，那究竟什么是項目型的思維呢？

所謂項目思維，其思考的方式為——“完成”，其目標為——“任務(wù)”。

項目思維重點關(guān)注如何實現(xiàn)任務(wù)的完成，從時間、成本、范圍、質(zhì)量等多個相關(guān)指標上推動工作的進展，實現(xiàn)任務(wù)交付物的產(chǎn)出。具體到實際工作中，因為重點在于完成任務(wù)，項目組成員所有的工作都在圍繞著項目的成功交付及驗收推進，當接到項目需求時，考慮的是如何完成這項需求，完成的時間、成本，以及如何能夠更快且保質(zhì)地交付到用戶方。

2. 產(chǎn)品思維

相對于項目思維，產(chǎn)品思維，其思考的方式為——“透視”，其目標為——“價值”。

產(chǎn)品思維重點關(guān)注于挖掘有效的根源性需求，從業(yè)務(wù)場景的角度構(gòu)建解決方案，提升產(chǎn)品價值及競爭力。具體到實際工作中，就是我們在進行產(chǎn)品構(gòu)建過程中，重點不是在完成增刪改查功能的堆疊，而是去透視需求背后的業(yè)務(wù)場景，什么樣的應(yīng)用痛點驅(qū)動需求的產(chǎn)生，如何去構(gòu)建解決方案可以更好解決需求，提升產(chǎn)品價值并且復(fù)用到多個項目中。

項目思維，類似于被動驅(qū)動，以完成任務(wù)為目標；而產(chǎn)品思想，則是自我驅(qū)動，以提升產(chǎn)品價值為目標。

舉一個在實際工作中曾經(jīng)發(fā)生的案例來說說兩者之間的區(qū)分：

1）用戶中心

我們在某個用戶中心分支的時候接到一個需求——”在部門屬性中添加中央業(yè)務(wù)指導部門代碼和中央業(yè)務(wù)指導部門名稱兩個屬性，屬性對應(yīng)于國家某平臺接口，需要在xx前完成“， 明確的用戶需求以及時間節(jié)點要求，由于當時時間趕且團隊缺少產(chǎn)品經(jīng)理，我們小伙子就直接將這個需求在分支上實現(xiàn)了，并按時提交給對應(yīng)的需求提出方。到此為止，這就是項目思維，以完成任務(wù)為目標。

在后續(xù)對于產(chǎn)品項目需求進行歸納中，我們發(fā)現(xiàn)了此需求，從表面上看，這只是一個增加兩個部門屬性的需求，但深入去分析挖掘后，可以發(fā)現(xiàn)這個業(yè)務(wù)指導部門屬性的出發(fā)點是為了解決政府部門橫向管理過程中條線管理缺失，實現(xiàn)業(yè)務(wù)部門的垂直化管理，如公安業(yè)務(wù)線、煙草局業(yè)務(wù)線等；而且省里面也會有實際的應(yīng)用情況，縣一級的一個部門，對應(yīng)的上級部門可能是多個，比如mh縣文體旅局對應(yīng)的上級部門分別是fz市文旅局+fz市體育局，在具體的執(zhí)行中，是不同的處室對應(yīng)到不同的條線管理；在用戶中心使用上，也會有按照條線展示部門、用戶、通信錄等需求。所以在最終的產(chǎn)品設(shè)計中，我們在主線版本部門中擴充所屬條線屬性，并且增加條線管理，調(diào)整了相應(yīng)對外服務(wù)接口。透過現(xiàn)象看本質(zhì)，通過業(yè)務(wù)場景解決方案提升產(chǎn)品價值，這就是產(chǎn)品思維。

03 團隊構(gòu)成

產(chǎn)品和項目在定位和目標的區(qū)別，也很直觀體現(xiàn)在團隊構(gòu)成上，包括對于團隊人員素質(zhì)相關(guān)要求上，建立好的團隊結(jié)構(gòu)能夠讓工作進展得更加順利。

1. 項目團隊

項目團隊一般會有以下必備成員：項目經(jīng)理、技術(shù)主管、需求分析員、開發(fā)工程師、測試工程師、客服人員（按合同要求）。

很多實際的項目中，一人多職情況較為普遍，項目經(jīng)理往往還兼著技術(shù)主管或者需求分析員的職務(wù)，而一些開發(fā)工程師也兼著需求分析員或客服人員的角色，而測試工程師大部分是由公司測試部門在關(guān)鍵時間節(jié)點上介入項目現(xiàn)場的。

2. 產(chǎn)品團隊

產(chǎn)品團隊一般會有以下必備成員：產(chǎn)品負責人、架構(gòu)師、產(chǎn)品經(jīng)理、交互設(shè)計師、開發(fā)工程師、測試工程師、配置工程師、項目對接人員。

很多人會把產(chǎn)品經(jīng)理跟需求分析員的職責定位混淆了，其實兩者的區(qū)別很明顯，需求分析員是帶著項目思維的人員，適用于項目的推動；而產(chǎn)品經(jīng)理就是要用產(chǎn)品思維帶著產(chǎn)品持續(xù)往前走，提升產(chǎn)品價值的人員。

在團隊構(gòu)成穩(wěn)定性的趨勢上來說，產(chǎn)品團隊相對于項目團隊較為穩(wěn)定，項目團隊由于項目進展的情況，有可能會出現(xiàn)中間某一階段需要大量人員，而其他階段只需要少量人員繼續(xù)推動項目的進展；產(chǎn)品團隊由于產(chǎn)品的持續(xù)迭代、產(chǎn)品在項目中應(yīng)用的持續(xù)增長，所以正常情況下產(chǎn)品團隊不會出現(xiàn)人員的大幅變動。

在相同崗位的成員素質(zhì)要求上，兩者也不盡相同。項目團隊對于成員的要求為能夠快速進入狀態(tài)，具備較高的承壓能力，除了本職工作外，還能夠兼任一些其他崗位的職責，比如開發(fā)工程師往往還需要兼著需求分析的工作；產(chǎn)品團隊對于成員的要求是本職工作需要精，知其然且知其所以然，比如開發(fā)工程師需要去考慮代碼的執(zhí)行效率、代碼并發(fā)能力、代碼的容錯性設(shè)置、代碼規(guī)范等內(nèi)容，通過自身專業(yè)上的深入提升產(chǎn)品的質(zhì)量。

04 需求來源

定位上的不同、思維方式上的不同，也直接決定了需求來源的不同，清晰地區(qū)分項目需求與產(chǎn)品需求，才能避免在工作開展中陷入是是而非的矛盾與麻煩中。

1. 項目需求

項目以客戶的需求為驅(qū)動，通過用戶訪談、問卷調(diào)查、可用性測試等多種方式明確需求內(nèi)容及邊界，并以書面\其他記錄的形式協(xié)同客戶對于需求進行評審和確認，項目組根據(jù)明確后的需求進行定制化開發(fā)。項目需求在本質(zhì)上，其實也就是文章開頭福特那句話的縮影，用戶角度的需求就是faster horses。

就其整體而言，項目需求的特點很明顯，來源明確、范圍明確、工作量明確。

2. 產(chǎn)品需求

產(chǎn)品以價值提升為驅(qū)動，需求圍繞產(chǎn)品價值提升而展開，需求來源是多渠道的，國家及行業(yè)政策、市場需求、用戶需求、項目需求等等；需求調(diào)研也是多樣化的，政策分析、競品分析、問卷調(diào)查、頭腦風暴、用戶反饋等等。

產(chǎn)品在需求管控上，更加趨向于敏捷模式，小步快跑，允許試錯，以市場接受度決定需求的正確與否。

項目需求本質(zhì)上是獲取到“faster horses”信息，而產(chǎn)品需求本質(zhì)上是獲取到“faster”信息，并且考慮除了“horse”之外，還有其他什么方法措施可以滿足這類需求。

在實際工作中，很容易存在幾個認知方面的誤區(qū)：

1）把項目需求當做產(chǎn)品需求去實現(xiàn)

項目應(yīng)用是產(chǎn)品非常重要的一個需求來源，因為項目需求來源于最終使用軟件產(chǎn)品的用戶，反映了用戶在實際業(yè)務(wù)場景中的應(yīng)用痛點、行業(yè)性需求等多方面因素。

但這并不是說項目需求等同于產(chǎn)品需求，項目需求為項目所服務(wù)，具有項目區(qū)域性、業(yè)務(wù)性以及臨時性等特征；在將項目需求沉淀為產(chǎn)品需求時，需要全面衡量可復(fù)用度、價值提升程度、已有業(yè)務(wù)場景破壞度、潛在隱性需求等等多維度影響因子，在此基礎(chǔ)上對于項目需求進行產(chǎn)品適應(yīng)性改造之后，才能夠吸納到產(chǎn)品需求中。

2）產(chǎn)品不介入到項目實際業(yè)務(wù)需求

結(jié)合前面的描述，項目工作內(nèi)容不等同于產(chǎn)品工作內(nèi)容，在實際的工作開展中，需要理清產(chǎn)品與項目之間的界限，避免產(chǎn)品做著做著變成了在做項目。

但這并不意味著可以矯枉過正，不能說產(chǎn)品版本發(fā)布且提供了二開機制支持后，在項目落地過程中的個性化改造就是屬于項目組的事情，與產(chǎn)品團隊沒有關(guān)系。

為了長期的戰(zhàn)略考慮，將產(chǎn)品團隊與項目實施交付團隊職能劃定是必然的，但是產(chǎn)品團隊與項目團隊需要建立良好的溝通渠道，包括前期的產(chǎn)品方案提供、產(chǎn)品部署操作、產(chǎn)品升級操作等工作，還包括落地后的新增需求分析、解決方案指導、功能二開協(xié)同等，產(chǎn)品團隊需要主動擁抱項目需求，以實戰(zhàn)檢驗產(chǎn)品的優(yōu)劣，通過應(yīng)用成效進一步完善產(chǎn)品自身，定期對于項目需求輪詢并歸納到產(chǎn)品需求，才能避免閉門造車還自我感覺良好，也避免由于產(chǎn)品團隊和項目團隊的沖突導致產(chǎn)品無法收集到項目需求。

3）未聚焦產(chǎn)品業(yè)務(wù)，無限制擴展產(chǎn)品地圖

需求蔓延不止是在項目中需要去預(yù)防管控的，同樣在產(chǎn)品中也是存在類似的問題，而且由于產(chǎn)品需求的不確定性，需求蔓延的可能性更加突出。

在產(chǎn)品推進過程中，產(chǎn)品經(jīng)理的首先要務(wù)就是要十分明確產(chǎn)品的定位、產(chǎn)品所要解決的業(yè)務(wù)場景，在此原則上對于產(chǎn)品需求進行分析，分析切記不能淺嘗輒止，也不能偏離主線業(yè)務(wù)無節(jié)制蔓延。

例如在財務(wù)輔助系統(tǒng)中，工程類付款涉及到工程所屬節(jié)點以及核算的結(jié)果、人工成本報銷單涉及到整體人力資源薪酬的核算與發(fā)放、付款涉及到與銀企系統(tǒng)的對接對賬等，但是這并不是說我們產(chǎn)品也要覆蓋到工程管理、人資管理、銀企等業(yè)務(wù)，而應(yīng)該是聚焦在我們產(chǎn)品的主業(yè)務(wù)上。

產(chǎn)品需求需要決定做什么，但更要決定不做什么。

05 商業(yè)模式

天下熙熙皆為利來，天下攘攘皆為利往，拋開我們在可研社會效益中寫到的那些偉光正，最終目的還是要實現(xiàn)公司效益的增長，但產(chǎn)品與項目創(chuàng)造效益的方式不盡相同。

在項目方面來說，談不上商業(yè)模式，更加側(cè)重的是如何降本增效，以項目驗收為目標，采用多種可取的方法降低項目的人力投入、提高項目組成員的生產(chǎn)效率、加快項目驗收時間節(jié)點，縮短公司的投資回報周期、并提高投資回報率。

而產(chǎn)品方面來說，承載著公司更高的期望值，追求溢價以及長期收益，通過戰(zhàn)略投入加碼未來，是公司進行產(chǎn)品化的根本動力。所以在進行產(chǎn)品規(guī)劃設(shè)計的時候，需要考慮清楚商業(yè)模式的方方面面，包括產(chǎn)品成本結(jié)構(gòu)、產(chǎn)品收入結(jié)構(gòu)、產(chǎn)品定價策略、產(chǎn)品投資回報周期等信息，簡單點說，就是需要能讓人相信產(chǎn)品能夠產(chǎn)生效益，而不是反向操作浪費資源。

在進行表單中心產(chǎn)品規(guī)劃時，我們就表單中心的商業(yè)模式進行以下思考：

• 預(yù)估產(chǎn)品研發(fā)投入的人力、時間，產(chǎn)品落地項目投入所需成本——成本結(jié)構(gòu)

• 是否采用云方式提供服務(wù)還是以私有化部署提供服務(wù)——成本結(jié)構(gòu)

• 表單中心市場銷售能力預(yù)估——收入結(jié)構(gòu)、投資回報

• 是否按照功能列表、授權(quán)數(shù)量進行可定制化銷售——定價策略

• 針對不同應(yīng)用級別產(chǎn)品的銷售報價、實施運維報價——定價策略

如果產(chǎn)品研發(fā)之前沒有經(jīng)過全面的商業(yè)模式論證，模糊的商業(yè)模式不止是讓產(chǎn)品未來打了個問號，也讓公司的銷售無從下手。

06 版本分支

由于項目是一次性的產(chǎn)品，所以其版本管理相對來說比較簡單明了，并不涉及到復(fù)雜的版本迭代及分支管理，在此文中我們不討論項目的版本及分支管理。

由于產(chǎn)品會在多個項目中進行應(yīng)用、項目應(yīng)用中二開功能存在可復(fù)用、項目應(yīng)用中二開功能屬于個性化定制等等多種情況，產(chǎn)品的版本及分支版本管理制度，對于產(chǎn)品團隊來說，直接決定了后續(xù)的產(chǎn)品運維的工作量。當然，在具體的管理制度制定方面，屬于仁者見仁智者見智，沒有標準答案。

以筆者所負責部的產(chǎn)品主線版本以分支版本管理制度側(cè)重點與大家分享：

1）一主線版本、多個長期演進版本、N個項目分支

熟悉Java開發(fā)的同學應(yīng)該對此策略極其熟悉，我們采用的就是跟JDK版本管理相似的策略。

一主線版本：

在產(chǎn)品的演進上，保持著產(chǎn)品只有一個主線版本，以主線版本作為產(chǎn)品的最新發(fā)布版本，按照版本規(guī)劃內(nèi)容定時進行封版發(fā)布。主線版本與產(chǎn)品內(nèi)容規(guī)劃保持一致，會根據(jù)產(chǎn)品演進的情況增加新功能、現(xiàn)有功能的優(yōu)化改造、現(xiàn)有功能的移除等。

多長期演進版本：

在主線版本的基礎(chǔ)上，我們還會根據(jù)項目應(yīng)用情況，選擇項目應(yīng)用較多的版本進行持續(xù)的長期演進工作，側(cè)重于bug修復(fù)、功能完善的支撐工作。

N項目分支：

由于項目難以避免存在個性化的需求，我們基于對應(yīng)產(chǎn)品版本建立項目代碼分支，并獨立進行項目分支建設(shè)。

如在API網(wǎng)關(guān)產(chǎn)品中，我們存在的主線版本，目前已演進到3.2，但同時我們?nèi)栽趯椖繎?yīng)用較多的1.3版本進行長期演進支撐工作。

2）產(chǎn)品發(fā)布及項目應(yīng)用策略

在產(chǎn)品迭代上，采用分版本的迭代策略，根據(jù)研發(fā)節(jié)奏保持兩個月或者三個月一個大版本發(fā)布，小版本根據(jù)實際情況進行發(fā)布，發(fā)布的同時并將升級更新履歷日志同步到產(chǎn)品的在線文檔中，供其他使用產(chǎn)品人員實時查看了解。

在新項目的使用上，默認以最新的版本版本分發(fā)。但這并不是絕對的操作，也會根據(jù)項目背景、項目所需功能、項目其他產(chǎn)品版本信息等，針對性選擇之前的某個版本進行應(yīng)用。

在產(chǎn)品的應(yīng)用上，產(chǎn)品經(jīng)理或者配置人員管理好產(chǎn)品應(yīng)用的臺賬，包括項目情況、產(chǎn)品版本等核心信息，方便后續(xù)升級或者問題追溯。

3）不主動升級策略，重大安全問題主動升級

對于項目所使用的產(chǎn)品版本，采取不主動升級策略，只在采用的版本上進行適應(yīng)性升級，而非跟隨產(chǎn)品迭代步驟進行同時升級，避免由于升級導致項目建設(shè)范圍不匹配或者引發(fā)其他潛在的問題。

對于協(xié)同的產(chǎn)品，比如作為政務(wù)中臺核心支撐的API網(wǎng)關(guān)產(chǎn)品，我們在產(chǎn)品升級的同時也會主動通知對應(yīng)的產(chǎn)品部門，保證作為一體化產(chǎn)品對外版本的一致性。

不過在涉及重大安全問題或者重大缺陷時，我們會采取主動升級策略，告知對應(yīng)的項目組/產(chǎn)品組存在的問題及發(fā)送對應(yīng)的補丁進行修復(fù)。

4）版本平滑升級策略

其實版本平滑升級策略，不管是產(chǎn)品還是項目，都是很基本的要求。對內(nèi)，需要能夠支撐產(chǎn)品自身的平滑升級，既要能夠從1.2升級到1.3，也需要能夠支持1.2升級到2.0；對外，需要能夠保持接口的延續(xù)性，能夠保證產(chǎn)品的升級對于現(xiàn)有的功能、現(xiàn)有的接口沒有影響，而不是每次更新，周邊對接系統(tǒng)都要同步修改。

07 配套工具

公司往產(chǎn)品化方向發(fā)展的時候，很多以前看似可有可無的人力投入就會一下子變得特別的突出，比如用戶中心產(chǎn)品安裝部署，除了自身應(yīng)用安裝之外還涉及到JDK、MySQL、zookeeper、Redis等中間件，且還需要對于配置參數(shù)、系統(tǒng)參數(shù)進行優(yōu)化調(diào)整，正常項目組具有編程人員經(jīng)驗對產(chǎn)品進行部署，平均需要一天半才能完整部署一臺服務(wù)器。按照目前用戶中心產(chǎn)品五十多個項目應(yīng)用數(shù)來說，這個人力投入就是極其可觀的數(shù)量，針對此情況，我們采用基于ansible的一鍵式部署方案，十幾分鐘就可將用戶中心部署完畢，大幅度減少產(chǎn)品部署的人力成本。

一個優(yōu)秀的產(chǎn)品，除了需要考慮產(chǎn)品自身的發(fā)展之外，也需要去為產(chǎn)品的應(yīng)用推廣進行優(yōu)化，降低產(chǎn)品應(yīng)用推廣實施的難度及工作量。

1）售前部門

產(chǎn)品白皮書、產(chǎn)品建設(shè)方案、產(chǎn)品宣傳彩頁、產(chǎn)品報價方案、著作權(quán)、專利等有利于售前部門推廣產(chǎn)品的工具。

2）交付部門

一鍵式部署支撐、產(chǎn)品培訓視頻、產(chǎn)品二開機制方案、產(chǎn)品使用手冊、產(chǎn)品運維手冊等有利于項目組更好進行產(chǎn)品交付實施的工具。

08 總結(jié)

筆者自16年底開始轉(zhuǎn)型負責產(chǎn)品之后，業(yè)務(wù)類產(chǎn)品及組件類產(chǎn)品均有涉獵，有成功也有失敗，目前部門所負責的四個產(chǎn)品已在全國七十多個項目落地應(yīng)用，支撐中臺、大腦、省市縣多級應(yīng)用，并為外部系統(tǒng)提供穩(wěn)定可靠賦能。

此文是對于自己最近幾年轉(zhuǎn)型心得體會的一個總結(jié)，希望能給在轉(zhuǎn)型產(chǎn)品路上迷茫的人一絲幫助，產(chǎn)品與項目既有聯(lián)系也有區(qū)別，把握好這里面的微妙關(guān)系，利用產(chǎn)品思維打造具有核心競爭力的解決方案，創(chuàng)造car。

【轉(zhuǎn)載說明】   若上述素材出現(xiàn)侵權(quán)，請及時聯(lián)系我們刪除及進行處理：[email protected]