| title |
|---|
管理者一定会遇到的那些事 |
作者：Tom哥
公众号：微观技术
博客：https://offercome.cn
人生理念：知道的越多，不知道的越多，努力去学
当一个员工不符合预期时，作为 Leader，一定不能轻易下结论，而是要先去分析他不符合预期的原因是什么。具体可能包括两点原因：
第一，他的能力确实没有达到。比如我当时作为校招生，确实不具备完成工作的能力。这个时候，你应该给他机会，比如安排一些学习、辅导，甚至是小师父。
第二，判断他是否被放在了正确的岗位上。比如，对校招生来说，可能做后端的存储模块难度较大，那么是不是可以给他安排去做一些偏前端的接口 PHP，或者是做一些 C++ 的模块，这些可能会更适合他。
所以，当有员工不符合预期的时候，我们应该具体问题具体分析，看看背后的原因是什么，是他的工作态度有问题，还是能力没达到，抑或是没有被放在正确的岗位上。
不要轻易放弃任何一个队友.
- 一，当员工不符合预期的时候，Leader 应该先找下原因，看看是他的能力没有达到，还是说他没有被放在正确的岗位上。
- 第二，不要轻易放弃任何一个队友，作为 Leader，应该给予下属一些指导，而且至少要给他 1~2 次机会。
作为 Leader，在带团队的过程中，言传身教是很有必要的。Leader 的核心职责是要把下属变成更牛的人，同时要给下属安全感，让他们有勇气展开拳脚做事。
所以在技术探讨的过程中，应该相互吸取对方方案的优点，规避掉缺点，这样整个架构才会越来越合理，双方的架构能力也会不断提升。
- 引导员工表达自己的意见
- 强势的反问句不可取
- 过去的经验未必正确，要结合当下业务分析
作为 Leader，心态应该开放一些，多听取员工的想法、建议来丰富自己，从而找到最佳的技术方案。
- 第一，在沟通的过程中，Leader 有义务引导员工表达出自己的意见，切忌打压对方。
- 第二，注意自己的表达方式，不可采用强势的反问句。
- 第三，过去的经验未必 100% 正确，任何脱离业务的架构设计都是耍流氓，并没有一成不变、普适的架构方案。
把自己身上沉淀下来的这些经验和方法，抽象出最佳实践，抽象出方法论，传授给底下的同学。这才是一个 Leader 的职责。
- 第一，作为 Leader，不必事必躬亲，而是要授人以渔。如果你把所有的细节都打理得妥妥当当，反而不利于下属获得提升。你应该把自己牛的地方抽象出方法论，传授给底下的同学，而你担任的也只是一个导师、教练这样的角色。
- 第二，不要拿下属的成果去邀功，要将团队内有成绩的人推向前台。同时，不要推下属出去背锅，这是我心中最为不齿的管理者。你作为 Leader，如果连锅都不敢背的话，还指望有人跟着你干吗？
-
- 要设置优先级机制，并根据公司的战略、方向制定项目优先级。
不管是哪个部门、哪个上游、哪个业务，不管对方和你的私交有多好，都要统一按照公司的战略、方向来安排项目的优先级。要有优先级机制，并且根据公司大方向来确定哪些项目优先级高，哪些项目优先级低。
-
- 要有优先级调整机制，而且大家一定要达成共识。
项目需求可以变，优先级也可以调，但是一定要有相应的优先级调整机制，而且大家一定要达成共识。当你把一个项目的优先级调高的时候，一定会有相关的项目受到影响。在这个过程中，大家一定要达成一致，不能通过走后门、强力 Push、利用私交等方式调整优先级，这样的话，机制和流程就会失效。
-
- 对于重点项目可以冲刺，但不要采用“运动式”加班。
作为 Leader，一定要集中精力把重点放在如何提高团队的工作效率上，而不是一味地延长工作时间。你需要判断自己的团队架构是否合理，使用的工具、平台是否是最适合的，你需不需要通过自动化的方式去实现一些东西？所以我有时候也会给我的团队定下这样的目标，比如我们的工具平台自动化能否再进一步，让我们的下班时间能够提前半小时。
-
- 不要随意找负责人改变优先级
一旦有人发现可以通过这种“走后门”的方式，提升项目的优先级，那么所有人都会采用这种方式来给你压力。这样的话，流程和机制就会失效，对 Leader 来说，没办法带项目，也没有办法带团队。
此外，作为 Leader，不要因为一个人评优与否，就改变自己对他的看法，其实什么都没有变。
现在回想一下，我当时为什么会对评优结果那么在意？就是因为我特别在乎我的 Leader、团队成员、公司同事，在乎别人怎么看我，如果他们看好我、认可我的话，我能够获得自我满足，激励自己。但仔细想一想，别人对你的看法真的有那么重要吗？你自己问自己，有没有一天比一天变得更好就可以了。
所以从那以后，我几乎一次都没有参加过评优了。现在我也跟底下团队的同学们说，不用太在意评优的结果，很多事情不是我们能够决定的。我特别认可你，你自己也要认可自己，拿昨天的自己、今天的自己、明天的自己去对比就可以了，自我激励。