# 问责制
问责制有助于人们审慎地使用自治权,明确责任有助于澄清决策权与建议权,帮助避免决策僵局,并提高响应能力。在这个组织设计中,如何明确责任,以及如何解决因计划与执行分离而导致的责任扭曲是重点要解决的问题。
有些人可能对在IT组织中使用权利这种字样会感到不适,权利是贬义词,影响力才是关系重大。然而这并非事实,在大型组织里,很多时候只有身居要职的人才能发挥影响力,成熟的组织中,理论上并不需要正式的权利,但在实际的实践中不可或缺。在人们在工作中已经养成了对环境和领地进行控制的习惯,承认对权力的渴望是走向遏制它的第一步。我们建议限制组织的层级,但是并不反对层级。
一定层级对组织的运作必不可少,完全消除层级往往会导致决策缓慢和责任分散,没有明确领导的工程团队可能会在设计解决方案时来回纠结以至于无法定版,没有明确领导的分布式团队可能会因为没有人确保齐心协力而失去领先优势。当层级缺失时,就会出现非正式的层级,如果团队没有正式的结构,那么将只有少数人知道决策规则,知道规则的人会有权利意识,那些既不清楚规则,又不得不工作的人,将会深陷困惑。
在这个背景下有些团队开始试着学会守护层级:建筑部门墙以免团队受外部干扰,扩大团队规模,保护逐渐增长的预算和资源,开始热衷彰显团队的成就,最终走上局部优化的歧途。这些问题的根源是权利的滥用,而不是权力的本身,为了阻止这种情况,我们需要有针对结果的明确问责机制。
组织设计的目标之一是鼓励自主性,但自主性必须和企业目标保持一致,因此需要借助于问责制来加以平衡,在组织中,自主性也需要授权,团队的行动自由需要得到权利的支持。人们在处理某事之前,要明白自己在此事中有哪些责任,为了对结果负责,人们需要有决策的权利,而不仅仅是执行的责任。因为明确分配责任很困难,所以高管们常常想回避这个问题,甚至希望下属自行解决,这样一来,管理体系就会陷入混乱。
可以利用责任地图描述谁应该对什么成功负责。画出组织结构图和业务成果图,然后再将组织结构图中的节点与树中的成果连接起来。当有多个人或团队对成果负责时,领导层就会对他们排定级别以明确责任线。责任线中的第一人有权推翻第二责任人或第三责任人的决策。
当职责分配不清晰时,经常会出现集体拥有权利但没人承担责任的情况,集体所有制在团队内部效果比较好,最常见的例子是代码所有制,在集体代码所有制中也有名气的问责制度:敏捷团队有版本控制和持续集成,“破坏构建”是一个非常明确的问责机制。在敏捷团队中,技术负责人对设计决策有最终的权利和责任,产品负责人对实现哪些特性有最终的权利和责任,而高层领导的工作是明确所有权。要把所有权落实到责任映射地图,责任地图最好让所有人看见,它清晰的阐述了谁都什么负责,帮助解决决策僵局并加快决策速度。
在没有明确责任人的情况下,分歧可能会进一步加大,经常需要上升到更高级别的人才能打破僵局,会议和电子邮件过多是角色不明确和责任缺失的常见症状。当决策权不明确的时候,邀请所有人参加会议,所有的电子邮件也会抄送给每个人,收件人也不确定哪些会议该参加哪些会议该忽略,所以他们会选择尽可能在老板参与的会议上多露面,而大多数会议和接收到的邮件都只是做一个沉默的旁观者,没有任何话语权。当角色不明确时,我们就不知道谁与什么讨论有关,因此只好让一大堆人参与几乎所有的事情。责任地图可以很好的解决角色重叠造成的困惑。
组织内的团队和部门都是社会系统,组织要高效的运作,就不能忽略人与人之间的互动,例如职能部门与产品、研发团队的互动。矩阵式的组织按照专业分工来进行组建,如果成功负责人所需要的资源由职能领导来掌控,就会埋下权利斗争的隐患。职能领导往往不对成功负责,却控制着工程、支持、运营等专家资源,而且在多矩阵式的组织中有很多潜在的政治斗争,这样就很难形成高效的跨职能团队。让所有职能领导听命于成果负责人,是一种防止政治行为损害成果的办法,但是这会剥夺职能领导的自主权并且打击其积极性。那么,如何构建组织才能在职能领导保留自主权的同时,由避免滋生权利斗争呢?
可以将影响力职位和权力职位放到平等的位置上,合作设置在西方被称为“教授和企业家”模型,在这个模型中成果负责人是企业家,职能领导是教授。在这种配置下,职能领导拥有自主权,但对资源没有控制权,他们仍然决定自身领域工作如何进行,但是没有人向他们汇报,他们也不负责安排任何人的时间,这时候他们就像敏捷教练一样进入团队开展工作,而不是拥有团队,他们可以自由决策,但其决策可能会被成果负责人否决,职能领导不像成果负责人汇报,如果其与成果负责人有分歧,可以向高层报告,职能领导和成果负责人拥有同等待遇。
成果负责人的选用可以根据麦肯锡的“三个地平线框架”来帮助做决定,H1代表成熟的业务线,其重点是维持或提高市场表现,使剩余价值最大化,这条线的产品需要销售能力强,善于与人打交道的成功负责人。H2指有巨大增长潜力的新兴业务线,成果负责人需要精通产品。H3像是新想法和实验的孵化器,需要有想法且能有落地能力的人来负责。
当然为结果负责也要包含失败,组织需要有人对失败负责,解释失败的原因并承认错误。错误有两种类型,一是行为错误,也就是做了不该做的事,二是不作为错误,即没有做该做的事。如果团队可以承担眼前的错误,就能够很容易从中吸取经验。
在组织中,计划和执行角色分类导致的责任悬空是造成失败的一个很重要的原因。规模较大的组织需要一定的层级,一定程度的分工是必须的,然而层级和分工也会带来一些问题,执行交付的软件,兑现业务成果的目标和计划中间至少隔着一层总层领导,而这些人的除了开会,他们可能不会直接与执行人员一起工作,也不直接服务于客户。一般情况下,层级倾向于将决策权集中于高层,这会侵蚀执行者的自主性,损害他们内生的动力,计划和执行分离进一步加剧了这种侵蚀。
为了弥合计划和执行之间的鸿沟,我们可以将职责重叠起来。比如在组织内要求计划人员投入20%的时间来从事实操工作,架构师要花一些时间进行编码、性能测试、技术债处理等工作。高级别领导可以花一些时间为部署脚本和持续集成等基础设施提供支持,项目经理可以安排时间进行软件测试,业务人员帮助产品经理编写用户故事和验收标准,甚至他们可以每周花一点时间来与研发团队进行结对。
职责重叠是获得团队信任的方式,这种做法比空谈和做计划能更好的领导团队,定期参与执行工作有利于我们了解现实情况,从而更好的做计划。另一个好处是,通过换位思考,可以让团队的不同人员获得新的视角,这会带来更为明智的决策。当执行人员体会计划这个角色的时候,他们也会慢慢的理解组织的一些通常不易捕捉的困难。