如何提高团队人效？这里有2个实用的建议，很多大公司都在用！

Posted 2023-04-27

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了如何提高团队人效？这里有2个实用的建议，很多大公司都在用！相关的知识，希望对你有一定的参考价值。

参考技术A 来啦，请坐。

我是老杨，这是我的《数字化研发管理》书籍的前奏，我带你稍微见识下其魅力。

如果你有强化管理能力，量化技术产出，提升技术效能，打造技术团队等需求，那么这套课程会为你揭开技术管理的神秘面纱，可以让“妈妈再也不用担心你的工作了”。

这是《数字化技术管理的方法和实践》第五讲，提升互联网技术团队的人效篇第二部分：提升业务投入率，提升研发人效。

一句话解释下：通过什么方法，来提升技术团队的业务投入和人效，让你的团队具备很高的投入度和很高的工作效率。

友情提示：本篇公式比较多，需要你具备清醒的大脑，请洗把脸再继续读哈。

接上篇，直奔主题。

二，提升业务投入率：

业务投入率

业务投入是实际人天除以理论人天，显而易见，要想提升业务投入率只有一条路：1. 增加每个人在研发阶段的实际人天，即每个人都把工作投入到需求、设计、开发、测试、线上bug这五部分中。

那具体怎么实施呢？简而言之，要求团队每个人不要开小差，不要磨洋工，甚至最好不要喝水不要吃饭不要上厕所（完蛋了一个不小心把zi本家嘴脸展露无遗了）。其实这个也是“想做”层面的事情，需要你把团队的愿景使命价值观给打造出来，当然它是一个长期的过程，不能一蹴而就，无论如何你也不要小看它，它是你的团队是否具备很强的凝聚力和执行力的关键所在，原因也很简单，你想人家跟着你拼跟着你干，你至少要告诉人家这件事情意义是什么，目标是什么，收获是什么，以及你准备怎么干吧？你的计划肯定不能是两眼一抹黑就是干，对吧？

愿景使命价值观每一家公司每一个团队也都不太同，没有标准答案，适合你的就是最好的。此处附上老杨的示例供参考，不做过多解释。

愿景使命价值观

细心的同学会问：“诶老杨，怎么感觉这两部分全是意识形态方面的东西，有点虚啊”。

哎哟我去，哪里虚了？意识形态层面的事情是决定你的行为的好么？细心同学麻烦你消停点，别再打扰我思路了。接下来继续讲提升研发人效了。

三，提升研发人效：

研发人效

研发人效是有效人天除以实际人天，其中只有设计和开发阶段的有效人天系数是1，需求和测试阶段的有效人天系数是0.5，线上bug阶段的有效人天系数是0，显而易见，要想提升研发人效只有三条路： 1. 减少需求阶段的投入；2. 减少测试和线上bug阶段的投入；3. 增加设计和开发阶段的投入。

下面分别讲解这三条路具体该怎么去实施。

1.减少需求阶段投入：迭代并行，把上一个迭代的需求阶段和下一个迭代的测试阶段合并成一个阶段，这样就达到了减少需求和测试阶段投入的目的，进而提升了有效人天。这个办法是最简单可行的，效果也不错。

2.减少测试和线上bug阶段的投入：1）最直接的办法就是引入单元测试、自动化测试、持续集成等自动化手段，尽量前置发现bug修复bug；2）提升编码的质量；3）架构优化，隔离影响等。这种方法也是可以去执行的。

3.增加设计和开发阶段的投入：敏捷管理，尽量把所有的时间都投入到开发阶段，效率能趋近于最高。这种方法需要开发人员能力很强，需要技术平台、技术组件、技术文档积累的很好，一般情况下需要较大的公司去执行。

好了，两个篇幅终于把提升人效的事讲清楚了，整个团队人效的事也告一段落了，信息量有点大，你和我都需要冷静冷静了。下一篇将进入技术指标的讲解，稳定性、性能和资产个数，欢迎持续关注。

谢啦，下次见啦。

如何做一个小型公司的技术总监

本文在腾讯内部论坛被浏览达7347次，收藏615次，评论几百条，曾经是讨论最热烈的项目管理文章之一。作为作者本身，感觉这个话题可以讨论的范围非常大，希望能有更多朋友一起切磋探索技术团队的管理之道。

资深程序员是团队中最强大的生产力，但往往被不合理的工作安排浪费掉。因此作为一个团队的技术的“头”，必须要有明确清晰的认识，把主要的事务性工作剥离出来。并且放弃大量的管理“权力”，以提高团队开发质量和效率为最主要的目标去安排自己的工作。一般来说技术总监其实会被要求做事实上是2个职位的工作：主程、项目经理（技术化）

因此必须明确此两个职位的工作任务分割。然后把项目经理的工作，安排给另外一个人做，当然其职称可能同样也得叫“技术总监”或“主程”，总之听起来越牛X越好。

