不光跟对领导重要，选对公司也很重要——Agile IT organisation design读书笔记

团队内外合作不顺，经常推搡职责，项目推进缓慢，领导不给力…是领导能力问题？是不幸遇到猪队友？还是合作方人品差？不不不，其实这一切或多或少是由企业结构、流程设计和推行的文化间接导致的！

Sriram Narayan在《Agile IT Organization Design》中，以自己20多年IT企业咨询的经验提炼出了IT企业组织设计上经常出现的问题，并提出了一系列让整个组织向敏捷发展，高效产出的方式方法。

巧遇这本书的时候我想，作为一个还没有做主管的人读这个未免有点早，就当开开眼界。 然而很快就被这本书精简的语句一次次戳中痛处，在脑中自动播放回忆片段，久久不能回神。即便是庞大企业组织中最普通的一颗螺丝钉，行为方式在无意识中时时刻刻受到企业这个庞大而复杂的系统驱动，长期下来，整个人生的轨迹可能都因此而变化。

很多人以为创造一个“敏捷”的IT企业，等同于使用被传得神乎其神的敏捷项目管理方法。然而事实并不是这样的！

Sriram说组织的方方面面都在时刻影响着产出，一些细节也不容忽视。说到底其实很简单——一切务必以业务产出为目标。今天我们就谈谈以下几个方面：

• 组织结构、团队设计
• 管理、负责人选择
• 达成共识
• 项目管理、经费预算

组织结构、团队设计

除了像HR一类与业务不紧密相关的团队外，主要以业务成果为导向设计组织及团队结构，制定相应的目标，而不能简单地用职能划分团队。

将多职能人员组为一个团队，将有效简化和减少多个不同职能团队间的交流消耗。如前后端分离作为两个团队存在时，通常需要后端提供详细的接口设计文档，并因为前端对后端实现限制和数据来源的了解有限，经常会有很多个来回的修改讨论。如果大家坐在一起面对面完成程序，解决问题会比较快，交流的效率也比较高。但多数情况下两个团队人数上涨之后，会相隔较远，甚至经常遇到不熟悉的新人。如此不善交际又比较宅的程序员通常选择用Email、聊天程序来来解决问题，实在不行的时候再拉个会议，如此一来，交流成本大大上升，项目交付的时间自然被延长了。

当以职能划分团队时，只有少数人以业务产出为目标，当混合职能以业务划分团队时，整个团队都统一以业务产出为目标。试想一下如果整个前端团队汇报给一个前端主管，队员们分别接手来自不同业务部门的需求，这些业务部门的成功与否与这位主管有关系吗？不，业务部门的产出也许会给前端主管的业绩增光添彩，但并不是必要和能令他获得更高奖金、晋升的部分。相较之下，业务外的技术产出才能凸显他的领导能力卓越。那作为队员，为了使自己获得主管的另眼相待和高度评价，就得将心思和精力更多地花在业务外的技术产出上，越是炫酷复杂，越是能博得技术人的眼球，能不能解决实际问题是其次，至于业务需求按期保证质量完成就好，追求更好没有什么意义。

管理、负责人选择

首先，一个业务产出只能有一个业务负责人。相信不少人有过一个项目有多个负责人的痛，因为职责划分的模凌两可，项目出了问题谁也没法做决策，互相推搡踢皮球，以致项目难以进行。只有一个业务负责人与业务产出利益相关的时候，他才会尽职尽责，为业务成功尽可能快尽可能好地做出有利于产出有利于团队的决策。

并且，计划和执行的负责人必须是同一个人。只负责计划，不负责干活的人不知干活的痛和苦累，往往容易向上做出不合理的承诺，出问题则推脱给干活的。而干活的人没有权利做决策，事事需向上汇报请求批准，费时费力。来来回回，项目推进自然缓慢。因此Sriram建议，负责人是执行者之一，他拥有项目决策的权限，而上级可以作为监管存在，必要时覆盖不合宜的决策。

这样组织结构就更复杂了，为了避免大家混淆和争议，可以发布一张清晰的负责人表让大家知道找谁决策。并建议发布决策的记录，增加透明度，减少争议。

此外，企业有必要根据业务是已成熟的，还是开发中非常有潜力的，或是全新孵化中的情况来选择合适的业务负责人（参考麦肯锡3-horizon模型）。

达成共识

只跟着业务主管走也不见得完全好。懂技术的业务主管可是珍贵的稀缺资源不容易遇上。而不够懂技术的人常常容易低估现有技术的限制，以及技术实现的复杂度，而做出错误的判断，如给开发预留的时间不足，忽略长期收益，不重视技术质量等等。因此，一些职能主管还是有必要存在的。

但是一个人不好同时汇报给两位主管，夹在中间不好做人对吧？对此，Sriram建议职能主管可以进行团队自治，但不能作为权威的存在压过业务主管的决策，确保以业务产出为主。

以业务产出为导向的时候，有可能发生的一个问题是业务负责人或者上层不懂IT的小伙伴费时费力搞架构的意义，但是技术架构是必要的存在，这时需要技术方提供明确的架构设计以及每项设计的目的（提升业务的什么方面）有助于达成共识，顺利推进。

项目管理、经费预算

项目则要以产出价值为导向而非完成计划。

我们常常会在项目开始前计划交付的时间截点。如果不幸无法按时保证质量的同时交付，第一个考虑牺牲的便是质量。你有没有过来不及自测，直接把未测试过的程序扔给测试，结果测试发现问题太多反而更令人头痛？如果这不够痛，让我举个严重点的例子，前两年的如日中天的三星发生了Note7爆炸事件，这样严重和容易发生意外的电池缺陷如果有足够多的测试还能进入市场吗？也许当时所有部门完美地按时完成了任务，最终对整个企业造成的却是巨大的亏损。如果以产出价值为目标而不是时间节点，延一下期或许能获得更大的价值的时候，何乐而不为呢？

除了时间外，经费也通常是计划的一部分。有些企业习惯在每年年初或年底时提交下一整年的经费预算，这个数字多了也不好，少了也不行。少了，万一不够用怎么办，多了，到每年经费使用截止日期就得设法花出去，否则就说明其实你不需要这么多经费，下一年批这么多没有意义。如此下来，怎么能确保企业的钱都花到了点上？

Sriram建议企业考虑风投的模型，给项目负责人为自己花的每一分钱证明其价值，并使用预算协作工具追踪辅助等。这让我想起了Netflex传说中只要以公司利益为考虑就可以报销的“自由”报销政策。

放宽了时间和金钱的管控之外，我们还可以进一步减少无谓的消耗，提升投入产出比。比如长期的项目拥有固定的维护团队，而不是临时拉人维护，更不能寻找短期外包，每一次交接都是一种消耗。再如项目的数量得根据组织的交付能力限制数量，项目数量超出负担能力不仅拖累更多的项目，员工也身心俱疲不利于整个企业的发展。

最后

以上只涵盖了书中的一部分内容，200多页的书中压缩了非常多的观察和改进的建议，这导致了这本书有个巨大的缺陷——讲得比较粗糙，没有足够深入的讨论。即便如此，对我来说已经得到了不少干货，足以慢慢回味吸收。