任何一个项目制的公司迟早都会面临这样一个问题：项目需求如何落地到产品需求里？本文总结了相关思路，一起来看看吧。

最近有同行问我，项目需求如何落地到产品需求里？我想，这或许是一个不错的选题，因为这是任何一个项目制公司迟早都要面临的问题。

一、产生的背景

一般公司做的项目多了，就会发现疲于奔命，客户需求多种多样，定制化有利于客户的需求，但对于甲方和乙方浪费了大量的时间和人力成本。

因此对于很多重复性较高且甲方都在用的行业方案，我们倾向于在内部形成自己的自研产品，提高项目实施的高效，满足快速且轻成本交付的需要。

二、自研产品的演变思路

于是，若形成公司内部自研产品，就大抵会经过这样的演变模式：

如上图示意：

我们从大量的甲方项目经验里，形成内部自研的产品版本，同时自研产品线可辅助用于交付项目，项目也可不断通过实战辅助迭代自研产品，这样相辅相成，直到形成行业较为成熟的解决方案。

这时候，产品版本清晰，承载的业务和核心能力也趋于成熟，可以快速用于项目交付。同时，因为已经积攒了太多的实战经验，完全可以逐步抽离出一部分共性需求，至于个性化较强的部分可以用apaas来灵活、自定义地解决，这又进一步融合形成了行业内标准的产品方案，即saas，甚至还可以再细分为行业saas、场景saas、通用型saas。

当然，走到这已经是与以往完全不同的两种商业模式了，在这里仅作为一种产品发展思路的设想，具体视情况而定；

三、建设意义

关于项目到落地自研产品的价值和意义，对公司和个人都同样深远。

对于公司，打磨战略级标准应用产品，提高产品扩展性和兼容性。降低定制率提高产品的复用率，易于扩大市场。

并且基于寻求多元化的业务增长点考量，这是一个资源整合的过程，也是一条必走的路。

对我们产品个人，如果有幸能参与到这样一次经历，会有很大的提升。或许能做一款接近市场客户的真实有用的好产品。

那如果你接到这样一个任务，又该如何着手开始呢？

以下是一个可以落地执行的思路，仅供参考！

四、落地自研产品的思路

1、沟通公司高层和战略层的想法、规划、了解落地形成自研产品的目标要求

2、作为产品经理，需要着重考虑产品架构和范围界定（这块从两大方向来考虑）

1. 确定自研产品的定位、范围界定，解决的场景和问题

主要包含：

• 梳理过往交付项目客户关注率较高的需求和业务；
• 梳理统计过往交付项目支撑率和覆盖率较高的需求；
• 参考市场上相对成熟的竞品、做竞品部分的调研；
• 可考虑收集招投标文件要求来进行需求梳理做一定参考；毕竟竞品挖掘有限；
• 收集客户使用侧.市场侧.售后运维侧.开发侧等需求反馈；

综上，综合考虑需求的覆盖面，市场的反馈，需求在技术侧实现方案的平衡等多方面进行需求池录入和优先级排序，形成产品版本和架构划分。

2. 拉通产品资源，拉通各关键部门，形成自研产品实施立项和计划

• 拉通技术、解决方案、市场销售等关键部门，进行立项计划宣导、需求评审‘和问题确认。
• 沟通技术侧的代码复用情况，做资源整合，即是否可解耦直接打包生成MVP1.0自研产品版本；尽量拉取功能闭环更全面的项目需求；将这部分可用的需求做筛选，梳理纳入1.0版本清单里。
• 后续根据立项计划，演进路线，再逐步进行产品迭代管理和推动。

3. 此外，还需要有以下方面的考量

在形成成熟的自研产品过程里，是一个不断在实战项目里验证和完善的过程，需要整个公司、产研团队的协同发力。

（1）技术侧的考量

关于技术侧，在架构和代码结构的开发侧，要侧重于微服务架构，低耦合，高内聚的目标需求，增加代码的复用性和易维护、可拓展性需求。

（2）产研协作侧考量

在团队分工协作侧，需要建立整个项目侧与自研侧的协作机制；需要一整套标准规范和要求制度，以便自研产品可以在项目侧得到推动和有效验证，并逐步提升项目需求的支撑率，同时可反向推动自研产品形成更加有核心竞争点的产品力，为后期占据市场做准备。

在这套机制里，项目侧和自研侧的干系人均有义务互相辅助和推动；并及时反馈，不能自成一派。

（3）架构设计的角度

产品架构边界和技术架构，需要在一定的范围内可灵活调整，以便于满足市场快速多元的需求。

这样，当项目侧和自研侧可以互相推动，形成良性循环时，自研产品的建设或许会走的相对容易一些。