如何激发团队潜能？

每一个技术人员最终可能都会走上管理岗位，从最初的开发 Leader、到部门负责人、甚至到 CTO,这每个角色的转变，都须要付出巨大的努力去进行思惟的转变。最近读的《受权》这本书可让咱们更好地胜任管理这个岗位。

本书的做者马凯特是一名海军军官，全书讲解了做者在 1999—2001 年指挥美国海军圣塔菲号攻击型核潜艇，在一两年的时间里将本来管理混乱、士气低落、倒数第一的圣塔菲号打形成太平洋舰队中凝聚力、战斗力俱佳的舰艇，并赢得不少奖项。

书中以在圣塔菲号上发生的各类事件为例，讲述了不少观点和方法，印象比较深入的有如下几点：

• 领导者-追随者到领导者-领导者的转变
• 我计划...
• 重要的事情反复强调
• 高于本身的职责
• 流程是把双刃剑
• 鼓励质疑
• 追求卓越，而不是减小错误

领导者-追随者到领导者-领导者的转变

能够说，大部分的企业以及马凯特领导以前的圣塔菲号潜艇的管理方式都是「领导者-追随者」模式。员工都是听「命令」作事，能把安排的事情按时完成就已经很不错了。

有一次，马凯特下命令将电力推动装置的转速由 1/3 提高到 2/3，命令一层一层地传达到最底层的执行人员，才反馈说电力推动装置没有 2/3 转速。其实在接收第一道命令的人员就知道没有 2/3 转速，但由于是上级下达的命令，即使是错误的，仍是照常执行。

咱们平时工做中，相似的事情家常便饭，因此说在「领导者-追随者」模式下，领导者的能力和眼界就成为了团队的瓶颈，不能充分发挥每一个人的才能。

而「领导者—领导者」模式的核心是让员工有充分的决策权决定作什么和怎么作，整本书就是在讲解怎样慢慢转变成「领导者—领导者」模式。

我计划...

「我计划...」是一种具体的手段，指的是，在汇报工做时，以我计划做为开头，后面接本身准备怎么作，以及可能有什么风险等。目的是为了让员工能主动思考，而不是被动接受。

现状

领导：小王，系统中须要添加日志功能，可使用 log4？
小王：功能已经实现了
领导：日志能存储到数据库中吗？
小王：如今只能记录到文本中
领导：不一样类型的日志有区分吗？
小王：如今只记录在一个文本文件中
领导：......

改进后

领导：小王，系统中须要添加日志功能，想一想怎么实现？
小王：在 dotNET Core 中，比较流行的就是使用 NLog 和 Serilog，我对比了下两个组件，Serilog 的扩展性更好，有不少的插件可使用。我计划这样来实现：

• 日志大类能够分为，系统日志和业务日志，系统日志用来定位问题，业务日志能够用来作审计；
• 每一个类型中能够根据不一样的日志级别进行分类处理；
• 可使用 dotNET Core 的过滤器或中间件来实现日志记录，方便代码维护，使用过滤器仍是中间件，我须要作进一步分析；
• 暂时能够先记录到文本文件中，后续若是须要扩展数据库或其余方式也很方便。

领导：好的，按照你的思路先实现一版吧。

上面的例子不必定恰当，但应该能说明问题：
一、领导早安排任务的时候，不能条条框框限制太死，须要给员工足够的空间；
二、员工在汇报时，应该有本身的独立思考，尽量多的想到各类状况，若是存在多种解决方案时，能够都给出，并给出本身的建议和推荐理由，这样领导只是作下确认就能够了。

重要的事情反复强调

当你引进一些全新的、亘古未有的东西时，有些人可以明白，在圣塔菲号上，咱们确实有一些军士长立刻就明白了，好比沃尔舍科高级军士长和拉森军士长；有些人过一下子明白了；另一些人则要花很长时间才能明白。

什么是重要的事情呢？

• 公司的愿景
• 团队的目标