而真正的主程（技术总监）则应该投身于尽量多的技术工作中。而最重要的工作则是开发——生产代码和文档。

主程的工作：

一、开发

从来没有一个资深的外科医生会放下手术刀，而转到手术室外面指手画脚。一个资深的程序员也不应该离开代码和文档的编写，而只是做做架构图。作为对一个复杂系统的负责人，必须亲手领导和参与建造，才能有足够的能力去负担起这个责任。因此需要至少使用60%的时间来参与开发的工作，并且建议从一开始上班就开始，虽然早上的效率很低，但是跟任何艰巨工作都一样：万事开头难。在你好不容易等待电脑慢吞吞的打开了所有的IDE、需求文档、参考资料、工作计划这堆要命的东西之后，你就迈出了最重要的一步，你会发现你不在需要在网上看微博和聊QQ来提振开始工作的激情，而会被某一个优化代码的灵感而激励，或者被一个复杂而有趣的问题所吸引，从而更快的能投入到开发中。坚持打开电脑做的第一件事是打开IDE软件，是这一切最重要的一步。

开发的工作内容包括有：

1. 提出非功能性需求

一般来说功能需求总是让开发人员焦头烂额的主要原因。但是实际上很多项目死在发布之后，却是因为性能、产品质量、扩展性、二次开发效率等非功能性需求没认真去解决而导致的。主程作为经验最丰富的成员，必须要利用自己曾经的经验和教训（在这里教训往往比经验重要），提出那些自己折腾自己的“非功能性需求”，来保障整个项目在发布后不会轰然倒塌。这是个吃力不讨好的工作，因为老板和客户往往只会抱怨技术人员在玩弄把戏，骗取更多的资源或者杞人忧天。如何说服这些家伙也许不是主程的工作，但是主程必须要以高度的责任心把问题放到台面上来。沟通的工作也许让项目经理去做会更好，他们有一整套如何威逼利诱老板和客户的戏法。

2. 设计和修正软件架构

软件架构设计至关重要，而且工作繁重。不画图纸就敢开工的技术人员要么是天才要么是笨蛋。对于团队来说，架构在分工合作、避免风险、提高质量等多个方面有无可替代的作用。架构要避免成为空洞的文档，最重要的一步是有人来掌控和实施。而主程主持设计和修正的架构，并且亲手实施，让团队中的腹诽之徒完全无法避开，否则代码将无法运行！所谓设计和修正架构，并不意味所有的文档应该一个人写，而是指这个架构的每个环节，都是经过主程决策同意的。当然最好这些文档能尽量由他撰写，对于“菜鸟”团队来说，输出这种文档本身就意味着“权势”，有助于主程建立个人威信——这种看起来有点肮脏的“政治”东西，在避免团队内无止境的扯皮，以及稳定那些随时准备跳槽的成员来说，都是相当实用的。

3. 难点代码（关键需求）的开发

主程必须写代码，写那些大家都认为风险大的代码。有的系统对于性能要求很高，他就必须去完成容易出性能问题的部分，比如IO操作或者设计数据库索引。有些系统的需求非常飘忽，他就要去想办法完成框架代码或者脚本引擎，以便众多小弟可以跟着产品人员疲于奔命。这种工作内容会让主程不必完全的读过所有代码，而能牢牢的“掌握”代码，以免团队成员甩耙子的时候能充当备胎。因为融入团队的代码开发，也是一个让架构设计从日常工作中真正控制系统的工作。而且主程代码通常会被别人接触，能直接教育其他团队成员，同时也能建立——威信。

4. 救火和杀虫

这个工作其实和代码开发是一致的，如果没有平日的开发，通常紧急问题的解决也是比较难处理的。但是这个也有一个调试技巧的要求，比如要求会使用各种诊断工具。这些工具一般的开发人员可能会比较少使用。找问题的过程本身也可以提高团队其他人的技术水平。

二、培训

培训的工作应该占用30%左右的工作时间。培训是稳定团队人员最重要的手段。也是提高团队开发效率最有效的手段。工具、过程、制度、奖惩，这些都代替不了程序员一行行的去写代码，最直接的方法是让他们做的更快更好，这些需要经验和知识的积累。

1. 代码审查

关于代码审查，有太多的论述。但是代码审查还是一种“强迫”推行某种风格或者技巧的手段，这是最真实的“控制”系统的手段。也是推广知识和经验最直接的手段。一个人写的代码通常应对的问题不会特别“广泛”，因此只要审查其中一部分代码，就能给大部分别的代码带来好处。

2. 技术方案评审

