程炳皓：关于技术领导力，十个耸人听闻的观点

Posted 2020-08-13

关于技术领导力，今天我想给大家分享这10个观点。

观点1：没有银弹

在软件开发的管理过程中，只有适度改进，而没有包治百病的银弹。可能有人会问，你讲这样一个观点有什么用呢？用处就是，不要再试图去寻找一个包治百病的银弹，我们在工作中适度改进、用外科手术的方式去解决问题就是最好的了。

我以前服务的公司就曾花费很大的力量来重塑整个软件开发的流程，按照软件工程的流程来管理，使用一套项目管理的系统，但最后慢慢还是要向事实去低头。

当然针对这位朋友的痛苦我还是有建议的。接下来讲一个真正耸人听闻的观点，也是我觉得最重要的观点。

观点2：打造优秀技术团队首先是CEO的职责

因为高水平的技术团队是一个互联网公司的核心竞争力。

很多CEO讲“我不懂技术”，但我要说，如果你把技术看成是一个麻烦，它一定会是一个麻烦。

我也见过很多强势的CEO，试图用管销售和运营的方式管技术，可能会有技术人员暂时接受这样的扭曲，但这就好比你把一个绝色美女娶回家，却只让她给你做饭。

有人说，马云也说过他不懂技术，那就来看看马云怎么说的，他说“正因为我不懂技术，所以我们公司技术才最好”，“不懂技术没有关系，要尊重技术、热爱技术”，在“码农”这个词泛滥的今天，看到“尊重技术”，做为一个程序员我很感动。

除了尊重，工程师还最看重什么呢？我有位朋友的公号（dowell之自言自语）写了一个非常有意思的例子：

有一个在线教育的CEO问我，我想找个技术大牛，发现特别难，每次聊到最后，人家还是不愿意来。我问他：你怎么聊的。他回答：我们的系统不是太复杂，你在某某公司的技术背景，我相信一定能胜任这个角色。我说：那人家一定不会来了，原因是：技术从业人员最关注的是他在一个新环境下技术水平的提高，没有技术挑战的活对他没有吸引力。

我来进一步分析一下，这位CEO应该很不了解工程师，如果我猜得没错，CEO可能是市场销售背景，这种谈法像是跟一个销售说，我们这里客户都特别好搞定，预算又都特别高，总之人傻钱多，你速来。销售听了肯定高兴。而技术人员听了他的话，第一念想的是，你的系统这么容易，你还找我，你是觉得我水平也很一般吗？会觉得受到侮辱，根本就不想谈下去了。

举一个栗子，我建议可以这样谈：

我们的技术团队一直都很拼，但是现在用户量一上去，系统就撑不住了啊！每天都有大批用户骂娘、流失掉，我们现在团队搞不定啊！而且我们用户成长非常快，未来两年估计要涨几十倍，必须要业界最强的系统才可以啊！我问了懂行的朋友，都让我来找你啊！但因为我们目前销售收入还没起来，没法给你特别高的现金，本来不敢来找你啊！但是最近这一周实在崩溃了，所以斗胆来请你，为了我们热情的用户，不要让他们失望啊！啊啊啊！

观点3：工程师最看重：尊重、成长、挑战

当然永远有例外，我再讲一个自己的栗子。

我刚做技术主管的时候，因为自己的管理天赋特别差，经历了一个特别惨烈的蜕变过程。

这期间我团队里加入了一个新工程师，他是我原来一家公司的老同事。在我刚进入那家公司的时候，是他带我工作的，他对那家公司技术环境、系统都非常熟悉，我对他的印象非常好。当他加入我的团队的时候，我觉得他一定能帮我很大的忙，所以按照我理解的“技术人员最看重挑战、成长”，把最新、最难的工作全都给他了，但是他的表现远没有达到我的预期。我们两个都很苦恼。

刚好公司及时提供了一个关于人的个性的培训，培训老师讲，人大概可以分成“活泼型、力量型、完美型、和平型”，工程师大部分都是完美型。但我突然意识到，那位新同事是和平型。

和平型不喜欢新东西，但是能把熟悉的东西越做越好。

我非常高兴，第二天一早到公司，就重新给他分配任务，让他只做现有系统的维护、运行和修补。

对当时的互联网公司来讲，系统的运维、修补工作任务是非常重的，也往往令人头疼，因为典型的工程师都喜欢新的事情、学新的技术、做新的项目。

但从此之后，他把维护工作做得非常好，他自己也非常开心。

这件事情是我领导力成长的里程碑，我获得了比写程序更强烈的巨大快乐，那是从“人”那里得到的快乐。

我意识到：

观点4：人性中蕴藏最大的力量

作为领导者，体察人性、随需而动、发挥人性中的光辉，必然获得生命的大和谐。否则，如没有渠道发挥正能量，必然变成负能量。

之前那位CTO列出的痛苦中，多数都是和需求有关的。在很多互联网公司，特别是应用型公司，核心矛盾就是需求和需求的变化。

我们该怎样看待需求的变化？

软件行业一直以建筑行业做参考和比喻，比如架构(Architecture)、项目(Project)……这些词都是从建筑行业那儿来的。

我们做程序员，当然希望能在开发前就把需求最大可能确定。所以我们跟需求方、业务方说，其实我们开发软件就跟盖楼是一样的，谁见过一座楼本来要盖5层，最后盖了20层呢，所以作为业务方，你们要在开发前确定全部需求。

但其实，软件毕竟不是建筑。

几十年来，需求一直在改，而且现在改得越来越厉害。所以实际上是可以改的。

而且，没有人能从一开始就想清楚所有事情，并且不再改变。我们自己可以吗？不可以，那么就不能要求别人。

传统软件工程是以实现为中心的，它面对的问题是从无到有，所以关注实现。

