当接手一个甲方项目的时候，你是否会遇到手足无措的情况？面对一个项目，不知道从哪里开始？ 产品经理如何独立从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去独立负责实战项目的机会，还是很难得的，要多珍惜，多积累，多沉淀。

同时这种业务模式，也重新定义了产品经理，很有助于我们对身处不同角色的自己有一个更清醒的认知。

此外，也尤其需要意识到，虽然大部分项目是一次性交付制，但你做的产品方案对于客户是否真的有价值，有意义？

我想，这应该是我们更值得深思的点。

本文由@凯拉Kella 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。