當接手一個甲方項目的時候，你是否會遇到手足無措的情況？面對一個項目，不知道從哪里開始？ 產品經理如何獨立從0-1著手甲方項目？本文總結了相關思路，希望對你有所幫助。

讓我們來看看，這個場景你有沒有很熟悉？

剛入手做甲方項目的時候，領導只是對我說了一句話，這個項目你來做；毫無疑問，我腦子里只有問號？又不想被別人看著很菜，啥也不懂的樣子，還得故作鎮定，其實心里慌得一批……

或許你對這個場景也似曾相識，這是一個順其自然的產品人的成長過程；從入行懵懵懂懂知道如何畫圖，到思考設計邏輯；從負責小模塊功能到0-1負責整個項目，從商業模式、數據分析，產品管理到項目管理，每一步都是產品人在摸索中成長的見證。

如果你正好是個產品經理，也正好處在開始負責甲方項目還無所適從的階段，或者做過項目沒有完整的思路，覺得項目做的毫無頭緒，大多被推著走等等，那這篇文章就是為你而寫的。如果你認真體會，將會很有幫助！

一、清晰的思路很重要

一般我們接手一個項目時，先不要急著完成領導布置的任務；任何時候，自己本身都要先給自己開一個【全局視角】，也就是用客戶或者老板思維做項目，這意味著登高望遠，運籌帷幄，可以很好幫助你做好每一步的決策和調整工作節奏。

這里提供一個著手做項目的全局思路，也是產品經理主要的職能工作：

1. 明確項目的背景、目標、其他影響因素；
2. 明確項目資源：相關干系人、生態方、產研團隊；
3. 明確項目計劃：立項、設計、開發、測試驗收各個環節節點目標以及整體計劃；
4. 明確解決方案、需求清單、需求范圍：去做實地調研，并輸出需求demo和終稿；
5. 其他關注點：跟進項目開發質量、測試驗收質量、推動支撐項目進度、與客戶、集成方等干系人保持溝通等。

以上思路為個人經驗之談，適用于各個待交付的甲方項目做參考。接下來我分別詳細來說明：

1. 明確項目背景、目標、影響因素

一個面向tob的甲方項目，需要提前了解清楚項目的基本情況：

這里就包括【背景】：

項目平臺是新建還是原平臺升級，與客戶側其他系統是否有交互和影響關系？

