创业公司做到了0-1，但是如何从1-100做到，需要项目管理的内修。本文从公司建设项目流程的角度，对整个创业项目的建设过程进行了回顾。
一、创业公司的痛苦
初创公司在流程管理上往往没有标准，这导致
项目延期导致加班无音频发货，影响业务出口。
通过项目管理完善对接流程，发挥以下作用:
确保沟通清晰，使产品端能够根据业务需求提供高质量的可交付成果，明确可交付成果的细节，避免对接问题导致的文档流转，便于后续项目复用，启动项目的敏捷管理。
二、对接过程描述
根据需求的类型，该过程可以分为四个部分:演示需求、产品需求、界面需求和迭代BUG需求。
1.演示要求
DEMO需求是业务找到了意向方A，产品方需要提供DEMO进行业务演示。这部分需求没有交付流程，主要工作集中在产品部和项目部。
一般一个公司在没有现成业务线的情况下需要做一个DEMO，所以公司需要评估是否需要拓展业务线。如果业务本身不适合发展，就要反馈给业务，这个业务的DEMO不能交付。
评估考虑因素包括:
是否有足够多的商业空房值得投资？技术能力是否满足需求？内部资源投入和业务空之间的权衡是否涉及法规遵从性是否与当前时间表冲突...
2.产品需求
成品需求是指业务已经完成签约，明确需要交付产品的优先级最高的需求。在这种需求下，需要各部门通力合作，完成产品从设计到交付的所有工作，给用户一个交付的完整产品。
整个项目周期跨度一般较大，设计是多部门的，需要做好文档的记录和项目的管理。
首先产品要确认需求清单，明确能做什么，然后讨论后确定开发需求。需求确定后，产品将开始原型设计。原型设计完成后，由业务和业务方确认需求样式，并在公司内部进行需求评审。需求评审完成，确定开发计划和负责人后，需求进入开发阶段。
开发完成后，测试将开始产品的界面、功能和系统测试。如果在测试阶段发现问题，将反馈给开发人员进行修改。如果是产品设计问题，会被产品修改。产品通过测试后，开始验收产品，并提供验收报告。
之后开发会提供接口描述文档和功能部署文档给运维，运维会进行部署。部署完成后，产品会提供产品使用说明书和交付清单，然后业务方开始验收工作。
3.接口要求
需求意味着外部业务方只需要我们开发的功能的接口就可以访问业务方自己的系统。
这种情况也通过业务-产品-开发过程联系在一起，这里需要考虑的是:
接口需求还涉及业务应用程序。因此，通过产品来定义接口的业务需求，可以避免接口开发过程中的需求溢出问题。接口是否已经被我们的技术支持也需要占用开发资源，产品需求评估和开发需求的冲突。
4.迭代需求
迭代需求是指产品功能迭代、BUG修复、功能回滚等需求。一般来自业务端的反馈或者业务线本身的迭代路线图。这些工作
5.项目会议
整个项目组运作过程中会有很多会议。会议开始前，会议发起人应明确会议参加人员、讨论内容和会议目的，提前做好会议通知和会议室准备。
会后写会议纪要，防止大家会后忘记会议结论。
6.演示评审会议
DEMO评审会就是判断这个DEMO是否需要做。这种情况一般针对内部有异议的业务线。如果业务本身决定不做演示，就没有必要启动演示审查。
如果企业认为有必要开设一条业务线，并且需要内部产品和技术建议，则启动对演示的审查。
7.需求审查会议
需求评审会议的目的是确定需求方案是否合理，需求方案是否有遗漏，需要实现的工作量。所以需求评审会议的内容会太多，是需求进入开发阶段前的最后一次检查。
需求评审会由产品经理发起，有开发人员和测试人员参与，需求设计的细节会一一确认。
8.需求调度会议
当需求数量超过工作能力需求时，将设置需求计划。目的是通过比较需求质检的优先顺序来确定开发的优先顺序。
将在产品组内进行需求调度，最终生成需求优先级排序结果，作为下一时间段工作量的参考。
9.问题解决研讨会
在项目开发的过程中，肯定会出现问题，可能是资源不足，性能不能满足需求，需要额外的接口。
出现任何问题都会先反馈给负责的产品部门，由产品协调资源解决。
如果超出了产品的能力范围，产品会发起相关人员一起讨论问题的解决方案。
10.需求在线会议
在完成需求开发、测试和验收后，我们将开始准备上线工作。系统是多种服务的组合。比如APP，涉及APP、后台服务、数据源、运营平台等。所以也有上线顺序的问题。否则，当用户打开它时，可能没有内容，甚至出现错误。
11.项目恢复会议
项目的完成并不是需求的结束。在磕磕绊绊的过程中，每个人都在慢慢成长，一个总结问题的好习惯可以让大家一起走得更远。
在项目的复盘会上，产品经理需要首先对这个需求过程中的各类问题进行总结，按照问题的类型进行分类，比如工艺问题、技术问题、产品设计问题等。，并总结不同类型的问题。
三。文件内容描述
整个项目实施过程中会有大量的文档，要明确写不是目的。目的是:
凡事负责，避免口碑信息的流失，作为后续工作的基础，为后续项目复用提供信息，帮助业务方更好的使用我们的产品。
1.演示要求
演示需求的目的是用产品解释清楚，这个演示的需求，演示的时间和方式，可以提供的资料等。Demo需求不是重要的文档，所以不需要指定文档的形式，简单的表格就可以了。例如:
2.要求列表
需求清单是整个项目实施过程的基础。产品需要根据清单设计需求，开发需要根据清单实现系统性能需求，测试需要根据清单进行。因此，本文件要求:
可读性高，可以满足产品、开发、测试等岗位的需求。信息一定要清晰，不能含糊，涉及的数据要明确。
需求需要按照模块进行分类，方便B端业务线功能迭代。总体规划需求需要有明确的优先级定义，针对B端调度的需求列表处理功能列表也要包含整个产品的系统性能需求。
需求列表流程:
简单连接业务端，完成需求清单，根据需求清单整理功能确认点反馈开发，整理接口确认点，完成业务端连接，内部开始产品开发。
有的公司有项目经理负责对接项目单，也有直接的产品经理负责对接项目单和业务方。这里为了避免公司内部和外部业务方之间多对多的情况，导致需求遗漏。所以采用统一出口，统一入口。这里的优劣势会根据公司的经营情况来跳。
3.原型设计文件
在产品环节，需要根据功能需求设计原型，比如:运营的后端功能，前端展示等。
原型设计作为产品经理的基本功，在此不再赘述。
4.需求文档
需求是对公司内部项目实施的说明性文件。需求是开发工作的基础。
5.实验报告
根据需求会有不同的测试任务，不同的测试任务会有不同的测试报告。比如接口需求中会有接口测试报告，迭代和bug中会有服务测试报告，产品交付相关的系统测试报告。
测试报告是运维在线发布的依据。没有检测报告，运维无法上线发布服务。
6.界面文档
接口是开发提供给访问人员的说明文档，也是产品交付后业务方二次开发的基础。公司内部开发的界面，开发完成后需要上传到公司内部文档管理平台，并保存文件。因此，有必要指定界面的内容，包括:
条目:条目字段描述、条目内容描述、条目类型、是否必填等。条目:条目字段描述、条目内容描述、条目类型、是否必填等。更正请求示例错误提示显示身份验证方法...
7.验收报告
验收报告是产品经理接受需求后提供的报告，表示产品符合产品经理的设计要求。验收包括两部分，一是界面交互验收，二是功能验收。在验收过程中，产品要尽可能模拟用户对产品的使用，也可以请项目组的同学来体验验收。
8.产品说明文件
交付项目B产品的同事需要提供一份可读性很强的产品说明文档。整个产品的功能逻辑要在文档中解释清楚，整个产品的操作要有详细的说明。
产品说明文件应注意:
避免一开始就从细节入手。首先要从整体上说明这个产品的使用方法。所涉及的整体模块和各模块的功能应以总分结构描述，便于用户理解和注意概念描述。业务端的用户不一定了解功能，需要注意涉及复杂操作的概念术语的解释，一定要截图。
9.交货清单
交付清单是指产品开发完成后，需要反馈给业务方的所有可交付成果的清单。交付清单应采用表格形式，详细说明可交付物的名称、形式、数量和其他信息。可交付成果包括物理硬件、电子文档、虚拟界面、产品安装包等。
10.部署文档
在需求开发、测试和验收之后，将需要发布操作和维护。复杂的需求涉及多个模块，发布上线是一项复杂的工作。开发完成后，需要向运维部门提供完整的部署文档，在发布上线之前，大家共同确定发布上线的顺序以及服务上线的关系。
四。特殊情况的说明
1.要求的修改和补充
已经开发:
如果已经开发了需求，又对需求进行了修改和补充，那么就要判断这种修改是否是对原需求的新的修改。如果是再造需求，就要及时调整需求的优先级顺序，调整需求。如果是锦上添花，那就根据开发进度评估是插入还是更新到需求池中作为迭代需求。
尚未开发:
评估产品需求变更的数量，如有可能，修改需求设计。
2.需求延期
由于其他更高的需求、技术难度等原因，需求可能会延迟。如因需求延迟导致交付延迟，开发应提前向负责需求的产品进行反馈，反馈中应明确延迟原因、预计延迟时间、预计交付时间，便于产品与业务及时沟通，避免违约导致的合同赔偿。
本文由@南风追忆原创发布。每个人都是产品经理。未经许可，禁止复制。
来自Unsplash的图像，基于CC0协议。
