技术管理学习组织者

本文是刘建国技术管理课程的学习笔记，该课程非常适用于一个即将走入技术管理或者刚走入技术管理的工程师。

整体概述及导读

1. 角色认知，关于角色认知和角色澄清的方法论
2. 管理规划，关于带着团队看方向的方法论

• 职能，关于如何澄清团队职能定位——回答团队核心价值的方法论
• 目标，关于目标设定和目标管理的方法论
• 团队，关于团队规划的方法论
• 路径，关于路径选择和成本预算的方法论

3. 团队建设，关于如何带人的方法论

• 能力，关于如何培养员工工作能力的方法论
• 激励，关于如何提升员工工作意愿和积极性的方法论
• 分工，关于如何做团队分工和组织架构设计的方法论
• 协作，关于如何提升团队凝聚力和默契的方法论
• 梯队，关于如何进行梯队建设的方法论
• 文化，关于如何打造团队文化价值观的方法论

4. 任务管理，关于如何做事的方法论

• 轻重缓急，关于如何排优先级的方法论
• 有效执行，关于如何做项目管理或项目执行的方法论
• 流程机制，关于如何通过流程机制来提升工作质量和效率的方法论

5. 管理沟通，关于如何有效沟通的方法论

• 目的，关于如何明确沟通初衷和目的的方法论
• 内容，关于如何确保信息有效传递的方法论
• 通道，关于如何建立和增进沟通关系的方法论
• 职权影响力，关于不断理解职能影响力的方法论
• 非职权影响力，关于提升和运用职权之外的影响力的方法论

本文主要从这五大方面、18 个要素去按图索骥地、系统地介绍管理的框架和方法。下面整理了管理的脑图，方便快速温故。更细致的介绍见下面各个部分的详述。

什么是技术管理

怎样的人才能做好技术管理

1）认同管理的价值，那些“琐碎杂事”如协调、沟通、梳理、推进等都是有价值，关于这一点，期望更高级Leader能够承认一线技术管理者在业务产出方面的贡献，这是一线管理者做技术管理的核心动力。即使有很多人都认为你适合做管理，而如果你自己不认为管理是有价值的，你是不会开心地长久做下去的。
2）热爱做管理，享受计划、拆解、协调、梳理、汇聚的过程，再强的个人产出也是有限的，协调好团队可以达到N倍产出效果。管理是做平台，好的平台能将团队中每个人的价值放大。
3）具有大局观，技术管理意味着更大的责任、更立体的视角、更灵活的思维方式。技术管理者的局限决定团队产出的上限。关于更大的责任，互联网领域，管理者带一个团队，更多是意味着要承担更大的期待和责任。即便有时看上去有一定权力，但归根结底，还是为了更好地实现团队目标，基本体会不到行使权力的快感；更立体的视角，在做工程师的时候，只要做好上级交代的任务就好了。而一旦做管理，为了带好整个团队，就需要考虑上级、下级、平级的期待和诉求，而且不能只是关心“眼前”，还得关心“从前”和“以后”，提升看待问题的系统性；更灵活的思维方式，多年的技术工作训练，你一定有很强的确定性的思维方式，讲究界限清晰、对错分明、言出必行、不出差错，往往靠谱就是你的代名词，而很多管理工作却是充满着不确定性的，有些工作的执行边界也是模糊的，甚至是非对错都很难界定清楚，在各种不确定因素中，却要去追求一个明确的目标，这对于很多新的技术管理者来说，思维方式会受到很大冲击。

怎样走入技术管理岗位

天时
“天时” 做管理的“天时”，其实就是机会、时机、大环境、时代背景。如果你要做管理，最好选择那些发展快的行业和公司，这意味着更多的机会。当然更多的机会也意味着更多的挑战，如果你希望工作得舒服轻松一些，依然可以去稳定的行业和企业工作，但在稳定的行业要走上管理岗位，可能就需要漫长的等待了。
地利
做管理的“地利”，就是你的优势、能力，以及你所负责的工作内容。如下这些工作内容的工程师，更容易成为管理者:
第一类是负责最全局的模块，核心是“广”。每一个团队的业务，都会分成很多模块，总会有那么几个模块是事关全局的，也是跟大家关联最多的，比如提供所有的服务接口、做所有的数据组装和呈现、产品功能的实现等等。这样的工作内容，使得负责的工程师很快锻炼出全局的视野、积极的沟通协调能力，并和很多人建立起合作关系。做得好的话，很快就可以成为一个团队的工作核心。因此，很多技术人是这样走上管理岗位的，他们往往管理成熟度也高，成功的概率很大。
第二类是负责最核心的技术模块，核心是“深”。这个就容易理解了，掌握着团队最核心、最重要、最有技术含量、最能体现团队价值的模块的工程师，是团队里的骨干，不可或缺的技术核心，容易得到上级重视去承担重任。他们往往影响力比较大，所以容易走上管理岗位，不过常常是被动的。有一点需要注意的是，这类工程师即便能走上管理岗位，很多管理的意识和能力还是需要修炼的，因为他不像第一类天然就有锻炼全局视野和管理技能的机会。但无论如何，他们也是容易脱颖而出的。如果你主动去了解技术和业务的全局，并主动争取做一些大型项目的负责人，你就具备了做管理的“地利”，前提是你先认识到这一点。
人和
“人和” 做管理的“人和”，就是你能否得到他人的支持。需要得到以下4类人的支持：

• 第一类，为你提供机会、平台和资源的支持。一般是你的上级，他们是否支持你做管理非常重要。
• 第二类，为你提供陪伴和共同成长的支持。一般是和你平级的管理者，尤其是那些你愿意与之持续交流、切磋管理问题的伙伴。当然也可以是之前的同学和朋友，还可以是一些管理社群。总之，你可以根据自己的情况和喜好来看看，谁可以做你的管理伙伴。
• 第三类，为你提供指导和前进的方向。一般是你的导师、指导人、管理教练或上级。你可以设定你认可的管理榜样，多和他交流，多听听他的看法和意见，这会让你的管理之路顺畅很多。
• 第四类，为你提供情感支持，让你勇于面对困难和挫折，在管理之路上走得更远。一般来说，你的家人和朋友，可以担当这样的角色。
  盘点以上四类人，并寻求他们的支持，尤其是稳定的支持，就构成了你做管理的“支持系
  统”，满足了你的“人和”。

技术管理初期的患得患失

技术管理者初期会存在以下3种想法：

