从技术转型做管理，我总结了这些套路！
|
上面四项对比，是我个人认为比较典型的 Case，比如上一节提到的一种情况：Leader 觉得某个问题很简单，嫌员工处理效率低，然后自己跳出来三下五除二给解决了，这种就属于很典型的员工思维。 单从搞定这件事情来看，这也许是很好的处理方式，业务方也会很满意，但是带团队是长远的事情，上述做法紧急情况可行，但是变成常态就是非常大的问题。 团队能力不提高，Leader 永远不会解放，这是作为 Leader 应该具备的意识。 如果通过这个问题能够提升组员某方面的能力，Leader 应该扮演好教练的角色，放手让组员自己去做，你要做的仅仅是观察、给一些指点、适当给予时间上的支持。 这次处理也许效率不高，但是下次碰到类似的问题，团队是不需要依靠你来解决的，另外组员也有自己的发挥空间，觉得团队在帮助他成长。 注重执行细节 对于刚转型做管理的一线 Leader，切忌被放权式的管理方式洗脑。 放权式管理对于对管理者的经验要求很高，它比较适用于工作流程清晰，团队骨干目标认知以及自驱力很强的团队。 当你个人的管理水平还处于菜鸟期时，一定要从细节抓起，通过手把手带员工，教会他们如何正确的做事，怎么才能达到你的要求，以及如何培养出团队骨干，搭建出团队的核心组织架构。 所有这些都经历过了，你在管理上才会有自己的心得体会，才会走得更扎实。 通过观察执行细节，你能非常清楚团队每个人的优劣势，深入感受自己的管理方式是否存在问题，然后再辅以 Leader 思维去思考和解决问题，管理上才能真正获得成长。 这个过程，你可能会收到上级、平级、下级的很多反馈，清楚细节后其实你就有了自己的判断，知道是否是自身的问题，是否要调整，而不是沮丧抓瞎。 学会用人所长，具备包容心 知人善任、人尽其才，是每个管理者都懂的道理，但是能做到的不多。 尤其在技术管理岗上，我见过有些 Leader 在技术上非常强势，技术权威不容有任何挑战，当组员提出更合理的技术方案时，他会用职级强制要求按自己说的执行，根本不做任何解释。 对于新晋 Leader，团队对你的信任感还在磨合期，上述做法很容易打击组员的积极性，消灭他们的创造力，这对你带团队来说是非常致命的。 如果组员的方案更合理，Leader 应该倍感欣慰，包容并鼓励这种行为，因为组员某方面的专业能力超过你了，你不再是团队各方面最强的人，你需要做的是调整自己的心智，学会用人所长。 另外，还有一种情况是：组员和 Leader 的技术方案都可行，我个人倾向将选择权交给组员，毕竟他们是真正的执行者，应该给他们自由发挥的空间，最后就算出问题对他们来说也是很好的经验积累。 重视情商，做好自我情绪控制 管理上能做多大事情，真的和情商有非常大的关系。IT 界的技术人员由于工作性质的原因，普遍注重技术上的提升，而忽略情商的培养和维护，作为新晋 Leader 必须从一开始就意识到情商的重要性。 管理是一个复合型的岗位，当你的专业技能和处理问题的方法论已经形成后，越往上发展，为人处事的软技能占比会越来越重。 每天和不同的人打交道，这个是管理者的日常工作，因为你需要调动所有可能的资源去解决团队的困难。 面对不同职位、不同 Level、不同性格的人，你要反复琢磨采取何种沟通方式和沟通技巧。 上一节提到一种情况：一件你认为很简单的事情，推动起来却很困难。 可能是因为你对外的沟通方式太生硬，别人不想配合你，或者别人确实有其他更重要的事情，但是如果私下关系建立好，你再当面软磨硬泡，多半也是可以解决的。 人际关系上，难免会有碰壁的时候，不要气馁，这跟技术同学写出 1 个 Bug 一样，是家常便饭的事情，但是一定要注意积累经验。 线下和关键的配合方维护好私人关系，多吃饭喝酒，别人有困难能及时伸出援手等等，套路有很多。 情绪控制，是一个比较难的事情。情绪很容易传递，如果 Leader 碰到不爽的事情，把组员当做出气筒，这是非常伤士气的，之前建立的信任感很容易消失，受不了的组员也可能就离职了。 另外，对外沟通上，如果 Leader 控制不好情绪，不将重点放在解决问题上，只是抱怨或者发火，也非常容易引起配合方的不满，认为你不专业，久而久之，你的团队也会被打上这种标签。 个人在情商方面目前做得也很差，踩过很多坑。提供三点建议： 保持积极乐观的心态，同时提高自己面对问题时的承受能力，想清楚情绪化是解决不了问题的，只会加大解决问题的难度。 能够自我反省并吸收别人的反馈，做得不好的地方要勇于正视并且持续改进。 培养亲和力，不要觉得自己是 Leader 就带着架子，要有一种鞠着的姿态，能够尊重人并且真诚待人。 做好时间管理 时间管理的 4 象限理论可以百度一下。重点说下我个人遇到时间管理问题是怎么解决的，以及技术和管理两个维度如何分配时间。 第一步，可以拿过去一周或者一个月的时间跨度为例，详细列一下你的时间花在哪些具体事情上了，以及每类事情大概的时间占比。 对于技术 Leader 可能的事情包括：需求评审，资源规划和项目排期，技术评审，团队周例会，研发规范制定和落地，项目管理，技术调研，架构设计，Coding，紧急任务协调和处理，业务以及新技术充电等等。 第二步，针对第一步列举的每类事情，考虑下哪些是非必须的，哪些是可以授权给团队骨干去做的，哪些是可以优化提高效率的。 比如一些简单的需求评审或者技术方案评审让骨干把关即可，项目管理制定好流程规范同时培养一些 Scrum Master 或者项目经理下放给他们来做。 不用凡事都事必躬亲，Leader 应该把时间聚焦在对团队最关键的事情上，学会授权和放权。 对于一线 Leader，技术和管理两个维度如何分配时间，个人的建议是： 大部分时间 Leader 是不需要亲自写代码的，但是如果有需要，Leader 要能够随时顶上，所以不能长期远离一线，纸上谈兵。长此以往，技术判断可能容易出现失误，而且如果管理不合适再转型回去代价太高。 技术维度：可以将重点放在架构设计、代码审查、技术调研、以及一些框架性的代码开发上，这些事情对于维持技术优势是足够的。 如果管理维度的时间占比超过 60%，个人觉得比例是有些失衡的，要么团队太大了(比如超过了 10 人)，要么自身的管理存在问题或者时间管理存在问题，需要关注并考虑做出调整。 上面这些内容，就是关于工程师转型管理的个人心得。关于管理，后续我会将更多实用的技巧以及方法论结合具体 Case 进行总结和分享! 2020 年，又一个十年的开端，认清基本盘，不忘初心，再接再厉! 作者：骆俊武 简介：一名程序员，985 硕士，前亚马逊 Java 工程师，参与过创业，目前是一家 B 轮电商公司的技术总监。在这里会持续分享我个人的成长之路，写一些关于技术和管理方向的总结，希望对你有所启发。 （编辑：源码网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
