前言

大家都知道做程序员不可能从头到尾一直都是一个人写代码研究技术，到了一定阶段 ，自身有了一些能力经验可能就会转变为组长，项目管理，哪怕没有升职转岗，公司领导可能也会让你去带一些新人。
说下我的情况，我迄今为止是做了2年多java开发，6年android开发，4年项目管理（java和Android时间有重叠），在上家公司完成了转型 ，刚进公司时岗位是 Android开发工程师，后面调整为 Android开发组组长->移动开发组组长->项目经理->事业部经理。来到现在的公司基本还是做同样的事情，只是项目规模不一样。看似顺风顺水的职业道路上，其实我犯过很多的错误，因为毕竟是技术出身，程序员思维，在很多时候考虑问题真的是惯性思维，没有调整过来，所以自己回顾复盘后希望把这些问题记录下来，希望能对后面的小伙伴有一点点帮助。
（ps:不同公司对团队领导定义略有区别 技术组长、技术经理、技术负责人、项目负责人、项目经理 这些角色我下文统称 经理。）

一、自身职责不清晰

有的公司升为经理后很多还会承担一些编码工作。在他们刚开始转为管理后，第一个最大的问题就是自身职责不够清晰，习惯性总是先考虑自己的工作内容，忽略团队的工作内容，一个新功能模块习惯性先考虑自己应该做的话需要做哪些工作，都有哪些技术难点。还是习惯性的把自己当一个开发来定位，没有整体考虑团队成员每个人的工作情况，每个人的工作能力，工作如何合理分配，会有哪些困难，后续进度质量如何跟进等，这点尤其需要注意。

二、亲力亲为

很多时候经理还习惯性自己做，因为写了那么多年代码，看到团队的某些小伙伴进度出问题或者碰到技术难点时候都会习惯性的说“我来搞”。

一 、为了在团队成员面前显示自己有能力
二 、有的项目工期确实紧张，自己做感觉进度能把控住。
举个例子：公司新开发一个项目，一期计划先实现基础功能，里面有个登录模块。
经理：这个登录功能很简单，xx项目里面有现成的，小明你来做吧，你参考改改两天差不多就搞完了，明天搞好了让测试测一下先。结果两天后去问进度，
小明：““xx的接口调试一直有问题，界面切图设计还差两个没给我；这个产品经理xx说需要再改一下”等等诸如此类的答案。
这时候有的经理一看到这种情况，想了一下项目上线时间。
经理：行了，你先别弄了，代码提交一下，我来搞吧！你先改下禅道上其他bug吧。

这是个非常普通但确实很多刚转变角色的人都熟悉的案例，很多刚升职的经理 角色转变没有那么快，都会犯这样的错误。
经理这过程的问题，没有站在小明角度考虑问题，他主观的认为自己做这件事的时间和小明做那件事的时间差不多。工作能力、公司项目熟悉程度、和其他部门协调沟通默契程度 等这些 他认为自己和小明应该差不多。

1.安排任务没详细沟通确认细节，后台接口完成情况、设计部门时间等
2.当出现进度未按期完成时，应该帮忙协调沟通确认部门外其他部门完成时间，而不是揽下来自己做。
3.殊不知“行了，你先别弄了，代码提交一下，我来搞吧！你先改下禅道上其他bug吧”当这句话说出来，不但伤害了小明自尊心，打击了他的积极性，让其他同事也会对小明有看法，破坏团队氛围的大忌。

三、对进度过于乐观

还是上面的例子，项目任务下来了，项目计划排好后，工作任务也安排给小明了，都落实到具体责任人身上了，这时候经理就坐等结果去了，那么可以吗？显然从结果来看，是不理想的，因为中间缺少了检查监督环节，没有及时跟进发现问题。布置好、落实好不代表监督好，一切工作还要有监督。另外还要通过监督总结，才可能发现问题、处理问题、总结经验、汲取教训，才可能在最后把项目完成得更好。
对进度太乐观了，可能就会导致结果有问题。监督跟进的环节是非常重要的，千万不要全凭经验来做事。因为很多都是都是变化的，多考虑目前实际情况，用数据和理论依据来思考问题。

