市面上写产品的书很多，多是大佬的深切体会，对于一个想入门的产品经理来讲，其实相对遥远。本文将根据我的从业经历，写下日常产品工作的一般完整的流程是怎样的。历经哪些节点，需要做哪些判断，以此来提高自己，也希望对诸位有所帮助。
一、为什么要做这个需求
不管是B端产品经理，还是C端产品经理，在日常的工作当中，不管接到别人的需求还是自己洞察到需求，都要反问自己为什么要做这个需求？这个需求的价值是什么？
判断是否要做思考三个层面：
1、逻辑上是否成立？
逻辑上成立指这个需求的背景是什么？目的是什么？业务方或你自己提供的解决方案是否可以达到目的？这个过程是在了解业务的前提下，考验产品的逻辑判断能力。需要注意的是一定不要被业务方带跑，业务同学仅站在自己的角度考虑问题，相对片面。
举例：我们是向商家提供售卖商品，之前业务向我提过一个需求背景是，当前有很多商家销售能力不强，每次需要向商家提供补货支持。在当前运力不足的情况下，会造成很多货放在前置仓库无人补货。希望做一个页面管理每个点位的运力情况。运营自己判断哪些点位，可降低补货频次。节省运力。
结合这个案例我们可以分析下，是否该做，作为产品，首先要了解当前的安排运力的逻辑是什么？在了解完成后，看是否当前的逻辑可以满足业务方的诉求。业务方的诉求：总结一句话就是，不卖货的上架，不该频繁安排补货，浪费运力。当前的逻辑实际兼容了这一点。那为啥会出现业务方所说的问题呢。经过沟通最终确定是业务在系统上设置的运营较多，导致此问题。所以解决这个问题核心点在于运营要缩减运力。
另外，假如即使问题不能靠现有系统解决，业务方提供方案是否可行？做运营页面就要运营打理，牵扯到人工的地方就一定会出错，一定会有延迟。这个案例也是同样的问题，且更好的方式是系统。做了反而会对业务有差的影响。因此这个需求就是一个逻辑上并不成立的需求。
2、是否业务真有这个诉求？
在逻辑成立的基础上在看第二层，是否真的有此诉求？很多情况下，业务方会”想当然“，他不会考虑系统的开发成本，一旦出了问题，就认为做个需求就解决了。但事实上，可能并不存在这个诉求。出了问题查问题，而不是先做需求。
举例：当前系统的补货逻辑，兼容了商品售罄和大补货量。业务方反馈有的商家卖得货多，补货不及时，因此应该多设置一档，优先计算补货。但从之前的了解，不管售罄还是大补货量都会优先考虑。因此就需要找出个例去查问题造成的原因，是否补货系统未考虑此问题造成的。经查明，是此点位不符合其他的标准导致无法计算补货。
从这个例子我们可以看出：运营提出的是问题，是现象。而造成此现象可能有很多问题。产品经理需要定位出问题所在后，再确定是不是通过做功能的方式解决。因此诉求的目的是解决问题，而不是非要做需求。
3、数据上需证明做的价值有多高？
当前两点就满足的情况下，基本可以确定这个需求应不应该做，但做的价值有多大，需要通过数据的方式衡量。这里有几个注意点：（1）此数据完全是为此需求设立的，因此需要判断数据口径是否能相对准确，相对完整的评判这件事。（2）取数后的数据需要抽样验证。
拿到数据后就可以判断需求的优先级了。定优先级需要考虑三方面：1、业务的紧急程度。2、影响的广泛程度。3、影响的严重程度。
二、如何做这个需求？
当上面3点成立时，这个需求就到了产品经理的需求前期调研和撰写文档阶段。
1、需求调研（B端产品）
很多情况下，产品需要做一些自己并不熟悉的业务需求。在这种情况下，前期调研就十分有必要。首先，产品当前已经明白了要在啥业务，啥系统里做啥功能？但业务与业务直接的关联，功能与功能直接的逻辑，产品此时就需要了解清楚。需求调研：最主要的调研方式就是问人。
问什么会有助于你做这个需求？这里面需要有几项准备
1）在问他人前，自己先理清楚本次要做的需求目的，大体的实现方式。
2）数据从哪个表里取?现有逻辑从哪个接口得到？
2）提前准备好问题，两个通用性问题必问：
·这个需求的背景，目的，实现逻辑是XXX，你帮忙把把关，看是否有啥纰漏？
·目前的总体流程和实现逻辑是怎样的？
2、PRD文档撰写
在撰写前基本已经知道大体的实现逻辑。因此在本阶段的主要目的是：为开发同学提供开发说明。需要阐述清楚，为什么做？数据为多少？如何实现等，提测前的testlist（测试前验收清单）。在本阶段的需求撰写中，除了将上述判断的背景，目的，数据支撑填写填写外，最主要的是需要将如何实现写清楚。
撰写的过程就是细致思考的过程。这里面有两个方法论：
1、用流程图梳理清楚大致业务流程、开发实现逻辑流程、用户交互流程。
2、在根据这个框架仔细思考每个环节，使用方的操作场景（千万不要跳流程，千万不要跳）
最终呈现的效果：1、尽可能做到需求点不遗漏。2、尽可能做到文档开发易于理解。
3、需求评审
这是将本需求与技术，测试、UI同学，表述，沟通，争辩的主战场。并最终决定实现功能，实现逻辑，排期等重要事项。
评审前需提前预设开发在评审会上提出的质疑？并提前准备应对答案。这里有个小技巧：在评审前，先和技术负责人简单过下，让其帮忙把关，可有效防止在需求评审会上被开发怼。
评审中，需简洁有力的介绍清楚：
1）一句话描述清楚：背景，目的，目标（根据需求的性质决定是否需要填写），数据支撑（根据需求的性质决定是否需要填写）
2）先总体，后细节。先将总体实现此次需求逻辑，在细致讲逻辑。在开发过程中，需要注意的点。
在评审中，可能遭遇开发各种问题挑战，只要上述的准备做得扎实，基本不会出现大问题。但一定会出现你之前预设不到的问题，如非阻断性问题，若在当场想不出解决方案，承诺会后确认或给出答复，先不要影响评审进度。
在这个过程中需要注意：评审时，开发可能提出更简单的方案。此时就需权衡与你提到的有何不同，如果损害到用户体验，需要衡量开发节省成本和用户体验的缺失那个影响更大。一般情况下，站在用户角度出发，据理力争，尽可能的做到不妥协。实在拿不定主意的，将此信息告知上级，让他拍板做决定。
评审结束后，第一时间解决评审中的疑问，在群里告知技术同学。当技术认可后，向技术负责人尽快确定排期：开始开发日期，联调日期，提测日期，发布日期，灰度日期（产品定），上线日期（产品定）
4、需求开发
在确定排期，真正进入开发阶段。
首先，这个过程可能存在意料之外的问题，在开发前需要告知技术同学，如果有了影响用户体验的问题，或影响开发进度的问题第一时间告知产品经理。而不是等到提测前告知，或上线前告知。
同时，在开发过程中，产品需清楚，各个开发在本需求中做什么功能，接口如何调用，前端向后端传什么信息，后端向前端传什么信息。
最后，产品应该管理开发进度，进度管理最主要方式为营造出紧迫感，关注感。譬如每天晚上询问开发进度。如进度较慢，询问遇到的问题，或需要协调的人员，提供开发进度，尽可能保证按排期节奏。
5、验收前提测
当需求联调完成后，将进入到测试阶段。在测试前，需要在测试环境需要产品经理与测试同学一同验收。验收通过后，此需求正式进入到测试阶段。
此时的验收其实与上线前的验收标准基本一致。验收原则为：
1）先验主流程，再验其他流程。
2）验收的case提前写出，尽可能保证验收的逻辑不遗漏。
6、测试完成上线
上线测试测试的内容基本与测试前验收一致，需要提前做好上线前准备，准备的原则为：先外部，在内部。先主要，再次要。
1）因为测试环境和线上不同，可能验收的流程涉及到各个部门。千万不要等到上线的晚上才开始准备， 此时多数协同部门可能已经下班，麻烦别人得趁早。
2）准备线上的测试用的数据等。
3）验收过程同提测前验收。
7、灰度
根据需求的性质，部分需求可能需要灰度（取一部分人员先生效最新功能）。需要在评审会上和测试同学沟通灰度方案，最好在提测前根据灰度方案，确定灰度范围。在需求待发布前一定需要提供灰度范围，一般为灰度人员名单或灰度城市范围。
8、什么时候全量发布
1）产品控制的全量过程
全量发布的时间取决于此次的灰度目的。若灰度目的仅为降低发布风险，功能执行方使用没有问题后即可全量发布。若此次更新为重大更新，需要观察执行方使用数据，则全量时间由反馈的数据结果决定。
2）非主观控制的其他全量
小程序所有用户可见最新功能，需要微信端审核，一般在发布的2天左右，功能会全量到所用用户，C端APP受版本限制，需要用户主动进入APP，才有机会被更新。
9、数据验证
在灰度阶段或全量发布后，积累一定数据量级后，需要评断本次需求是否达到了预期的效果，因此需要出数据验证。为这一阶段出数顺利，需要在需求撰写阶段就确定好数据维度，口径，统计时间等信息。在开发阶段，需要让开发将相关数据信息存表，或记录在工单里，方便数据取数。
数据验证的过程有一个关键点：如何客观的用数据衡量需求效果。这个比较考验产品的数据思维能力，可以从几个维度考虑：
1）本次需求的需求目的是什么？根据目的来确定需要衡量目的的数据字段以及每个字段的计算逻辑。思考过程遵循时间顺序，树状图结构等等。
2）根据此次需求使用的流程中的数据流（常见的有漏斗型）。根据此数据流来确定字段来衡量需求效果。
在完成上面9个步骤后，一个需求基本就算交付了。当然，在业务方使用过程中，可能出现各种各样的问题，遇到问题解决问题，就不算开发需求的范畴内了。
最后，珍惜每个需求，在每个需求结束后复盘整个过程，不断反思总结这9大阶段里面的问题点，不断总结自己做需求的思考方法论，相信你我都会是一个优秀的产品经理，加油。
