robbin谈管理：改造团队的经验(1)
程序员文章站
2022-03-01 12:48:02
...
一转眼入职CSDN已经两年了。这两年我分管的网站产品、研发和运营方面都取得了令自己感到非常满意的成绩。记得当初来公司担负的主要使命就是改造CSDN网站平台，到现在为止，总共占据CSDN网站流量90%以上的产品除论坛以外，包括博客，下载，Passport，个人空间和搜索产品已经全部重写完毕；此外我还砍掉了几百个废弃的站点，几十个半死不活的频道；梳理了整个网站的统一风格；建立了完善的社区产品运营体系；待今年CSDN论坛重写完毕，可以说完成了一大使命了。
当然，很多人可能觉得不以为然，认为CSDN网站首页仍然很乱，频道仍然很杂，我没能改变什么，还认为我应该为密码门负责。我想说的是，CSDN的确还有流量仅占全站不到8%的部分(包括首页)仍然很乱，但这个不是我短期之内能够改变得了。至于密码门，被挂马拖库是我入职CSDN之前发生的，而我入职以后，即在当年8月果断的清理了明文，并立即启动Passport产品重写计划，随后在元旦上线新版Passport，彻底解决了这个问题，若非如此公司会面临更大的损失。如果非说我巧言令色，非要我背这个前任留下的黑锅，我也认了。不过我从不觉得这些成绩有什么可以炫耀的，擦屁股的事情从来都不耀眼，更不容易邀功。擦屁股的最高境界是让用户不知不觉当中就把屁股给擦干净了，我没能做到这一点，深感遗憾。不过说到改造团队的经验，自认为可以炫耀一下。
在之前自己创业的经历当中，我的团队管理能力就是一大弱点，经常无法调动团队积极性而陷入个人孤军奋战当中。被CSDN并购之前，收购方对我能力最担心的也是团队管理能力。两年前我接手的团队是公司公认最差的部门，人员也残缺到只有15人；两年后，我的团队是公司公认最好的部门，人员扩充到了60人，而且部门员工离职率极低，团队气氛很融洽。团队管理能力这两年得到了质的提升，回想起来，团队管理中所有能遇上的问题都遇到过了，其中的磕磕绊绊之处数不胜数，完全是在实践当中吸取教训，所以《robbin谈管理》的专栏，第一篇就是谈改造团队的经验。去年写过一篇博客《我来CSDN的这一年》，已经详细的谈了很多这方面的经验和教训了，这篇主要想补充一些当时的想法，也给自己做做总结。
一般来说新官上任三把火，新的高管空降之后往往会大肆招人，快速推进改革。但我在入职CSDN之前就考虑过这个问题，以为宜缓不宜急，理由如下：
1、做为空降高管，在公司没有任何根基，亦没有做出任何成绩来证明自己，这个时候领导的信任和授权是有限度的。一旦初战不利，领导的信任度被透支，在公司恐怕难有立足之地，更遑论改造团队，发挥自己的才能了。
2、我早年做过很多软件咨询项目，给很多公司讲过敏捷开发、领域模型、面向对象建模和ORM。但我能够得到这些公司的信任，却并非因为讲这些时髦的内容，而是因为擅长解决各类技术上的疑难杂症，可以扮演一个救火队长的角色，对客户公司的问题基本做到手到病除。当一个公司出了大麻烦请你过去的时候，无论未来愿景有多好，其实真正需要你的只有一点，就是让你去灭火的。你不能快速灭火就没有实用价值，无论你社区名望多高都扯淡。
因此刚到CSDN的前半年，我相当沉得住气，没有招过一个新员工，而是立足于稳定现有的团队，止住继续下滑的趋势，给团队到处灭火。之所以半年都不招人有3个考虑：
1、不想让现有的团队感觉一朝天子一朝臣，担心自己在公司没有发展前途，成为弃儿，而希望给每个人平等的发展机会。不招新人可以让现有团队心理比较安全，可以安心的好好工作，不至于发生更多的动荡。
2、我认为只有好的制度才能造就好的团队，在没有解决现有团队的痼疾之前招聘新人，不但不会带来新的生产力，反而会造成团队更加混乱，应该先打下一个好的根基，再招人才能事半功倍。
3、对现有团队缺乏深入了解，对公司现有业务了解也不够透彻，也不清楚现有团队真正缺的是什么样的人才，在这种情况下招聘会显得非常盲目，不如对团队有了深入了解之后再有针对性的招人更有的放矢。因此尽管人事部门一再催促，我硬是压着简历不看，拖了好几个月，给当时负责招聘的人事mm带来了很大的压力。
其实我为自己当时没有一上来就盲目招人而感到庆幸。因为后来我看到过类似的案例，空降的高管在没有对业务深入了解，对团队能力没有深刻认识的情况下就从外面急吼吼招来了新的主管，结果新主管的业务能力和现有团队匹配不上、配合不好，造成了新主管和老团队的尖锐对立，团队搞得一团糟。
解决团队问题首先在于找到问题根本之所在，因此我入职后第一个月就做了一件事情：对团队进行深入的调研。从人事部门调集了每个员工的资料仔细研读；对其他部门高管做访谈，问他们对本部门员工的印象和评价；给部门员工发自己写好的调查问卷，要求每个人认真填写；和每个员工进行面谈，问他们认为公司问题在哪里；写出来我对每个员工的印象和评价。
经过一个月调研，我发现团队混乱根源在于三点：
1、业务配合没有建立合理的工作流程，工作目标既不清晰亦不明确，员工往往无所适从。
2、部门内部管理一塌糊涂，没有清晰明确的管理制度，没有合理的绩效考核，没有赏罚分明的奖惩制度，员工之间没有交流和沟通，积怨很深。
3、跨部门之间的工作配合毫无规范可言，部门之间相互推诿，随便什么业务人员都会随时给研发人员下命令，长此以往，伤害了研发团队的积极性。
简单的说就是：无业务流程，无部门管理，无规范协作。针对这三点我分别采取了相应的措施：
1、针对无业务流程的问题，我设立了产品团队，亲自兼任产品经理把所有产品都抓过来统一管理。无论部门内部还是跨部门产品研发，统一走产品设计流程，制定了规范的产品流程，强调以互联网产品设计驱动整个产品设计，UI，研发和运营流程，将目前公司所有平台级产品开发统统规范起来了。关于这一点，在《我来CSDN的这一年》有很详细的介绍，不再多说。
2、针对无部门管理的问题，进行了部门组织架构调整，减少了部门管理层级，强化了自己对团队的管理权。此外逐步建立和完善部门规范的管理制度，如：使用JIRA进行整个部门的工作任务量化管理；建立定期周会，周报和月报制度；我亲自制定了部门绩效考评内容、评分标准和奖励等级；要求团队间工作配合必须邮件书面确认抄送给我等等。关于部门管理制度的制订，以后准备另外撰文来介绍。
3、针对跨部门无规范协作的问题，反复在部门内部强调一条纪律：跨部门合作必须通过邮件得到两个部门高管确认，口头说的统统无效，拒绝合作；凡未通过我，未得到我邮件批准擅自去做的员工一律严惩。同时亲自接管所有跨部门工作配合，事无巨细都会亲自来做。这半年我很少花时间和自己的团队待在一起，反而花了大量时间和精力用来和其他各个部门的高管沟通和搞好关系。
其中特别想说说这第3点，在我看来如果跨部门协作的问题不解决，即便解决前2个问题也没用。因为产品、研发和运营部门在公司的体系中不是直接创造收入的业务部门，而是承担业务部门的服务者角色。作为一个服务者，往往站在一个被动和弱势的位置上，很容易被业务人员举着收入的大棒指挥你无条件的服从。这样一来，部门内部无论怎样合理的计划都会被外部的力量轻易打破，让员工无所适从。
我之所以亲自接管所有跨部门协作，之所以花那么多时间和其他部门沟通，目的只有一个：充当团队的保护伞，给自己的团队创造一个相对宽松和*的工作空间，保护团队不被外部的原因伤害到。
当时员工的工作积极性之所以不高，喜欢互相推卸责任，究其原因在于：员工的工作很被动，业务部门人员随便指派任务，随意变更需求，员工无所适从。好不容易按照业务人员的需求做好一个东西以后，业务人员又随意的否定做出来的成果，乱指挥且无计划性，挫伤了我们部门员工的积极性。再者一旦这项工作最终没有取得一个预期的结果，责任又往往被推卸到我们研发人员身上。久而久之，员工就产生了自我保护意识，凡工作尽量往后退，凡责任尽量往别处推，不求有功但求无过。
为打破员工养成的这种自我保护意识，鼓励员工更加积极主动做事情，我能够做的就是把这些责任都扛在自己身上，亲自去协调每项工作，让员工没有后顾之忧，让员工相信我可以搞定他们担心的事情，而一旦工作有成绩，我会在员工月度绩效考评当中体现出来。这也是为什么我花了那么多时间去处理和其他部门协调的原因。
通过半年的努力，渐渐赢得员工对自己的信任，这种信任是替员工解决一个又一个实际工作问题，并且坚持公平公正的给员工的工作成绩考评带来的；团队也开始变得积极主动起来了，我的团队管理制度也基本上定型了，后来只是不断的强化而已。这半年尽管我已经彻底摸清团队，对团队改造已经拿出了有针对性的措施，形成了管理制度，但团队毕竟还在起步阶段，没有什么可以拿得出手的工作业绩，所以当时连公司大老板也觉得我动作太缓慢了，要求我动作快点。
这几年，我根据自己的经验，以及亲眼看过的诸多案例，总结了一个规律：一个新的高管接手团队以后，问题将在半年之后集中爆发出来，而成绩将在一年之后得以体现。
接手一个团队的前半年，往往还处在逐渐消除前任痕迹，打上自己烙印的过程中，在这半年无论高管多能干，业绩也不可能立竿见影。如果这半年能迅速出业绩，往往不是因为你能干，而是因为你的前任给你留下了一个很厚的家底。
真正的挑战来自于半年之后，前任的余热已经全部发挥完了，你的烙印开始打在团队身上，而前任的痕迹还没有消除干净，各种矛盾就会集中爆发出来，这才是真正考验你的时刻。你能不能消化掉这个团队，和这个团队发生美妙的化学反应，全看这半年。
而到一年任期的时候，你合格不合适可以盖棺定论了。要么你已经改造了整个团队，业绩开始快速上升；要么你的团队还是一团遭，业绩没有任何起色。
我前半年以稳为主，并没有遇到什么挑战，业绩也确实乏善可陈，真正的考验都发生在半年以后，而产品改造的成绩差不多都是在一年左右的时间开始井喷的。我也见过这样的案例：高管空降过来的前半年恰逢不错的外部环境，前任留下的家底也不错，业绩开门红，上下皆喜。但是半年过后形势大变，各种矛盾集中爆发，团队动荡，骨干员工纷纷离职，业绩一落千丈。
所以我以为，前半年就出业绩对空降高管来说不是什么好事，这个业绩本来和你无关，但是这么快出业绩非常具有迷惑性，让你以为自己轻松的搞定团队了，混不知下面矛盾重重，暗流汹涌。而且就算你当时能够意识到问题，但由于有良好的业绩，任何人都会犹豫要不要动手调整。而等问题在半年以后集中爆发出来，你再想着手调整团队，已经错过了最佳时机了，就算最终能够解决问题，也需要付出巨大的代价。
在前半年已经打下了一个良好基础上，就可以大规模招聘新员工了。这个就留到下篇博客再说。总结一下到这个阶段的经验如下：
1、刚接手一个有问题的团队，不着急上来烧三把火，要先对整个团队做深入的调研，搞清楚整个团队的核心问题在哪里，团队的组成架构和运作方式，团队每个成员的特点和能力，他们之间的关系，要彻底的摸清楚这个团队过去成功的地方和失败的地方，具有的优点和存在的问题。即首先做充分的调研工作，调研工作可以从公司上至CEO，下至每个员工方面进行一对一的谈话。
2、找到核心问题以后，针对核心问题进行团队微调和解决问题，但不能做大的手术，以安抚现有的员工，调动员工积极性为主，帮助他们解决实际问题，树立他们对我的信任和依赖。这个阶段基本上在到处灭火，解决团队各种问题，目的在于取得员工的信赖，树立团队威信。
robbin谈管理:改造团队的经验(2)
当然，很多人可能觉得不以为然，认为CSDN网站首页仍然很乱，频道仍然很杂，我没能改变什么，还认为我应该为密码门负责。我想说的是，CSDN的确还有流量仅占全站不到8%的部分(包括首页)仍然很乱，但这个不是我短期之内能够改变得了。至于密码门，被挂马拖库是我入职CSDN之前发生的，而我入职以后，即在当年8月果断的清理了明文，并立即启动Passport产品重写计划，随后在元旦上线新版Passport，彻底解决了这个问题，若非如此公司会面临更大的损失。如果非说我巧言令色，非要我背这个前任留下的黑锅，我也认了。不过我从不觉得这些成绩有什么可以炫耀的，擦屁股的事情从来都不耀眼，更不容易邀功。擦屁股的最高境界是让用户不知不觉当中就把屁股给擦干净了，我没能做到这一点，深感遗憾。不过说到改造团队的经验，自认为可以炫耀一下。
在之前自己创业的经历当中，我的团队管理能力就是一大弱点，经常无法调动团队积极性而陷入个人孤军奋战当中。被CSDN并购之前，收购方对我能力最担心的也是团队管理能力。两年前我接手的团队是公司公认最差的部门，人员也残缺到只有15人；两年后，我的团队是公司公认最好的部门，人员扩充到了60人，而且部门员工离职率极低，团队气氛很融洽。团队管理能力这两年得到了质的提升，回想起来，团队管理中所有能遇上的问题都遇到过了，其中的磕磕绊绊之处数不胜数，完全是在实践当中吸取教训，所以《robbin谈管理》的专栏，第一篇就是谈改造团队的经验。去年写过一篇博客《我来CSDN的这一年》，已经详细的谈了很多这方面的经验和教训了，这篇主要想补充一些当时的想法，也给自己做做总结。
一般来说新官上任三把火，新的高管空降之后往往会大肆招人，快速推进改革。但我在入职CSDN之前就考虑过这个问题，以为宜缓不宜急，理由如下：
1、做为空降高管，在公司没有任何根基，亦没有做出任何成绩来证明自己，这个时候领导的信任和授权是有限度的。一旦初战不利，领导的信任度被透支，在公司恐怕难有立足之地，更遑论改造团队，发挥自己的才能了。
2、我早年做过很多软件咨询项目，给很多公司讲过敏捷开发、领域模型、面向对象建模和ORM。但我能够得到这些公司的信任，却并非因为讲这些时髦的内容，而是因为擅长解决各类技术上的疑难杂症，可以扮演一个救火队长的角色，对客户公司的问题基本做到手到病除。当一个公司出了大麻烦请你过去的时候，无论未来愿景有多好，其实真正需要你的只有一点，就是让你去灭火的。你不能快速灭火就没有实用价值，无论你社区名望多高都扯淡。
因此刚到CSDN的前半年，我相当沉得住气，没有招过一个新员工，而是立足于稳定现有的团队，止住继续下滑的趋势，给团队到处灭火。之所以半年都不招人有3个考虑：
1、不想让现有的团队感觉一朝天子一朝臣，担心自己在公司没有发展前途，成为弃儿，而希望给每个人平等的发展机会。不招新人可以让现有团队心理比较安全，可以安心的好好工作，不至于发生更多的动荡。
2、我认为只有好的制度才能造就好的团队，在没有解决现有团队的痼疾之前招聘新人，不但不会带来新的生产力，反而会造成团队更加混乱，应该先打下一个好的根基，再招人才能事半功倍。
3、对现有团队缺乏深入了解，对公司现有业务了解也不够透彻，也不清楚现有团队真正缺的是什么样的人才，在这种情况下招聘会显得非常盲目，不如对团队有了深入了解之后再有针对性的招人更有的放矢。因此尽管人事部门一再催促，我硬是压着简历不看，拖了好几个月，给当时负责招聘的人事mm带来了很大的压力。
其实我为自己当时没有一上来就盲目招人而感到庆幸。因为后来我看到过类似的案例，空降的高管在没有对业务深入了解，对团队能力没有深刻认识的情况下就从外面急吼吼招来了新的主管，结果新主管的业务能力和现有团队匹配不上、配合不好，造成了新主管和老团队的尖锐对立，团队搞得一团糟。
解决团队问题首先在于找到问题根本之所在，因此我入职后第一个月就做了一件事情：对团队进行深入的调研。从人事部门调集了每个员工的资料仔细研读；对其他部门高管做访谈，问他们对本部门员工的印象和评价；给部门员工发自己写好的调查问卷，要求每个人认真填写；和每个员工进行面谈，问他们认为公司问题在哪里；写出来我对每个员工的印象和评价。
经过一个月调研，我发现团队混乱根源在于三点：
1、业务配合没有建立合理的工作流程，工作目标既不清晰亦不明确，员工往往无所适从。
2、部门内部管理一塌糊涂，没有清晰明确的管理制度，没有合理的绩效考核，没有赏罚分明的奖惩制度，员工之间没有交流和沟通，积怨很深。
3、跨部门之间的工作配合毫无规范可言，部门之间相互推诿，随便什么业务人员都会随时给研发人员下命令，长此以往，伤害了研发团队的积极性。
简单的说就是：无业务流程，无部门管理，无规范协作。针对这三点我分别采取了相应的措施：
1、针对无业务流程的问题，我设立了产品团队，亲自兼任产品经理把所有产品都抓过来统一管理。无论部门内部还是跨部门产品研发，统一走产品设计流程，制定了规范的产品流程，强调以互联网产品设计驱动整个产品设计，UI，研发和运营流程，将目前公司所有平台级产品开发统统规范起来了。关于这一点，在《我来CSDN的这一年》有很详细的介绍，不再多说。
2、针对无部门管理的问题，进行了部门组织架构调整，减少了部门管理层级，强化了自己对团队的管理权。此外逐步建立和完善部门规范的管理制度，如：使用JIRA进行整个部门的工作任务量化管理；建立定期周会，周报和月报制度；我亲自制定了部门绩效考评内容、评分标准和奖励等级；要求团队间工作配合必须邮件书面确认抄送给我等等。关于部门管理制度的制订，以后准备另外撰文来介绍。
3、针对跨部门无规范协作的问题，反复在部门内部强调一条纪律：跨部门合作必须通过邮件得到两个部门高管确认，口头说的统统无效，拒绝合作；凡未通过我，未得到我邮件批准擅自去做的员工一律严惩。同时亲自接管所有跨部门工作配合，事无巨细都会亲自来做。这半年我很少花时间和自己的团队待在一起，反而花了大量时间和精力用来和其他各个部门的高管沟通和搞好关系。
其中特别想说说这第3点，在我看来如果跨部门协作的问题不解决，即便解决前2个问题也没用。因为产品、研发和运营部门在公司的体系中不是直接创造收入的业务部门，而是承担业务部门的服务者角色。作为一个服务者，往往站在一个被动和弱势的位置上，很容易被业务人员举着收入的大棒指挥你无条件的服从。这样一来，部门内部无论怎样合理的计划都会被外部的力量轻易打破，让员工无所适从。
我之所以亲自接管所有跨部门协作，之所以花那么多时间和其他部门沟通，目的只有一个：充当团队的保护伞，给自己的团队创造一个相对宽松和*的工作空间，保护团队不被外部的原因伤害到。
当时员工的工作积极性之所以不高，喜欢互相推卸责任，究其原因在于：员工的工作很被动，业务部门人员随便指派任务，随意变更需求，员工无所适从。好不容易按照业务人员的需求做好一个东西以后，业务人员又随意的否定做出来的成果，乱指挥且无计划性，挫伤了我们部门员工的积极性。再者一旦这项工作最终没有取得一个预期的结果，责任又往往被推卸到我们研发人员身上。久而久之，员工就产生了自我保护意识，凡工作尽量往后退，凡责任尽量往别处推，不求有功但求无过。
为打破员工养成的这种自我保护意识，鼓励员工更加积极主动做事情，我能够做的就是把这些责任都扛在自己身上，亲自去协调每项工作，让员工没有后顾之忧，让员工相信我可以搞定他们担心的事情，而一旦工作有成绩，我会在员工月度绩效考评当中体现出来。这也是为什么我花了那么多时间去处理和其他部门协调的原因。
通过半年的努力，渐渐赢得员工对自己的信任，这种信任是替员工解决一个又一个实际工作问题，并且坚持公平公正的给员工的工作成绩考评带来的；团队也开始变得积极主动起来了，我的团队管理制度也基本上定型了，后来只是不断的强化而已。这半年尽管我已经彻底摸清团队，对团队改造已经拿出了有针对性的措施，形成了管理制度，但团队毕竟还在起步阶段，没有什么可以拿得出手的工作业绩，所以当时连公司大老板也觉得我动作太缓慢了，要求我动作快点。
这几年，我根据自己的经验，以及亲眼看过的诸多案例，总结了一个规律：一个新的高管接手团队以后，问题将在半年之后集中爆发出来，而成绩将在一年之后得以体现。
接手一个团队的前半年，往往还处在逐渐消除前任痕迹，打上自己烙印的过程中，在这半年无论高管多能干，业绩也不可能立竿见影。如果这半年能迅速出业绩，往往不是因为你能干，而是因为你的前任给你留下了一个很厚的家底。
真正的挑战来自于半年之后，前任的余热已经全部发挥完了，你的烙印开始打在团队身上，而前任的痕迹还没有消除干净，各种矛盾就会集中爆发出来，这才是真正考验你的时刻。你能不能消化掉这个团队，和这个团队发生美妙的化学反应，全看这半年。
而到一年任期的时候，你合格不合适可以盖棺定论了。要么你已经改造了整个团队，业绩开始快速上升；要么你的团队还是一团遭，业绩没有任何起色。
我前半年以稳为主，并没有遇到什么挑战，业绩也确实乏善可陈，真正的考验都发生在半年以后，而产品改造的成绩差不多都是在一年左右的时间开始井喷的。我也见过这样的案例：高管空降过来的前半年恰逢不错的外部环境，前任留下的家底也不错，业绩开门红，上下皆喜。但是半年过后形势大变，各种矛盾集中爆发，团队动荡，骨干员工纷纷离职，业绩一落千丈。
所以我以为，前半年就出业绩对空降高管来说不是什么好事，这个业绩本来和你无关，但是这么快出业绩非常具有迷惑性，让你以为自己轻松的搞定团队了，混不知下面矛盾重重，暗流汹涌。而且就算你当时能够意识到问题，但由于有良好的业绩，任何人都会犹豫要不要动手调整。而等问题在半年以后集中爆发出来，你再想着手调整团队，已经错过了最佳时机了，就算最终能够解决问题，也需要付出巨大的代价。
在前半年已经打下了一个良好基础上，就可以大规模招聘新员工了。这个就留到下篇博客再说。总结一下到这个阶段的经验如下：
1、刚接手一个有问题的团队，不着急上来烧三把火，要先对整个团队做深入的调研，搞清楚整个团队的核心问题在哪里，团队的组成架构和运作方式，团队每个成员的特点和能力，他们之间的关系，要彻底的摸清楚这个团队过去成功的地方和失败的地方，具有的优点和存在的问题。即首先做充分的调研工作，调研工作可以从公司上至CEO，下至每个员工方面进行一对一的谈话。
2、找到核心问题以后，针对核心问题进行团队微调和解决问题，但不能做大的手术，以安抚现有的员工，调动员工积极性为主，帮助他们解决实际问题，树立他们对我的信任和依赖。这个阶段基本上在到处灭火，解决团队各种问题，目的在于取得员工的信赖，树立团队威信。
robbin谈管理:改造团队的经验(2)