四、重进度、轻质量

一个项目不仅仅要管理好进度，还要保证项目的质量达到可以交付的标准。这个也是一个非常难的事情，因为对于信息化项目来讲，变化的因素太多了，有效的保证项目顺利进行，一定要建立一套完善的运行机制才可以，给大家举一个真实发生在我身上的例子。

举例：当时给某公司研发一套信息化平台，原定2018年10月20号给客户交底培训V1.0版本的平台，我当时为了确保万无一失，和开发定的提前两周封版，不增加任何功能，只做测试修复问题。
基本提前一周完成修改复测，最后几天每天都登录测试演示流程。2018年10月19号晚上8点左右还又和产品经理一起完整走了一遍流程，确保没问题，开开心心回家了。第二天直接从家里面出发去客户现场，提前一个小时到了现场，连上wifi开始测试，这时我发现演示的账号admin登录不上去了…紧急给开发打电话处理，开发这时候还没有到公司（艰难）…后来半小时后开发说处理好了，让我重新试一下，结果登录上去以后 ，界面也有问题了…很多模块权限不对了…后来当天一半内容用ppt完成的讲解…
回来后，得知是其中一位开发人员临时清理数据误清除了其中的一个字典数据表，影响了整个系统的逻辑…当时我的心情简直难以形容…每次我或者产品经理外出给客户演示或者培训时都交代不要动服务器的任何东西，也不要做任何更新操作，都在本地测试环境操作。竟然还会发生这种事…
后来我仔细回想了一下这个事情，其实是自己的管理机制有问题，之前我们的项目组后台更新线上平台和数据都是各自负责自己模块，也就是说谁都可以有权限动线上的东西，假如当时只把更新代码，操作线上系统数据库权限等权限只分配给一位后台开发人员，他每次更新系统版本或者操作修改线上数据库之前都和我沟通一下，是不是就能很大程度的避免这种情况呢。
总之，项目经理对项目的管理不能只重视进度 ，不重视质量，任务安排下去完成后，要进行有效的监督检查，制定完善的机制确保项目质量，才能保证项目按时正常交付。

五、工作重点、目标不明确

有些经理太过关注当下急需解决的事情，而缺乏远虑和远见。每天都在忙于处理各种突发紧急问题，做的都是紧急不重要的事情。对问题做出反应是人的本能，这让经理感觉良好，因为他们在不停处理问题，而且别人也会看到他们在做事。

时间久了，经理还习惯了这样的方式，典型的表现有以下几种：
1.每天不停的处理各种看起来很紧急的问题，各种公司群，公司邮箱反馈回复。
2.在工位上大声给项目团队成员下达各种指令。
3.给公司外面的客户或者领导打电话，不聊重要的事情，扯闲篇扯半天。
4.有的甚至没工作的时候也要装作很忙的样子，找点八百年不维护的项目让团队的人去做优化。。
5.没事喜欢往自己上级领导办公室跑，去汇报一些鸡毛蒜皮的小事情来刷存在感。
6.从来不认真分析团队规划、团队文化建设、项目更新、技术创新等更有意义的事情。

六、缺乏担当

举例：项目原定10号上线，结果因为bug太多拖延到了15号。上级找经理问什么原因导致项目延期，晚上线了一周时间，给公司损失了抢占市场的绝佳机会。