1. 转管理之前没有仔细了解过管理。管理几乎是一个全新事物，在全新事物面前，因为无法掌控而感到或恐慌、或焦虑就在所难免了，担心做不好退路在哪里。
2. 才开始做管理，还无法靠管理“安身立命”。至少在他们自己心中，管理能力并不能让自己安心，更不能让自己依靠，就好像还没有完全驯服的野马，还不确信能骑好。
3. 认为技术才是自己的“大本营”。由于技术作为自己依存的资本，在过去的工作中已经得到了很好的证明，因此非常值得信赖。所谓“成功路径依赖”，每个人都大抵如此，尤其是做事特别讲究精确与可靠的技术人，自然在所难免。

专门针对“患失”
做技术管理并没有放弃技术，而且也不能放弃技术，放弃了技术是做不好技术管理的，你只是在一定程度上，放弃了编码而已。那么，都没时间编码，怎样才能做到不放弃技术呢?
首先，把技术提到更高视角来看待。做技术的时候，把技术做好就是最大的目标;而做了管理之后，你会把技术作为一个手段来看待，看它究竟能为目标带来什么。但这并不意味着你就不再关心技术，只是关心的层次不同了，你开始需要借助每个人的技术能力去做更大的事情了。
其次，换一种学习方式来掌握技术。你要深刻地认识到，亲自写代码固然是很好的学习技术的方式，但是作为 leader，你需要快速掌握更多的技术，并且快速判断该如何搭配使用，所以技术管理者需要持续的学习新技术。
如果技术本身就是你的优势，你完全可以结合自己的兴趣和优势，打造出自己的管理风格。
总之无论从哪个方面讲，你都并没有放弃技术，只是换了一种方式去学习和运用技术。所以，你不会失去什么，也不需要“患失”。
专门针对“患得”（ 这里的“患得”其实是患“不得”）
那么怎样才能不再担心做不好管理呢?
首先，做管理对个人成长和个人发展来说，不会失败。因为管理总体上是一项修炼，只要你持续不断地实践、练习，你的造诣就会越来越高，最后你一定可以胜任某个规模或某个职能的团队。我们通常所谓的“不胜任”，只是说不匹配，而不是说你就完全做不了管理。而且，管理是很个性化的工作，你完全可以使用自己擅长的方式，去达成管理效果。
其次，一线技术管理者，即便“做不好”也并非没有“回头路”。刚刚从工程师岗位转到管理者岗位时，离技术很近，如果尝试下来，感觉管理工作确实不是自己想要的，那么，回过 头来继续做工程师，几乎是没有门槛的。所以，如果当下不知道自己适不适合做管理，不如全力以赴去尝试一段时间，你其实还有充足的时间来慢慢做这个决定，不需要有后顾之忧。
最后，做管理所积累的能力，完全可以迁移到做“技术带头人”或“技术 leader”这个角色上。所以，你都不用担心管理的工作会白做，或者本来可以做技术的时间被耽误了。因为，即便你再回头去做工程师，也需要练习去做高级工程师或架构师，需要尝试去负责一个完整的技术方向，此时，你做管理时锻炼的全局视野、规划能力、结果导向意识、项目管理方法、沟通协调能力等等，都会派上用场。
所以，我开出的第二个药方就是:你一定会有所得，会在做管理过程中有丰富的收获，既然 一定能“得到”，所以不需要去“患得”。
“认清现实”
随着工作年限和阅历增加，工作“升维”已不可避免。一方面，每个人的内心都有成长的诉求;另外一方面，公司和团队也需要你承担更复杂、更具挑战性的任务。所以，无论是做技术管理，还是做技术架构师，开启一条技术升维之路，都在所难免。即便不做技术管理者，要做好一位技术带头人或架构师，工作视角也要做如下的升级：首先，从目标出发去看待技术，只有目标明确，才能选择最佳的技术方案，做出最好的技术决策。其次，从评估的角度去看待技术。做工程师的时候，把一个技术方案设计好、实现出来就好了，而做了架构师之后，你需要非常清楚一个技术方案是通过哪些维度来评估其好坏优劣的。最后，从借助自己的技术到借助大家的技术。做技术的时候，了解自己能做什么就好了。但是无论是做管理者还是架构师，你都需要带人做事了，这个时候你就需要熟悉团队里每个人的技术情况，知道谁能胜任做什么事情，适合做什么事，然后借助大家的技术去做事。
综上你可以看到，即使是放弃管理继续做技术，从工程师进阶到架构师，也一样有很多的视角需要转换，有很多的能力需要锻炼。

总之，技术转管理的纠结，归根结底是“对管理的患得和对技术的患失”。既然你已经看到，做管理不会让你“患得”，也不会让你“患失”，那么你是不是可以安心奋力一搏。

如何保持技术判断力

技术判断力就是指对技术的评估能力。作为一个技术管理者，即技术应用者，要评估的维度主要是以下三个方面:
第一个维度是结果评估。用什么技术指标来衡量团队的某项技术工作，而不只是完成一个个项目。事关每项工作的效果和业绩，对结果的评估能力最为关键。虽然结果验收都是放在项目完成后，但是在事先就要明确如何验收，这样才能让大家有的放矢，以终为始。

第二个维度是可行性评估。可行性有两层含义:一是“能不能做”，二是“值不值得”。 能不能和值不值得，是两码事。有经验的技术管理者和资深工程师，考虑的是“值不值得”。
所谓“值不值得”，包括当前一次性的ROI，也包括技术维护成本，我们往往只考虑到项目发布，而发布后的维护成本很容易被忽略。常见的技术维护成本有如下四个方面，依次是:技术选型成本，越成熟的技术，其技术实现成本和人力成本都是相对要低的，但是并不是说，选择新技术就一定不划算，只要考虑到成本和风险，才能做出合理决策；技术升级成本，这是指在评估技术方案的时候，其兼容性和扩展性水平带来的后期升级的难度和成本；问题排查成本，在做技术实现的时候，要特别关注后续的问题排查。代码维护成本，在编写代码的时候，要记得代码是要有可读性的，这体现在别人升级代码要花多长时间才能看明白，修改起来是否简单、安全。
跨团队项目一定要考虑协作成本，即多人协作所增加的时间精力开销。一个方案的协作方越多，需要沟通协调的成本也就越高，可控度越低。如果可能的话，尽量减少不同团队和人员之间的耦合，这样会大大降低协作成本。

第三个评估维度，即风险评估。技术风险评估，也叫技术风险判断力。即有哪些技术风险需要未雨绸缪，考虑该技术方案带来最大损失的可能性和边界，以及在什么情形下会发生。 这项评估工作很考验技术管理者的技术经验和风险意识，而且需要借助全团队的技术力量来做出准确判断。

