先来说第一个先，需求先于设计。我觉得进入研发最重要的前提就是，首先你要准确的理解业务需求，下面我们就来详细聊一下这个话题。
很多时候，大家会说，业务需求不就是产品的需求文档嘛，这是产品经理的活啊，技术人员只要按照文档去做就可以了。但是，事实上，再好的文档也无法完整的描述业务的所有情况，甚至哪怕经过了需求评审，甚至大家也充分讨论了，都有可能存在理解的偏差。
信息的传递一定是存在损耗的，需求文档已经是产品经理在理解业务方和客户的需求之后整理出来的，这一次转化已经存在损耗。然后，再通过文档和口述告诉大家，又存在一次损耗。所以，好的开发流程可能还会有技术人员复述需求的环节，就是要通过这种双向的确认来尽量避免信息的损耗和误差。
但是，无论采用什么方式，技术人员能否准确的理解并吃透这个需求才是最重要的，这是编写出好代码的前提。如果吃不透需求，就没法预知业务未来发展的方向，要么出现过度的设计，浪费人力，要么设计得不灵活，无法持续扩展，没法满足未来业务的发展。那么，怎么吃透这个需求呢？
首先，要了解业务的背景、流程和目标。所谓业务，简单说就是用户通过我们系统解决了哪些问题，业务背景就是我们为什么要解决这个问题，以及当下是怎么解决的，解决的过程中又碰到了哪些问题。流程就是解决问题的步骤，其中涉及了哪些不同的角色，不同的角色是怎么参与进来的，以及最终我们的目标是什么。
以打快车为例，我们帮用户解决的问题就是帮他打到一辆车，并顺利的到达目的地。我们帮司机解决的问题是，可以拉到更多的乘客，赚到更多的钱。我们的目的就是从中赚取佣金，实现盈利。这就是业务的背景，我们从中可以看出，无论是打车人还是司机，在这个过程中的体验非常重要，只有打车人和拉车人越来越多，我们才能把这个生意持续下去。不断优化这个流程，不断拉更多的人进来，这就是我们的目标。
再来看一下流程，每一个问题的解决都是一个流程，每个流程都会有一些关键的步骤或节点，每个步骤上都需要多个角色的互动，我们都需要进行具体的拆解。还是以帮用户打车为例，要解决这个问题就得需要几个关键的步骤，第一个步骤就是下单环节，用户要输入准确的目的地，并下单；第二个步骤就是匹配到合适的司机接单，并通知到用户，方便他顺利乘车；第三个步骤就是选择适合的路线，把乘客顺利的送达目的地；第四个步骤就是顺利完成支付，完成订单。
通过这样的拆解，我们就可以梳理出所要解决的问题有哪些，每个问题的解决有哪些关键步骤，每个步骤有哪些角色参与和互动。强烈建议大家把这个流程图画出来，非常有助于我们理解自己的业务。我们把打车的业务流程画出来就是图1-1的样子。
其次，了解了大的业务流程还不够，还得细化到具体的场景。所谓场景，就是一个角色在这个关键步骤上怎么完成自己的任务的。我们平时的需求评审中，经常会以一个个功能页面为主来进行讲解，其实这样很容易把页面跟整个流程和场景区隔开，不容易让大家站在使用方的角度来思考问题。比较好的方式，还是先去讲清楚整个流程，然后细化到一个角色的一个场景。如图1-1所示，场景1就是乘客这个角色在完成下单这个任务。
最后，了解了整个流程，我们就可以在这个场景下继续拆解功能点，就如在场景1中，我们可以带入到乘客这个角色中，扮演他，亲身体验一下，他是如何通过这些功能页面完成任务的，在操作的过程中，揣摩他可能会碰到什么问题和疑惑。通过这样的方式就可以让我们真正站在用户角度想问题。通过这样的方式，我们也可以快速的定位目前流程中可能需要优化的点，是在哪个场景下的哪个功能点上。通过对每个功能点的优化，就可以不断优化整个流程的效率和质量，为用户提供更好的体验。
总结一下，准确理解业务需求是高效、高质量满足业务需求的前提，吃透业务需求也是有规律的，先从大的背景和目标开始，我们为用户解决了哪些问题，然后，每个问题再细化到具体的流程节点和场景，场景就是描述了一个角色在一个节点下是怎么完成自己的任务的。最后，每个场景又分拆为具体的功能点。通过这一步步的对业务场景的拆解，我们就可以带入到这个角色里，揣摩每个功能点的设计，不断帮助我们真正吃透业务需求。
