【腾讯Bugly干货分享】总结一个技术总监的教训和经验

本文来自于腾讯Bugly公众号(weixinBugly),未经作者同意,请勿转载,原文地址:http://mp.weixin.qq.com/s/Ry-G0Nikh6m-h3ZVC2cLyQ

导语

2017年来了,新年开篇,就不跟大家聊技术啦,给大家分享一篇鹅厂技术总监在多年工作中总结出的教训和经验。

这篇文章自从在腾讯内部论坛发表后,精神哥每年都会拿出来重新研读一番,每次都有新的感悟和收获,所以强烈推荐给大家。

正文

资深程序员是团队中最强大的生产力,但往往被不合理的工作安排浪费掉。因此作为一个团队的技术的“头”,必须要有明确清晰的认识,把主要的事务性工作剥离出来,并且放弃大量的管理“权力”,以提高团队开发质量和效率为最主要的目标去安排自己的工作。

一般来说技术总监其实会被要求做事实上是2个职位的工作:主程、项目经理(技术化)

因此必须明确此两个职位的工作任务分割,然后把项目经理的工作,安排给另外一个人做。当然其职称可能同样也得叫“技术总监”或“主程”,总之听起来越牛X越好。而真正的主程(技术总监)则应该投身于尽量多的技术工作中,其中最重要的工作则是开发———生产代码和文档。

主程的工作:

一、开发

从来没有一个资深的外科医生会放下手术刀,而转到手术室外面指手画脚。一个资深的程序员也不应该离开代码和文档的编写,而只是做做架构图。作为对一个复杂系统的负责人,必须亲手领导和参与建造,才能有足够的能力去负担起这个责任。因此需要至少使用60%的时间来参与开发的工作,并且建议从一开始上班就开始,虽然早上的效率很低,但是跟任何艰巨工作都一样:万事开头难。

在你好不容易等待电脑慢吞吞的打开了所有的IDE、需求文档、参考资料、工作计划这堆要命的东西之后,你就迈出了最重要的一步,你会发现你不在需要在网上看微博和聊QQ来提振开始工作的激情,而会被某一个优化代码的灵感而激励,或者被一个复杂而有趣的问题所吸引,从而更快的能投入到开发中。坚持打开电脑做的第一件事是打开IDE软件,是这一切最重要的一步。

【腾讯Bugly干货分享】总结一个技术总监的教训和经验

开发的工作内容包括:

1. 提出非功能性需求

一般来说功能需求总是让开发人员焦头烂额的主要原因。但实际上,很多项目死在发布之后,却是因为性能、产品质量、扩展性、二次开发效率等非功能性需求没认真去解决而导致的。

主程作为经验最丰富的成员,必须要利用自己曾经的经验和教训(在这里教训往往比经验重要),提出那些自己折腾自己的“非功能性需求”,来保障整个项目在发布后不会轰然倒塌。

这是个吃力不讨好的工作,因为老板和客户往往只会抱怨技术人员在玩弄把戏,骗取更多的资源或者杞人忧天。如何说服这些家伙也许不是主程的工作,但是主程必须要以高度的责任心把问题放到台面上来。沟通的工作也许让项目经理去做会更好,他们有一整套如何威逼利诱老板和客户的戏法。

非功能性需求中,其中有三类:

  • 性能需求
  • 运维需求
  • 开发效率
性能需求

最好的性能需求实际上所有没有需求,因为性能优化往往错的。特别是有一定经验的开发人员,更容易产生“执念”。经验不是特别丰富,而又热爱学习的开发者,往往对很多网上的所谓文章、经验没有太多的识别能力,又缺乏动手实际测试的机会,所以道听途说先入为主的观念也是非常多的。这些观念里面最多的就是关于性能的,先不论所谓优化性能的各种说法,就是推荐各种高性能框架、库的文章也很多。这个时候,拨开纷繁的信息迷雾的人,就只能靠主程了。

运维需求

运维需求的目标是尽量自动化,这里除了最基本的批量启动、停止、重载静态数据(配置)外,还应该包括自动读取本地IP地址,以及自动下载配置文件来启动;等待所有用户退出后才停止的“安全退出”;自动检查进程停止后重启等等功能。

