很多程序员在刚晋升为leader时，多多少少都会犯些管理上的小错误，因为思维方式的转变需要一定时间。
从之前的和机器打交道，变成要和人打交道甚至要为成员的成长负责、为整个项目的风险负责，除了认识到身份的转变、工作方式的变化，更需要改变之前的一些惯性思维。
正好最近看到一篇很有感触的分享，让我想起自己刚带团队的时候，也是这么磕磕绊绊成熟起来，有了自己的管理方法和风格。
团队比项目重要
作为程序员，最重要的工作之一就是按时交付需求，因为程序员的工作很难量化，所以向领导证明开发团队的价值和能力的很重要的一个方法就是按时交付且符合需求。
所以在我刚晋升为leader的时候，我还一直保持这种惯性思维，觉得只要按时交付了，产品不出大差错，那就是带整个团队做好了工作。
至于开发团队中的每个成员，谁走了不重要，再招个新人就行。
但随着我工作越来越久，带过的团队和成员数也越来越多，我发现项目本身并不是最重要的，和什么人一起共事一起奋斗更为重要。
因为项目是短期的、暂时的、且很大概率会过时，所以你做过的大部分工作，其价值是会慢慢减少和被淡忘的。
但团队中每个合作过的成员，却可以成为曾一起奋斗的伙伴，甚至长期的朋友，至少在这个行业内会给你提供潜在的帮助。
这也是为什么很多人都说公司之间的竞争其实是组织的竞争，是人才的比拼。
当我意识到这一点后，我开始更加关注每个成员的个人发展意向和成长，除了关注他们的工作状况，还会更多了解生活上的问题，更像和一群朋友相处，而不是上下级的严肃关系。
我发现很多年轻的技术leader在这一点做得远远不够，只要是和下属交流，永远绕不开项目和工作，只对工作目标负责，忽视了人与人之间的多维度联系。
长此以往，成员没有团队归属感，离职频率就会升高，时间久了也会影响工作积极性，项目的交付也会受影响。
流程不是为了监控过程，而是为了方便开发
相信大部分程序员都是比较自律的，对于自己该在什么时间完成什么工作，都会有比较清晰的规划。
我刚开始带团队的第一年，想法比较多，目的都是想怎么提高大家的工作效率，以此提高团队整体生产效率。
一些想法被验证确实有效，我也沿用至今，但有些想法，也被验证会影响开发效率。
比如有一次我为了让一个大项目有明确的工作量划分，以及详细的时间节奏把控，建了个项目表，还弄了很多自动计算公式，一切看起来非常地自动化、完美！
虽然有些开发提出了意见，觉得这纯粹就是浪费时间，但我当时还是告诉他们：“如果你不能衡量它，你就不能改进它。”
这种工作模式试行2周后，我就果断停止了。
为啥？因为这样不仅没有帮大家提高生产力，还反倒增加了他们的工作量，他们得在自己的to do里记着这个事，定期更新工作表，并且反复确认计算结果，然后把一些工作数据生成图表方便可视化，甚至还要做个周总结。
现在你应该明白了我为啥停止这种流程化工作模式。
说到底，引入新的流程目的是帮助开发们更好地开展项目，而不是让他们承担比实际工作更多的“任务”。
为什么很多公司都略反感“项目经理”这个角色？尤其对于程序员来说，我接触过的很多程序员都会吐槽项目经理降低了自己团队的生产效率，增加了很多不必要的工作量。
可能在更大的领导看来，这有利于管理大的团队，但对于每个单独的团队来说，真的是很没必要的一个环节。
不过这仅对于那些只会管控流程，做表面工作的项目经理，对于那些真正深入了解各团队工作模式的非常专业的项目经理，不得不说，他们还是很厉害的，确实是能为团队赋能的。
最后我想说，量化不是目的，获取工作数据也不是目的，能提高生产力交付“漂亮”的结果才是目的。
今天先分享这些，剩下的几点，老王下篇文章再跟大家仔细讲讲～喜欢文章的可以点个关注，或者加老王微信一起聊聊！
大家好，我是程序员老王。 年薪百万老码农，待过一线大厂创过业，带过团队，目前专注于一线技术。 分享程序员进阶路上的点滴，帮助大家提升认知，升职加薪。
