职什么责

随着软件在现实社会中的日益普及，越来越多人逐渐对软件领域里名词有所了解，从最基本的“程序猿”、“攻城师”，到技术含量稍高一点的“Bug”、“对象”，都已经能随处听到或看到。而对于软件从业者来说，很多普通的名词却附上了有别于大众认识的意义，例如“需求”、“对象”、“抽象”等。

最近一段时间，又一个名词开始频繁地冲击我的脑子，引发了我的一些思考和感悟。这个词就是——“职责”。

既然在这里提到了这个词，说明它肯定在大众认识与软件领域中有两个较为不同的含义。在大家普遍的认识中，职责就是指任职者为履行一定的组织职能或完成工作使命，所负责的范围和承担的一系列工作任务，以及完成这些工作任务所需承担的相应责任。而在软件领域中的职责，则往往跟面向对象设计或模块化设计相关联，它代表着一个软件对象或系统模块所需要提供的信息和行为，也可以简单地理解为数据+函数。

由于近来一个月左右，做了不少关于产品架构、设计，以及团队管理、开发管理等方面的工作，从问题寻找到原因分析，再到解决方案的探索，诸多环节都很奇妙地聚集到“职责”这么一个词汇上来，这也是为什么我会突然对这个词反应如此强烈，如此感兴趣。也正是经过这一段时间的思考，让我原本对“职责”在大众认识和软件领域中一分为二的含义认知，形成了一个完整而统一的理解。这二者在本质上其实是一致的，没有太大区别，只是在表现方式上会有不同呈现。因此，我想结合一些实际的例子，把自己关于“职责”的一些感悟记录下来。

1. 职责不应该只是别人要求你做什么，而更应该是你自己意识到该做什么。比如负责某个模块开发的程序员，就应当有责任确保该模块的正确性。因此，这个程序员本身就应该意识到自己需要去做诸如单元测试之类的工作，而不是等PM或者老板发现产品质量有问题，再强制引入这些措施。同样的，在代码里，也需要清楚定义每个类和对象的职责。对哪些信息提供访问机制，对哪些信息进行必要的隐藏，都取决于这个逻辑单元在系统所承担的角色。

2. 职责是明确而强制的，否则就相当于没有职责。当职责明确了之后，就必须时刻有意识地遵从和履行这些职责。一个人在团队中可能是个多面手，很多事情都有能力做，但如果不仔细考虑自身的职责，就既可能无法保质保量地把你涉足的方方面面都做好，还可能打乱团队其他成员的工作计划。而在软件中，如果一个类明明起名为xxxController，却同时能够控制各类UI的展现，领域模型的逻辑计算，还能够涉及数据的持久化，那这就相当于无视对象职责。这种行为，必然引起的结果就是混乱。定义了职责，却不按照职责去履行，那么定义它的意义何在？

3. 为一个个体赋予相似的职责是最高效的，而把一个职责分配到多个个体则相反。对于这句话，影响相对大的一点的，应该是软件领域。当划分系统，拆分模块的时候，我们往往倾向于这么做，因为这是最符合逻辑的，也是最容易让人理解的，甚至可以说是最有效的（减少复杂度，降低出错的概率）。在团队中，这么做有时候也是非常有利的。比如，把用户访谈与需求文档编写分配给一个人或者一个专门的小组去做，是比较合理的。因为这可以减少沟通成本，可以减少可能产生误解的环节，同时也免去了很多分配任务、解决冲突的工作。

4. 职责的赋予，意味着个体之间联系的建立，以及依赖的产生。这一点在团队协作之中不言而喻，A负责需求，B负责测试，那么B的工作必然依赖于A。其实，强调这一点的原因，更是因为它在软件开发方面的影响。当你设计了任何一个类甚至任何一个方法时（此时你就是在为这个类或对象赋予一定的职责），你都要意识到你可能正在引入一个关联。当你设计的系统中无处不充斥着各种混杂的关联和依赖的时候，你的灾难可能就要降临了。因此，如何减少依赖、管理依赖都是需要我们格外注意的。

5. 职责是可变化的，并且每一次职责变化，都可能引起与该个体相关联的其他个体受到影响。基于上一点，我们知道软件系统中的任何实体都可能与其他实体有着千丝万缕的联系。尤其是越核心的对象，关联到的模块就越多。此时，“牵一发动全身”就不再是危言耸听了。团队也是如此，人员或职责的变动，不仅仅是换一个人做事，或者是换一件事做，而是牵涉到方方面面。比如A调离了岗位由B替代，那么以前与A配合完成任务的人员需要花多少时间才能重新适应与B的合作？又比如由于C的离职，A突然需要多承担来自于C原来的开发工作，这导致A将无法投入足够多的时间到自己负责的需求工作去，间接导致了团队的开发进度大幅下降，还多次使得与目标客户的交流被迫取消。所以，任何一次看似可以轻易决定的改变，都需要足够的深思熟虑。

6. 提出职责，就意味着面临的问题足够复杂，假如我们处理的事情十分简单，那么不需要引入职责也可以做得很好。当我们写Hello World的时候，应该没有人会想到要去分配什么职责；而当你写一个网站的时候，你已经自觉地知道你至少需要宏观地把系统划分为界面、逻辑、数据三个层次。同样的，我们把公司从大大小小的层面划分成了多个小组织，为每个人定义了不同的角色，也是因为我们正在做的事情很庞杂。没有人愿意无缘无故地引入各种职责和机制来约束各个个体，这么做的核心目的只有一个，那就是使复杂的局面清晰化，无论从软件角度还是团队角度而言，都是一样的。

基于以上的感悟，我认为无论是在软件设计还是在团队管理当中，对于职责的考虑都是一件重中之重的事情。职责的分配，不是分蛋糕，要合理计划；职责的承担，不是挂名头，而是需要按质按量地履行；职责的影响，不只关乎个人业绩，而是涉及一个整体的共同进退。所以，当我们提出了所谓的职责的时候，不能把它想得太简单，因为职责不只是说说而已。