但是运维的工具也要避免过度设计。很多人往往一想到搞运维工具,就想搞一个功能非常大而全,具备漂亮的WEB界面的大平台。实际上真正救命的往往是一些自动化的小型工具,只有这些小工具和小功能都齐备了,耐心额漂亮界面的平台系统真正有意义。所以这主要依赖于经验,但也需要有想象力。

开发效率

开发效率的需求一般都在代码结构上,而这是最容易产生争吵的地方。实际上所谓的代码结构,是对业务领域抽象的一种表现形式,所以对业务领域的理解能力和经验是第一位的。如何抽象好业务领域的模型,不能照搬别人的经验,但也不能完全靠自己想象。需要自己对业务领域做深入思考,同时也多学习了解其他项目的模型。

【腾讯Bugly干货分享】总结一个技术总监的教训和经验

一般来说,比较底层的技术模型,作为开发人员,都是非常熟悉的。比如UNIX系统把所有东西都抽象成文件。而大量的开源项目,作为通用的技术产品,对于比较技术层面的抽象,也都非常优秀。但是,作为业务逻辑开发人员,是绝对不应该被这些模型所困住的,因为我们要解决的问题,并不是去写一个操作系统,或者某个开源框架,而是具体的某一个领域的问题。只有真正深入的去了解业务领域,才能很好的抽象业务领域的模型。

也就是说,如果你是开发游戏的,就要深入的理解游戏产品的概念;如果你是开发电商产品的,就要对商业贸易有深入理解,否则是不配作这些产品的开发*的。我们有一些技术人员,并不愿意去深入业务领域做理解,而是希望把所有的业务问题,都抽象成他自己最拿手的某一种技术模型,这样反而是会严重影响开发效率的。

比如说有的人,喜欢把所有的业务逻辑,都看成是一种“输入数据结构”和“输出数据结构”的处理管道,不管写什么程序,都是同样一套类似的代码结构,就是“读输入-解包-处理-写输出”。尽管这样一定可以完成所有的需求,但是其代码结构并不能应对真正的需求变化,开发效率也一定是低的。真正的主程,就是应该在这个时候,挺身而出提出自己的抽象模型,从而带动整个团队,提高开发效率,同时也做好应对需求变化的准备。

2. 设计和修正软件架构

软件架构设计至关重要,而且工作繁重。不画图纸就敢开工的技术人员要么是天才要么是笨蛋。对于团队来说,架构在分工合作、避免风险、提高质量等多个方面有无可替代的作用。

架构要避免成为空洞的文档,最重要的一步是有人来掌控和实施。而主程主持设计和修正的架构,并且亲手实施,让团队中的腹诽之徒完全无法避开,否则代码将无法运行!所谓设计和修正架构,并不意味所有的文档应该一个人写,而是指这个架构的每个环节,都是经过主程决策同意的。当然最好这些文档能尽量由他撰写,对于“菜鸟”团队来说,输出这种文档本身就意味着“权势”,有助于主程建立个人威信——这种看起来有点肮脏的“政治”东西,在避免团队内无止境的扯皮,以及稳定那些随时准备跳槽的成员来说,都是相当实用的。

【腾讯Bugly干货分享】总结一个技术总监的教训和经验

很多软件架构只有运行时架构,没有代码架构,这是非常可惜的。诚然,我们要关注系统的运行效率,运行时架构(进程结构图)是必不可少的。然而,代码架构是更加稳定的设计方案,因为在必定会发生的需求变更下,进程结构往往也会因此变化。代码的结构是对需求的抽象和描述,这种描述是对业务需求的理解,业务需求小的变化非常多,而大的方向却往往不会变化很频繁,因此如果能基于这些大的方向来组织代码,划分模块,那些繁复的小需求,仅仅是对系统局部的修改,而不会影响过多的其他部分;反之,如果我们没有整体的视野去组织代码和模块,仅仅从一开始的细节需求去组织进程代码,一定会因为需求变化而把整个系统改的乱七八糟。

