资深程序员是团队中最强大的生产力，但往往被不合理的工作安排浪费掉。因此作为一个团队的技术的“头”，必须要有明确清晰的认识，把主要的事务性工作剥离出来，并且放弃大量管理的“权利”，以提高团队开发质量和效率为最主要的目标去安排自己的工作。
一般来说技术总监有两个职责：主程、项目经理
因此必须明确此两个职位的工作任务分割，然后把项目经理的工作，安排给另外一个人做。当然其职称可能同样也叫做“技术总监”或“主程”，总之听起来越牛X越好。而真正的主程（技术总监）则应该投身于尽量多的技术工作中，其中最重要的工作则是开发——生产代码和文档。
主程的工作
一、开发
从来没有一个资深的外科医生会放下手术刀，而转到手术室外面指手画脚。一个资深的程序员也不应该离开代码和文档的编写，而只是做做架构图。作为一个复杂系统的负责人，必须亲手领导和参与建造，才能有足够的能力去负担起这个责任。因此需要至少60%的时间来参与开发工作，并且建议从一开始上班就开始，虽然早上的效率很低，但是任何艰巨工作都一样：万事开头难。
在你好不容易等待电脑慢吞吞的打开了所有的IDE、需求文档、参考资料、工作计划着堆要命的东西之后，你就迈出了最重要的一步，你会发现你不在需要在网上看微博和聊QQ来提振开始工作的激情，而会被某一个优化代码的灵感而激动，或者被一个复杂而有趣的问题所吸引，从而更快的能投入到开发中。坚持打开电脑做的第一件事情是打开IDE软件，是这一切最重要的一步。
开发的工作内容包括：
1. 提出非功能性需求
一帮来说功能需求总是让开发人员胶头烂额的主要原因。但实际上，很多项目死在发布之后，却是因为性能、产品质量、扩展性、二次开发效率等非公能性需求没有认真去解决而导致的。
主程作为经验最丰富的成员，必须要利用自己曾经的经验教训（这里教训比经验更重要），提出哪些自己折腾的“非功能性需求”，来保障整个项目在发布后不会轰然倒塌。
这是个吃力不讨好的工作，因为老板和客户往往只会抱怨技术人员在玩弄把戏骗取更多的资源或者杞人忧天。如何首付这些家伙也许不是主程的工作，但是主程必须要以高度的责任心把问题放到台面上来。沟通的工作也许让项目经理去做会更好，他们有一台如何威逼利诱老板和客户的戏法。
非功能性需求中国，其中有三类
- 性能需求
- 运维需求
- 开发效率
性能需求
最好的性能需求，因为性能优化往往是错的，特别是一些有一定经验的开发人员，更容易产生“执念”。经验不是特别丰富，而又热爱学习的开发者，往往对很多网上的所谓文章，经验没有太多的识别能力，又缺乏动手实际测试的机会，所以道听途说先入为主的观念也是非常多的。这些观念里面最多的就是关于性能的，先不论所谓性能的各种说法，就是推荐各种高性能框架、库的文章也很多。这个时候，拨开纷繁的信息迷雾，就只能靠主程了。
运维需求
运维需求的目的是尽量自动化，这里除了最基本的批量启动、停止、重载静态数据（配置）外，还应该包括自动读取本地IP地址，以及自动下载配置文件来启动；等待所有用户退出后才启动的”安全退出“；自动检测进程停止后重启等等功能。
但是运维的工具也要避免过度设计。很多人往往一想到搞运维工具，就想搞一个功能非常大而全，具备漂亮的WEB界面的大平台。实际上真正救命的往往是一些自动化的小工具，只有这些小工具和小功能都齐备了，耐心而漂亮的平台系统真正有哦意义。所以这主要依赖于经验，但也需要有想象力。
开发效率
开发效率的需求一般都在代码结构上，而这时最容易争吵的地方。实际上所谓的代码结构，是对业务领域抽象的一种表现形式，所以对业务领域的理解能力和经验是第一位的。如何抽象好业务领域的模型，不能照搬别人的经验，但也不能完全靠自己想象。需要自己对业务领域做深入思考，同时也多学习了解其他项目模型。
一般来说，比较底层的技术模型，作为开发人员，都是非常熟悉的。比如UNIX系统把所有东西都抽象成文件。而大量的开元项目，作为通用的技术产品，对于比较技术层面的抽象，也都非常优秀。但是作为也逻辑开发人员，是觉得不应该被这些模型所困住的，因为我们需要解决的问题，并不是去写一个操作系统，或者某个框架，而是具体的一个领域的问题。只是真正深入的去了解业务领域，才能很好的抽象业务领域模型。
也就是说，如果你是开发游戏的，就要深入理解游戏产品的概念；如果你是开发电商产品的，就需要对商业贸易有深入理解，否则是不配做这些产品的开发领导人的。我们有一些技术人员，并不愿意去深入业务领域做理解，而是希望把所有的业务问题，都抽象成他自己最拿手的一种技术模型，这样反而是会严重影响开发效率的。
比如说有的人，希望把所有的业务逻辑，都看成是一种输入数据结构，和输出数据结构的处理管道，不管写什么程序，都是同样的一套类似的代码结构。尽管这样一定可以完成所有的需求，但是其代码结构并不能应对真正的需求变化，开发效率也一定是低的。真正的主程，就是应该在这个时候，挺身而出提出自己的抽象模型，从而带动真个团队，提高开发效率，同时也做好应对需求变化的准备。
设计和修正软件架构
软件架构设计至关主要，而且工作繁重。不画图纸就敢开工的技术人员要么是天才，要么是笨蛋。对于团队来说，架构在分工合作、避免风险、提高质量等多个方面有无可替代的作用。
架构要避免成为空洞的文档，最重要的一步是有人来掌控和实施。而主程设计和修改中架构，并且亲手实施，让团队中的腹诽之徒完全无法避开，否则代码将无法运行。所谓设计和修正架构，并不因为这所有的文档应该一个人写，而是指这个架构的每个环节，都是经过主程决策同意的。当然最好这些文档经理由他撰写，对于”菜鸟“团队来说，输出这种文档本事就意味着”权势“，有助于主程建立个人”威信“——这种看起来有点肮脏的”政治“东西，在避免团队内无休止的扯皮，以及稳定哪些随时准备跳槽的成员来说，都是相当实用的。
很多软件架构只是运行时架构，没有代码架构，这是非常可惜的。诚然，我想需要关注系统的运行效率，运行时架构（进程结构图）是必不可少的，然而，代码架构师更加稳定的设计方案，因为在必定会发生需求变更下，进程结构往往也会因此变化，代码的结构对需求的抽象和描述，这种描述是对业务需求的理解，业务需求小的变化非常多，而大的方向却往往不会变化很频繁，因此如果能基于这些大的方向来组织代码，划分模块，哪些繁复的小需求，仅仅是对系统局部的修改。而不会影响过多的其他部分；反之，如果我们没有整体的视野去组织代码和模块，仅仅从一开始的细节需求去组织进程代码，一定会因为需求变化吧整个系统改的乱七八糟。
所以，作为技术”头“，把控代码结构，往往比把控进程结构更为重要。同样的代码可以组织到不同的进程中来启动，如果进程结构不适应性能需求，还是可以优化的。但反过来就行不通了，一个混乱的代码结构，不管你怎么去进程结构调整，还是会问题百出。
难点代码（关键需求）的开发
主程必须写代码，写那些大家都认为风险大的代码。
有的系统对于性能要求很高，他就必须去完成容易出性能问题的部分。
救火和杀虫
这个工作其实和代码开发是一致的，如果没有平日的开发，通常紧急问题的解决也是比较难以处理的。但是这个也有一个调试技巧的要求。
培训
培训工作应该占用30%左右的工作时间。培训是文档团队人员最重要的手段。也是提高团队开发效率最有效的手段。工具、过程、制度、奖惩，这些都代替不了程序员一行行去写代码。最直接的方法是让他们做的更快更好，这些需要经验和只是的积累。
1. 代码审查
关于代码审查，有太多的论述。但是代码审查还是一种“强迫”推行某种风格或者技巧的手段，这是最真实的“控制”系统的手段，也是推广只是和经验最直接的手段。一个人写的代码应对的问题不会特别“广泛”，因此只要审查其中一部分代码，就能给大部分别的代码带来好处。
代码审查的实施，应该有一定的基础。需要代码作者进行问题描述、代码结构的讲解。而且也需要作者自己来挑选重点代码段。主程序猿应该指出自己关系的重点代码应符合什么特征。
2. 技术方案评审
技术方案评审不能做的太琐碎，而是要提炼出“关键”的需求和“关键”的解决方案进行评审，而这些关键往往不是在功能，而是在质量上的需求，比如：扩展性、可维护性。但是决策人是主程的地位是不容动摇的。君子和而不同，每个人都可以拥有自己的看法，但是代码必须能按照方案运行起来，主程必须进程申明这点。
管理
管理的目标是提高绩效，如果和这个目标无关，而是和“管理者”这个头衔有关的事情，最好求给别人去做，包括那个头衔。管理主要手段是创新：相处新的方法去解决问题，而不是繁杂的事务性工作——一个准也秘书能比主程做的好一百倍。技术工作的创新，最主要还是在技术工作里面。而不是跳出来说：做这个，做那个。
管理的事情如果超过10%的工作时间，等于说你更像一个项目经理而非主程。
1. 绩效评定
以专业的意见来衡量别人的工作，这个负担是无人能够承担的。这个工作往往是利益分配的一种手段。类似奖惩手段。这种管理方法已经不是新事物了。但是实际上技术人员对于绩效往往吃一定保留和暧昧的态度，因为这种事情难以很清晰的界定出来。需要判断而非度量，才是绩效真正的手段，如果一定要打分，一共两项足够了：进度，质量5分制即可。更重要的事情是，告诉每个人主程的看法，告诉别人，怎样做才是更好。或者告诉团队，怎样做菜更有利于我们成功。把目标清晰告诉团队，发挥他们的主动性，是绩效评定的主要目标。
关于KPI，有几个观点是必须明确的：
- 难以量化的东西，就不要强行量化；
- KPI应该以人物是否有去完成的标志，而不是做到效果为标志。
- 分解和设计KPI是一个非常需要承担风险的工作，基本上等于提出时间的工作方案。
以上三点是互为结合的，技术工作的质量很难量化，或者指导性不强，还不如以工作的数量为标准，指导性反而更强。
那么要怎样设置这些工作任务的数量呢？
应该去设计一些能“保证质量”的工作任务，作为必须要完成的工作数量。那么，问题就更进一步了，要设置些什么药的工作，才能作为指标？这就需要技术总监更加自己的经验和智慧，提出切实可行的方案去要求下属完成，而不是把需求简单的分切后丢给下属自行了断。
举个例子，有个部门的业务逻辑开发任务很重，由于需求多变化快，代码质量难以监督，所有葛洪性能和逻辑故障都层出不穷。如果你只是设置了BUG数量和需求完成数量作为指标，靠这种KPI是难以推动真正的改进的。反过来，如果你对需求实现模块，设置了必须要完成的单元测试任务指标，设置了运行质量监控系统的开发指标。如果不能完成了这些事情，项目的质量和进度自然就会有提高。——但是这些措施是否真的能奏效，这就是作为技术总监必须自己承担的决策风险。
2. 需求评定
最让技术人员头痛的可能就是和客户谈判。这个事情实际上不应该让技术人员来分心，有项目经理就可以了。而需求评定更多的是可行性的讨论。主程如果参加每个需求评定，他要三头六臂也搞不定，真去的做法应该是具体开发团队人员参加，而主程在开会前给与自己的意见，或者会后听取参与者的总结。——这是了解别人做什么事的一个重要手段，但无需下入太深，因为还有代码评审和项目经理的帮忙。
3. 跨部门沟通
少参加， 会撕逼
4. 进度审核和任务分派
又是一个很有“权势”的工作，实际上团队成员的情况大家都知道，决定谁应该做什么事情并非需要很多时间去想的事情。所以大家可以把方向性的意见告诉项目经理，让他去做。
5. 面试
如果真的想帮忙，准备一份有区分度的笔试题目吧。不靠谱的人太多了，老板可不是花钱请你喝他们聊天的。让项目经理去聊，不用担心他们技术不强，再不够，也会比大多数面试者要牛X，他们搞不定的人，就是应该雇佣的人。
网友评论