如何提升自己的技术判断力呢?
判断力不是天生的，也不是一蹴而就的。新经理的技术判断力，基本都来自于之前技术上的实际操作，来自于自己的经验积累。而做管理之后，技术评估方面的要求更高了，研究技术的时间和精力却减少了，这该怎么破?
别忘了，自从你带团队的那一天起，你就已经不是一个人在战斗。所以，你可以依靠团队和更广的人脉，去拓展技术视野和技术判断力。常见的几个方式如下:

1. 建立技术学习机制。盘点你负责的业务，需要哪些方面的技术，成立一个或几个核心的 技术小组，让团队对各个方向的技术保持敏感，要求小组定期做交流和分享，这样你就 可以保持技术的敏感度。
2. 专项技术调研项目化。如果某项技术对团队的业务有重要的价值，可以专门立项做技术 调研，并要求项目负责人做调研汇报。
3. 和技术大牛交流。越是厉害的技术人，越能深入浅出地把技术讲明白，所以针对某项技 术找大牛取经，也是学习的好途径。你看，虽然实际操刀的时间少了，但是你和技术大 牛的交流机会多了，一方面因为你有更大的影响力了，另一方面，你和大牛有了共同的诉求，就是把技术“变现”，让技术产生价值。
4. 听取工作汇报。因为你带的是技术团队，大部分工作都和技术相关，在读员工的周报、 季度汇报时，相互探讨，也是一种切磋和学习。
   总之，你会发现，技术管理人的技术水准的提升和保持，主要看能从周围人的身上汲取到多少信息和知识，而不再只是靠自学。
   归根结底，从技术实现者到技术应用者的转变，不断提升的是技术的使用能力，而技术实现能力由于投入的时间越来越少，会逐渐减弱。

管理风格

所谓管理风格，本质就是你和团队的协作方式，也就是你和团队的“位置关系”，即你站在团队的什么位置。可以总结为以下四种：

• 指令式管理:重事不重人，关注目标和结果，喜欢发号施令但不亲力亲为。
• 支持式管理:重人不重事，希望带头冲锋亲力亲为，特别在意团队成员的感受，并替他们分担工作。
• 教练式管理:重人也重事，关注全局和方向，并在做事上给予教练式辅导和启发。
• 授权式管理:不重人也不重事，关注目标和结果，不关心过程和人员发展。

这四类风格无所谓谁好谁坏。一个成熟的管理者应该对这四类风格都能有很好的了解和认知，甚至是能驾驭。
在不同的场景下，的确会有不同的适用程度，下面简单列出几个场景做一些说明:
当一项工作不容有闪失，而你又是唯一熟悉、且最有掌控力的人时，一个命令式的你可能更能降低风险、达成目标。所以，命令式管理最适用于需要强执行的场景。
当一个团队特别需要凝聚力和斗志，需要攻坚的时候，一个支持式的你会促成很好的效果。所以，支持式管理特别能带团队士气和凝聚力，在带动大家热情和积极性方面很有优势。
当有一些核心人才需要重点培养，团队需要发展梯队的时候，一个教练式的你会带来明显的效果。他们不但能把事情做好，个人能力还能成长。虽然执行速度通常不会太快，但是不会偏离方向。
当团队梯队很成熟，团队成员需要发挥空间的时候，一个授权式的你能提供最恰当的管理方式。
当然，如果你能驾驭多种风格，那是非常厉害的。大部分管理者都还是以自己最拿手的风格来带团队，其他方式仅在必要时使用。

如何快速转型技术管理

新经理不自信的来源，主要是如下几点:
第一，管理经验不足和能力欠缺。对于很多管理事务不知道该怎么着手，在摸索前行中磕磕绊绊，于是怀疑自己没有能力做好管理。
针对这一点，能力是相通的，能做好技术已经证明了你的能力，坚信你一样可以做好管理。模仿是积累经验的第一步，你可以模仿之前工作中你觉得类似管理做不错的领导的方式，依葫芦画瓢。同时换位思考，你刚从技术转变过来，你清楚你作为技术时的心态和想法，换位思考就知道团队成员期待的是什么。

第二，和团队成员对立比较。由于资历或能力不是团队里最突出的，担心团队里资历老或能力强的团队成员会不服自己，尤其是当这些人提出不同意见的时候，常常会引起新经理的挫败和颓丧。
针对这点，团队的负责人需要把自己从和任何团队成员的比较和竞争中抽离，把目光投向远方，去看看你将带出一个什么样的团队，以及在这个过程中，你能为公司、团队和各位团队 成员带来什么样的成绩和成长。你要做的不是管束和控制大家，而是引导和支持大家。

第三，背负着沉重的包袱。因为担心管理工作做不好会辜负上级的期望，所以带着很大的压力去工作。
针对这一点，建议先把反馈通道建立起来，尤其是和上级的沟通通道，可以和上级约好一个例行的沟通机制，定期汇报团队工作，并就已经完成的一些重要工作征求上级的看法和评价。这其中，改进建议固然是很宝贵的，但是你还需要寻求一些肯定性的反馈。

管理做什么

“现代管理学之父”彼得·德鲁克认为，“管理是一种实践，其本质不在于‘知’，而在 于‘行’;其验证不在于逻辑，而在于成果。其唯一权威就是成就。”他这个说法的焦点在于实践性和结果性。众所周知，德鲁克是“目标管理理论”的创始人，尤其强调“目标”。
当代管理大师斯蒂芬·罗宾斯给管理的定义是:“所谓管理，是指同别人一起，或通过别人使活动完成得更有效的过程。”这个说法的背后蕴含着管理的三个要素:人、过程和有效，用正式一点的词汇叫组织性、过程性和目标性，强调了“带人”“做事”和“目标”。
管理工作可以分为角色认知、管理规划、团队建设、 任务管理和管理沟通五个管理要素。
其中，角色认知存在于管理工作的一言一行、一举一动，它无处不在，就好像空气一样，这是做好管理的基础和前提;而管理沟通贯穿于所有管理工作之中，把所有相关的合作方都连接在一起，就好像水流一样，是做好各项工作的手段和载体。管理规划、团队建设和任务管理，就是管理者的工作内容了，分别对应着看方向、带人和做事，这和近代几位管理大师的 观点也是统一的。
我们把无所不在的空气般的认知作为“天”，把承载一切管理工作的沟通作为“地”，把管理者需要做的看方向、带人、做事放在中间，就组成了管理者的管理框架，由于看上去像一块三明治，我把它形象地称为“管理三明治”。

十个角度看角色变更