所以,作为主程或技术总监,把控代码结构,往往比把控进程结构更为重要。同样的代码可以组织到不同的进程内来启动,如果进程结构不适应性能需求,还是可以优化的。但反过来就行不通了,一个混乱的代码结构,不管你怎么去用进程结构调整,还是会问题百出。

3. 难点代码(关键需求)的开发

主程必须写代码,写那些大家都认为风险大的代码。

有的系统对于性能要求很高,他就必须去完成容易出性能问题的部分。比如IO操作或者设计数据库索引。有些系统的需求非常飘忽,他就要去想办法完成框架代码或者脚本引擎,以便众多小弟可以跟着产品人员疲于奔命。这种工作内容会让主程不必完全的读过所有代码,而能牢牢的“掌握”代码,以免团队成员甩耙子的时候能充当备胎。因为融入团队的代码开发,也是一个让架构设计从日常工作中真正控制系统的工作。而且主程代码通常会被别人接触,能直接教育其他团队成员,同时也能建立——威信。

在大公司中,由于团队成员普遍素质比较高,所以都这部分的需求会比较少。但是还是有一些部分的代码,应该亲自操刀。如果不能对最核心的实现模块下手,起码也应该对客户使用界面有一定的编码经验。

比如游戏开发中,某个比较复杂的业务逻辑脚本;在发行的产品或库中,编写针对用户演示用的DEMO等等……。究其原因,是因为客户是最重要的,而领导者起码应该直接参与面对客户的部分。店长不迎宾,厂长不进车间,事情是绝对做不好的。

而中小型公司里面,如果编码工作还是放给别人做,到头来还是给自己找麻烦。因为小型公司人力本来就紧张,而质量低下的代码,造成的故障和BUG,会更加消耗不多的时间成本。自己做的越多,项目成功的几率就会越大。

【腾讯Bugly干货分享】总结一个技术总监的教训和经验

4. 救火和杀虫

这个工作其实和代码开发是一致的,如果没有平日的开发,通常紧急问题的解决也是比较难处理的。但是这个也有一个调试技巧的要求,比如要求会使用各种诊断工具。这些工具一般的开发人员可能会比较少使用。找问题的过程本身也可以提高团队其他人的技术水平。

二、培训

培训的工作应该占用30%左右的工作时间。培训是稳定团队人员最重要的手段。也是提高团队开发效率最有效的手段。工具、过程、制度、奖惩,这些都代替不了程序员一行行的去写代码,最直接的方法是让他们做的更快更好,这些需要经验和知识的积累。

1. 代码审查

关于代码审查,有太多的论述。但是代码审查还是一种“强迫”推行某种风格或者技巧的手段,这是最真实的“控制”系统的手段。也是推广知识和经验最直接的手段。一个人写的代码通常应对的问题不会特别“广泛”,因此只要审查其中一部分代码,就能给大部分别的代码带来好处。

代码审查的实施,应该有一定的基础。需要代码作者进行问题描述、代码结构的讲解。而且也需要作者自己来挑选重点代码段。主程序员应该指出自己关心的重点代码应该符合什么特征。

2. 技术方案评审

什么事情应该写一个技术方案,然后进行评审,这是一个关键的问题。一般认为开发时间在2周以上的单项工作应该先做个方案。往往技术方案是系统架构的完善和补充,或者是挑战。所以主程的参与是非常必要的。但是要注意不需要去做的太琐碎,而是要提炼出“关键”的需求和“关键”的解决方案进行评审,而这些“关键”往往不是功能,而是质量上的需求,如这个系统的扩展性,是否能方便后续开发等等。也有可能在这些会议上会发生争吵,但是决策人是主程的地位是不容动摇的。君子和而不同,每个程序员都可以拥有自己的看法,但是代码必须能按方案运行起来,主程必须经常申明这点。

技术方案在差距较大的团队中评审,一般来说可以视为一种培训;而在水平相当的团队中评审,可能会变成各自想法的争执。不同的项目经历,绝对会造成意见的大分歧。其实这就是所谓“非功能需求”没有被明确出来造成的。这个时候主程就应该履行自己的义务,去提炼争论中的“非功能需求”,然后做出决断。

