从需求到落地，产品全链路实现流程

让想法变成现实，考验着每一位产品经理的汗水和智慧。下图是产品全链路的实现流程。总计13个环节，闭合成环，称之为产品迭代环。产品全链路实现流程前面讲了需求收集及需求分析（可看文末链接）。接下来讲讲从需求到落地还需要做哪些事。一，需求优先……

让想法变成现实，考验着每一位产品经理的汗水和智慧。

下图是产品全链路的实现流程。总计13个环节，闭合成环，称之为产品迭代环。

前面讲了需求收集及需求分析（可看文末链接）。接下来讲讲从需求到落地还需要做哪些事。

一，需求优先级评审会议

拉领导及开发同事参与。拉开发同事参与的目的主要是为了让开发对需求的可行性、开发难易层度做大致的评估，以及提供实现思路（不同的实现方式对逻辑流程和原型会有影响）。部分需求可能要分期开发。会后输出需求优先级、争议点和难点。开发在会后就可以开始技术预研。

二、逻辑流程图到设计草图

设计原型前，先进行结构层和框架层的设计。也就是流程图到设计草图（纸面原型）。这一步不能跳过，前期考虑周全，会节约大量的时间，避免后面修改起来牵一发而动全身。这个环节很多同学会去研究竞品或者寻找相似设计，这本身没什么错，但最好不要这样。容易固化思维。你要先把自己脑中想象的东西画出来，然后再去对标竞品，如果对方好的设计你可以借鉴，不好的地方那就你设计的独到之处了。我对团队里面的同事也是这么要求的，这样对自身成长也比较快。养成好的习惯。

三、原型图

好的原型工具有AxureRP、墨刀等等，学一款原型工具很简单，找个视频看一下，10分钟就会了。重点在于要把自己的想法通过原型表达出来。原型也是跟视觉、开发和测试沟通的桥梁。原型有低保真和高保真，甚至动态原型图之分。这个看团队需要。具体怎么做原型图，我会在本次的系列文章中详细介绍。

四、需求评审会议

拉领导、开发、视觉、测试等多方参与。评审内容以原型图为主。第一次需求评审会议，需要给团队介绍产品目标、目标用户、设计思想等等这些问题，确保大家目标一致，思路统一。会后同样也要输出原型修改点和争议点等等这些内容。一般需求评审会议开个几轮都是正常的。有的公司要求在需求评审阶段就要输出PRD文档，有的公司不鼓励写PRD文档，毕竟写PRD文档也是一项耗时的工作，开发还不一定看。，这因公司而异。

五、需求文档（PRDProductRequirementDocument）

我还是建议写一下PRD文档，一方面可以更深刻的梳理自己的思路，让逻辑没有死角。一方面PRD文档也是公司知识库的沉淀，人员变动时，方便传承。一方面，方便测试同学写测试用例，开发也可以作为查阅手册，避免重复回答同样的问题。也有人说这是甩锅专用文档。

六、开发排期、视觉排期

开发排期技术负责人会把控，但产品作为总协调人，需要统筹开发和视觉进度。开发和视觉启动，这没什么问题，但视觉进度一定要快于开发进度，这是肯定的。开发排期有粒度的概念，即开发会将需求拆分成小的功能点，每个功能点完成时间是以天为单位、0.5天为单位还是以小时为单位。这个时间单位就是粒度。这就需要产品去要求开发同事了，不然他到时排期给你个以周为单位，这就没有多大指导意义了。颗粒度越大，进度越不可控。因为开发过程中，有很多不可控因素，比如中途插入更高优先级需求，这时候你需要清晰的知道，在哪个环节延误了，已经延误了多长时间。以方便及时调整开发计划。一般大的功能点可以以天为单位，小功能点以0.5天或小时为单位（比如需要及时响应的运营需求）。

七、项目跟进

有点类似项目管理，协调资源、催进度（周启动会议、周会议）、关心开发实现上的问题、安排好后续测试和上线环节。这些都是分内的事。所以也不是人人都是产品经理啊，产品经理要求还是比较全面的。

八、视觉验收、产品验收

视觉验收有视觉设计师负责，主要是看看视觉上有没有需要调整的地方、开发是不是把资源合入错误了、开发实现是否跟视觉标注一致等等。产品验收是啥都管，除了检验开发是否按需求文档实现外，视觉、bug、逻辑实现问题、响应速度加载速度、边界问题（如弱网、断网、服务器失联、空白页）等等都要检查到。产品验收也不是非得等到开发完成后，中途穿插几轮验收也未尝不可。

九、测试

测试同事在PRD文档确定后，就可以安排开始编写测试用例。一般团队也有测试指标，达到指标后，方可上线，比如无一二级bug，三级bug（不影响体验的小概率bug）少于几个，功耗、性能指标等等。，上线前，还可以安排可用性测试、A/B测试、压力测试等等。

十、上线

上线前准备好上线材料，跟运营同事配合做上线工作。上线后要实时监测各项数据及用户反馈，做好预警方案。如果是重大功能上线或影响范围比较大，为了可控，避免造成突发事件，还可以安排一轮灰度测试。

以上是从需求到落地的整体流程，后续文章会挑重点进行介绍。相信你看完这些，对产品的每个环节就会有一个比较清晰的认识了。