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

8月30日，我在EGO主办的“GTLC技术领导力峰会”上，做了一个主题演讲。本文系根据这次演讲而来。顺便赞一下，EGO活动组织得很专业。

大会的主题是“技术领导力”，今天到场有很多CTO，我想起自己20年前第一次听到CTO这个称呼，充满崇拜之情，那时我眼中的CTO是这样的：

多年之后，我自己的名字终于和CTO发生联系，那时我眼中的自己是这样：

后来我经历渐长，又和很多CTO交流后，发现在其他高管眼中，我们好像是这样的：

或者是这样的：

 

但是我不做CTO好多年了，所以我去找了一些还在做CTO、技术总监的朋友，问他们三个问题：

1.你技术领导历程中三个最头疼的问题；

2.你的解决方法；

3.你工作历程中三个最重要的收获。

他们都非常热情地给予我帮助。

其中有一位初创公司的CTO，写了很长的回复，非常生动、丰富，我就把原文贴在这里了。

CTO的痛苦

1.霸道总裁批评质疑

自以为做得不错了，但经常达不到强势CEO或其它直属联合创始人的预期，挨批、被质疑，自信心狂受打击。  

痛苦指数：*****

2.时间紧张，丑陋实现

本能地想把系统设计得更灵活、更通用、易扩展、易维护，但需求需要快速上线，时间、人力实在不允许，导致很多丑陋的实现，怎么看怎么不爽，经常有冲动想重构一把。

痛苦指数：*****

3.工作强度太大

高压状态下干活，强度也大，感觉大脑都快转不动了，但还要确保自己以及团队高效产出、并且少出错。  

痛苦指数：*****

4.需求变化太快

需求变化太快，技术文档、使用文档等完全跟不上，系统存在于大家的大脑里，经常信息同步不及时，导致沟通效率低下，经常需要翻看代码才知道是怎么回事。

痛苦指数：*****

5.各部门都有众多紧急需求，又都觉得很容易

财务、人力、市场、运营等各兄弟团队都有需求提过来，都说很紧急，都觉得需求不大，开发稍微花点时间就能搞定。   

痛苦指数：****

6.讨论策略、需求，被缺席

经常几个联合创始人讨论下就把策略、需求敲定了，开发被动地照单实现，对背景上下文缺乏了解，实现之后的运营效果咋样，也经常不知道，完全没有参与感。

痛苦指数：*****

7.需求直接发到手下人

有些需求为了求快，越过你直接打到开发，有时做完上线都不一定知道，老板突然问起相关问题，答不上来，还被质疑自己的系统怎么这么不了解。

痛苦指数：****

8.各种非常规操作，手动修复

各种奇葩的数据修复需求、以及非常规操作流程，需要手动去执行，有时手动修复失误，又要花精力修复刚才的手动失误   

痛苦指数：*****

9.招不到人，现有的又闹辞职

老是找不到靠谱的开发、测试，或者干得好好的人突然提出离职，手忙脚乱。

痛苦指数：*****

10.手下人捅篓子，给他擦屁股

稍不留神，底下的小兄弟又捅了篓子，需要亲自帮忙找bug、擦屁股，到处救火。

痛苦指数：*****

11.身兼多职

身兼多职（架构师+核心开发+运维+DBA+管理配置+测试结果验收等），经常要在多种场景下快速切换（比如正上着线，有紧急问题要查或者修复），当出现纰漏时被质疑怎么这么简单的问题也能搞出错。

痛苦指数：****

12.家人抱怨

媳妇、女朋友、娃各种抱怨，比如怎么越来越不关心我们，抱着你的电脑睡得了。

痛苦指数：****

这一切我感同身受，非常希望自己能有一套系统的办法帮助他完美解决所有问题，但是坦率地说，我没有。

观点1： 没有银弹

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

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

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

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

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

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

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

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

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

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

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

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

我们的技术团队一直都很拼，但是现在用户量一上去，系统就撑不住了啊！

每天都有大批用户骂娘、流失掉，我们现在团队搞不定啊！

而且我们用户成长非常快，未来两年估计要涨几十倍，必须要业界最强的系统才可以啊！

我问了懂行的朋友，都让我来找你啊！

但因为我们目前销售收入还没起来，没法给你特别高的现金，本来不敢来找你啊！

但是最近这一周实在崩溃了，所以斗胆来请你，为了我们热情的用户，不要让他们失望啊！啊啊啊！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

所以，应该鼓励需求的更改。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

观点8：去它的 KPI

这就是KPI

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

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

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

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

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

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

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

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

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

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

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

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

我们给了一些建议：

开发一个功能，自动生成帐号和密码，当然密码强度要高；

密码分为两封邮件发送；

用户初次登录强制要求修改密码，强制要求强度；

如果一个新帐号，24小时没有登录，注销掉，给用户的邮件中告知用户这一点；

如果一个帐号间隔一个月内没有使用，提醒管理员，是否清除。

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

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

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

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

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

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

送上这张图，让我们自豪地用技术去解决所有问题，不然会被贼都看不起。