今天我们来聊一些软性的东西——

对于技术负责人来讲，如何分析产品解决方案（PRD）？或者说，对于普通的开发工程师，如何做好PRD分析？

对于很多毕业一两年的小朋友，在接到产品给过来的开发需求后，内心独白是这样的：这么简单的需求，给我3天，保证完成任务！然后就立马开始做表设计、动手写代码，等到代码写完提交测试了，却开启了无尽改BUG的潘多拉魔盒……或者是做完了才发现不对劲，然后不断找产品经理确认需求、改代码、确认需求、改代码……等到把产品经理、相关方都麻烦几圈后，项目才跌跌撞撞地上线……

相信不少人也有过这样的经历，我们过去就是一次次跳进坑里，又一次次从坑里爬出来，解决问题的经验也一点点积累了起来，因而我们相信——那些不能把我们埋没的坑，终将使我们强大。

其实在这过程中，暴露了以下几个问题：

1. 缺乏上游思维

2. 重点诉求不突出

3. 缺少PRD分析与技术设计

这里说明一点：需求分析是产品经理对业务方需求的分析，PRD分析是开发人员对产品解决方案的分析。PRD分析处于开发过程的前期，在项目的整个生命周期中，它真的太重要了，甚至比技术设计还要重要。

为什么这么说呢，因为它的成败，决定了我们的技术设计符不符合最终目标，会不会给后来者、给自己挖坑，决定了研发质量的高低，决定了有没有返工的风险……

既然PRD分析这么重要，那我们该如何客观正确地做好PRD分析呢？

接下来我分几个点来讲，希望对你有所帮助。

一、明确项目目标与意义

之所以我一开始讲的是“产品解决方案”，而不是“开发需求”，是因为开发人员需要把控好产品经理输出的“产品解决方案”，而不是全盘接受产品经理给过来的“开发需求”。

在PRD评审的时候，不妨先问问产品经理：

1. 这个需求的业务方是谁？

2. 做这个项目的意义何在？

3. 做完这个项目，能产生多大价值？

举个例子，比如我是在电商行业的，接到一个商家返佣的产品需求：产品经理要求实现客户在下单支付后与推广商家进行关系绑定，在活动期内该商家绑定的用户下单可以免扣平台佣金，同时还可以根据运营情况，获得该客户在其它商家店铺下单的返佣奖励。

在PRD评审的时候，我第一时间去找产品经理确认：谁是业务方？为什么要做商家入驻这个需求？这个需求能给平台带来什么价值？

产品经理告诉我，这个需求来自平台运营部门，做这个需求的意义有两点：第一，吸引第三方商家入驻到平台；第二，将第三方商家的线下客户引流至平台，给平台拉新，为我们带来更多新用户，从而带来更多订单、收益。

理解到这一步就可以了，接下来讨论的实现方案是产品经理经过专业思考提出来的，而且该方案已经取得与业务方的认可，并不需要开发人员花过多时间去思考别的更好的方案代替。开发人员需要做的是，给产品提出的解决方案把好关，思考在技术层面该如何实现。

明确项目意义非常重要，它让所有项目成员达成共识，明白自己实际上不是在做需求，而是在做一件对产品、对公司非常有价值的事情。

二、持续做对的事情

一个项目，通常业务方会把核心诉求反馈给产品经理，产品经理收集完需求，经过一番梳理后，会给业务方的核心诉求添砖加瓦，力尽完善一个独立的功能。产品经理需要考虑的事情要更加尽善尽美，对他们的产品设计有要求，往往小需求就会越堆越多，这本身并没有错。

但凡事有侧重点，对于开发人员来讲，开发人员有很多项目在手上等着做，不是所有需求都可以吃得下。而对于企业来讲，每个项目都需要投入很大成本，如果产品做出来投入市场使用后效果很好，那产出的就是项目业绩；万一做出来的产品不被市场认可，那产出的就是项目负担。所以往往大项目会拆成多个版本，第一个完整版本叫MVP版本。MVP版本要求业务主流程通畅、核心数据打通、主功能需求满足，为的是节省成本、快速试错。

做项目也遵循二八原则——20%的核心需求需要我们花80%的时间去关注。

想想，如果我们把时间持续花在做对的事情上，而非在简单的事情上，那距离成功只是时间问题罢了。

在一个项目里，业务方、产品经理、开发人员都有自己想要达成的目标，只要产品经理实现的需求是业务方想要的，开发人员实现的需求是产品经理想要的，我们三者之间目标重合度越高，那我们能够达成的目标就越准确，要知道，项目业绩就是这么来的。

我们想象中应该是这样的：

真实的情况可能是这样的：

所以，我们在PRD评审会的时候，不但要尽可能去理解产品经理，还要往上走一步，和产品经理一起去理解业务方的真实诉求，这也是一直以来老大告诉我的——要走向业务方。这要求我们在PRD评审之前，花时间提前消化一遍，带着问题去评审，让评审会更加高效。

如果有能力，可以往上再走一步，走向市场，去洞察市场的需求，比如研发多去一线体验——做仓储的去仓库体验下，做物流的去体验下配送，这样开发就能更好的理解业务了。如果做不到，那我们选择相信他们即可，敏捷团队要求我们团队内互相得有足够的信任，业务方大多是前端人员，是距离市场最近的，专业的事情本应交给专业的人去做。

当然了，产品经理也应该做好需求分析，对自己的PRD和原型负责，连接好业务方和开发人员，让上下游省省心。比如，至少要做到：

1. 使用较好的prd规范

2. 理解研发的思维