第一个角度，从工作职责来看。对应到工作中就是，你做工程师时，完成好上级安排给你的工作就诸事大吉;而作为一个管理者，你要做的是带领整个团队往前走，上级只是帮你设定一个目标，剩下做什么、怎么做，都是你要考虑的，所有对达成目标有帮助的工作都是份内的。
第二个角度，从负责对象来看，即，你需要对谁负责。作为一名工程师，用他们自己的话说，“管好自己就可以了”，所以主要是对自己和自己的工作负责。而作为一名管理者，由于团队是上级和公司给你的资源，你需要对上级负责;你还得关心团队成员的发展和成长， 对下级负责。
第三个角度，从关注焦点来看，也就是什么对你来说是最关注的。工程师一般是过程导向的，因为他们需要一步一步把工作执行到位，眼睛盯着的常常是“脚下的路”;而管理者是目标和结果导向的，他们时时关心目标和前进方向，盯着“远方的目标”，因为他们得决定要带着团队去哪里。
第四个角度，从工作内容和能力要求来看。工程师属于个人贡献者，是靠个人专业能力来产生业绩的，工作内容以发挥专业能力为主，相对比较单一;而管理者要做成一项工作，除了技术判断力，还需要目标管理能力、团队规划能力、项目管理能力、沟通协调能力、团队建设能力等等，需要看方向的、带人的、做事的更加多维和立体的能力。
第五个角度，从任务来源来看。工程师的工作任务来源，主要是上级安排，听上级指挥;而管理者的工作内容，虽然也有上级工作的拆解和安排，但更多是靠自己筹划，然后和上级去沟通确认，从被动“等活儿”变为主动规划。
第六个角度，从实施手段来看。大部分工程师的工作还是要亲力亲为的，因为工程师角色是个人贡献者角色，所以主要靠自己完成。而管理者的工作清单涵盖了整体团队的工作，靠自己一个人是无论如何都做不完的，因此主要是依靠团队来完成。
第七个角度，从合作维度来看。工程师主要的合作内容就是和平级的伙伴共同做好执行，因此主要以平级合作为主。而作为管理者，合作的内容非常丰富，比如，需要和上级合作规划好整个团队的目标，和下级合作做好落地执行，和平级管理者合作完成联合项目，有时候还需要和平级的上、下级去一起协调资源和进度。所以合作的维度变得非常立体。
第八个角度，从和团队成员的合作关系来看。之前做工程师的时候，和大家都是平等竞合关系，以合作为主，也有“竞”的成分。
在之前平级的时候，你和其他同事虽然不会有“争”，但是有“竞”的成分在。而当你成为大家的上级，作为管理者来带领这个团队的时候，你和大家反而形成了全面合作的关系，“竞”的因素不存在了。
第九个角度，从思维方式来看。做工程师的时候，大部分工作内容和工作要求都是执行，所以是明显的“执行思维”，特点是关注过程和细节，更重要的是关注风险和成本，希望通过对风险的排除和成本的掌控，来保证工作交付的确定性。
所以技术出身的人往往在项目执行，尤其是过程控制管理方面，有明显优势，他们天然就认为这不是什么难事。当然，他们估算排期一般也会比较保守，因为他们需要确保能完成才愿意答应。而作为管理者，虽然也考虑风险和成本，但是更习惯于去关注做一件事能带来的可能性收益，并以此来判断是否值得投入资源去做，我们把这种叫“规划思维”。
由于管理者总是在盘算和筹划一些可能会对公司和团队有价值的事情，而没有仔细考虑风险和成本，所以在工程师的眼中，管理者时不时会提出一些“不靠谱”的期望和需求，但这正是两个角色关注的东西不同造成的。而这恰恰是一种很好的合作与互补:赶车的看方向选路径，而拉车的排除各种风险和困难，把车拉向前方。
第十个角度，从技术视角来看，即两个角色该如何看待技术。这个角度我们在前面的文章中已经探讨过，因为很多新经理都担心做了管理会丢掉技术，而其实只是看待技术的视角发生了变化。做工程师的时候，技术是用来做事情的，掌握好技术的目的就是为了做好实施，看待技术是从如何运用的角度出发。而对于管理者来说，技术是达成目标的手段之一，所以看待技术是从如何评估的角度出发，评估该项技术是否是最合理的手段，以及如何选择才合理，并据此做出决策，因此常常被称为技术判断力。我们的老领导经常会告诫我们，即使做了管理，技术判断力不能丢，就是指这种能力。

新技术管理者的6种误区

管理更多的是一门实践科学，从“知道”到“做到”，还需要长期地刻意练习。在
实际操练过程中，你会碰到各种各样的问题，这会是常态。新的技术管理者一般会遇到以下六类误区:

• 过程导向、被动执行。这会导致团队方向感缺失，大家都只是着眼于手头工作，团队得不到愿景的凝聚和激励； 团队做不出有效的业绩，因为团队没有方向感，所以结果就很难有效；无法带领一个团队
• 大包大揽、唯我最强。大包大揽的管理者会带来梯队问题，梯队迟迟培养不起来，梯队的培养需要授权让高潜人才有发挥空间并承担相应的责任；由于管理者冲得太靠前，团队成员积极性受挫，遇事往后缩；由于得不到团队成员的有效支持，自己又忙又累，做不了更大的业务。
• 带头大哥、当家保姆。不职业的管理风格和文化，这会给公司带来很大的潜在风险；同时团队会没有方向。
• 单一视角、固化思维。遇到问题和困难，很容易被卡住，到处都是绕不过去的鸿沟；认知层次低，由于被单一惯性思维所支配，认知层次和考虑问题的维度无法提升；难堪重任，由于创造性地解决问题的能力不足，难以承担具有挑战性的工作。
• 自扫门前雪、固守边界。这会导致项目推进不畅，从而影响全局的结果；自我设限，个人成长也会受限；个人影响力更是无法扩展。
• 患得患失、犹豫反复，无法全力以赴去做好管理，成长缓慢；对技术的看法太狭隘，从而影响技术判断力的提升；由于误判，可能会错失一个好的发展平台。

如何做管理

管理规划

