时间: 2021-07-30 11:51:20 人气: 0 评论: 0
创业公司实现了0-1，但是怎么实现从1-100就需要内修好项目管理了。本文通过在公司搭建项目流程的角度对整个创业公司项目流程搭建进行了复**。
创业公司往往在流程管理上还没有规范，这就导致了
通过项目管理完善对接流程，起到如下作用：
流程可以根据需求的类型分为四部分：DEMO需求、产品需求、接口需求、迭代BUG需求。
DEMO需求是指商务找到了有意向的甲方，需要由产品端提供DEMO供商务演示，这部分的需求没有交付的流程，主要工作集中在产品部、项目部。
一般公司没有现成业务线时需要制作DEMO，因此公司内部需要评估是否需要拓展该业务线，如果该业务向本身就不适合开展的话，那么就应该反馈给商务，这个业务DEMO无法交付。
这其中评估考量有：
成品需求是指商务已经完成了合同签订，明确需要交付产品的了，是优先级最高的需求。在这个需求中需要各个部门一起协作，完成产品从设计到交付的全部工作，给到用户的是一个交付的完整产品。
整个项目周期跨度一般较大，并且设计多部门协作，因此需要做好文档的记录以及项目的管理。
产品先确认需求清单，明确哪些是可以做的，讨论后确定开发需求。确定好需求后产品就**开始原型设计，完成原型设计后通过商务与业务方确认需求样式后，在公司内部进行需求评审。完成需求评审，确定好开发方案和负责人后，需求就进入了开发阶段。
开发完成后，测试**开始产品的接口、功能、系统测试，如果在测试阶段发现问题就**反馈开发进行修改。如果是产品设计的问题，就由产品进行修改。测试通过后产品**开始验收产品，验收通过的**提供验收报告。
之后开发**提供接口说明文档、功能部署文档给运维，由运维进行部署。部署完成后，产品提供产品使用说明书及交付清单，之后由业务方开始验收工作。
接口需求是指外部业务方只需要我们开发功能的接口，接入业务方自己的系统。
这种情况也通过商务-产品-开发这种流程进行对接，这里面的考量为：
迭代需求是指产品的功能迭代、BUG修复、功能回滚等需求。一般来源于业务方反馈，或者业务线本身的迭代路线图中。这些工作
在整个项目组运行过程中**有很多**议，在**议开始前，**议发起人要明确好**议的参与者、**议的讨论内容和**议的目的，并提早做好**议通知、**议室准备。
在**后要写**议纪要，避免**议结束后，大家遗忘**议结论。
DEMO评审**是为了判断这个DEMO是否需要做，这种情况一般针对的是内部有异议的业务线情况。如果商务自身决定不做DEMO的，就不用发起DEMO评审了。
如果商务觉得有必要开一条业务线时，需要内部产品、技术等建议时，发起DEMO的评审。
需求评审**的目的是确定需求方案是否合理，并确定需求的方案是否存在遗漏，以及实现需要的工作量。因此需求评审**内容**偏多，并且是需求进入开发阶段前最后一道把关。
需求评审**有产品经理发起，需要开发人员、测试人员参与，针对需求设计的细节进行一一确认。
需求排期时针对需求数量**过工作能力要求时而设立的。目的就是通过对比需求质检的优先级顺序，确定开发的优先级。
需求排期**由产品产品组内部进行，最后生成一个需求优先级排序结果作为以后一个时间段内的工作轻重参考。
在项目开发过程中肯定**有出现问题，这可能是缺资源、性能满足不了需求、需要额外的接口等。
如果出现问题都先反馈到负责的产品处，由产品协调资源进行解决。
如果**过了产品能力的范围，由产品发起相关人员，一起讨论问题的解决方案。
需求完成开发，并完成测试验收后就**开始准备上线工作了。一个系统都是多个服务的组合，就比如APP就涉及到APP、后端服务、数据源、运营平台等。因此上线也存在先后顺序的问题。不然就可能**出现用户打开后，没有内容甚至报错的情况。
项目完成了上线并不是一个需求的结束。在磕磕绊绊中大家慢慢得到了成长，良好的总结问题习惯能够让大家一起走的更远。
项目的复****议，产品经理需要先总结这个需求过程中的各种问题，按问题的类型进行分类，流程问题、技术问题、产品设计问题等，针对不同问题的类型进行总结。
在整个项目实施过程中**有很多文档，写文档是需要明确写不是目的，目的是：
Demo需求的要求的目的是和产品说明清楚，这个demo的要求，需要演示的时间以及演示的方式，可以提供的物料等。Demo需求要求不是重要的文档，所以不用明确文档的形式，只需要一个简单的表格即可。例如：
需求清单是整个项目在实施过程中的依据，产品需要依据清单设计需求，开发需要根据清单实现系统性能要求，测试要根据清单进行测试。因此这个文档要求：
需求清单流程：
有的公司有项目经理负责对接项目清单，也有公司直接产品经理与业务方对接项目清单，这里为了避免公司内部与外部业务方多对多的情况导致需求遗漏。因此采用统一出口，统一入口的方式。这里面的优劣势情况**根据公司业务情况进行跳转。
在产品环节需要针对功能需求设计原型，比如：运营后台功能、前端展示等。
原型设计作为产品经理的基本功，不再赘述。
需求文档是公司内部项目实施的说明文档。需求文档是开发工作的依据。
根据需求的情况**有不同的测试任务，不同的测试任务**有不同的测试报告。例如在接口需求中就**有接口测试报告，迭代和BUG中就**有服务的测试报告，涉及到产品交付的还**有系统测试报告。
测试报告是运维发布上线的依据，如果没有测试报告，运维就不能把服务发布上线。
接口文档是开发给接入者提供的说明文档，也是产品交付后业务方二次开发的依据，在公司内部开发的接口，需要开发完成后上传到公司内部文档管理的平台上，做好留档。因此需要明确接口的内容，包括：
验收报告是产品经理验收需求后提供的报告，意思是产品满足产品经理设计的要求。验收包括了两部分，一块是界面交互验收，另一块是功能验收。在验收环节，产品应该尽可能的模拟用户使用产品，或者也可以找项目组的同学进行体验验收。
B端项目产品在交付的同事需要提供一份高可读性的产品使用说明文档。在文档中需要说明清楚整个产品的功能逻辑，并针对整个产品使用操作进行详细的图文说明。
产品使用说明文档需要注意的是：
交付清单是指产品完成开发后，需要向业务方反馈的所有交付物清单。交付清单应该是表格式的，明确交付物的名称、形式、数量等信息。交付物包括实体的硬件、电子版文档、虚拟的接口、产品的安装包等等
需求完成开发，测试验收后就**需要运维进行发布。在复杂需求中涉及到多个模块，因此发布上线是一个复杂的工作。开发在完成开发时，需要向运维提供完整的部署文档，并在发布上线前，由大家一起确定发布上线的顺序及服务启动的关系。
已经开始开发的：
需求已经开始开发的，遇到了需求修改补充的，需要判断修改是否对原需求是推到重来的情况。是推倒重来的需求就应该及时调整需求的优先级顺序，对需求进行调整了。如果是锦上添花的修改，那么根据开发进度进行评估是插入还是作为迭代需求更新进需求池。
还没进行开发的：
产品评估需求改动的量，如果可以则修改需求设计
需求可能由于其他更高优需求插队、技术难度等导致延期。需求延期导致的交付延期，开发应该提早向负责需求的产品进行反馈，在反馈时需要明确说明延期的原因、预计延期时间、预计交付的时间，方便产品及时与商务沟通，避免违约导致合同赔偿问题。
本文由 @南风追忆 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Unsplash ，基于 CC0 协议
