楚王好细腰，宫中多饿死 ——职业化和专业化才是王道，管理与技术不可偏废

楚王好细腰，宫中多饿死 ——职业化和专业化才是王道，管理与技术不可偏废

一度公司走上了“千军万马”走“管理者”独木桥的路，近几年随着公司认识到问题后导向的牵引，多年提出的技术和管理双通道似乎开始奏效了，但最近一年来看到的一些现象不仅又让人担忧，是否“矫枉过正”的太过了。

现象一：****某项目组刚成立，组件项目组要选拔PL，项目组里有很多16，17级甚至18级的开发人员，结果候选人只有14级，才毕业一年。一开始笔者还挺高兴，初步面试后发现也的确是个人才，有冲劲。认为公司似乎真的又“恢复了”不拘一格降人才的年代，不看资历看能力。但当我和周边部门交流的时候发现，据说最近的确在研发没有人愿意做“管理者”，即使是PL，PM这样的“小官”，理由是怕影响发展。真的是“楚王好细腰，宫中多饿死”。

现象二：**最近无论是心声还是博客上，技术大牛和蓝军对软件的改进发出很多“震耳欲聋”的声音，这是非常好的现象，这其中不乏一些好的建议，但关键是这些“吐槽”和“建议”如何落实？如何被吸收？如何纳入组织级的改进？

软件问题现在是热点问题，也绝对不是靠一两个顶级程序员能解决问题的。用一句调侃的话来说：“我们缺的是一两个大牛程序员吗？我们缺的是成百上千个大牛、中牛和小牛，我们更缺的是成千上万的“牛犊子”怎么长起来？如何成为大牛？”

为什么被技术专家诟病最大的问题就是管理者的干预？我认为这也是被公司长期以来重技术，轻管理导致的。可能这句话会被很多人不认同，因为事实上本文一开头也承认公司一度是走上千军万马过“管理者”独木桥的路，这也的确是事实。

过去之所以大家认为公司导向管理，这个误解是被两个事实“填充”的，一个是“总”文化，中国人的学而优则仕，“官本文”文化，导致芝麻大小的官，官不大，“僚”很大。据说以前研发一些PDT经理出去拜访客户，客户不是总经理那是不见得，从公司一些研发人员的名片上也可“窥见一斑”，总监，总经理，总裁各种自加的头衔，导致伙伴、客户都很“困扰”；第二个事实是“待遇”，管理者职级提升的快，待遇提升高，这个最近几年似乎反过来了。

但为什么又说公司是轻管理和重技术的呢？一个现象即可证明。为什么管理者或身居高位者这么热衷于“搞技术”？对“技术问题”指指点点? 这是因为公司在文化和精神层面评价一些管理者的重要标准是这个人懂不懂“业务”，而这个“业务”在研发被直接等同于“技术”了。这也间接体现和导致了为什么“汇报”这么多，“胶片”这么多。管理上的“红屁股效应”，指的是一群猴子在爬树，越是爬的快的，爬的高的猴子，它的屁股（红屁股）就会被下面越多的猴子看见。因此也越容易成为其他猴子嘲笑的对象。本质上，不是说其他猴子就没有红屁股，而是因为其他的猴子爬的低，所以它们的红屁股不容易被其他人看见而已。

公司提倡看的《激情的岁月》中打动人的不仅仅有为两弹一星钻研的科学家，更让我感动的是当年一批将军在聂帅的主持下如何为这些科学家做好后勤，做好支撑，做好必要的“管理”的，这些管理是很专业的，在当年那个条件下解决和克服了物资匮乏，粮食短缺，科学家闹情绪等等各种问题。

宰相起于郡县，猛将发于卒伍。这句话很好，但提拔猛将或成长为猛将必定不是仅仅是因为是个“神枪手”或“单兵作战”能力强，肯定是要表现出能带领一个排，一个连，一个团打更多“胜仗”才可以，这也正是我们提倡的“结果导向”。兵熊熊一个，将熊熊一窝就是这个道理。

微软的总裁萨提亚·纳德拉在《刷新》中并未提及自己直接或间接带领了那个研发团队，或指导了哪个技术发明。核心是他把微软数以万计的人的工作方式、文化改变了，从“内斗”和“指责”，人人都希望“变成最聪明”的人变为一个“成长型”公司，拥抱变化，抓住了软件、云化新趋势。

公司正在为过去十几年在软件技术专家的成长上的忽视和疏于管理付出代价来提升我们的软件工程能力，但如果在这个过程中，我们又因此偏废忽视中基层管理者的专业化，导致各种导向、发文不是被“简化”而是被“简单化、粗暴”的执行，那么未来我们需要付出更多代价为之买单。

说到底，我们目前面临的问题不仅仅是技术专家稀缺，或软件架构问题，准确的描述是“软件架构普遍有问题”，“技术专家普遍稀缺”和“普遍成长慢”的问题，而这个问题需要更多“管理者”来解决，来排兵布阵，来“薪火相传”的培养。管理者目前不能安心为专家做好后勤，识别和激发专家，赋能专家；反而因为可能曾经是个技术牛人去代替技术专家或直接指挥技术专家，进而导致技术专家无所适从，或感受很差，影响专家成长和发挥的工程师文化没有形成；进而出现工程师自信、能力不足，或在这两者之间恶性循环，俗称“干废”了。