问题驱动型思维转变为规划驱动型思维：1）弄清楚它是一个背负着什么样职责和使命的团队，决定了你需要设定什么样的工作目标，并通过哪些要素来衡量你的目标；决定了你需要什么样的人加入你的团队，以及需要多少；还决定了你选择什么样手段，投入什么样的资源来完成工作，这就是团队“职能”。2）只有明确了要去的目的地在哪里，才能评估需要什么样的马、多少匹，以及有哪些路线可以选择。这个关于“目的地在哪里”的问题，是管理规划的第二个要素，称为“目标”。目标设定的最基本的初衷就是着眼自己想要的结果，去实现资源的有效配置。3）盘点自己的团队，以及看看在整个“赶路“的过程中要如何升级完善自己的团队，并思考在达成目标之后你期待收获一个什么样的团队，都是必须要考虑的问题。这就是管理规 划的第三个要素，称之为“团队”。4）前面有了职责，有了目标，有了团队之后既要考虑选择路径。不要混淆路径选择和计划制定。这二者最大的区别在于，路径选择主要是为了预算资源，而制定计划主要是为了执行过程可控。这四个要素并不是彼此孤立和静止的，而是相互关联、动态平衡的。其中最稳定的要素是职能，它是管理的起点。
职能
团队职能的两个层次:基本的职责和升华的使命。职责，是团队职能的下限，即至少要完成的工作，如果这些职责都搞不定，意味着团队的 基本价值都不能体现。使命，是团队职能的上限，即如果我们团队做得好，就能承担更大的职责，体现出更大的价值。基本职责解决的是“团队生存”问题，而使命解决的是“团队幸福”问题。
设定团队职责和使命的方法和步骤，大体分为三步:
第一步，收集信息。可从以下四个角度来梳理职能信息:1）向上沟通。听听上级对你团队的期待和要求，以及希望用什么维度来衡量你做得好还是不好。这个信息非常重要，团队的初始定位和基本职责，一般都是上级直接给定的。 2）向下沟通。主要是和大家探讨对团队业务的看法和理解，以及对未来发展的期待，为以后的沟通做好铺垫。3）左看右看。主要是看职能定位的边界在哪里，最好和兄弟团队的职能是无缝对接的。不要覆盖兄弟团队的职责，否则会带来各种合作上的冲突。4）你对业务的理解，你对领域的理解，你对团队的期待，以及你对自己的期待。团队的更高职责--团队使命和愿景，往往来自于你的设想。
第二步，提炼和升华。团队的职责和使命，不能只停留在 leader 的脑海中，为了方便记忆和传播，则必须从上述信息中进行提炼和升华。提炼和升华有三个要点：1）职责的提炼。基于上级的期待和要求，以及你对业务核心价值的理解，最好用上级和团队成员、兄弟部门都易于理解的语言，对职责进行简短化提炼，并尽可能长时间稳定下来。2）使命的升华。基于基本职责，寻找团队对于部门和公司的独特价值，并和行业发展趋势结合，设定自己的期待。基于结果的描述会更有使命感。3）确定衡量维度。一般来说，团队的职责和使命决定了衡量的维度，但是如果有明确的关于衡量维度的说法，会让员工对职责和使命有更深刻的理解。常见的案例有:服务端团队，会特别重视性能、稳定性、扩展性等维度;而前端团队，往往重视开发效率、兼容性、安全性等维度;数据团队关注数据准确性、完整性、及时性、安全性等维度。你也需要根据自己团队的职能，向员工明确传递，什么指标维度对团队是最重要的。
第三步，确认和主张。提炼完成之后，接下来就是确认和主张。确认主要是和自己的上级确认，得到上级的认同和支持后，有计划、有步骤地把团队的职责和使命宣贯给大家。团队职能的设定和宣贯是一个长期工程，不要期待一蹴而就。
目标
做目标设定的时候，是基于你自己的动力，而不是被惯性推着走。那么，目标对于团队管理到底都意味着什么呢?
第一，目标包含着你和上级的诉求，即，你们希望收获的东西。
第二，目标意味着资源的有效配置。明确的目标可以让你把资源投注在有效的方向上，从“该做什么”去调配资源，而不是“能干什么”。
第三，目标意味着执行力。表现出“执行力不够”的最大的原因，都在于目标的不清晰或多变。
第四，目标意味着凝聚力。明确的团队目标和愿景，就是提升团队凝聚力的重要手段之一。大家因为相同的目标而并肩作战，在一起取得成就的过程中建立起深厚的“革命友情”，这对凝聚力有莫大帮助。
第五，目标也意味着激励。在提升员工自驱力的要素中，员工在工作中产生沉浸其中、物我两忘的“心流”状态，就需要有清晰的目标为前提。而且，团队目标感带给员工对工作的意义感和使命感，也是提升自驱力的重要来源。
目标设定的原则，即“SMART”原则。分别对应着 5 个英文单词，即 Specific、Measurable、Attainable、Relevant 和 Time-bound，用中文来说就是目标的明确性、可衡量性、可达性、相关性和时限性。
团队
团队规划，主要从如下三个视角:

• 第一个视角是看团队目标。“团队目标”的设定不是指团队所要完成的业务目标，而是你希望在某个时间节点到来的时候，把团队发展成什么状态。团队规模、分工和梯队是如何的。
• 第二个视角是看资源。技术团队往往是最昂贵的资源和成本，预算人力，实质上就是预算资源。所以，作为一个管理者，在盘点自己当前人力和预算人力的时候，需要有成本意识，要考虑投入这么多资源和成本是否值得，是否合理。
• 第三个视角是看人才培养。到下一个时间节点，你需要重点培养出哪些人，给他们什么样的平台和空间，以及你有能力提供给他们什么指导和支持，期待他们能够胜任什么职能和角色。

路径选择和资源申请
1）了解资源的丰富性，资源不仅包括人、财、物这三大项，还包括时间、信息、权限等。
2）了解手段的多样性，需要放弃一些执念了。一旦放松这个念头，你就会发现，完成一项工作，原来还有很多的手段可以选择。
3）人力资源的持续性。通俗说就是，不是所有的人力短缺，都要通过招聘来解决。招聘作为一种迟缓的解决问题的手段，更多地是看长线是否需要。

团队建设

团队建设时 6 个维度的工作要素:
针对员工个体的两个要素是:能力和激励;
针对员工个体之间的两个要素是:分工和协作;
针对团队整体的两个要素是:梯队和文化。

