本文主要与大家分享企业内部产品从0到1建设的完整思路，不涉及具体的内部调研方法，希望能够给大家带来一些帮助，或者一些新的思路。

在启动项目立项初期，首先需要明确的一点的是，这次我们需要解决企业内部的哪些问题，如果不清楚那请脚踏实地先调研（不考虑上层直接下达命令），其次是自己的大致策略，我是从上到下的梳理，还是从下到上的梳理都是不同的，之前有看到有小伙伴将企业信息化建设分为了五个大的阶段，我个人是非常认同的，在这里我简要的引入一下，不做深入讨论，需要的小伙伴们可以自行查找。

• 第一阶段：系统记录代替手工记录阶段
• 第二阶段：解决简单，重复的问题
• 第三阶段：管理要求融入系统
• 第四阶段：通过数据监控企业经营情况
• 第五阶段：智能办公，解放人力

大的思路可以按照这个思路走，但是其中细节会因为企业环境不同，会存在一定的改动，在这里我想对这五个步骤之前进行一个补充，就是快速定位问题点，寻找临时替代方案，用户习惯先培养起来，在使用替代方案的同事快速梳理问题，定位当前紧急迫切的问题，框架层面要清晰，细节层面要缩减。

项目执行阶段流程大的可以分为：项目启动 → 系统目标确认/业务实质理解 → 业务流程问题梳理/问题整理 → 产品需求梳理与分析 → 产品方案设计 → 测试与验证 → 项目管理与实施 → 使用跟踪/问题反馈收集 → 产品优化和完善；

一、项目启动

在这个阶段核心的工作有四个部分组层：成立项目组、前期调研、编制总体项目计划、项目启动大会。

1. 成立项目组

部门经理接到项目实施任务后，任命项目经理，制定项目目标，指定项目组成员及成员任务，并制定初步方案。

项目目标：旨在解决XX内部流程规范、时间节点工作记录、工作内容存档等问题；

项目组成员及成员任务分配清晰；

2. 前期调研

项目经理带领项目组成员与用户建立联系，对用户进行调研，并确认项目干系人，确定他们的需求和期望，如何满足和影响这些需求、期望以确保项目能够成功。

产出物：《项目需求调研计划书》、《项目初步需求调研表》、《初步栏目结构表》。

3. 编制总体项目计划

《项目总体计划方案》是一个文件和文件的集合，随着项目信息不断丰富和变化，会被不断变更，主要介绍项目目标、主要项目阶段、里程碑、可交付成果等。

• 计划职责分配；
• 沟通管理计划：确定项目干系人对信息和沟通的需要；
• 质量管理计划：确定适合于项目的质量标准和如何满足其要求；
• 未解决事宜和未定的决策。

产出物：《项目总体计划方案》

4. 项目启动会议

项目组与用户（需求方）共同召开项目启动会议，由项目经理负责召集相关人员召开启动会。会议内容如下：

1）共同组建项目实施组织，确定成员权利和职责；

2）由项目组介绍《项目总体计划》，包括以下内容：

• 项目目标；
• 主要项目阶段；
• 里程碑；
• 可交付成果；
• 所计划的职责分配；
• 项目实施中项目管理的重要性；
• 如何进行项目管理；
• 项目的质量如何控制；
• 项目实施中用户的参与和领导的支持的重要性；

产出内容：《项目启动会会议纪要》、《项目开工报告&项目组联系表》

二、系统目标确认/业务实质理解

1. 系统目标确认

针对基于项目管理的内部项目系统开发，需要和用户一起确认项目的目标和范围。我们可以从以下几个维度先搞清楚有哪些关键因素可以影响到项目目标的确认：

• 首先我们要了解这个项目是做什么系统？
• 这个项目是为谁而做？
• 用户为什么要做这个项目？
• 确定项目在公司内部的商业价值？

我们可以通过访谈的形式对项目接口人/主管领导进行相关调研，通过分析这些问题来确认整个项目目标。我们梳理的提纲如下：

产出物：《收集初步资料》

2. 业务实质理解

确定了系统目标之后，我们需要对目前的业务实质进行了解，可通过当前线下业务流程的梳理，找到线下业务存在痛点，然后在形成系统的线上业务流程时，知道如何来更好的优化和调整，这也是后期产品设计导向的依据，我们可以通过制定《需求调研计划》，建立《初步需求池》对公司业务进行调研。

对于项目的业务调研，我们梳理的提纲如下：

