技术总监应该做哪些事情?一个人精力有限,开发、带人、培训、管理如何权衡?怎么才能做到最好?本文作者韩伟,他将会和我们分享他的个人经验,韩伟就职于腾讯互动娱乐研发部。


如何胜任一个小型公司的技术总监?_架构师


开发


从来没有一个资深的外科医生会放下手术刀,而到手术室外面指手画脚。一个资深的程序员也不应该离开代码和文档的编写,而只是做做架构图。作为对一个复杂系统的负责人,必须亲手领导和参与建造,才能有足够的能力去负担起这个责任。因此需要至少使用60%的时间来参与开发的工作,并且建议从一上班就开始,虽然早上的效率很低,但是跟任何艰巨工作都一样:万事开头难。在你好不容易等待电脑慢吞吞的打开了所有的IDE、需求文档、参考资料、工作计划这堆要命的东西之后,你就迈出了最重要的一步,你会发现你不在需要在网上看微博和聊QQ来提振开始工作的激情,而会被某一个优化代码的灵感而激励,或者被一个复杂而有趣的问题所吸引,从而更快的能投入到开发中。坚持打开电脑做的第一件事是打开IDE软件,是这一切最重要的一步。

下面我来谈谈开发的主要工作内容。

1. 提出非功能性需求

一般来说功能需求总是让开发人员焦头烂额的主要原因。但是实际上很多项目死在发布之后,却是因为性能、产品质量、扩展性、二次开发效率等非功能性需求没认真去解决而导致的。主程作为经验最丰富的成员,必须要利用自己曾经的经验和教训(在这里教训往往比经验重要),提出那些自己折腾自己的“非功能性需求”,来保障整个项目在发布后不会轰然倒塌。这是个吃力不讨好的工作,因为老板和客户往往只会抱怨技术人员在玩弄把戏,骗取更多的资源或者杞人忧天。如何说服这些家伙也许不是主程的工作,但是主程必须要以高度的责任心把问题放到台面上来。沟通的工作也许让项目经理去做会更好,他们有一整套如何威逼利诱老板和客户的戏法。

2. 设计和修正软件架构

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

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

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

4. 救火和杀虫

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


培训


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

1. 代码审查

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

2. 技术方案评审

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

3. 学习与讲座

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


管理


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

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

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

1. 绩效评定

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

如何胜任一个小型公司的技术总监?_代码审查_02

4. 进度审核和任务分派

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

5. 面试

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

如何胜任一个小型公司的技术总监?_项目经理_03

1. 进度

  • 指定工作计划
  • 进度检查和告警
  • 工作总结和统计

2. 资源

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

如何胜任一个小型公司的技术总监?_架构师_04

-END-如何胜任一个小型公司的技术总监?_项目经理_05

欢迎关注“互联网架构师”,我们分享最有价值的互联网技术干货文章,助力您成为有思想的全栈架构师,我们只聊互联网、只聊架构,不聊其他!打造最有价值的架构师圈子和社区。

公众号覆盖中国主要首席架构师、高级架构师、CTO、技术总监、技术负责人等人 群。分享最有价值的架构思想和内容。打造中国互联网圈最有价值的架构师圈子。

  • 长按下方的二维码可以快速关注我们
  • 如何胜任一个小型公司的技术总监?_项目经理_06