3. PRD改动必须同步

4. PRD要完善，避免变成需求讨论会（重要）

5. PRD业务实现方案要清晰，形成闭环

三、设计先行

“欲速则不达”，做项目也不例外。当你接到一个开发需求的时候，先不要急着动手，先思考清楚，问自己几个问题：

1. 这个需求我需要关注的重点是什么？

2. 除了实现功能，性能上有什么要求？

3. 预估数据的数量级有多少？

4. 类似现成的技术实现能复用吗？

……

还是上面那个例子，业务方提出的商家入驻需求，需要重点关注哪些问题呢？如：

1. 商家与客户绑定、解绑的时间点、触发条件，绑定后如何进行免佣计算？

2. 是用简单ifelse判断还是引入策略模式？

3. 预计的绑定数量有多少？

4. 哪些流程需要同步返回、哪些流程可以通过异步优化？

5. 同步调用出错需不需要重试，异步执行出错需不需要告警？

6. 以前的商家表、客户表、平台佣金计算逻辑能不能复用？

7. 领域模型应该划分到运营、商家、订单、还是财务？

……

当这些问题在这个阶段都有了定论，基本上就能把后续80%的问题给提前规避掉，而且技术设计定下来后，代码开发效率会特别特别的高。

道理都懂，那在战术层面如何做设计？

我常用的方案是：活动图+领域建模+表设计。

我在之前的文章有具体说过怎么做技术设计，无非就是先根据产品原型梳理业务、提炼领域模型，再把产品经理梳理的流程结合领域模型，通过活动图再画一次，最后做表设计。

活动图案例如下：

商家返佣主流程（脱敏）

我来讲解一下这里的重点：

1. 纵向泳道按微服务/系统来划分。因为在我们整个开发团队中，人员的职责范围就是按微服务按领域划分的，按照这样划分能清楚知道哪个团队做什么事情，拆任务的时候职责能细分到具体的团队，PRD文档里往往不会按照这个维度画业务流程；

2. 每个活动就是一个子流程，表示当前服务需要做的事情。新增的内容使用绿色，修改的内容使用橙色，不变的内容使用黄色（为了理解业务）。区别于时序图，不需要画太细，把控好设计粒度；

3. 活动之间的关系，同步和异步的连线是不一样的，为了简化条件判断，条件可以写在连线上；

4. 角色使用小圆点表示，在系统之外，表示数据流入口。具体参考状态图的起点、终点；

5. 如果整个流程过长，可以加入横向泳道来划分业务阶段。这个划分就比较主观了，没有标准，但要合理；

别人觉得你的设计图画得专不专业，除了逻辑是否正确合理，另一方面就是细节把控有没有到位。比如对齐连线尽可能不交叉，同种元素的位置要统一大小和位置等等，这是个体力活，只要你多画就悟了。

至于领域建模与表设计，这里不再详述，对这一块感兴趣的同学可以看看这篇文章：你一定要掌握的画图技巧

工程师可以改变腐化的代码，腐化的代码也可以影响工程师，而设计则可以改变工程师和腐化的代码。

总结一下：明确项目目标与意义、持续做对的事情、设计先行。作为一名出色的技术负责人，在动手写代码之前，记得先做好这三件事。

到这里，你已经了解了一个合格的技术负责人该具备怎样的业务分析能力与设计能力，哪些是我们需要重点关注的内容。在这一点上，我们都需要不断修炼，不断积累业务知识，持续产出高价值的代码。

题外话：项目的技术负责人需要做什么？

作为一个项目研发的负责人，一定要衔接好上下游，上游是产品部门，下游是测试部门，如何衔接好当前的开发工作？四个字：按部就班。

谁都没有三头六臂，一个团队的技术负责人接的项目多了，单靠一个人肯定是管不过来的。假设你现在就是一个团队的总负责人，你会怎么做呢？

其实，谁都可以是项目的技术负责人，从管理的角度来讲，管理者只需要制定流程规范，后续的工作大家按照流程照做就行了，前提是这个流程具体可执行，而不是凭空想象设计出来的。

举个例子，近几年外卖配送员为什么能够风生水起？我们简单分析一下他们的工作流程：

接单、打电话叫你拿外卖、等待客户取餐同时又接另一单，如此循环……这些简单重复的事情特别容易执行，而且能够让一个人熟能生巧。

在这背后，是外卖平台制定的一系列规则，实际上说明了一件事：我们需要按照流程做事情，而不是凭感觉做事情。要是流程不合理可以优化、可以定制化，但不能没有标准，没有标准的事情很容易脱离原定轨道，造成失控。

所以，请好好珍惜那些工作流程明确清晰的公司，不要抱怨每天做的事情重复没价值。公司如果长时间对同一个问题无法在多位员工上达成一致，那就是流程上出了问题。有了流程有了标准，就有了确定的工作内容，至于能不能完成工作内容，那是员工岗位胜任的标准之一，完成工作内容的质量好坏，是绩效评判的依据之一。

比如我最近给我们财务开发团队制定了一个项目研发流程规范：

以上主要从项目负责人的视角来描述项目开发的过程，虽然是从我个人做项目的经验出发，也没有从专业的项目管理的角度来梳理，但只要抓住每一个关键节点，顺手好用就是好办法。有了规范和流程，即使团队加入了新伙伴，也知道每一步该怎么执行，谁都可以是项目的技术负责人。

最后，预祝好学勤奋的你，早日在PRD分析、技术设计这两件事跃迁到上另一个台阶！

老规矩，一键三连，日入两千，点赞在看，年薪百万~