【腾讯Bugly干货分享】总结一个技术总监的教训和经验

3. 学习与讲座

如果团队碰到问题,没有新的方法和技术去解决,是不会提高开发效率的。就好像你用牛来耕地,不管用什么管理方法,都不会赶上机械化的速度。而主程承担着不断突破自己的技术上限,介绍和推动团队使用更新的技术来解决问题的责任。抱残守缺,思想僵化,最后会被团队成员所抛弃,而且也会让团队的效能落后于业界,最后直接影响产品的生死。每年学一门新语言,这个说法可能有点激进,但是这也是作为程序员应该有的激情。

三、管理

管理等于权势?管理等于沟通?管理等于文山会海?多年专业训练出来的技术人员如何去做管理?

管理的目标是提高绩效,如果和这个目标无关,而只是和“管理者”这个头衔有关的事情,最好丢给别人去做,包括那个头衔。管理主要手段是创新:想出新的方法去解决问题,而不是繁杂的事务性工作!——一个专业秘书能比主程做的好一百倍。技术工作的创新,最主要还是在技术工作里面,而不是跳出来说:做这个,做那个。

管理的事情如果超过10%的工作时间,等于说你更像一个项目经理而非主程。

1. 绩效评定

以专业的意见来衡量别人的工作,这个负担是无人能够承担的。这个工作往往是利益分配的一种手段。类似奖惩手段。这种管理方法已经不是新事物了。但是实际上技术人员对于绩效往往持一定保留和暧昧的态度,因为这种事情难以很清晰的界定出来。需要判断而非量度,才是绩效的真正手段。如果一定要打分,一共两项足够了:进度、质量,5分制即可。更重要的事情是,告诉每个人主程的看法,告诉别人,怎样做才是更好。或者告诉团队,怎样做才更有利于我们成功(发财、上市、赢得老板和客户……)——把目标清晰告诉团队,发挥他们的主动性,是绩效评定最重要的目标。

【腾讯Bugly干货分享】总结一个技术总监的教训和经验

KPI是一个争论非常多的话题,技术人员的KPI的争议更多。

关于KPI,有几个观点是必须明确的:

  • 难以量化的东西,就不要强行量化;
  • KPI应该以任务是否有去做完为标志,而不是做到的效果为标志;
  • 分解和设计KPI是一个非常需要承担风险的工作,基本上等于提出实际的工作方案。

以上三点,是互为结合的。技术工作的质量很难量化,或者指导性不强,还不如以工作的数量为标准,指导性反而更强。

那么要怎么设置这些工作任务的数量呢?

应该去设计一些能“保证质量”的工作任务,作为必须要完成的工作数量。那么,问题就更进一步了,要设置些什么样的工作,才能作为指标?这就需要技术总监根据自己的经验和智慧,提出切实可行的方案去要求下属完成,而不是把需求简单的分切后丢给下属去自行了断。

举个例子,有一个部门的业务逻辑开发任务很重,由于需求多变化快,代码质量难以监督,所以各种性能和逻辑故障都层出不穷。如果你只是设置了BUG的数量和需求完成数量作为指标,靠这种KPI是难以推动真正的改进的。反过来,如果你对需求实现模块,设置了必须要完成的单元测试任务指标,设置了运行质量监控系统的开发指标。如果部门完成了这些事情,项目的质量和进度自然就会有提高。——但是这些措施是否真的能奏效,这就是作为技术总监必须自己承担的决策风险。

2. 需求评定

最让技术人员头疼的可能就是和客户谈判。这个事情实际上不应该让技术人员来伤心,有项目经理就可以了。而需求评定更多的是可行性的讨论。主程如果参加每个需求评定,他要三头六臂也搞不定,正确的做法应该是具体开发的团队人员参加,而主程在开会前给与自己的意见,或者会后听取参与者的总结。——这是了解别人做什么事的一个重要手段,但无需陷入太深,因为还有代码评审和项目经理的帮忙。

3. 跨部门沟通

实在没必要参加,能躲就躲,这是扯皮的天堂。让项目经理去吧,他们的专业技巧能让这些事情更加有效。只要回来后让项目经理告诉你发生了什么事情就可以了。

