如何胜任一个小型公司的技术总监？

资深程序员是团队中最强大的生产力，但每每被不合理的工做安排浪费掉。所以做为一个团队的技术的“头”，必需要有明确清晰的认识，把主要的事务性工做剥离出来，同时放弃大量的管理“权力”，以提升团队开发质量和效率，并为最主要的目标去安排本身的工做。通常来讲，技术总监这个职位主要包含两个角色（职位）的工做：主程和项目经理（技术化）。

所以咱们必须明确此两个职位的工做任务分割，而后把项目经理的工做，安排给另一我的作，固然其职称可能一样也得叫“技术总监”或“主程”，总之听起来越牛X越好。

下面我就主程和项目经理两个角色，来谈谈他们的主要工做。先从主程开始提及，真正的主程（技术总监）应该投身于尽可能多的技术工做中，这其中最重要的工做就是开发——生产代码和文档。

一,开发

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

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

1. 提出非功能性需求

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

2. 设计和修正软件架构

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

3. 难点代码（关键需求）的开发

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

4. 救火和杀虫

这个工做其实和代码开发是一致的，若是没有平日的开发，一般紧急问题的解决也是比较难处理的。可是这个也有一个调试技巧的要求，好比要求会使用各类诊断工具。这些工具通常的开发人员可能会比较少使用。找问题的过程自己也能够提升团队其余人的技术水平。

二,培训

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

1. 代码审查

关于代码审查，有太多的论述（编辑推荐文章）。可是代码审查仍是一种“强迫”推行某种风格或者技巧的手段，这是最真实的“控制”系统的手段。也是推广知识和经验最直接的手段。一我的写的代码一般应对的问题不会特别“普遍”，所以只要审查其中一部分代码，就能给大部分别的代码带来好处。

2. 技术方案评审

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

3. 学习与讲座

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

三，管理

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

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

管理的事情若是超过10%的工做时间，等于说你更像一个项目经理而非主程。

1. 绩效评定

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

2. 需求评定

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

3. 跨部门沟通

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

4. 进度审核和任务分派

又是一个颇有“权势”的工做，实际上团队成员的状况你们都知道，决定谁应该作什么事情并不是须要不少时间去想的事情。因此大能够把方向性的意见告诉项目经理，让他去作。不少优秀的开发者玩EXCELPROJECT之类的水平还不如只有一年工做经验的秘书，别折腾本身了。

5. 面试

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

6. 各类会议

饭无好饭，会无好会，超过6我的的会议应该坚定抵制。若是你有一个程序等着你去写，你必定无比痛恨这些会议，顺应你的心里吧！上帝保佑你。

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

1. 进度

• 指定工做计划

• 进度检查和告警

• 工做总结和统计

2. 资源

• 整合提供各类资源，如找DBA，IT，运维人员，硬件，SVN权限，测试环境，福利，周末的活动……

• 面试：人员是最重要的资源，不是吗？

• 资源谈判：每每是和老板谈判，让别人明白如今的真实状况。又一个吃力不讨好的差事，可是总须要人作。

3. 沟通

• 需求评审：和需求方讨价还价，项目经理真是命苦啊……

• 组织会议或者用其余方式通知信息给全部人：小喇叭、大喇叭、全服广播、世界频道……

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