提升团队战斗力的基础和前提，是提升员工的个体能力
人的能力分为知识、技能和才干三个层次。大部分管理者希望员工提升的能力，是在“技能”这个层次，也就是员工能操作和完成的技术，比如快速学习能力、进度控制能力等。
人格力量通常是指一个人在面对某一情形时稳定的态度和表现，比如迎难而上、坚持不懈、积极正向、主动担当等等。这些人格力量对于个人能否搞定一件事情有时至关重要，但是培养起来却不是一朝一夕的，关键在于平时。
专业能力很容易理解，对于技术人来说，一般就是指技术能力。很多公司都有技术能力衡量标准和体系，用于评估工程师的技术水平。创业公司即使不会明文规定和实施这样的技术职级体系，但是一般也会参照这些大公司的要求和标准。所以，工程师专业能力的评价维度和标准相对于通用能力更加有据可循。
通用能力是指沟通表达能力、团队协作能力、快速学习能力等。需要团队共同认同。
提升员工个人能力的重点，会放在工作技能层面，包括专业能力和通用能力。
对于有些员工，你对他们的期待是把交代给他们的工作做好即可，所以侧重于提升他们的专 业技能，以达到专业能力的硬指标，目标是“胜任”，也就是上面我们提到的“及格”，这是你期待的下限。而对于另外一些员工，你对他们的要求和期待就不只是做好本职工作那么简单了，你还希望他们经过培养之后，能成为团队里的顶梁柱，这是你期待的上限。在这样的初衷之下，你不但对他们的专业能力要求高，还会对很多通用能力做出要求，比如目标管理、沟通协作等等，你甚至会为他们量身打造一个培养计划。
显然，不同的初衷决定了你制定什么样的标准，然后把这个标准写入员工的 IDP(个人发展计划)，并双方达成一致，这就形成了个人能力提升的目标，是你们直接的一个“合作协议”。
员工培养无外乎“7- 2-1”法则，即:10% 靠听课和看书自学，20% 靠相互交流和讨论，70% 靠工作实践。
帮助员工自学方面可以通过组织员工参加培训，为员工推荐和购买书籍，提供学习文档、视频等。关于相互交流讨论，常见的做法有组织兴趣小组、读书会、技术分享交流会、代码评审会、重点工作复盘等。关于工作实践，常见的做法有:
授权和辅导，给员工独立负责重要工作的机会，并给予辅导和反馈；调研工作项目化，即把调研学习的工作进行项目化管理；总结并内化，对于员工完成的重要工作，有必要请他们做一个工作总结，看看从中学到了什么，员工在这个总结和反思过程中的收获，甚至比总结的结果本身更重要。
对于提升员工个人能力来说，最关键的往往不是学习的方法，而是学习的意愿。激发员工学习的动力和意愿方式可总结为如下三板斧:“推”、“拉”、“放手”。
所谓“推”，就是给压力，推着他们学，提出明确的工作要求，设置学习机制，peer pressure，惩罚等。所谓“拉”，就是给方向，引导他们学，树立榜样，配备导师，给“技能图”（最好能标记出重要等级）。所谓“放手”，就是给发挥空间，让他们自主学习，给员工勇挑重担的机会，给员工自主空间，让他们独立思考，独立决策，给员工信心和耐心，允许他们犯错、走弯路。
团队分工和协作
当团队个体间的分工和协作都很良好的时候，就可以将个体战斗力凝聚成强大的合力了。如果协作不好的话，分工只会让效率变低。
究竟为什么要分工？第一，为了实现规模化，通俗点说，就是为了干大事。第二，为了实现协作。分工是手段，协作是目的，分工和协作是不能割裂开的。第三，为了实现专精。时代发展需要全才，也需要专精人才，分工为这类人才的成长提供了很好的条件。所以，我们是出于规模化、协作和专精的目的来进行分工的，在做分工的时候不能忘记了这个初衷。
最常见的一个分工误区，就是分工模糊。而且有些管理者为了能够让大家互相补位、 主动承担、增强互助，还会刻意去模糊边界。在“边界模糊”之前，要加上“分工明确”这四个字。分工需要尽可能稳定，因为只有稳定的分工才能体 现出分工的价值，比如对某项工作的专精、员工的归属感等，所以，分工能稳定的话，就最 好稳定。分工能带来专精，同时也带来了割裂的视野，所以很多管理者会通过“轮岗”的方式来提升员工的能力和全局观。我认为这种主动求变的意识非常好，因为主动求变就意味着这种变化是在你的掌控之内。
分工明确只是具备了合作的前提和基础，真正能够让大家良好互动并高效产出的，是日常工作中的协作。
如何不断提升团队的协作水平呢?
第一个角度是建立协作机制，通过机制来约定协作的动作，以此来保证大家“动作协调”。所谓靠机制，就是设计一套方案，来专门应对某个场景出现的问题，这套方案可以指导和“搀扶着”员工做好这类工作。机制建立的5个步骤：1）首先要明确该机制要解决什么场景下的什么问题，即明确目标，比如服务报警响应机制、公关事件应对机制、新人入职培养机制、项目沟通机制等等；2）提炼应对该场景的关键点。从你和其他经验丰富的人身上提炼出应对该场景的关键环节，当有成功经验时，这些关键点的提炼会容易得多。3）明确由谁来确保机制的执行，即谁在什么时候检查什么关键点。每个流程和机制的执行情况如何，谁来检查和确认。4）确认操作成本。即确认该机制对于执行者来说是可操作的。最好能够做到“自动驾驶”，如果建立的机制反而给执行者带来更大的操作成本， 那你就得反思这个机制建立的必要性。5）沟通，并和其他执行人取得共识。由于机制的制定者和执行者常常不是同一个人，所以，该机制是否有效，以及能否实施，需要和其他执行人沟通，并达成一致。
第二个视角是提升团队凝聚力，通过提升团队成员间的信任度、认同度和默契度来降低协作 成本，提高协作效率。提升团队凝聚力可以从下面4个方面着手：1）设立共同愿景。这就要求团队首先要有一个使命和愿景，有一个共同的长远目标，供大家“往一处想”。清晰的目标可以提升团队的凝聚力。团队的使命和愿景需要反复灌输给团队。2）提升员工归属。个人职责清晰合理（事对）、良好的团队人际关系形成紧密的连接（人对）、认同团队的文化价值观（味对）。3）加强相互了解。加深员工互相的了解，是提升信任和默契的良方，例如团建之类。4）共同面对挑战，共同经历过大项目、处理过紧急故障等
团队梯度和文化建设
团队产出是否可持续，是考量管理者价值的一个很重要的维度，它体现了这个团队是否健康，是否有耐力和韧劲。其中，耐力让团队走得远， 韧劲让团队走得稳。一个团队的梯队，就好像一个团队的“骨架子”，这“骨架子”是否健康良好，决定了团队是否健壮。而团队文化就好像是团队的气质和调性，它会吸引“气味相投”的人持续加入，而把不符合团队气质的人筛选出去，越来越鲜明的团队价值观让大家紧密地聚拢在一 起，从而让团队越来越“结实”，越来越“经得起折腾”，不断增强团队的耐力和韧劲。
选人：要保持人才选拔和团队建设的一致性。即，你对核心人才的选择，需要和你团队建设的理念保持一致，这主要体现在能力、协作意识和文化价值观三个要素上。和你相似的人才是人才，和你互补的人才是更宝贵的人才，这条原则就是在强调行为风格和思维方式的多样性。
育才：1）对齐期待，达成共识。常用方式是 IDP，即个人发展计划。通常把绩效计划和 IDP 合二为一，培养人才也是要以做出绩效为依托（这部分站8层），IDP主要约定了未来的一个绩效周期内，个人需要特别聚焦的成长有哪些，并通过“把哪几件事情做到什么标准”来体现（这部分占2层），在对齐期待的环节，有一个原则需要引起重视，就是不承诺原则。2）提供机会和发挥空间，做好授权。能力和影响力都是在实战中积累起来的，授权要按以下10点：审视初衷、明确期待、听其思路、重要约定（关于怎么check 进展，你们最好提前有个约定）、了解进展、给予支持（教练式的引导和启发， 而不是直接告诉答案）、评估结果、洞察优势、积极反馈、一条改进（1~2 条改进建议）。3）建立反馈机制。建立周期性沟通机制（不要随意沟通），review IDP，安排第二导师，给予支持和反馈。
鲜明的团队文化及价值观，究竟能给一个团队带来什么呢？1）效率。由于文化里包含着约定俗成的工作标准和决策依据，并且团队成员都对此持有共识，因此不必事事请示上级和彼此确认。2）空间。在符合价值导向的前提下，员工可以自主选择自己的工作手段，甚至是工作内容。3）归属。认同该文化的人会不断加入进来，而不认同该文化的人也会逐渐淡出，久而久之，团队里都是对该文化认同度很高的员工。4）耐力。能够在新、老员工间传承，并不会因为个别人员的变动而明显变化，除非是团队负责人有调整，才会给团队带来明显影响。
如何打造团队文化？1）“命名它”。其实就是提炼你团队的文化，用合适的词句把它表述出来。2）“主张它”。就是要把你提炼出来的团队文化，宣贯给整个团队成员，甚至还包括上级和合作的兄弟团队。3）“追求它”。管理者要以身作则，做到言行一致。文化的践行，更多的体现在管理工作中，在绩效沟通、评优表彰、新人导师等日常的管理工作中需要体现团队文化。