4. 进度审核和任务分派

又是一个很有“权势”的工作,实际上团队成员的情况大家都知道,决定谁应该做什么事情并非需要很多时间去想的事情。所以大可以把方向性的意见告诉项目经理,让他去做。很多优秀的开发者玩EXCELPROJECT之类的水平还不如只有一年工作经验的秘书,别折腾自己了。

5. 面试

如果真想帮忙,准备一份有区分度的笔试题目吧。不靠谱的人太多,老板可不是花钱请你和他们聊天的。让项目经理去聊,不用担心他们技术不强,再不够,也会比大多数面试者要牛X。他们搞不定的人,就是应该雇佣的家伙。毕业生招聘怎么办?只要看看他们课外活动是不是有搞些专业的事情就可以了,上进心比别的东西都重要,HR会比主程看的更准,相信我。

6. 各种会议

饭无好饭,会无好会,超过6个人的会议应该坚决抵制。如果你有一个程序等着你去写,你一定无比痛恨这些会议,顺应你的内心吧!上帝保佑你。

最后说说项目经理的工作:

项目经理就像下水道的清洁工,所有那些主程不愿意去做的事情,他们都弯下腰去认真的把玩,实在是太伟大了。既然如此,为何不让他们拥有更好一点的头衔呢?如果没有他们去处理这些工作,任何一个主程都会被逼疯掉,或者他们自己变成了项目经理,让团队损失了最强力的一台代码发动机。

在一些公司,有专门的项目经理的岗位,这无疑是幸福的,但也是不幸的。因为项目经理本身是一种既需要专业性,也需要通用技能的岗位。项目经理由于专业定义不清晰,导致了大量的误解,这就是不幸的原因。有的团队会说我们不需要项目经理,又有的团队会认为项目经理无比重要,这两种观点的争论一直没有平息过。因此比较实际的做法是,不要轻易的去评价“是否需要项目经理”,而是努力把工作细分,专业化,然后再看应该安排谁去做。不同的项目和不同的团队,也许项目经理的工作都是不同的。

【腾讯Bugly干货分享】总结一个技术总监的教训和经验

根据经验,项目经理大概的工作内容方向包含以下这些:

一、进度

  1. 指定工作计划
  2. 进度检查和进度延迟的预警
  3. 工作总结和统计

二、资源

  1. 整合提供各种资源,如找DBA,IT,运维人员,硬件,SVN权限,测试环境,福利,周末的活动……
  2. 面试:人员是最重要的资源,不是吗?
  3. 资源谈判:往往是和老板谈判,让别人明白现在的真实情况。又一个吃力不讨好的差事,但是总需要人做。

三、沟通

  1. 需求评审:和需求方讨价还价,项目经理真是命苦啊……
  2. 组织会议或者用其他方式通知信息给所有人:小喇叭、大喇叭、全服广播、世界频道……

总结

对于一个小型公司,职权,头衔,收益,往往会更加敏感。但是这些都不是让项目失败的理由。一颗叫程序员的种子说:长大了我就是叫管理者的树。这个错误的观念只会让这个种子永远无法发芽。软件开发是类似外科医生的行业,而不是血汗工厂,所以不需要手持皮鞭的经理,而需要仁心仁术的神医。


更多精彩内容欢迎关注腾讯 Bugly的微信公众账号:

【腾讯Bugly干货分享】总结一个技术总监的教训和经验

腾讯 Bugly是一款专为移动开发者打造的质量监控工具,帮助开发者快速,便捷的定位线上应用崩溃的情况以及解决方案。智能合并功能帮助开发同学把每天上报的数千条 Crash 根据根因合并分类,每日日报会列出影响用户数最多的崩溃,精准定位功能帮助开发同学定位到出问题的代码行,实时上报可以在发布后快速的了解应用的质量情况,适配最新的 iOS, Android 官方操作系统,鹅厂的工程师都在使用,快来加入我们吧!

上一篇:[翻译 EF Core in Action 1.10] 应该在项目中使用EF Core吗?


下一篇:使用python+flask让你自己api(教程源代码)