每一个团队成员只有充分理解了公司的愿景、团队的目标，才能将本身的我的发展和此联系起来，实现共赢，但每一个人的理解速度有差异，因此须要反复强调，不能嫌麻烦。

好比目前咱们团队的目标就是按时交付高质量的迭代版本，那么只要是和团队开会、或私下沟通讨论，都会反复进行强调，直到每一个人都可以深入理解，理解以后才可能愿意更多地去思考，才可能在具体执行的时候更贴近团队目标和公司愿景。

高于本身的职责

每一个人都很习惯作「份内之事」，缺少思考，长时间下去就会从一个初学者变成一个熟练工，工做 10 年，也就是 1 年的工做经验重复了 10 年。持续思考，总结，提高本身的技能而且能同时朝着团队目标和公司愿景在前进，这样你的能力才会超出你的职责，才有升职加薪的可能。每一个人都能如此，团队也就变得强大了。

最近有团队成员和我沟通，说天天都只是在改改 Bug，作一些小功能，感受没什么挑战，这就是典型的将本身局限在「份内之事」的表现。

再简单的事情也能作到极致，前提是要清楚本身要作什么，在作什么。在开发中最怕的就是开发出来的东西不知道是作什么用的，只是按照要求这样作了。

因此在工做安排或者会议沟通时，须要添加一个环节：反向交底，分配的任务，每一个人须要说出本身的理解以及「我计划...」，会议沟通时，也不能最后问一句，你们还有问题没有？而后没人回答，就此散会了，也须要每一个人都谈谈我的的理解，每一个人都能理解，会也就不白开了。

流程是把双刃剑

任何公司都有各类各样的流程，流程是手段不是目的。流程能够帮助咱们进行管理，但必定不能受到流程的束缚。

由于潜艇部队并无将救火做为核反应堆操做人员的训练科目。海军所倡导的理念是：最好的操做应该是由最专业的人员按照标准工做流程进行的。

由于流程规定救火只能是专门救火人员才能进行，因此，在演习的时候，有一个地着火了，结果周围的人所有都撤离。潜艇的走道是很是狭窄的，这些救火的人根本过不去，那边要撤退的人也撤不出来，卡在那儿。而后那边的火越着越大，若是真的是着火的话，就会形成严重的后果。

若是是朝着灭火的这个目的，确定是离火最近的人拿起灭火工具把火灭掉就能够了。

鼓励质疑

可以独立思考，才有可能提出质疑，在「领导者-追随者」模式下，每一个人都是你说什么我作什么，都认为领导说的是对的，那质疑就无从谈起了。

鼓励质疑是发挥集体智慧的一种手段，领导也不是神，也有会出错的时候，这时若是可以有及时的质疑，就能避免一些错误的发生。

追求卓越，而不是减小错误

在平时的工做中，由于有各类考核手段，每一个人都惧怕出错，写程序时惧怕出 Bug，那有没有不出 Bug 的程序呢？答案是：有，具体能够看看 Github 上的这个项目：https://github.com/kelseyhightower/nocode 。

固然，那个项目只是个玩笑，只要有代码输出就可能会有 Bug，若是是一个追求卓越的程序员，会想办法去作重构，让代码变得更易读、扩展性更好，在这个过程当中可能会出现新的问题，咱们应该多思考怎样来解决问题，而不是规避问题的方式来减小错误。

以不断减小错误的方式行事，最后结果就是金玉其外败絮其中，后果终究仍是要本身来承担，至今尚未谁能打破墨菲定律。

总结

马凯特经过「领导者-领导者」的管理模式使将圣塔菲号有翻天覆地的变化，更厉害的是在马凯特离开圣塔菲号十年内，这里仍然人才济济，领导力获得了传承，这才是最高境界。

若是领导者老是试图「事事亲力亲为」并依靠自身「人格品性」，他们一旦缺席，将会给组织的表现带来巨大影响。

推行一种新的方式始终是困难的，但不试试怎么知道呢？