| title |
|---|
第一次带团队，感觉很慌怎么办？ |
作者：Tom哥
公众号：微观技术
博客：https://offercome.cn
人生理念：知道的越多，不知道的越多，努力去学
有些同学技术扎实，为人热情，乐于助人，熟悉业务与系统，基于工作中的出色表现，被提拔成为团队Leader。当角色发生变化后，工作内容随之也发生了变化，每天要参加各种产品需求会、技术方案讨论会、复盘会，定期还跟老板的汇报工作等，同时还要负责团队的日常管理、工作安排，搞的焦头烂额，晕头转向，感觉不像coding时那么有成就感了，甚至有种失控的感觉！
另外随着时间的积累，原来的技术还有可能落下，更加重了自己的焦虑感。
初入管理，很多人都有类似感觉，感觉深陷泥潭。那么到底要不要走管理路线？你是否已经做好了充分准备，很重要。
但在现实中要更复杂，你要先把人凝聚起来，让团队成员有提高、有成长，形成团队战斗力，之后再把事情理清楚、做明白、拿到结果
管理并不像很多书中说的那样难以琢磨，虽然其中包含了很多感性驱动的认知和做事方法，但依然有足够大的比重可以被理性逻辑化（比如技术工作的安排、团队机制与流程的讨论和执行，这些不单纯由感性与情感来驱动和判断）。
管理是一门艺术，我认为其中也存在因果性很强的“工程逻辑”，你可以通过观察、模仿、学习、总结，找出管理的脉络与规律，结合你对人性的理解与实际场景，提炼出适合自己的管理方法和框架。
发展才是硬道理，管理就是以解决问题为根本，追求事务的可持续发展（这是管理的主线脉络）。
从技术升级到管理者，从原先的一个人升级到带领一群人，角色发生转变，意识也要变化。具体体现在工作上，原先可能只关注个人产出，高效完成编码工作就可以拿到不错的绩效。现在要关注团队成员的成长，思考如何带领团队拿到结果。这样大家才愿意跟着你干。
因地制宜，没有一成不变的方法，想找到开箱即用的管理框架不太现实。更多是结合公司业务、团队现状、当前遇到的问题等，因材施教，灵活变通，才能达到最佳效果。一句话，不管白猫黑猫，捉住老鼠就是好猫
要有大局观，大局观，大局观。作为管理者格局一定要宽，要以公司利益为先，切不可搞些“山头主义”、“地盘意识”，如果这样，很容易让自己束手束脚，在管理道路上一般很难走太远。
作为技术人，我们只想埋头写代码做架构，给系统预留足够扩展空间，把系统性能优化到极致，仿佛只有这样才能证明一个技术人的能力。
但是世间的事很难衡量，比如技术很难直接产生价值，需要通过业务功能来满足客户需求，进而挣到钱。所以业务和技术就成为一对矛盾综合体。到底是业务向技术妥协，还是技术向业务妥协，相信很多技术人多多少少都遇到过这个难题。
技术债务就是这种矛盾的常见产物。很多时候我们都听过这样的话，产品经理总是说：先把功能上线，后面我们再做优化。虽然做到了短期的快速交付，但系统的性能、扩展性会大打折扣。日积月累，我们便积累了很多技术债务。
从价值角度来讲，抛开任何一方来取悦另一方都是不合适的。毕竟大家是一个团队、一个整体。只有相互协作，相互理解，达到一种平衡，才能价值最大化。
作为团队 Leader，虽然写代码少了，但是团队成员的代码规范、代码质量、code review 还是要重点关注。此外还要关注核心系统的稳定性、架构扩展性，历史债务的偿还问题。
Team Leader就像一艘巨轮的船长，看的一定要远，要有很强的规划能力&风险意识，善于提前做谋划，将潜在风险扼杀在摇篮中。
如何做技术规划？技术规划不是天马行空，要与公司的战略规划、业务架构相呼应，方向要一致。这样才能最大化实现业务价值。
首先要分清轻重缓急，聚焦短期目标，同时为长期规划做好铺垫，逐步实现一个大目标。
要足够聚焦，由于人的精力、资源、时间有限，关键目标不要超过3个，要找最有客户价值、对公司战略最有帮助的点。目标少了，方向才会更清晰。
设定团队目标要有一定的挑战性，能体现出技术的价值，助力业务实现价值。
关注团队成员的个人成长。很多同学在目标制定特别容易忽略这一点，但其实制定目标的过程，也是一个让成员不断打磨自己的过程。通过一个个目标的完成，让参与的同学得到个人能力的提升，未来可以承担更大的职责，组织也在这个过程做能力的积累与沉淀。