软件研发的管理支撑体系

软件工作区别于制造业的一个重要特征就是知识性工作（关于更多知识性工作者可以参考德鲁克著的卓有成效的管理者一书），工作时间长短、工作量大小、参与项目的多寡不一定能够反映一位软件工程师的绩效。简单的讲，一个人除了睡觉就是坐在电脑前工作，可能是新手在学习，可能是在赶工，可能是在磨洋工，也能是在优化已经实现的代码，可能是在研究新技术，总之，工作量不能直接反映业绩，工作内容未必马上能够见到成效。因此，一个相对宽松、注重整体、支撑发展、关注效率的管理框架，是引导软件研发正向发展的重要基础。

首先要构建的是组织架构和岗位职责。这对于一个度过生存期的软件公司，往往是一个比较艰难的选择。初创团队经过无数彻夜未眠的辛苦工作，经历脆弱睡眠的全天候思考，承受家庭内外的压力，终于有所成绩的时候，对于大部分老板来说，希望给大家一个交代，从职位到待遇，从副总到总监再到部门经理。道德经有一句话说的好，恩生于害，害生于恩，无条件的爱，可能会带来令人遗憾的恨。公司老板有必要在合适的实际，建立符合公司发展现状和中期需要的组织架构和岗位职责，考虑到创业团队的贡献，不一定从职位高低角度体现，可以考虑从专业发展、股权等多角度考虑，从而逐步形成健壮的公司架构。

第二是公司奖金机制的引导。无论大小公司都经历过奖金分配的痛苦，给谁给多少什么时间给，困扰着具有责任心的中高层领导。不少中小软件企业按照项目对研发团队进行奖励，在公司发展到一定阶段，对于工程师来说，可能更喜欢选择合同额大的项目，从而获得更多的收益。现实情况可能是，小额度的项目是公司新发展机遇，而没有合同额的研发性项目，可能是公司提升和未来的关键，奖励良好的奖金引导机制，是对基层研发工程师正确引导的关键，使得工程师不要花精力去选择哪些工作，而是与团队共同完成公司业绩所需要的各项工作。对于研发团队来讲，奖金应该对整体绩效的奖励，而不是针对部分项目。研发团队总体是高月薪，从而对应的是相对固定的奖金，对于年终奖来说，从保底的1~2倍月薪奖金，到6~8倍封顶，在研发团队内部通过相对公平的绩效评价均值进行分配。

第三是关于绩效评价。我个人不建议对研发团队实行绩效考核和KPI等刚性指标，更倾向于结合工作过程积累数据的评价评分机制，其中包括60%的日常工作完成情况评价，以及40%的职业素养评价，包括主动、责任、学习、分享等方面。绩效评价由直接主管定期（例如每月）通过面谈进行，因此，其主管须对工程师具备日常工作跟踪的职责，但是不一定完全负责分配所有的工作任务（但是必须知悉和同意），从而支持矩阵式的管理结构。评价结果总体看应是正态分布，60分以下约为15%，这个群体难以胜任工作，61~85是公司比较期待的范围，能够完成日常工作，分值表示完成结果的差异性，会在40%的职业素养方面进行体现，超过85分则表示超过了本职工作，是升职和晋级的潜在对象。某些动不动就90多分的绩效结果，还不如不做绩效评估。

第四是职位等级和晋级路线。不少公司存在一个现象，似乎认为部门经理一定是他团队中薪酬最高的，或者项目经理是项目组薪酬最高的，这就导致一个奇怪的现象，所有人都想当部门经理、项目经理。我曾经和一公司的研发团队做过一次调查，几乎所有研发人员的发展目标都是项目经理，这说明研发团队的职位等级和晋级路线出现了畸形。与此同时，几乎所有的管理者，无论公司大小，都知道软件公司分为技术和管理两条晋级路线，但是在上升空间上又制造了人为的壁垒，使得难以培养或留住高级资深的技术专家，因为他们只有转为管理岗位，才能在收入和事业上更上层楼，在这样的团队中，似乎认为工程师只是在公司架构里面的中低层次群体。恰恰相反，技术路线应该是从低到顶，简单的说，一位技术路线上的顶级工程师，可能比公司的CEO收入都高。难道不觉得，一个公司、部门或项目组中，有一个能够掌控公司技术现状和发展，或引导产品线发展的牛B工程师，是一件非常有面子的事情吗？可能有人会讲，我们技术路线的顶级是技术总监，那么初级、中级和高级工程师都在研发团队中做什么？高级工程师之上是什么技术级别呢？如果一个研发团队中的高级工程师，90%以上的时间在忙于项目业务开发，认为不知道如何在技术路线上继续发展，要么这个高级工程师不称职，要么这个公司的技术梯队建设存在重大隐患。没有技术路线和技术等级对于研发团队是一个危险信号，对于公司则是无法控制的隐患风险点，老板今年给这个工程师10K月薪，那么明年呢？后年呢？如果要加薪，是加多少？为什么？加薪后，应该承担原有职责，还是有更重要的定位？如果这些不清楚，即便有产品和技术，也难以持续发展。

软件公司的老板还须在发展过程中建立持续可改进的研发管理体系框架，支撑公司现在和未来的健壮的、可持续的发展。