当我们在一线开发软件的时候，有时会抱怨来自管理方面的问题，
可当我们自己对项目、人和事 进行管理的时候，
就把这些问题忘在脑后了，久而久之就形成了角色所带来的坏习惯。
本文就尝试切换一下视角，看看管理者有哪些「职业病」，
以及需要怎样的管理技巧才能应对它们。
不要打断别人的工作
开发者最痛恨的事情之一，就是在写代码的时候不停的被打断，
在聊天工具中，一会让你干这个，一会让你干那个，或者临时加个紧急任务。
我们自己在编码的时候，对被打断耿耿于怀，
但这并不意味着，自己进行管理的时候，就能规避这个问题。
这是需要一定的管理技巧、方法 才能解决的。
因为人和人沟通和交流的规律，就是由打断构成的，这是一个由「中断」构成的世界。
为了不要频繁的打断别人，需要管理者做好这几点：
提前把工作安排好，使得每个人都有整块的时间独立工作
减少主动打断别人的频次，紧急事项 每天/每周 固定时间进行沟通
了解每个人的工作习惯，在 打断与阻塞 之间找平衡点
所以管理者应该能允许一定程度的工作阻塞，并能在自己这里进行缓冲。
外界虽是狂风暴雨，团队内部却是涓涓细流。
而这一点是需要折中考虑的，直接安排工作不行，都阻塞在自己这里也不行。
一般以每周为维度进行安排就可以了。
或者跟每一个人商定「异步」「不打断」的任务看板，开发者根据自己的工作习惯，
定期的去看板中查看即可。
结论就是，管理者和开发者，要在被打断这件事情上达成共识，
一起商议最适合每个人的任务排定方式，包括日常工作和紧急事项。
让每个人一次只做一件事情
我们自己在编码的时候都知道，多个开发任务来回切换，会频繁的切换上下文，
这对大脑来说也是一种极其消耗精力的行为。
更重要的是，来回切换任务也会使得工作效率降低，并且容易出错。
成为管理者之后，很多人都会忘记这一点，这是因为管理工作的切换成本变小了。
多年的管理者经常会有一个疑问「我不明白为什么切换任务就这么难」，
这是因为已经对低成本的任务切换形成习惯了。
为了避免开发者在多个任务之间来回切换，需要做好这几件事，
提前商议好每个任务的优先级，在一整块的时间内，只做一件事情
不要频繁的添加新任务，尤其是优先级最高的新任务
把记录任务和切换工作交给管理者，开发者只负责执行
同时进行开发任务管理，并进行开发，这会给开发者造成极大的心智负担。
既想着要做什么，还要想着怎么做，就很难专注。
所以，管理者应该为每个开发者维护一个任务列表，并商议好优先级。
很多管理者对需求也没有优先级意识，来者不拒，
不考虑团队定位和开发者的工作负荷，是多任务来回切换的根本原因。
不要说让员工主动找自己
很多管理者经常说的一句话是「有问题你就来找我」，但一般别人都不会去找他。
这是什么原因呢？
因为「找」管理者就意味着两件事，
第一，我有问题，
第二，管理有问题。
大家都不想让自己有问题，也不想披露别人的问题。
打破这个游戏规则的办法是，更正「有问题你就来找我」的说法，
管理者应该这样说「如果你不找我，那么问题就是你的」。
责任和边界清晰，问题只能有一个负责人
触发的条件更明确，大家对哪些问题可以找管理者达成了共识
从表面虚伪转变成了表面诚实，直面利益人人平等
管理者其实不必避开利益，而只建立正面形象。
越是能把利益说清楚的管理者，越是能让管理工作变简单。
所以不要说「我会给你一切帮助」「有需要的尽管问我」，这些都是场面话，
不如说「某某问题你决定不了，需要找我来决策」「某某事情你可以全权负责」。
这样能做什么和不能做什么，以及什么时候需要管理者来介入，就很清晰了。
因此，管理最难的一点是清晰的传递诉求，一般要从正反两面进行阐述。
通过「能做什么」和「不能做什么」双重界定。
一个例子是，安排工作时，不要只说「要做什么」，
更要说「如果做不好会怎样」，以及「截止日期」和「质量要求」。
不肯放权不信任
事情既然交给别人做，那就要放权，不然就不要交出去。
所以管理者对每件事，要么对问题负责，要么对方案负责。
如果对问题负责，那么方案就不要太多过问，开发者可以随意选择适用的方案。
如果对方案负责，那么管理者就亲自去做，不要这个我不管那个我不管。
管理者容易对问题和方案都想负责，既要解决问题，还得用被认可的方式。
这是不现实的，因为管理者所假设的方案，可能根本就行不通。
一旦想明白这一点，那么各种评审会、标准化的流程就可大大削减了。
在分工和放权方面，可以这样做，
安排工作是对结果负责，要对预期描述清楚，什么是符合预期的，什么不符合
方案是要评审，但不是评审具体的方案，而是评审决策过程
对结果的进度要把控，是否按照里程碑计划设施，最终交付是否有风险
管理者对问题、结果、交付 这种全局性质的事件负责，如果还是纠结细节，
那么一个人的精力是十分有限的，说明无法识别到什么是「投入产出比」最高的事情。
以及什么是「仅适合自己做」的事情。
其实管理工作从更高层次来看，也是一个方案，公司的中高层只对管理结果负责，
并没有不会对「管理过程」「管理形式」太多过问。
如果每个管理者都要向上汇报「我是如何管理的」，就能知道开发者的处境了。
总之，管理者的工作是设置「游戏规则」，并能在游戏中及时的给出反馈。
游戏没玩好，有时候不是玩家的问题，也有可能是「规则」不清晰。
换个位置考虑问题
尤其是在中国，管理者是有行政权利的，所以很多事情是由位置决定的。
在管理位置待久了，可能就会忽视位置带来的加成作用。
容易把自己成功的原因归结为能力优秀，而不是位置/角色。
例如，管理者在组织一个会议时，会发现大家的参与度挺高的，每个人都踊跃发言。
可是为什么当下属们内部开会时，总是有人反映大家都不积极呢？
这就是位置决定结果的一个典型例子。
职场中不可能没有勾心斗角，而大多数斗争在上层看来都是云淡风轻的。
因为这些斗争并不想上升到管理层的视野中。
这并不是一种揣着明白装糊涂，而是不可见。
事情可能比想象中的更难解决，通过对员工访谈是无法看到人们不想让自己看到的内容的。
每个人在自己面前只说好，态度都非常友善。
这样就容易沉迷在其乐融融的假象中。
从古代帝王治理权臣方面，可能隐藏了大智慧。
做什么和不做什么都要明确
员工如果为了拿到好评，会不断揣测管理者的想法。
所以，如果事情不明确说出来的话，就会得到一个模糊的共识。
一个典型的例子是，只说正面约束，而没有强调反面约束。
只说做什么，不说不做什么，会多做很多无用功。
优秀的管理者，会明确传达自己想要什么，以及不要什么，而不是让别人揣测。
这其实是挺难的一项技能，因为在日常生活中，我们很少需要这么做。
我们只要说自己想要什么就行了。
这是因为，没人会为了讨好我们，而故意多做一些工作。
管理者可能会忽视这一点，认为大家理解错他的意思了，是没有对齐。
不知道为什么人们会想得太复杂。
原因就在于，管理者没有明确表态，复杂的东西并不是自己所需的。
结语
一个工程师能否达到优秀，很明显的特点之一是，能否经常反思、持续更新。
这一点对于管理者而言，也是如此。
「厨师」最重要的是有一颗为「食客」着想的心，那么「菜品」才能精益求精。
「管理者」也要有一颗不断为「员工」着想的心，想做不好都难。
上文中我们看到，很多管理决策、技巧 都是建立在共同商议基础之上的。
管理者只要能放低姿态，心平气和的看待分工，
管理方面的困难，是可以通过合作来克服的。
古人无复洛城东，今人还对落花风。
年年岁岁花相似，岁岁年年人不同。