程序员那些事：总结一个技术总监的教训和经验( 四 ) _程序员

文章插图

3. 学习与讲座如果团队碰到问题，没有新的方法和技术去解决，是不会提高开发效率的。就好像你用牛来耕地，不管用什么管理方法，都不会赶上机械化的速度。而主程承担着不断突破自己的技术上限，介绍和推动团队使用更新的技术来解决问题的责任。抱残守缺，思想僵化，最后会被团队成员所抛弃，而且也会让团队的效能落后于业界，最后直接影响产品的生死。每年学一门新语言，这个说法可能有点激进，但是这也是作为程序员应该有的激情。
三、管理管理等于权势？管理等于沟通？管理等于文山会海？多年专业训练出来的技术人员如何去做管理？
管理的目标是提高绩效，如果和这个目标无关，而只是和“管理者”这个头衔有关的事情，最好丢给别人去做，包括那个头衔。管理主要手段是创新：想出新的方法去解决问题，而不是繁杂的事务性工作！——一个专业秘书能比主程做的好一百倍。技术工作的创新，最主要还是在技术工作里面，而不是跳出来说：做这个，做那个。
管理的事情如果超过10%的工作时间，等于说你更像一个项目经理而非主程。
1. 绩效评定以专业的意见来衡量别人的工作，这个负担是无人能够承担的。这个工作往往是利益分配的一种手段。类似奖惩手段。这种管理方法已经不是新事物了。但是实际上技术人员对于绩效往往持一定保留和暧昧的态度，因为这种事情难以很清晰的界定出来。需要判断而非量度，才是绩效的真正手段。如果一定要打分，一共两项足够了：进度、质量， 5分制即可。更重要的事情是，告诉每个人主程的看法，告诉别人，怎样做才是更好。或者告诉团队，怎样做才更有利于我们成功（发财、上市、赢得老板和客户……）——把目标清晰告诉团队，发挥他们的主动性，是绩效评定最重要的目标。

文章插图

KPI是一个争论非常多的话题，技术人员的KPI的争议更多。
关于KPI ，有几个观点是必须明确的：

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

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

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

应该去设计一些能“保证质量”的工作任务，作为必须要完成的工作数量。那么，问题就更进一步了，要设置些什么样的工作，才能作为指标？这就需要技术总监根据自己的经验和智慧，提出切实可行的方案去要求下属完成，而不是把需求简单的分切后丢给下属去自行了断。
举个例子，有一个部门的业务逻辑开发任务很重，由于需求多变化快，代码质量难以监督，所以各种性能和逻辑故障都层出不穷。如果你只是设置了BUG的数量和需求完成数量作为指标，靠这种KPI是难以推动真正的改进的。反过来，如果你对需求实现模块，设置了必须要完成的单元测试任务指标，设置了运行质量监控系统的开发指标。如果部门完成了这些事情，项目的质量和进度自然就会有提高。——但是这些措施是否真的能奏效，这就是作为技术总监必须自己承担的决策风险。
2. 需求评定最让技术人员头疼的可能就是和客户谈判。这个事情实际上不应该让技术人员来伤心，有项目经理就可以了。而需求评定更多的是可行性的讨论。主程如果参加每个需求评定，他要三头六臂也搞不定，正确的做法应该是具体开发的团队人员参加，而主程在开会前给与自己的意见，或者会后听取参与者的总结。——这是了解别人做什么事的一个重要手段，但无需陷入太深，因为还有代码评审和项目经理的帮忙。