关于技术领导力,今天我想给大家分享这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人发现问题之后就会寻求解决方案,他们会确认某种需求,找到某种契机,然后系统地、合理地、积极地通过创新解决问题。
最后送上这张图,让我们自豪地用技术去解决所有问题,不要让贼看不起。