创业公司实现了0-1，但是怎么实现从1-100就需要内修好项目管理了。本文通过在公司搭建项目流程的角度对整个创业公司项目流程搭建进行了复盘。

一、创业公司的痛

创业公司往往在流程管理上还没有规范，这就导致了

1. 项目拖延导致没有音讯
2. 交付超时，影响商务对外输出

通过项目管理完善对接流程，起到如下作用：

1. 确保沟通明确，使得产品端能够根据商务的需求提供高质量交付物
2. 明确交付物细节，避免对接问题导致的溜单问题
3. 对流程文档化，方便后续项目复用
4. 开始对项目进行敏捷管理

二、对接流程说明

流程可以根据需求的类型分为四部分：DEMO需求、产品需求、接口需求、迭代BUG需求。

1. DEMO需求

DEMO需求是指商务找到了有意向的甲方，需要由产品端提供DEMO供商务演示，这部分的需求没有交付的流程，主要工作集中在产品部、项目部。

一般公司没有现成业务线时需要制作DEMO，因此公司内部需要评估是否需要拓展该业务线，如果该业务向本身就不适合开展的话，那么就应该反馈给商务，这个业务DEMO无法交付。

这其中评估考量有：

1. 是否存在足够的商业空间值得投入资源。
2. 技术能力是否满足需要
3. 内部资源投入与商业空间的权衡
4. 是否涉及监管合规
5. 与当前排期是否冲突
6. ……

2. 产品需求

成品需求是指商务已经完成了合同签订，明确需要交付产品的了，是优先级最高的需求。在这个需求中需要各个部门一起协作，完成产品从设计到交付的全部工作，给到用户的是一个交付的完整产品。

整个项目周期跨度一般较大，并且设计多部门协作，因此需要做好文档的记录以及项目的管理。

产品先确认需求清单，明确哪些是可以做的，讨论后确定开发需求。确定好需求后产品就会开始原型设计，完成原型设计后通过商务与业务方确认需求样式后，在公司内部进行需求评审。完成需求评审，确定好开发方案和负责人后，需求就进入了开发阶段。

开发完成后，测试会开始产品的接口、功能、系统测试，如果在测试阶段发现问题就会反馈开发进行修改。如果是产品设计的问题，就由产品进行修改。测试通过后产品会开始验收产品，验收通过的会提供验收报告。

之后开发会提供接口说明文档、功能部署文档给运维，由运维进行部署。部署完成后，产品提供产品使用说明书及交付清单，之后由业务方开始验收工作。

3. 接口需求

接口需求是指外部业务方只需要我们开发功能的接口，接入业务方自己的系统。

这种情况也通过商务-产品-开发这种流程进行对接，这里面的考量为：

1. 接口需求也涉及到业务应用，因此由产品明确接口的业务需求，能避免接口开发过程中的需求溢出问题
2. 该接口是否我们技术已经支持
3. 接口需求也需要占用开发资源，产品需要评估与开发中需求的冲突情况

4. 迭代需求

迭代需求是指产品的功能迭代、BUG修复、功能回滚等需求。一般来源于业务方反馈，或者业务线本身的迭代路线图中。这些工作

5. 项目会议

在整个项目组运行过程中会有很多会议，在会议开始前，会议发起人要明确好会议的参与者、会议的讨论内容和会议的目的，并提早做好会议通知、会议室准备。

在会后要写会议纪要，避免会议结束后，大家遗忘会议结论。

6. DEMO评审会

DEMO评审会是为了判断这个DEMO是否需要做，这种情况一般针对的是内部有异议的业务线情况。如果商务自身决定不做DEMO的，就不用发起DEMO评审了。

如果商务觉得有必要开一条业务线时，需要内部产品、技术等建议时，发起DEMO的评审。

7. 需求评审会

需求评审会的目的是确定需求方案是否合理，并确定需求的方案是否存在遗漏，以及实现需要的工作量。因此需求评审会内容会偏多，并且是需求进入开发阶段前最后一道把关。

需求评审会有产品经理发起，需要开发人员、测试人员参与，针对需求设计的细节进行一一确认。

8. 需求排期会

需求排期时针对需求数量超过工作能力要求时而设立的。目的就是通过对比需求质检的优先级顺序，确定开发的优先级。

需求排期会由产品产品组内部进行，最后生成一个需求优先级排序结果作为以后一个时间段内的工作轻重参考。

9. 问题解决方案讨论会

在项目开发过程中肯定会有出现问题，这可能是缺资源、性能满足不了需求、需要额外的接口等。

如果出现问题都先反馈到负责的产品处，由产品协调资源进行解决。

如果超过了产品能力的范围，由产品发起相关人员，一起讨论问题的解决方案。

10. 需求上线会议

需求完成开发，并完成测试验收后就会开始准备上线工作了。一个系统都是多个服务的组合，就比如APP就涉及到APP、后端服务、数据源、运营平台等。因此上线也存在先后顺序的问题。不然就可能会出现用户打开后，没有内容甚至报错的情况。

11. 项目复盘会

项目完成了上线并不是一个需求的结束。在磕磕绊绊中大家慢慢得到了成长，良好的总结问题习惯能够让大家一起走的更远。