但是现在我们从中国制造转化为中国创造，整个创业、创新的过程就是在创造需求、探索需求。很多初创公司一直在探索，最后也没有创造出有效的需求来，如果初创公司历经劫难，探索出一个真正有效的需求，那已经是非常的了不起。怎么可能去要求业务方在一开始就能把需求确定呢？

所以，初创公司其实是一个探索需求的过程，我们作为CTO，应该鼓励需求的更改。

观点5：传统软件工程过时，创业核心是探索需求

但更改需求会产生很大的问题，会导致产品和技术的责任边界不清楚。那怎么办呢？那就打破边界。

IT行业最早盛行的组织模式是业务公司 vs 技术公司，这是边界最清楚的模式，也是最低效的模式。

最高效的模式是把产品和技术组成一个团队，共同为一个产品目标负责。

工程师也要参与设计，而不只是一个编码的工具。

大家是一个团队，共同为一个产品目标去奋斗，而不是以我的专业画地为牢。我们不光要懂自己的专业，也要略懂别人的专业，要争取做一个通才。不懂技术的产品经理不是好运营。

观点6：欢迎、支持需求和需求的变化是CTO的职责

观点7：管理、控制需求和需求的变化是CEO的职责

这两句话是一枚硬币的两面。

但现实中，大部分情况正好反过来，大家花费无尽的时间和精力讨价还价，沟通成本、交易成本变得非常非常高。

当然要做到这一点非常不容易，需要人世间最宝贵的东西，就是信任和真诚。

信任也是人生一个非常重要的能力。

作为CEO或CTO，寻找能够信任的创业伙伴，建立信任，坚守信任，都是非常重要的能力。

恋爱容易，婚姻不易，且行且珍惜。

如何赢得信任呢？我认为是三个词：真诚、能力、开放。

下面再摘录我的采访成果。

一切问题的健康解决都要基于人与人理解和信任，然后适用此基础上的制度。如果强权或者不充分的沟通，都只是表面的解决。为下次解决增加障碍。

第一，技术领导要在公司内部建立威信和信任，对方部门负责人把事情交给你是放心的，建立靠谱形象，同时可以建立私交。比如我当初带研发部门，研发经常被销售部门骚扰就主要用规则解决，经常需要去麻烦运维部门，就双方建立信任和私交。与产品人员的协调问题，在我的职业生涯中算是处理得比较好的。第一还是在产品人员中建立信任，对于合理的需求绝不迟疑，回复只有三个字，没问题。

第二，对于可以优化的需求，提出自己的想法，对有理有据和产品协商，直至说服。

第三，在需求之外的额外功能，无论是关乎体验还是功能，均要和产品商量，得以实施。

第四，为研发争取额外时间，一般程序员预估时间要么故意拖延，要么乐观，均需要合理分析，对内对外让他们认可，达成理解和一致。

观点8：去它的KPI

这就是KPI：

可能管理专家会鄙视我，但是我不是一个人在战斗：

绩效考核毁了索尼—by索尼常务理事 土井利忠

我们一定要放弃KPI—by 雷军

很多时候我看到KPI就是一群人假装写，一个人假装看。当然我不否认KPI可能是管理销售和某些职能部门的好工具。

观点9：创新是一件平常小事

创新力和技术领导力高度相关。

大部分人可能都认为创新就像叶孤城的那一招天外飞仙，需要一个非常伟大的头脑，不知怎么回事蹦出一个惊天动地的想法。但我看到大量创新就是长时间做一件事，慢慢磨，有一天偶有所得，比前人改进一点点。不要只看到最后一个烧饼，前面的慢慢磨更重要。

举一个栗子，我采访的朋友讲给我的，他们在开发游戏的过程中，发现他们用的一个开发工具，每次启动都要花费很长的时间。

程序员在开发过程中，经常需要调试，每一次修改代码后重新运行，启动都要很长的时间，程序员就要在那儿等。然后他们针对这个小事儿做了改进，花费很多的心力找到办法，让这个启动加速，结果他的开发效率得到非常大的提升。

我们有非常多这种平常小事儿是可以创新，值得创新的。

观点10：少管理，尝试用技术去解决所有问题

举一个非常简单的例子。好多年前有一家公司给我开了一个服务器帐号，发到我的邮箱。我发现帐号和密码都是我名字的全拼，我说你们这样做不安全。对方技术主管马上说，他去告诉那个工程师，以后密码要提高强度。我想，为什么要求人记住一件事，而不去用技术解决？

我给了一些建议：

开发一个功能，自动生成帐号和密码，当然密码强度要高；密码分为两封邮件发送；用户初次登录强制要求修改密码，强制要求强度；如果一个新帐号，24小时没有登录，注销掉，给用户的邮件中告知用户这一点；如果一个帐号间隔一个月内没有使用，提醒管理员，是否清除。

这都是很容易想到的做法，只是需要树立“用技术去解决所有问题”的意识，而不是用“管理”。

因为管理经常是反人性的，我们在面向用户设计产品的时候，都是想尽办法顺应人性的，为什么我们要对员工反人性呢？

以下这段话我觉得很有启发，出自《google 将带来什么》：

去生产你从未敢奢望过的更多的电力，去创造并管理丰饶的资源，而不是控制稀缺资源——这仍然是Google的世界观。

就在戈尔谈论我们不能怎么办的同时，Google却在谈论我们能够怎么办的问题，从中我们可以看出政治家与工程师在思维观念上的明显区别。

Google人发现问题之后就会寻求解决方案，他们会确认某种需求，找到某种契机，然后系统地、合理地、积极地通过创新解决问题。

最后送上这张图，让我们自豪地用技术去解决所有问题，不要让贼看不起。