创业公司实现了0-1，但是怎么实现从1-100就需要内修好项目管理了。本文通过在公司搭建项目流程的角度对整个创业公司项目流程搭建进行了复盘。创业公司的痛创业公司往往在流程管理上还没有规范，这就导致了 项目拖延导致没有音讯交付超时，影响商务对外输出通过项目管理完善对接流程，起到如下作用： 确保沟通明确，使得产品端能够根据商务的需求提供高质量交付物明确交付物细节，避免对接问题导致的溜单问题对流程文档化，方便后续项目复用开始对项目进行敏捷管理对接流程说明流程可以根据需求的类型分为四部分：DEMO需求、产品需求、接口需求、迭代BUG需求。
1. DEMO需求DEMO需求是指商务找到了有意向的甲方，需要由产品端提供DEMO供商务演示，这部分的需求没有交付的流程，主要工作集中在产品部、项目部。一般公司没有现成业务线时需要制作DEMO，因此公司内部需要评估是否需要拓展该业务线，如果该业务向本身就不适合开展的话，那么就应该反馈给商务，这个业务DEMO无法交付。这其中评估考量有： 是否存在足够的商业空间值得投入资源。
技术能力是否满足需要内部资源投入与商业空间的权衡是否涉及监管合规与当前排期是否冲突……2. 产品需求成品需求是指商务已经完成了合同签订，明确需要交付产品的了，是优先级最高的需求。
在这个需求中需要各个部门一起协作，完成产品从设计到交付的全部工作，给到用户的是一个交付的完整产品。整个项目周期跨度一般较大，并且设计多部门协作，因此需要做好文档的记录以及项目的管理。产品先确认需求清单，明确哪些是可以做的，讨论后确定开发需求。
确定好需求后产品就会开始原型设计，完成原型设计后通过商务与业务方确认需求样式后，在公司内部进行需求评审。完成需求评审，确定好开发方案和负责人后，需求就进入了开发阶段。
开发完成后，测试会开始产品的接口、功能、系统测试，如果在测试阶段发现问题就会反馈开发进行修改。
如果是产品设计的问题，就由产品进行修改。测试通过后产品会开始验收产品，验收通过的会提供验收报告。之后开发会提供接口说明文档、功能部署文档给运维，由运维进行部署。
部署完成后，产品提供产品使用说明书及交付清单，之后由业务方开始验收工作。3. 接口需求接口需求是指外部业务方只需要我们开发功能的接口，接入业务方自己的系统。这种情况也通过商务-产品-开发这种流程进行对接，这里面的考量为： 接口需求也涉及到业务应用，因此由产品明确接口的业务需求，能避免接口开发过程中的需求溢出问题该接口是否我们技术已经支持接口需求也需要占用开发资源，产品需要评估与开发中需求的冲突情况4. 迭代需求迭代需求是指产品的功能迭代、BUG修复、功能回滚等需求。一般来源于业务方反馈，或者业务线本身的迭代路线图中。
这些工作5. 项目会议在整个项目组运行过程中会有很多会议，在会议开始前，会议发起人要明确好会议的参与者、会议的讨论内容和会议的目的，并提早做好会议通知、会议室准备。在会后要写会议纪要，避免会议结束后，大家遗忘会议结论。6. DEMO评审会DEMO评审会是为了判断这个DEMO是否需要做，这种情况一般针对的是内部有异议的业务线情况。如果商务自身决定不做DEMO的，就不用发起DEMO评审了。
如果商务觉得有必要开一条业务线时，需要内部产品、技术等建议时，发起DEMO的评审。7. 需求评审会需求评审会的目的是确定需求方案是否合理，并确定需求的方案是否存在遗漏，以及实现需要的工作量。因此需求评审会内容会偏多，并且是需求进入开发阶段前最后一道把关。需求评审会有产品经理发起，需要开发人员、测试人员参与，针对需求设计的细节进行一一确认。
8. 需求排期会需求排期时针对需求数量超过工作能力要求时而设立的。目的就是通过对比需求质检的优先级顺序，确定开发的优先级。需求排期会由产品产品组内部进行，最后生成一个需求优先级排序结果作为以后一个时间段内的工作轻重参考。
9. 问题解决方案讨论会在项目开发过程中肯定会有出现问题，这可能是缺资源、性能满足不了需求、需要额外的接口等。如果出现问题都先反馈到负责的产品处，由产品协调资源进行解决。如果超过了产品能力的范围，由产品发起相关人员，一起讨论问题的解决方案。
10. 需求上线会议需求完成开发，并完成测试验收后就会开始准备上线工作了。一个系统都是多个服务的组合，就比如APP就涉及到APP、后端服务、数据源、运营平台等。因此上线也存在先后顺序的问题。不然就可能会出现用户打开后，没有内容甚至报错的情况。
11. 项目复盘会项目完成了上线并不是一个需求的结束。在磕磕绊绊中大家慢慢得到了成长，良好的总结问题习惯能够让大家一起走的更远。项目的复盘会议，产品经理需要先总结这个需求过程中的各种问题，按问题的类型进行分类，流程问题、技术问题、产品设计问题等，针对不同问题的类型进行总结。
文档内容说明在整个项目实施过程中会有很多文档，写文档是需要明确写不是目的，目的是： 做到件件有交代，避免大家口口相传中的信息丢失作为后续工作复盘中的依据给后续项目复用提供资料帮助业务方更好的使用我们的产品1. DEMO需求要求Demo需求的要求的目的是和产品说明清楚，这个demo的要求，需要演示的时间以及演示的方式，可以提供的物料等。Demo需求要求不是重要的文档，所以不用明确文档的形式，只需要一个简单的表格即可。例如：2. 需求清单需求清单是整个项目在实施过程中的依据，产品需要依据清单设计需求，开发需要根据清单实现系统性能要求，测试要根据清单进行测试。因此这个文档要求： 高可读性，能满足产品、开发、测试等各个岗位的理解信息必需是明确的，不能是模糊的说法，涉及到数据的需要明确 需求需要根据模块进行分类，方便B端业务线功能迭代时，统筹规划需求需要有明确的优先级定义，方便B端排期时安排需求清单处理功能的列表还应该包含整个产品的系统性能要求需求清单流程： 商务与业务方简单对接，完成需求清单产品根据需求清单，整理功能确认点反馈开发根据接口需要，整理接口确认点商务完成业务方对接，内部开始产品开发有的公司有项目经理负责对接项目清单，也有公司直接产品经理与业务方对接项目清单，这里为了避免公司内部与外部业务方多对多的情况导致需求遗漏。
因此采用统一出口，统一入口的方式。这里面的优劣势情况会根据公司业务情况进行跳转。3. 原型设计文档在产品环节需要针对功能需求设计原型，比如：运营后台功能、前端展示等。
原型设计作为产品经理的基本功，不再赘述。4. 需求文档需求文档是公司内部项目实施的。