项目的复盘会议，产品经理需要先总结这个需求过程中的各种问题，按问题的类型进行分类，流程问题、技术问题、产品设计问题等，针对不同问题的类型进行总结。

三、文档内容说明

在整个项目实施过程中会有很多文档，写文档是需要明确写不是目的，目的是：

1. 做到件件有交代，避免大家口口相传中的信息丢失
2. 作为后续工作复盘中的依据
3. 给后续项目复用提供资料
4. 帮助业务方更好的使用我们的产品

1. DEMO需求要求

Demo需求的要求的目的是和产品说明清楚，这个demo的要求，需要演示的时间以及演示的方式，可以提供的物料等。Demo需求要求不是重要的文档，所以不用明确文档的形式，只需要一个简单的表格即可。例如：

2. 需求清单

需求清单是整个项目在实施过程中的依据，产品需要依据清单设计需求，开发需要根据清单实现系统性能要求，测试要根据清单进行测试。因此这个文档要求：

• 高可读性，能满足产品、开发、测试等各个岗位的理解
• 信息必需是明确的，不能是模糊的说法，涉及到数据的需要明确

• 需求需要根据模块进行分类，方便B端业务线功能迭代时，统筹规划
• 需求需要有明确的优先级定义，方便B端排期时安排
• 需求清单处理功能的列表还应该包含整个产品的系统性能要求

需求清单流程：

1. 商务与业务方简单对接，完成需求清单
2. 产品根据需求清单，整理功能确认点反馈
3. 开发根据接口需要，整理接口确认点
4. 商务完成业务方对接，内部开始产品开发

有的公司有项目经理负责对接项目清单，也有公司直接产品经理与业务方对接项目清单，这里为了避免公司内部与外部业务方多对多的情况导致需求遗漏。因此采用统一出口，统一入口的方式。这里面的优劣势情况会根据公司业务情况进行跳转。

3. 原型设计文档

在产品环节需要针对功能需求设计原型，比如：运营后台功能、前端展示等。

原型设计作为产品经理的基本功，不再赘述。

4. 需求文档

需求文档是公司内部项目实施的说明文档。需求文档是开发工作的依据。

5. 测试报告

根据需求的情况会有不同的测试任务，不同的测试任务会有不同的测试报告。例如在接口需求中就会有接口测试报告，迭代和BUG中就会有服务的测试报告，涉及到产品交付的还会有系统测试报告。

测试报告是运维发布上线的依据，如果没有测试报告，运维就不能把服务发布上线。

6. 接口说明文档

接口文档是开发给接入者提供的说明文档，也是产品交付后业务方二次开发的依据，在公司内部开发的接口，需要开发完成后上传到公司内部文档管理的平台上，做好留档。因此需要明确接口的内容，包括：

1. 入参：入参字段的说明、入参的内容说明、入参的类型、是否必填等
2. 返参：返参字段的说明、返参的内容说明、返参的类型，是否必填等
3. 正确请求示例
4. 错误提示说明
5. 认证方式
6. ……

7. 验收报告

验收报告是产品经理验收需求后提供的报告，意思是产品满足产品经理设计的要求。验收包括了两部分，一块是界面交互验收，另一块是功能验收。在验收环节，产品应该尽可能的模拟用户使用产品，或者也可以找项目组的同学进行体验验收。

8. 产品使用说明文档

B端项目产品在交付的同事需要提供一份高可读性的产品使用说明文档。在文档中需要说明清楚整个产品的功能逻辑，并针对整个产品使用操作进行详细的图文说明。

产品使用说明文档需要注意的是：

1. 避免开篇就开始将细节。应该先从整体讲解这个产品的用处，整体涉及模块及各模块的作用
2. 内容应该采用总分总的结构进行描述，方便用户理解
3. 注意概念说明，业务方的使用者对功能不一定理解，因此需要注意概念性名词的解释
4. 涉及到复杂操作的，务必带上截图

9. 交付清单

交付清单是指产品完成开发后，需要向业务方反馈的所有交付物清单。交付清单应该是表格式的，明确交付物的名称、形式、数量等信息。交付物包括实体的硬件、电子版文档、虚拟的接口、产品的安装包等等

10. 部署文档

需求完成开发，测试验收后就会需要运维进行发布。在复杂需求中涉及到多个模块，因此发布上线是一个复杂的工作。开发在完成开发时，需要向运维提供完整的部署文档，并在发布上线前，由大家一起确定发布上线的顺序及服务启动的关系。

四、特殊情况说明

1. 需求修改、补充

已经开始开发的：

需求已经开始开发的，遇到了需求修改补充的，需要判断修改是否对原需求是推到重来的情况。是推倒重来的需求就应该及时调整需求的优先级顺序，对需求进行调整了。如果是锦上添花的修改，那么根据开发进度进行评估是插入还是作为迭代需求更新进需求池。

还没进行开发的：

产品评估需求改动的量，如果可以则修改需求设计

2. 需求延期

需求可能由于其他更高优需求插队、技术难度等导致延期。需求延期导致的交付延期，开发应该提早向负责需求的产品进行反馈，在反馈时需要明确说明延期的原因、预计延期时间、预计交付的时间，方便产品及时与商务沟通，避免违约导致合同赔偿问题。

本文由 @南风追忆 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash ，基于 CC0 协议