使用對象是誰？使用場景是？項目的價值(對于我方和客戶的價值）？項目使用目標是？（這里就包括領導人甚至政府、實際決策人、采購人、實際使用人等不同層級的目標訴求）

注：與toc不同，在tob項目里，采購人不一定是使用人，也不一定是決策人，可能只是付費方；使用人的訴求有時候沒那么重要，領導的決策和指標要求比較重要；有時候也不一定能接觸了解到使用人的訴求，視情況而定；總之，了解清楚不同干系人的期望訴求，對項目建立初步認知。

目標訴求來說：包含項目的建設需求（為什么要建設這個），功能需求（有什么好處），項目周期、以及交付的標準需求（交付驗收節點和驗收標準）。

影響因素來說：即項目目前存在的潛在風險是什么？包含項目當前所處階段，若涉及到硬件需要考慮硬件采購，以及數據管理、實施等需求部分是否已經界定？

以上可以直接問項目經理或者從現有項目資料里了解；在整個項目過程中也需要格外關注。

2. 梳理明確項目資源

做一個完整的大型項目，一定是大家抱團協作的過程；因此梳理現有的項目資源是第二步著重要做的；主要包含：

（1）都有哪些干系方，各自負責的部分是什么？

客戶側：付費方？使用方？決策方？驗收方？了解清楚各自的職能，建立通訊矩陣，幫助很快建立對客戶關系的認識，方便后期開展協調和項目推進工作。

生態側：生態側即圍繞整個項目的合作方都有哪些？一般大型項目都是總包-分包-子包的層級交付模式，所以了解合作的生態集成商，就包含都有哪些集成商？各自負責什么？與我方的協作關系？

注：一般甲方項目，我們常見于1v1定制化開發項目、或者做中間的分包商，1&N（即總包-分包-子包的多層級模式）來交付，視情況而定。

一般這里的集成商會包含：硬件集成商（物聯設備、硬件設備等）、軟件集成商（比如音視頻能力、AI、甚至子系統的分包等）、平臺集成商（比如數據庫、云平臺、apaas/iaas等用于部署、數據管理的需要）

以上這部分，可以通過項目經理來了解或者作為調研問題待定；通過這些問題，你就提前清晰了項目的關鍵干系方都有哪些了，這會大大提升后期協作。

（2）清楚我方產研團隊的建設情況

項目的人力分配情況，含前端、后端、UI、售前、解決方案、銷售各個節點的人員角色分配和組織協作流程；有的公司每一個角色都會配備對應的管理層，有的是并行管理多個角色；視各個公司組織架構而定，了解這些有助于后期有問題可以及時協調管理角色來調配資源，幫助產品側進度的推動。

一個項目正常的實施推進流程都會有這些環節：

01招投標中標/人脈/銷售推廣拿到項目—–02銷售打單簽單—-03項目投入立項——04售前進場（了解客戶訴求，有時候該環節也會前置，同銷售沒有明顯區分）—–05解決方案、產品經理進場（開展溝通調研、整體方案敲定）—–06產品經理設計階段（深度調研、細節方案敲定、簽字確認）——07UI、開發測試投入—–08項目節點驗收—-09項目交付初驗—-10項目交付終驗—-11售后運維投入

（3）梳理現有的資料

招投標文件、項目簽約合同，解決方案文件等等，形成初步調研方案，為下一步做準備。

3. 去實地做調研

（1）對外客戶側調研

調研前：梳理明確調研目標、方式、調研流程（一般公司都會有自己的調研要求，可根據實際需要進行調整）

主要思路就是：以整體的解決方案為主（這個售前環節已基本界定了），梳理大致的功能清單，然后做細節拆分，這一步就跟自己平時做產品設計是一樣的邏輯了，遵循從整體到細節；

比如現有已知要做一個智慧園區平臺，分為三期開發，本期開發目標是完成園區安防系統的建設，包含【實時監控】、【錄像回看】、【車輛人員預警】等部分

調研目標就可以為：01使用部門，使用人，平時的安防訴求和存在的漏洞都是什么？02平時是怎么做安防管理的？工作流程是？關注點是？03安防系統建設情況是？等等

方式：訪談溝通、結合一些調研工具、面向不同的調研對象做不同的調研溝通（由領導到下屬、由關鍵角色到次要角色，由主要業務到次要業務）來整體把控；在溝通過程中，盡量做方案的引導，因為大部分客戶并不知道自己需要什么？），這需要考驗你作為產品人的需求挖掘能力。

調研結果：隨時做好記錄和留存，必要時可進行客戶側的確認簽字，指導進一步的細節調研。

注：在調研時，同時收集客戶側的業務資料，文件，表格，數據資料等來輔助理解業務，做后期的產品設計；靠競品去理解差異化還是挺大的；競品挖掘也較困難。

最終，輸出原型設計demo。

注：提前也要梳理下自身公司的產品資源，比如之前項目是否做過類似功能，盡量快速進行復用；提高設計效率，不用從0開始設計。

（2）對內集成側調研

01需求交底：若作為項目中間的集成商，需要調研關注各個集成商與自身協作的部分，主要為軟硬件的集成和數據對接，接口調用等部分的細節調研溝通，看是否與原型demo設計功能不匹配，或者有缺失。

若有不匹配的部分，集成商需要調整重新定義接口內容，或者產品側需要做頁面功能設計方案的調整，來提前避免后期開發過程中的對接風險。

注：這部分需要拉通各個集成方的技術，做需求交底，產品側關注技術側的對接部分，如何協作，接口如何調用？這是一個絕佳的機會，可以理解功能實現的技術側邏輯。

02資料留存：除了溝通調研，也可以通過提前協調要求各自集成商提供接口文檔、演示環境等開發側、產品側需求資料，來熟悉集成需求。

若不需要對接，則可不考慮這部分內容。

調整完成后，原型設計也由demo到終稿的確認和簽字，每一步都需要盡量與客戶進行溝通確認，并留存簽字證明，來避免后期客戶需求隨意變更的風險。

4. 項目立項進入開發階段

這個階段，產品經理主要組織開發進行評審，支撐技術架構的敲定，同時會有一些prd等項目資料的編寫。

在正式投入前進行開發立項，立項后，產品與項目經理要著重關注開發各個里程碑節點進度，保證開發正常進行；過程當中，幫助解決各種障礙問題。

5. 測試驗收階段

產品在后期配合團隊內部、客戶做好節點驗收和培訓指導工作，以及一些資料的編寫等工作；視各個公司情況而定；有的公司這部分是配備有專業的驗收團隊，在保障客戶售后這塊還是不錯的。

二、重新定義項目中產品經理的定位

與自研產品不同，項目側的產品交付更考驗產品經理在整個環節中的溝通成本是否高效、問題響應速度是否足夠快、方案設計和需求調研是否足夠匹配客戶需要等多個衡定產品的高要求；需要產品經理懂產品、懂協作、懂溝通、懂業務、懂項目、懂集成、甚至懂技術、懂硬件。

不過在整個過程中，能很好地接觸到項目基層人員的訴求和反饋，與協作方多線程作業，如果有這樣0-1去獨立負責實戰項目的機會，還是很難得的，要多珍惜，多積累，多沉淀。

同時這種業務模式，也重新定義了產品經理，很有助于我們對身處不同角色的自己有一個更清醒的認知。

此外，也尤其需要意識到，雖然大部分項目是一次性交付制，但你做的產品方案對于客戶是否真的有價值，有意義？

我想，這應該是我們更值得深思的點。