任务管理

大部分工作都是以“项目”形式存在的，因此，任务管理大体上又是项目管理，只是为了涵盖非项目的那些工作，才把“做事”叫做任务管理。话说回来，“做事”是一个过程，可以分成“事前”“事中”和“事后”三段。在做事之前分清楚轻重缓急，也叫优先级梳理。在做事过程中，要确保事情的进展按照计划推进，也就是有效地推进执行。在做事之后，我们要复盘做事的整个过程，并从过去的经验之中抽取一些流程机制，以便以后在类似的场景下也可以做得更好、更顺畅。因此，把事前的轻重缓急、事中的有效执行和事后的流程机制，称为任务管理三要素。这也是接下来三篇文章的三个主题。
轻重缓急的梳理
对于每个团队来说，当下能做的工作是有限的，增加并发并不会让大家的产出更高效，所以，多任务并行问题归根结底还是优先级问题。
到底怎么判断一项工作重要不重要，紧急不紧急呢？可以通过下面两个问题来得到答案：1. 如果做，收益是否很大？收益越大，这个事情就越重要。2. 如果不做，损失是否很大？损失越大，这个事情就越紧急。在实际的工作中，我们经常做的并不是梳理轻重缓急四象限，更常见的情形是，我们要把日常的工作分为两种情况：一种是计划内的，也就是按照我们的规划进行的；另外一种是计划外的，即突发的情况和任务。我们的应对策略其实非常简单：1. 对于计划内的工作，我们更关注它在一个规划周期内的价值和收益有多大。我们会把价值足够大的任务安排进来，并持续地往前推进。2. 对于计划外的工作，由于是一种突发情况，是否要中断既有安排来高优先级跟进呢？中断既有安排一定是会影响正常推进的收益的，所以我们要做的决定是，是否要立刻跟进？如果不立刻跟进，带来的损失有多大？我们是否愿意并能够承担？如果不能，那就立即跟进。如果可以不立即跟进，那就转化为一个可以安排到“计划内”的工作，并参考第1条的策略就可以了。
总结起来，对于任何工作任务，决策的步骤就两步：1. 对于“计划内工作”，看收益是否足够大。收益越大就越重要，也就越需要给予相匹配的优先级、资源和关注度；收益相对不大，就放入“To do list”，作为待办任务处理。2. 对于“计划外的工作”，看损失是否足够大。损失够大，就按照紧急任务安排，以止损为核心目的；如果损失可控，就放入“计划内工作”列表。

