建一个项目的流程，组建项目公司

初创公司从0到1，但如何从1到100，需要内部在项目管理方面的改进。本文从一个公司项目流程的角度回顾了一个创业公司的整个项目流程。

1. 成立公司的痛苦

初创公司通常缺乏标准化的流程控制，这会产生以下问题：

项目延误会导致不知情的加班并对外部业务成果产生影响。通过项目管理完善对接流程：

确保沟通清晰，以便产品方能够根据业务需求交付高质量的交付物明确交付物细节，避免因对接问题造成延误便于后续项目重用记录您的流程敏捷项目管理入门2. 对接流程图解

这个过程根据需求类型可以分为四个部分：demo需求、产品需求、接口需求、迭代BUG需求。

1. 演示要求

Demo需求是公司需要寻找干系人，产品方需要提供业务demo的部分，这部分没有交付流程，主要工作在产品部门和项目之间。部门。

一般来说，企业如果没有现成的业务线，就需要创建一个demo，因此需要评估是否需要扩展业务线。反馈给企业后，我们将无法再为该企业提供演示。

评估考虑因素包括：

是否有足够的商业空间来证明资源投入的合理性？技术能力是否满足内部资源投入和商业空间要求，监管合规性与当前进度是否存在冲突…… 2、产品要求

成品需求是最高优先级的需求，很明显公司需要完成合同并交付产品。这一要求需要不同部门共同努力，完成从产品设计到交付的所有任务，并将成品交付给用户。

一般来说，整个项目周期较长，设计需要多个部门协作，因此需要文档和项目管理。

对于产品，我们首先查看需求清单，明确可以做什么，然后讨论后决定开发需求。确定需求后，我们开始产品的原型设计，完成原型设计后，我们通过公司/客户确认需求模式，并进行内部需求评审。一旦需求评审完成并确定了开发计划和人员，需求开发阶段就开始了。

开发完成后，就开始对产品的界面、功能和系统进行测试，测试阶段发现的任何问题都会反馈给开发团队进行纠正。如果产品设计有问题，我们会针对每个产品进行修复。测试合格后，产品将开始检验，如果检验合格，将出具合格报告。

然后开发向运维提供接口描述文档和功能实现文档，运维进行部署。安装完成后，将提供产品说明书和发货清单，商家开始接受申请。

3、接口要求

接口需求是指外部业务方只需要开发一个功能接口，访问业务方自己的系统即可。

这种情况也与企业产品开发流程有关。

由于接口需求还包含业务应用，因此在产品侧明确接口的业务需求，可以避免接口开发过程中出现需求溢出问题。另外，接口是否兼容你们公司的技术也占用开发资源。竞争格局4.迭代要求

迭代需求是指产品功能迭代、bug修复、功能回滚等需求。通常，它来自于业务方的反馈或业务线本身的迭代路线图。这些工作

5、项目会议

很多会议是在项目团队运作的整个过程中召开的，但会议发起者必须在会议开始前明确参与者、会议内容、会议目的，并准备好会议通知和会议室。提前做好准备。

会议结束后应制定会议纪要，以便每个人都不会忘记会议的结论。

6. Demo评审会

DEMO反应器审查会议决定是否需要DEMO反应器，并且通常针对的是公司内部持反对意见的业务部门。如果公司本身决定不进行演示，则无需启动演示审核。

当公司决定需要开设业务线并需要内部产品、技术等提案时，就会启动演示审核。

7、需求评审会议

需求评审会议的目的是确定需求计划是否合理、需求计划是否有遗漏以及实施所需的工作量。因此，需求评审会的内容很丰富，是需求进入开发阶段之前的最后检查。

需求评审由产品经理发起，开发人员和测试人员参与，对需求设计进行一一检查。

8.需求日程会议

当需求数量超过工作能力要求时，建立需求调度。目的是通过比较所需质量检查的优先级来确定开发优先级。

需求调度发生在产品组内，最终产生需求优先级排名，有助于确定下一阶段工作的优先级。

9. 问题解决研讨会

在项目的开发过程中，难免会因为资源不足、性能不能满足需求、需要额外的接口等问题而出现问题。

当出现问题时，首先报告给负责的产品部门，由产品部门协调资源解决。

如果超出了产品的功能范围，产品会指导相关人员讨论问题的解决方案。

10.需求线上会议

一旦需求被开发、测试和批准，上线的准备工作就开始了。系统是多种服务的组合。例如APP包括APP、后台服务、数据源、运营平台等。所以上网的时候也存在一个排序问题。否则，可能会导致内容无法显示或用户打开内容后出现错误。

11、项目评审会

项目已完成并上线并不意味着需求已完成。每个人都是慢慢成长的，都经历过坎坷和挫折。总结问题的好习惯有助于大家共同努力，取得更大的进步。

在项目评审会上，产品经理首先要把需求过程中的各种问题按照类型进行分类总结，比如流程问题、技术问题、产品设计问题等。不同类型的问题。

3. 文件内容说明

在整个项目实施过程中会创建大量文档，但文档的目的必须明确。

为了避免由于口碑造成的信息丢失，业务利益相关者通过确保一切都被考虑在内并提供信息作为后续工作审查和在后续项目中重复使用的基础，使您能够更有效地使用我们的产品。

演示要求的目的是清楚地描述您的产品、您的演示要求、演示的时间和方式以及可以提供哪些材料。由于demo需求不是关键文档，所以不需要指定文档的格式，只需要简单的格式即可。例如：

2. 需求清单

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

需求开发、测试和批准后，发布需要操作和维护。在线发布是一项复杂的任务，因为复杂的需求涉及多个模块。开发完成后，必须向运维提供完整的实施文档，并且在发布和启动之前，大家必须决定发布和启动顺序以及服务启动关系。

四、特殊情况说明1、要求变更和补充

已经在开发中：

如果已经编写了要求并且您想要更改或补充它，则必须确定更改是否会降低原始要求。如果您要从头开始替换需求，则需要及时确定需求的优先级并调整需求。如果是红利变更，会根据开发进度来评估是作为迭代需求插入需求池还是更新。

尚未开发：

评估产品需求的变更量，并在可能的情况下修改需求设计。

2、需求延迟

由于其他高质量请求、技术问题等导致插队，请求可能会被延迟。对于因需求延迟而造成的交付延迟，开发者必须明确说明延迟原因、预计延迟时间以及负责需求的产品的预计交付日期，并尽早反馈。促进产品和业务之间的及时沟通，避免因合同违规而导致合同覆盖问题。

本文首发于@南风Memory，人人都是产品经理。它禁止未经授权的复制

标题图片由Unsplash 根据CC0 协议提供