什么事情应该写一个技术方案，然后进行评审，这是一个关键的问题。一般认为开发时间在2周以上的单项工作应该先做个方案。往往技术方案是系统架构的完善和补充，或者是挑战。所以主程的参与是非常必要的。但是要注意不需要去做的太琐碎，而是要提炼出“关键”的需求和“关键”的解决方案进行评审，而这些“关键”往往不是功能，而是质量上的需求，如这个系统的扩展性，是否能方便后续开发等等。也有可能在这些会议上会发生争吵，但是决策人是主程的地位是不容动摇的。君子和而不同，每个程序员都可以拥有自己的看法，但是代码必须能按方案运行起来，主程必须经常申明这点。

3. 学习与讲座

如果团队碰到问题，没有新的方法和技术去解决，是不会提高开发效率的。就好像你用牛来耕地，不管用什么管理方法，都不会赶上机械化的速度。而主程承担着不断突破自己的技术上限，介绍和推动团队使用更新的技术来解决问题的责任。抱残守缺，思想僵化，最后会被团队成员所抛弃，而且也会让团队的效能落后于业界，最后直接影响产品的生死。每年学一门新语言，这个说法可能有点激进，但是这也是作为程序员应该有的激情。

三、管理

管理等于权势？管理等于沟通？管理等于文山会海？多年专业训练出来的技术人员如何去做管理？

管理的目标是提高绩效，如果和这个目标无关，而只是和“管理者”这个头衔有关的事情，最好丢给别人去做，包括那个头衔。管理主要手段是创新：想出新的方法去解决问题，而不是繁杂的事务性工作！——一个专业秘书能比主程做的好一百倍。技术工作的创新，最主要还是在技术工作里面，而不是跳出来说：做这个，做那个。

管理的事情如果超过10%的工作时间，等于说你更像一个项目经理而非主程。

1. 绩效评定

以专业的意见来衡量别人的工作，这个负担是无人能够承担的。这个工作往往是利益分配的一种手段。类似奖惩手段。这种管理方法已经不是新事物了。但是实际上技术人员对于绩效往往持一定保留和暧昧的态度，因为这种事情难以很清晰的界定出来。需要判断而非量度，才是绩效的真正手段。如果一定要打分，一共两项足够了：进度、质量，5分制即可。更重要的事情是，告诉每个人主程的看法，告诉别人，怎样做才是更好。或者告诉团队，怎样做才更有利于我们成功（发财、上市、赢得老板和客户……）——把目标清晰告诉团队，发挥他们的主动性，是绩效评定最重要的目标。

2. 需求评定

最让技术人员头疼的可能就是和客户谈判。这个事情实际上不应该让技术人员来伤心，有项目经理就可以了。而需求评定更多的是可行性的讨论。主程如果参加每个需求评定，他要三头六臂也搞不定，正确的做法应该是具体开发的团队人员参加，而主程在开会前给与自己的意见，或者会后听取参与者的总结。——这是了解别人做什么事的一个重要手段，但无需陷入太深，因为还有代码评审和项目经理的帮忙。

3. 跨部门沟通

实在没必要参加，能躲就躲，这是扯皮的天堂。让项目经理去吧，他们的专业技巧能让这些事情更加有效。只要回来后让项目经理告诉你发生了什么事情就可以了。

4. 进度审核和任务分派

又是一个很有“权势”的工作，实际上团队成员的情况大家都知道，决定谁应该做什么事情并非需要很多时间去想的事情。所以大可以把方向性的意见告诉项目经理，让他去做。很多优秀的开发者玩EXCELPROJECT之类的水平还不如只有一年工作经验的秘书，别折腾自己了。

5. 面试

如果真想帮忙，准备一份有区分度的笔试题目吧。不靠谱的人太多，老板可不是花钱请你和他们聊天的。让项目经理去聊，不用担心他们技术不强，再不够，也会比大多数面试者要牛X。他们搞不定的人，就是应该雇佣的家伙。毕业生招聘怎么办？只要看看他们课外活动是不是有搞些专业的事情就可以了，上进心比别的东西都重要，HR会比主程看的更准，相信我。

6. 各种会议

饭无好饭，会无好会，超过6个人的会议应该坚决抵制。如果你有一个程序等着你去写，你一定无比痛恨这些会议，顺应你的内心吧！上帝保佑你。

最后说说项目经理的工作：

项目经理就像下水道的清洁工，所有那些主程不愿意去做的事情，他们都弯下腰去认真的把玩，实在是太伟大了。既然如此，为何不让他们拥有更好一点的头衔呢？如果没有他们去处理这些工作，任何一个主程都会被逼疯掉，或者他们自己变成了项目经理，让团队损失了最强力的一台代码发动机。

一、进度

1. 指定工作计划

2. 进度检查和告警

3. 工作总结和统计

二、资源

1. 整合提供各种资源，如找DBA，IT，运维人员，硬件，SVN权限，测试环境，福利，周末的活动……

2. 面试：人员是最重要的资源，不是吗？

3. 资源谈判：往往是和老板谈判，让别人明白现在的真实情况。又一个吃力不讨好的差事，但是总需要人做。