前言
日常开发中，当拿到一个需求后，我应该按照什么样的流程去做？当你发出这样疑问的时候，我们的‘第一剑’就应该出鞘了。
【第一剑：准备阶段】是重中之重。它指定了业务方向，它决定了我们代码该怎么写。假设给我十分力写代码，我可能会花费四分以上的力气去做‘准备工作’。所谓磨刀不误砍柴工，方向都错了，后面的代码哪怕写出花来也毫无价值。
产品需求评审
需求评审的不确定
需求评审的过程是充满各种不确定性的。
1、‘开发人员’对业务掌握程度的不确定性。‘新开发人员’对‘旧业务’不熟悉来参加评审、‘老开发人员’对‘旧业务’的遗忘来参加评审… 虽然我们期望参加这次评审的开发人员，是对原有业务有足够理解的，但是往往事与愿违。
2、‘产品经理’提出需求的不确定性。产品经理可能也不清楚新需求业务对旧业务造成哪些影响。产品经理是基于‘产品思维’来提需求的，他的关注点更多在于[实现这个需求]。 虽然我们期望自己面临的是专业性极强的产品经理，在提出需求之前，会主动把新需求业务联系与旧业务做关联性判断，从而给大家一个尽可能清晰的产品文档。
3、待补充
需求评审的侧重点
需求评审的时候，侧重点在于：需求评审时，需要考虑哪些问题。
不管你对这个项目业务是否熟悉，你都要在需要需求评审的时候 想尽办法 做好下面几件事。
1、评估需求是否合理。产品提的这个需求是否符合“伦理”。这个需求的价值在哪，值不值得做。
2、需求进行划分归类。该需求偏向于新增类需求还是改进类需求，这一步是为了评估需求复杂度以及工作量。
-
技巧：如果不熟悉业务，可以让产品经理自己来评估，这个需求到底属于‘新增类’还是‘修改类’。评估的标准是新需求业务对旧业务的影响面。
-
进一步划分：偏业务性需求还是偏技术性需求。
3、评估这个需求业务对旧业务造成哪些影响。如果属于‘改进类’需求，那么势必会对‘旧业务’产生影响。
4、待补充。
产品需求梳理
需求的划分归类
实际开发是针对【产品需求】进行的。将需求进行划分归两大类：
-
新增类需求；
-
改进类需求。
进一步细分：
-
偏业务类需求；
-
偏技术类需求。
以“十”字象限划分，将需求具体分为：新增且偏业务类、新增且偏技术类、改进且偏业务类、改进且偏技术类。
分类原则
需求与旧业务的关联性是否紧密。
新增类需求的特点
这类需求，一般是不需要在‘已有代码上’进行改动。业务梳理中，不需要过多的考虑与旧业务的关联；代码开发中，因为是新代码，没有对旧代码逻辑的改动，因此也不需要考虑对旧代码的影响。
你需要做到：
1、业务的正确理解。
2、技术方案的正确设计。
改进类需求的特点
这类需求，一般需要你在‘已有代码上’进行改动。无论是偏技术类的改进，还是业务类改进，你需要做到：
1、新业务的正确理解；
2、旧业务的正确理解；
3、评估旧逻辑改动后造成的影响。一旦旧接口内容被修改，必须核实到底有多少处地方被调用。比如修改了web端接口，需要前端确认多少地方调用；修改了serv端，需要确认多少下游调用。
需求梳理的侧重点
1、业务的正确理解。
2、接口改动后的影响面评估。比如修改了web端接口，需要前端确认多少地方调用；修改了serv端，需要确认多少下游调用。
编写技术文档
技术文档的前提
1、产品文档。已对产品文档进行仔细阅读，且针对疑惑点已和产品经理或者第三方沟通；
2、代码。已对旧代码进行阅读，了解旧代码的执行流程；
技术文档的编写
流程图和时序图
1、如果是新增类需求，你需要准备两张图，一个是宏观上的流程图，一个是较细节的时序图。
2、如果是改进类需求，你大约要准备三张图，一张是旧逻辑的流程图，一张是旧逻辑的时序图，一张是新逻辑的时序图（基于旧逻辑做对比）。
无论是新增类需求还是改进类需求，你应该首先画出流程图，后画时序图。
1、流程图目的。站在更高的角度分析问题，以架构的思维看世界。且在流程图中给出正向、逆向流程，展现出程序可能出错的点。
2、时序图目的。以‘流程图’为蓝图，进行更细粒度的设计。
至于流程图和时序图的示例文档，建议看一下拉取反馈邮件的示例。
文档目录结构
技术文档的目录，是‘技术评审’时的路线蓝图。典型的三段式进行：
1、开头；
2、内容：主要由流程图和时序图呈现，但是在讲具体方案之前，必须描述自己对该模块的业务理解(目的是测试在场的各位是否站在和自己一致的业务理解，然后再谈解决方案)；
3、结尾；
建议看一下之前评审的【模板服务改造】需求的文档目录结构。他的开头声明、内容呈现形式、结尾注意事项还是比较清晰的。
技术文档侧重点
在正确理解业务的前提下，以流程图、时序图的方式准确的描述程序执行的流程。
技术方案评审
此时，经过阅读产品文档➕三方沟通➕旧代码阅读等，相信你现在手中已经有了一份技术评审文档。上面有着你对本次需求的技术方案，这个文档肯定有123项是你本次需要新增、修改的地方。肯定有你画的流程图、时序图 。
明确技术评审的目的
针对产品提出的需求，开发人员是否相应的给出正确的技术方案实现。评估开发人员是否完成了以下两点：
1、业务理解是否正确；
2、方案设计是否合理；
如何主持好一场技术评审
技术评审是按照‘技术文档’进行的。所以说，你的‘技术文档’的目录结构，决定了会议的走向。在此我只强调一句：确保大家处于对业务统一理解的前提下，再具体讲技术实现前(我的方式是在讲技术方案前，先描述自己对业务的理解，以测试大家是否和我理解的一致)。
技术评审的侧重点
如果努力的方向都错了，走在远的路有何用？这一阶段，你要着重做的就是在评审每个功能点之前，刻意强调你的业务理解。因此，你需要在讲每个点具体的方案之前，先去铺垫业务。你的目录结构应该是这样:
一、新增模板功能
0.功能概述
简短的话概述这个功能，让大家知道你下面要讲的东西。
1.业务理解（产品经理确认）
此处突出自己对业务的理解。此处用词必须是【语气肯定】的词眼。
2.具体的技术方案
方案是否正确，取决于业务理解是否正确。方案提现形式:流程图，时序图，接口变更的参数……
总结
1、在真正进行构建活动前，我们需要做足准备工作。只有我们努力的方向是正确的，我们的努力才变得更加有意义。
2、做好【侧重点】的事情。准备工作包括：产品需求评审、产品需求梳理、编写技术文档、技术方案评审。无论哪个处于哪个阶段，我们都有必须关注的侧重点。
致读者
由于能力、经验、认知有限，本节内容若有不足之处，望请广大读者批评指正，可在评论区或私信给出建议。后面会陆续给出‘开篇声明’、‘程序设计第二剑：构建活动’、‘程序设计第三剑：防止墨菲定律’。