经理：领导，这个事情是这样的，本来功能都开发完了，也都测试完了。后来小明改了一下xx模块，导致项目其他有关联的模块也都出了问题，bug太多我就决定先不上线，我安排他紧急加班处理的，同时我也让测试和我一起加班复测了，复测都没有问题后才上线的。
领导：好的，我知道了！
看似经理处理的很妥当，而且也表明自己在这个过程中和团队加班一起处理跟进了，但是实际上经理把锅甩给小明了，不是自己造成的！典型的甩锅行为。
如果他能这样回答，就好很多，也体现了作为一个领导的担当：
“领导，这次的问题都是我对项目风险预估不足，中间出了些问题，好在我们团队的人都非常给力，连续加了好几天班，大家一起处理好了，已经及时上线了，延期了几天上线，下来我会复盘总结，保证以后不出类似的问题”。
所以作为领导一定要搞清楚自己的定位，只要是你领导的团队，他们当中任何一个人出了问题，你作为领导都有责任，不是说谁改错找谁，他出的问题，你在团队内部沟通，而不是去你领导那把自己团队的人推到前面去背锅。
合格的领导都有一个共同的优点，那就是有担当，不合格的领导也有一个共同的缺点，那就是没有担当，没有担当就是这个人综合工作能力的表现，想好好地开展工作和向上发展，就应该在合适的时候，合适的场合，选择合适的对象，承担起自己这个岗位应该肩负的责任，这才是正途！

七、沟通不明确

这个也是常犯的错误之一，交代任务后没有确认团队成员是否完全理解，是否真正的知道自己所要接收的任务目标是什么。尤其对没有经验的一些团队成员，比如刚招进来的实习生，在传达任务的时候一定要说清楚，并且将一些细节以及需要注意的问题都一并说清楚。其实这个最好的办法是：安排任务后让任务接收人复述一遍，这种办法是最有效的。
当然自己在接收领导任务的时候也是一样，老板有事情交代给你的时候，也要在接受任务的时候问清楚具体细节，这样最后完成的结果才不会有太大的偏差。

八、抱怨、情绪化

有的时候项目周期客户要求的上线时间要越快越好，给的开发周期非常短，客户和领导一直催，一直问进度，部门员工还得让他们不停加班赶进度，有的员工肯定会有怨言。作为团队的领导在这样的压力下，通常难以理智冷静面对各方需求，往往会做出习惯性否定、习惯性接受，在得不到满意反馈时习惯性抱怨。
刚上任需要通过一段时间了解组员和项目的情况和问题，拿出合适的方案和老板协商并改进，不能盲目否定和接受别人的意见，更不要抱怨。因为作为团队的领导一旦将不好的情绪展现到团队成员面前，那么这个团队的整体氛围一定很差，工作效率也不会很高。

九、项目风险认识不足

互联网的信息化项目从立项到交付验收整个过程看似简单的流程，其实充满了各种各样的风险，项目的各种不确定性实在太多了，需求、决策、团队成员、进度等等。
这就需要我们对项目有整体的全景认知，认真详细的提前考量各种约束风险，并且在各种实战中积累出一套成体系的风险管理方法实践，用这样的方法做风险管理，我们才能做到胸有成竹，将风险降到最低，最大化的提升项目交付效率。
这需要在项目早期考虑这些风险，最好按类别逐项列出，一般的风险大概涵盖以下几类：
1. 人员风险
如：人员请假离职、项目人手不足、任务人员分配不合理、新加入成员对项目不熟悉、项目人员工作态度技术能力、项目组人员之间有矛盾等有问题
2. 需求风险
如：需求规划不全面、需求不断新增、需求不断变更、部分需求存在技术难点、需求变更未及时通知各相关参与人员等
3. 技术风险
如：复杂需求技术存在难点、需求需要采用三方技术，技术选型周期过长、开发人员技术水平问题，做出来功能漏洞百出，开发环境不稳定、技术方案设计存在漏洞等
4. 外部风险
如：需和其他厂商配合开发，配合沟通有问题，调用三方服务不稳定、项目组外支持人员配合默契度不够等
5. 环境风险
如：服务器、网络、域名证书、手机等各种硬件测试设备不到位等
那这么多的风险如何应对呢？
1.需求调研多花时间确认细节，多在这个环节上花心思，最好通过几轮的讨论确定设计方案。
2.制定完善的流程，每件事对应到具体责任人来负责。
3.采用合理的管理工具及平台，提高沟通协作效率。
4.出现任何问题，及时响应处理，不要拖延。
5.和各方人员沟通时，调整好心态。