关于任务优先级的安排，除了决策的步骤和方法，还有几个重要的原则：
第一，目标是需要一以贯之的。前面我们提到，通过看收益来判断一个任务是否重要，参照“目标”来衡量收益。我们规划的目标里蕴含着我们一段时期内最重要的诉求和期待，也是衡量一项工作收益大小的坐标轴。目标的设定和评估贯穿着整个管理工作的全过程，目标越明确，在关键时刻我们的方向感就越强；反之，就会瞻前顾后，反复掂量却不得要领。所以，好的决断力，往往基于明确的诉求和目标。
第二，任务安排是弹性的。很常见的一个情况是，我们在做任务安排的时候，往往不自觉地会在心里做一个设定，即，这个项目做成某个样子才叫完成，所以需要预算这么多时间。而实际上，对于一个任务来说，其进度、质量和效果这三个要素是可以此消彼长的，所以在拆解任务的时候，对进度的预期不同，对质量的要求不同，对效果的期待不同，都会导致时间预算和优先级的变化。所以，不能用固化的视角看待一个任务，每一个任务其实都是可以弹性安排的，根据进度、质量、效果的不同期待，你可以给出很多种排期方案。这体现一个管理者的经验是否丰富。
第三，沟通是不可或缺的。虽然排优先级主要是管理者来做，但是这并不意味着排好优先级之后就大功告成了。只有和所有相关的人员充分沟通了之后，才算是调整完毕，尤其是和自己的上级，一定要和他沟通新的工作安排方案。告诉他，你优先保证了什么，从而可能会影响什么。
如何确保项目的有效执行
“有效执行四要素”，即目标清晰、责任明确、机制健全和沟通到位。
目标清晰：虽然都是有目标的，但是很多目标容易出现下面三个情况：1）目标不够明确具体，至少没有具体到执行人员可以执行的程度。2）上、下级对目标的理解看似一致，实则有偏差，尤其是对进度、质量和效果的拿捏上。3）目标发生变化了，没有及时同步给相关的人员。归结起来，这三种情况都导致了目标不清晰的后果。当目标不清晰的时候，必然会引起员工在紧急程度、质量水平和效果取舍上的偏差，最后也就引发了执行上的偏离预期。那些执行良好的项目都有一个共同而又必要的条件：清晰的目标，只不过在实际执行过程中，每个人对“清晰”的理解会有所不同。
责任明确：很多项目执行障碍的一大源头就是“责任人”不明确。其中有两个模糊的地方，让“责任人”这个简单的问题变得失控。1）各负责人对于“负责”的理解常常是不一致的。很多负责开发的工程师，他们认为的“负责”就是承担自己份内的开发工作，而项目某一角色的负责人是指对该项目中所有涉及项目执行和协调的问题都要负责。2）总负责人无效。虽然有名义上的总负责人，但是总负责人顾不过来也好、自己不认同也好，都会在项目执行过程中“缺位”。 对于这个问题，有效的办法是把上级作为“客户”来看待，并另寻总负责人和这个“客户”来对接需求。而这个总负责人，是从项目的各个角色的团队负责人中产生，来总体负责和协调该项目。如果各个角色之间有长期稳定的合作关系，就可以把各个角色的负责人组织起来，组成一个项目管理的虚拟组织，大家轮流来做总负责人。这样既解决了项目总负责人缺失的问题，还培养出多个更高级的项目管理人才。并且假以时日，整个团队甚至整个公司的项目交付水平，都会有明显的提升。这归结起来，第二类问题是集中在大家认为最简单、最容易，但又最容易忽视的项目总负责人的“缺位”上。
机制健全：团队成员的能力水平都是正态分布的。另外，如果真的是“人不行”，那么人从“不行”到“行”也会是一个缓慢的过程，而此时此刻你就得做事，那你打算怎么办呢？这就要靠流程和机制了。于是很多管理者就制定了全套的流程让团队遵循，但由于学习和执行成本很高，员工遵循起来非常痛苦，因此就干脆让流程机制去“睡大觉”。这也是很多团队的真实情况，他们有很多流程机制、规章制度的页面，但是还是做不好项目。归结起来，这类问题主要体现为：1）过于依赖人的主动性，缺乏基本的流程和机制。2）虽然有机制，但是没有人监督执行。3）虽然机制有人监督执行，但是大家依然不愿意执行。后面会有专门篇幅探讨这个问题。
沟通到位：“信息不对称”是大家在一些事情上没有达成共识，产生了协作上的偏差和误会的主要原因。“信息不对称”可能是对信息本身的理解就不一致，也可能是没有有效传递和同步，总之在沟通这个问题上有诸多的不顺畅，归结起来就是：1）主动意识不足，沟通不够主动。2）通报意识不足，没有知会到所有相关人员。3）闭环意识不足，广播出去了，就默认对方收到了。关于管理沟通的问题，沟通不畅是项目执行不到位的主要原因之一。
至此，我们就了解了项目执行过程中最常见的四类问题。当然，关于项目得不到有效执行，也许还有许许多多的其他问题，就好像“不幸的生活各有各的不幸”一样，项目执行不好也各有各的原因。上面我们阐述的，只是最常见的四类问题。如果你的项目没有这四类问题，不见得一定执行良好，但是如果出现了这四类问题中的某一类，执行上一定会有问题。
如何让流程机制得到有效的执行
要想让员工分担我们手头上的工作，要么靠梯队，要么靠机制。所谓靠梯队，就是团队里有胜任度非常好的人，可以帮我们搞定这件事，并且这个人已经是这方面可靠的梯队人才。所谓靠机制，就是设计一套方案，来专门应对某个场景出现的问题，这套方案可以指导和“搀扶着”员工做好这类工作。机制要怎么建呢？大体上是五步：
1）首先要明确该机制要解决什么场景下的什么问题，即明确目标。机制的一大特点，就是场景化特性非常明显，因为它们都是为了应对好特定场景下的问题而产生的。比如服务报警响应机制、公关事件应对机制、新人入职培养机制、项目沟通机制等等，你会发现前面的定语都是场景化的。建立一个机制时，首先要描述清楚场景是什么。
2）提炼应对该场景的关键点。从你和其他经验丰富的人身上提炼出应对该场景的关键环节，因此当有成功经验时，这些关键点的提炼会容易得多。这里，我并没有说要去整理一个流程文档，因为和一个步骤完整的文档相比，关键点的提炼更为重要，这会让执行成本降低，也更有可操作性。
3）明确由谁来确保机制的执行，即谁在什么时候检查什么关键点。每个流程和机制的执行情况如何，谁来检查和确认呢？如果少了这个监督者，流程和机制的有效性就得不到保证。所以，每个机制，都要设立监督者或检查者。
4）确认操作成本。即，确认该机制对于执行者来说是可操作的。你建立机制是为了简化工作，最好能够做到“自动驾驶”，如果建立的机制反而给执行者带来更大的操作成本，那你就得反思这个机制建立的必要性。
5）沟通，并和其他执行人取得共识。由于机制的制定者和执行者常常不是同一个人，所以，该机制是否有效，以及能否实施，需要和其他执行人沟通，并达成一致。这就是我在前面的案例中最后所交代的“和员工商量一下怎么配合执行”。
通过这五个步骤，相信你也会制定出应对各种场景的机制。不过，随着日积月累，你会发现机制和流程越来越多，它们慢慢变得不再那么好用，最后甚至长篇累牍地躺在一些页面上“睡大觉”。那如何才能让这些流程机制得到有效的执行呢？
建立机制时还要遵循如下的四个原则：
1）可操作，即简单原则。也就是说，机制要以最小的学习成本和操作成本为原则，这是最首要的原则。如果建立的机制不具备可操作性，那么你自我感觉再完美，能应对的问题再多，最后也要被抛弃掉的。因为不具备操作性的机制是没有意义的。
2）只打关节点，即关键原则。建立一套机制，不必要对所有的细节进行完整的描述，没有人喜欢看长篇大论的文字，你只要告诉大家，在哪几个最关键的节点，做什么样的动作即可，而且这样的关键点也不能太多，以不超过5个为宜。这样做可以大大降低执行成本，提升机制的可操作性。
3）明确到人，即问责原则。在各个关键点由谁来跟进呢？这个问题要有明确的约定，不能完全靠人的自觉性。
4）从 case 中来，到 case 中去，即实用原则。千万不要为了建机制而建机制，每一个机制都要有实用价值。由于机制都是有场景化特性的，当场景发生了变化，机制也要随着升级，而对于机制的重新审视和学习都意味着额外的开销，所以，每个机制的维护都是有成本的。如果没有随着场景更新升级，那这些机制也就成了没有意义的机制，时间长了就变成大家常遇到的情况：什么机制都有，但是大家不执行，或执行效果不好，反而成了管理的累赘和负担。
机制不是越多越好，而是越少越好。机制的建立并不会解决问题，对机制的执行才能解决问题，而机制的建立、执行和后期维护都是需要成本的，所以，千万不要贪多，在风险可控的前提下，机制能不建就不建，能少则少。人的靠谱度的方差比机制大，即，人靠谱的时候比机制靠谱，人不靠谱的时