中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

前言：

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

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

01 定義

1. 項目是什么

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

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

2. 產品是什么

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

如果用更加貼近于軟件開發方式來描述的話，那么軟件產品是面向解決業務場景需求，持續迭代，并可在多個項目中被復用的一類具有通用性的軟件形態。

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

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

02 思維方式

在筆者從項目負責人轉變成產品負責人時，把思維方式從項目級別提升到產品級別是最大的挑戰，兩者之間的區別與聯系很容易能讓人感覺到迷惑與無從選擇，就其內容而言，兩者沒有高下之分，但如果應用錯了場景，就容易把簡單的事情復雜化，而把多層次的內容應付了之。下面談談項目思維與產品思維之間的差異。

1. 項目思維

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

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

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

2. 產品思維

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

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

項目思維，類似于被動驅動，以完成任務為目標；而產品思想，則是自我驅動，以提升產品價值為目標。

舉一個在實際工作中曾經發生的案例來說說兩者之間的區分：

1）用戶中心

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

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

03 團隊構成

產品和項目在定位和目標的區別，也很直觀體現在團隊構成上，包括對于團隊人員素質相關要求上，建立好的團隊結構能夠讓工作進展得更加順利。

1. 項目團隊

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

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

2. 產品團隊

產品團隊一般會有以下必備成員：產品負責人、架構師、產品經理、交互設計師、開發工程師、測試工程師、配置工程師、項目對接人員。

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

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

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

04 需求來源

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

1. 項目需求

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

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

2. 產品需求

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

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

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

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

1）把項目需求當做產品需求去實現

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

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

2）產品不介入到項目實際業務需求

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

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

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

3）未聚焦產品業務，無限制擴展產品地圖

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

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

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

產品需求需要決定做什么，但更要決定不做什么。

05 商業模式

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

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

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

在進行表單中心產品規劃時，我們就表單中心的商業模式進行以下思考：

• 預估產品研發投入的人力、時間，產品落地項目投入所需成本——成本結構
• 是否采用云方式提供服務還是以私有化部署提供服務——成本結構
• 表單中心市場銷售能力預估——收入結構、投資回報
• 是否按照功能列表、授權數量進行可定制化銷售——定價策略
• 針對不同應用級別產品的銷售報價、實施運維報價——定價策略

如果產品研發之前沒有經過全面的商業模式論證，模糊的商業模式不止是讓產品未來打了個問號，也讓公司的銷售無從下手。

06 版本分支

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

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

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

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

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

一主線版本：

在產品的演進上，保持著產品只有一個主線版本，以主線版本作為產品的最新發布版本，按照版本規劃內容定時進行封版發布。主線版本與產品內容規劃保持一致，會根據產品演進的情況增加新功能、現有功能的優化改造、現有功能的移除等。

多長期演進版本：

在主線版本的基礎上，我們還會根據項目應用情況，選擇項目應用較多的版本進行持續的長期演進工作，側重于bug修復、功能完善的支撐工作。

N項目分支：

由于項目難以避免存在個性化的需求，我們基于對應產品版本建立項目代碼分支，并獨立進行項目分支建設。

如在API網關產品中，我們存在的主線版本，目前已演進到3.2，但同時我們仍在對項目應用較多的1.3版本進行長期演進支撐工作。

2）產品發布及項目應用策略

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

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

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

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

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

對于協同的產品，比如作為政務中臺核心支撐的API網關產品，我們在產品升級的同時也會主動通知對應的產品部門，保證作為一體化產品對外版本的一致性。

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

4）版本平滑升級策略

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

07 配套工具

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

一個優秀的產品，除了需要考慮產品自身的發展之外，也需要去為產品的應用推廣進行優化，降低產品應用推廣實施的難度及工作量。

1）售前部門

產品白皮書、產品建設方案、產品宣傳彩頁、產品報價方案、著作權、專利等有利于售前部門推廣產品的工具。

2）交付部門

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

08 總結

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

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

本文由 @隨 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議