十、不注重团队建设

说起团队建设可能很多人就认为是叫大家一起晚上吃个饭、K个歌，放松Happy一下，这个起作用吗？起作用，但是这种方式并不是最植入内心的，只是增加大家团队凝聚力的一种方式。人都是感情动物，在和团队成员相处的时候一定是多换位思考，团队成员佩服什么样的领导，真正喜欢什么样的工作氛围其实大家应该也都清楚，毕竟都是从底层员工成长上来的。
好的领导我认为一般具备以下几个特点：

1. 能力、技术水平极为突出
2. 情商非常高，有亲和力，所有人和他相处都感觉很舒服
3. 帮助团队成员成长
4. 非常有担当
5. 做事条理清晰、逻辑思维缜密
6. 良好的心态 很少有负面情绪
   员工心里面喜欢什么样的领导：
   1.能帮我解决我碰到的技术难点
   2.能给我的工作提供思路和方法的
   3.跟着他可以学习提高我的技术
   4.能帮我争取涨工资的
   5.出了问题可以帮我顶雷的

所以综上总结：团队建设最核心的两点我认为是尊重和帮助他们成长。
1.尊重
员工是员工，但是首先是个人，每个人在团队中都希望被他人尊重，不能根据团队成员的技术水平高低、项目经验多少来贬低或者嘲讽他人，安排工作的时候有意或者无意的让别人下不来台。举几个反面例子，大家自己感受：

• 开会安排工作：xx模块很简单，所以这个就小明你来做。（当众贬低他人）
• 小明迟到，当众批评：你要再迟到，这个月的奖金就给你都扣了（粗暴解决问题）
• 这么简单的问题搞不定吗？大哥，你这基础太差了（当众贬低别人）
• 下次再这么多bug，你自己找老板说原因吧（用领导压员工）
• 和其他同事说xx技术太差了，不能把这个让他做。（背后贬低别人）
• 项目出问题，说是xxx的改的出了问题。（甩锅行为）
• 奖金分配根据自己好恶及小圈子分配（标准不一，不透明）
• 工作任务安排不合理，强行压缩工期（工作安排不合理）
• 项目取得成功，功劳归为己有。（贪功，缺乏团队意识）
• 制定各种扣钱制度（无能表现）
  不多说了，有这些行为的各自对号入座吧…希望各位迷途知返
  2.帮助他们成长
  团队的成员工作积极性是怎么被激发的？我认为就是他们可以在这个团队获得足够多的成就感，这种成就感基本都是在工作中获得的。
  反面例子我就不举了，对如何使团队成员获得成就感，我谈下我自己的看法：
• 多赞美和鼓励团队员工
• 多和他们沟通，倾听他们内心真实的想法
• 尽量不打断他们说话，耐心听完，然后再发表意见
• 他们犯了错误，及时指正提醒，不能放任不管
• 不要帮他们做任务，可以指导方法
• 承担责任，不要把问题的责任都归到团队成员的身上，让他们背负压力
• 了解熟悉每个人的长处和短处，合理安排任务

其实这方面的经验，我自己也在不停探索中，其实中国式的管理没有那么强的条条框框。因人而异，因事而异，需要自己体会。同样的方法对不同的人可能效果不一样。但是多用心，拿出自己的真诚来面对团队的每个人，我认为结果就不会太差。

还有10多天，就是2022年除夕了，提前祝大家新春快乐，身体健康，阖家欢乐！

文章来源: wukong.blog.csdn.net，作者：再见孙悟空_，版权归原作者所有，如需转载，请联系作者。

原文链接：wukong.blog.csdn.net/article/details/122426848