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

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

少管理,尝试用技术手段解决问题。

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

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

1

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

2

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

3

或者是这样的:

4

 

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

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

2.你的解决方法;

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

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

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

CTO的痛苦

1.霸道总裁批评质疑

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

痛苦指数:*****

2.时间紧张,丑陋实现

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

痛苦指数:*****

3.工作强度太大

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

痛苦指数:*****

4.需求变化太快

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

痛苦指数:*****

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

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

痛苦指数:****

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

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

痛苦指数:*****

7.需求直接发到手下人

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

痛苦指数:****

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

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

痛苦指数:*****

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

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

痛苦指数:*****

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

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

痛苦指数:*****

11.身兼多职

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

痛苦指数:****

12.家人抱怨

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

痛苦指数:****

5

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

观点1:没有银弹

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

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

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

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

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

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

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

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

除了尊重,工程师还最看重什么呢?我有位朋友的公号(dowell之自言自语)写了一个非常有意思的例子:

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

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

举一个栗子,我建议这样谈:

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

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

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

我问了懂行的朋友,都让我来找你啊!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

观点8:去它的KPI

这就是KPI

7

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

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

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

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

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

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

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

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

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

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

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

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

我们给了一些建议:

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

密码分为两封邮件发送;

用户初次登录强制要求修改密码,强制要求强度;

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

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

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

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

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

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

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

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

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

8

技术 管理 领导力
赞(...)
文章评论
匿名用户
发布