针对以上问题，我们可以通过个别交流（就某一问题或业务处理和相关人员直接交流）、开会讨论，对跨部门、跨岗位的业务，把相关人员召集在一起，了解相关业务的实际情况，根据制定的《需求调研计划》将用户的初步需求记录在《初步需求池》中。

产出物：

• 《需求调研计划》
• 《资料收集》
• 《初步需求池》

三、业务流程梳理/问题整理

任何业务的开展都有其既定的流程，不管是线上业务还是线下业务，通过对业务实质理解调研获得的资料，进行材料整理，梳理业务流程，整理业务问题；将其流程化的表达出来。

• 公司组织架构、部门架构
• 每个角色工作目标
• 工作主线任务链
• 系统内主线任务链
• 关键表单信息分组，优先级
• 细节专题访谈

清晰展示我们收集到的信息，澄清它们之间的关联：

• 业务构成/关系图，展示业务模块关系（跨职责流程图）
• 工作流程图，展示用户工作历程
• 体验地图，呈现用户具体任务/行动过程
• 利益人关系图，呈现用户组织关系
• 业务指标澄清

进一步细化目标、痛点。找切入点，搞清楚问题，冲突、未满足的需求所在：

• 对业务痛点的澄清
• 对当期改进目标的不同角色不同观点澄清
• 用户使用历程中得阶段感受
• 用户的痛点、未满足目的需要、操作需要
• 澄清相关影响因素

产出物：

• 《资料整理及确认》
• 《各业务流程架构图》
• 《业务问题列表》

四、产品需求梳理与分析

通过对业务流程的梳理，以及业务问题的整理后，我们需要对获得的需求在业务流程以及业务问题的基础上进行梳理与分析，整理需求，消除需求之间的矛盾，定义产品边界，制定最终大家认可的、可执行的需求方案。

1. 产品需求梳理与分析

我们主要将需求分为业务需求、用户需求以及软件需求，通过建立的需求池，结合整体业务流程对需求池中的需求进行判断与分析，首先对需求池进行初步筛选和评估，保留确实可行的需求。

需求梳理分析时，我们可以通过几个不同的维度进行分析。

2. 需求来源

1）业务需求：业务需求某种程度可以理解为产品建设的目标

2）用户需求：使用者需要完成什么任务，完成这个任务的过程中遇到的问题；这里需要注意的是用户需求可能是零散且存在矛盾的，用户会从不同角度，不同层面提出需求，因为用户处于不同层级，不同部门。

3）软件需求：

用户需求类型：

获取用户需求分三类：意识到的需求、无意识需求、进一步的需求。

无意识需求是用户在实际工作场景中「没有意识到是问题」的问题，这种问题需要产品经理对业务有一定理解。

意识到的需求通常是一些困扰用户的问题，或者是用户自己能想到的功能。但是往往无意识需求和进一步需求才是产品设计的功能兴奋点。

侧重点：针对不同层级我们要考虑的侧重点是不同的。

①高层管理人员

• 罗列出部分问题/机会点
• 准备相关系统实施经验案列
• 列举一些潜在方案

②中层管理人员

• 罗列出相关业务事件列表
• 收集与特定业务事件相关的资料
• 准备一些业务事件的关键问题点
• 准备一些相关的管理控制点

③操作层

• 罗列出相关业务活动
• 业务活动的问题，需求点
• 罗列相关业务规则，数据

产出物：清洗过的需求池

3. 需求评审

需求评审会：

汇总完所有的需求到需求池后，产品经理需要组织需求评审会议，邀请相关同事参会，围绕风险大小、成本把控、开发难度、现有资源以及版本周期对《需求池》进行评审，讨论V1.0版本需要做哪些需求。会议结束后，产品经理把需求池列表的需求进行过滤，把V1.0版本初步需要做的需求进行需求整理，确认本版本需求列表。

需求确认会：

汇总完所有的V1.0需求，产品经理需要组织需求确认会议，确定需求评审会议后确定下来的需求。产品经理需要记录这次会议上针对需求提出来的一些讨论结果的记录。（在此期间可能会爆发新一轮的需求讨论，但产品需要确认好最终的需求版本）产品会后需根据需求确定的版本进行排期。

最终需求表：

需求确认会后，产品经理需要整理一份《最终需求确认表》，确认本次版本的内容以及排期（排期需要与研发leader先行讨论定制）后，以邮件形式发给需求方，进行需求确认的相关事宜，告之相关部门及人员安排好工作，准时参与需求确认工作，为顺利完成需求确认工作做准备。

产出物：最终需求确认表

五、产品方案设计（在这里也不做深入讲解，后续文章会足部完善）