当前“管理者干废者”有之，“专家干废者”也有之，核心原因就是大家都不“专业”，所以公司提倡的“专业化”应该是正道，如何能真正让各个岗位，乐得其所，醉心于提升自己的“职业技能”，相互促进和配合，最终把业务做成才是王道。

子在川上曰：“逝者如斯夫”，老板呼吁“人才辈出”，公司成就ICT领导者数千亿或万亿大业，肯定需要的是成千上万的科学家，软件专家成长，也需要成千上万能带领团队打“胜仗”的各级专业管理者、综合管理者；也需要更多财务专家，法务专家，人力资源专家。而这些都不能凭借一时导向，需要更多“专业化”人才在专业岗位上自尊、自爱，修炼、精进，而这一切都需要“专业管理者”来成就他们。
所以：职业化和专业化才是王道，管理与技术不可偏废。

附上对于新晋技术管理初阶人员的一个建议：（可能只适用14级左右的PL，大牛绕过）

1. 确立团队的目标。
不论项目大小，一定要有目标，有目标才能让所有人明确方向，知道每天工作的意义在哪儿，工作是不是朝着团队的目标在一步步靠近。 纯技术人员的执行者思维应该切换为宏观思维，因为现在个人的成功已经不叫成功，团队成功才是成功，如何让团队产出高的绩效才是你应该思考的问题。

2. 离达成这个目标我们还缺哪些资源。
这点主要涉及到统筹规划能力。在项目初期，你就需要非常清楚明确地知道目前团队的能力以及你能调配的资源，这样才能保证后期不会因为资源不足导致目标无法达成。

3. 我们如何朝着目标迈进。
这一点穿插在整个过程中，是最重要，它囊括了技术管理的方方面面。

如果某件事一个人做需要m个工时来完成，那么n（n>1）个人来做，理论所需工时是m/n，但是实际的时间一定比这个多，结果是（m/n）*α（α>1），α就是协作成本。技术管理者要做的，就是尽量降低协作成本，包括以下方面：

任务分配
之前你一个人能把事情做得很好，现在怎么保证团队一群人把它做好？任务分配包括如何把任务合理地分配给适合的人，能达到最好的结果，即人的价值得以体现，产出质量也高。这就要求管理者对任务的了解要全面深入，对团队每个人的能力了解也要准确。

全局观
技术人员工作时都需要专注，反过来，作为技术管理人员，要防止过度专注。多去了解项目各方面的进展和存在的问题， 对项目和团队的任何细节了如指掌，出现任何大大小小的问题都能迅速定位和分析解决，不会因为专注于技术细节而失去对全局控制。

沟通能力
以前每天和机器沟通，现在切换为和人沟通。以前的桀骜不驯和不屑是因为技术能力强，现在应该切换为更耐心，更注意语气和用词的沟通。另外，更多的去主动发现问题，然后通过沟通技巧来解决问题。

协调调度能力
项目过程中一定会遇到一些无法预期的技术问题导致项目被block，如果问题已经持续未被解决，这时需要及时调度有能力的人来参与解决，防止项目一直处于不确定状态。当多个功能或者项目并行进行时，由于人力资源有限，可能需要不断地根据项目进展来动态调整各项目优先级来保证整体的进度。优先级调度和调整是一个很复杂的过程，但记住一点，我们永远只做优先级最高的事情，最高优先级事情完成以后，优先级第二的事情自然会升级为优先级最高的事情，在这个升级的过程中，我们也许还需要和产品等相关部门进行一次优先级动态调整或者评估。这也涉及到项目管理的负反馈，让每一个阶段的结果反馈给新的阶段，保证最后的结果更接近我们的目标。

时间管理能力
时间管理是每个团队都头疼的事情，直接体现在项目进度上。时间管理看起来很难，实际很简单。每个任务拆分一定要足够细可量化，2天以上的任务都是不合理的。而且过程中需要严格控制好每一个量化好的时间节点或里程碑，保证每个节点的质量和时间点无误是保证最终结果的最好方式，出现任何一处delay都需要强制想办法及时补救，避免积少成多，这样才能防止项目最后出现不可能预期的延期。

放权和培养
亲自去解决具体的技术问题，做代码审核看代码哪些地方存在不规范，和测试人员讨论具体的测试用例是否合理，这些工作现在需要做，但是，它们已经不再是你关注的重点，你应该更多的放权让其他人去做，在这个过程中一定不需事事亲为，在这基础上，你应该更加注重对成员的培养，培养他们的学习能力，思考能力和解决问题的能力（这三个能力是我对技术人员的基本要求），让成员快速进步和成长，独当一面。

倾听
不管以前技术多牛，多恃才放旷和桀骜不驯，作为管理者，需要背负团队的使命和绩效，所以应该在任何时候主动听取团队核心成员的意见，做一个好的倾听者。倾听一定要做到多维度听取，然后再分析和做决定。

能做到并实践好上面这些点，恭喜你已经蜕变成为了一个优秀的技术管理人员。