此阶段主要在需求确定之后，整理产品需求方案，方案内容主要针对：核心业务流程、产品定位

应用架构、功能模块以及演进蓝图（迭代规划）进行整理。

产出物：

• 产品流程架构图
• 产品交互原型图
• 页面交互说明
• 产品需求文档

六、测试与验证

测试验证主要是为了比较实际输入与预期输出的差别，以确定系统的正确性、完整性。可通过设计的产品原型方案给到各部门相关人员体验，体验结果可制定体验反馈表反馈至产品负责人，由产品负责人统一收集处理，修改产品方案并再次进行评审确认直至通过。

这个测试主要是方案（原型），这一步至关重要。

产出物：体验反馈表

七、项目管理与实施（这里核心需要考虑跨部门协作合作）

测试与验证通过后，由项目负责人与开发leader制定详细工作排期。

1. 视觉交互设计

此阶段主要是对产品进行交互设计和界面设计。

• 交互设计：包括完整的界面规划图，如区域的布局状态如何。用户操作的效果设计，如登录按钮在点击时报错有提示，提示分别为1.2.3等。
• 界面设计：根据原型，对页面布局、内容展示等众多界面进行细节设计。
• 产出物：交互设计稿、设计说明书、产品交互文档、界面设计稿、设计标注

2. 项目实施

在最终需求表确认后，开展软件功能实现阶段工作。此阶段的是将软件设计的结果转化为计算机可运行的程序代码。主要对软件的体系框架、数据结构和主要算法进行设计和编码实现。在程序编码中必定要制定统一、符合标准的编写分UI规范，以保证程序的可读性、易维护性，提高程序的运行效率。主要阶段如下：概要设计 → 详细设计 → 软件编码 → 项目BUG处理

产出物：

• 《软件功能确认表》
• 《软件系统概要设计书报告》
• 《软件系统详细设计书报告》

3. 测试

在软件设计完成后要进行严密的测试，通过测试去发现在整个软件设计过程中的问题并加以纠正。测试人员需要根据PRD、交互稿、视觉设计稿编写测试用例，测试用例评审通过后执行测试。整个测试阶段分为以下阶段进行：编写测试用例 → 测试用例评审 → 单元测试 → 集成测试 → 系统测试 → 输出测试报告

产出物：

• 《测试用例》
• 《测试分析报告》

4. 系统培训

系统培训阶段工作是整个项目实施工作中比较重要的工作，用户对软件的操作功能是否熟练将直接影响到后面的软件应用效果，所以软件公司和用户双方要对此阶段的工作给予足够的重视。具体培训工作流程如下：制定培训计划 → 发布培训通知 → 组织培训 → 培训总结

产出物：

• 《培训计划》
• 《培训人员一览表》
• 《培训人员签到表》

5. 系统试运行

此阶段主要是在用户真实环境下，对用户网络及硬件设备进行测试，对软件系统进行容量、性能压力等进行测试。测试及试运行的目的在于确保系统各项功能均能正常使用；把尽可能多的潜在问题在正式运行之前发现并改正；同时在正式运行前有关的用户能进一步提高操作水平，掌握操作规范。此阶段的主要内容为：试运行计划 → 发试运行通知 → 搭建环境及数据准备 → 试运行总结

产出物：

• 《试运行计划》
• 《试运行通知》
• 《试运行总结》

八、使用跟踪问题反馈收集

产品/功能上线后，首先应该建立问题反馈跟踪机制，以便了解系统的功能是不是用户真正所需要的，也可以通过用户反馈的问题为下一步的迭代做准备，对产品的功能和体验做进一步优化。其次产品需要做好复盘工作，回顾项目执行过程中遇到的问题，并输出完善的举措和计划，并切实执行，避免同类型问题的出现。

产出物：

• 产品复盘报告
• 系统使用反馈表

九、产品迭代优化

产品迭代是产品生命中非常重要的一环，在产品上线后，要结合实际环境、用户需求等对产品进一步优化，延长产品生命周期。

可通过以下几个维度对产品迭代进行分析：

• 整体业务流程分析
• 核心业务分析
• 子业务分析
• 设计迭代规则

产出物：《产品迭代分析报告》

到这里就结束了，我还整理一份过程中的相关文档目录，就不在这里展示了，有需要的小伙伴留言评论就好，我会发出来的~~ 非常感谢

预告：下一篇《B端项目内部如何调研梳理》

本文由 @技术差一般不说话  原创发布于人人都是产品经理，未经许可，禁止转载。

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