软件开发团队是体现软件公司业战斗力的最小组织单元，很多情况下我们张口闭口谈团队协作精神。但是每个软件开发人员工作时的状态和心态截然不同，在一个团队中吃“大锅饭”难免有人懈怠，让其他软件开发人员心生不平。软件公司如何明确软件开发人员任职资格标准、制定更合理晋升机制，实现能者多劳多得，同时杜绝慵懒懈怠?本文一起来听听这些软件开发技术大牛的一手经验。

搞管理的得懂技术，搞技术的得懂管理。晋升可以分开，如果软件公司不大，都是合在一起的。我觉得大于100的软件开发公司就有必要搞清晰的任职资格标准和考核体系了。团队大了就可以搞，小团队没必要。这个体系建立与维系，需要耗费很多的人力物力，至少要分成三个以上的团队，每个团队达到25人以上才有意义。

给每个人明确现在能达到什么，通过如何努力能达到更高一个级别，每个级别对应的待遇是什么样的。如果长期看，小团队还是也应该规划的，一个人不可能在一个位置呆一辈子，像我们公司，最短的都呆了5年以上了，一个萝卜一个坑。我们现在200多人，所以虽然确实会耗费人力、物力。但是，无论向上，还是向下，能达到公平，公正，公开，透明。很多公司没有把 T和M系列分开，所以为了涨工资，只能先给个经理、高级经理，但是实际上这个人不一定适合管理，甚至下面可能都没有兵。

框架对大多数公司来说太大了，但是普通、优秀、卓越不好区分。按结果考核，比如我们定了一个项目，如期保质保量完成，这一项就考核通过。可能要把握一个度，客观+主观。系统建设不会一直有任务，日常运维可以外包，建议把人员重点放在安全和数据分析上。

我觉得工资还是要和级别挂钩的，你能力再强，不升个经理级别(或技术经理)的话，你的贡献也达不到经理级别，当然薪水也就不该到经理级别。老实说，一般的内部IT，技术牛与很牛差距不是那么大，真正自己做产品的单说。要分管理与技术两条线吧，对于不想管人的，但技术够牛，也是可以拿高薪的。我觉得工资还是要和级别挂钩的，你能力再强，不升个经理级别(或技术经理)的话，你的贡献也达不到经理级别，当然薪水也就不该到经理级别。」这不适用于技术大牛吧，有一种情况，有人技术很强，但完全不会管理，但是作为技术攻坚，能力突出。

内部IT不需要技术太强，要了解公司业务需要什么样的技术。管理与技术两条线更合理。就是晋升途径的问题，一条是行政线，一条是技术线。不喜欢管理的技术大牛可以给他另外一些职称，达到经理或副经理的级别，拿这种级别的工资。互联网公司可能需要的技术大牛多，需要不断创新技术，一般企业信息化的软件开发公司对技术大牛的需求不多，多为IT应用。技术层面可以简单分为三个层次：1、熟练使用现成产品和工具;2、在现有产品和工具的基础上，可通过产品自身的命令或自己写，变成脚本，实现部分自动化或半自动化;3、具备较强的开发能力，可根据需求灵活的实现不同的技术方案。

内部IT和产品研发区别对待。引入ITIL服务体系和系统，提升IT服务与运维效率，自然人的效率就提升了。技术线就是走技术大牛路线，攻坚某一个技术防线，管理线多考察沟通、协调、项目管理、情商等。另外一种是部分，都是技术线，要求技术线的领导任职资格是技术必须强，必须能知道手下日常工作，管理方面不做明细的要求。运维也不需要技术太强，因为他工作的面太窄，不需要走大牛路线。真正的大牛肯定不会满足一直从事运维工作，运维要的是安全稳定不出差。

技术大拿搞研发对路，别的不对路。由软件开发的部门储备技术大牛，IT应用与运维部门更多侧重管理、协调与技术支持，一般管理岗和工程师岗就够了。每个领域如果研究很深入的话，都可以成为技术大牛，不论是开发、运维、还是IT，主要看你使用的是什么类型的技术，通常能有机会处理一些高并发、大集群、上P级数据，有实操经验，基本在中型公司都能当个小头。IT跟产品研发不太一样的地方，咱们除了跟机器打交道以外，有大量时间都要跟人打交道，所以对沟通、协调能力要求会比其他技术岗要高。企业内部的IT，一方面是建立新的业务支撑能力;另一方面是保障这个能力的持续、稳定运行。个人感觉两方面都是需要技术高手。

KPI也有局限性的，现在的大企业开始做模糊KPI了。现在的企业变化太快了，年初的KPI目标年底可能已经都变了。所有的内容肯定无法做到100%量化和客观，但尽力往这个方向靠，相对来说，评价标准比较明确，数据来源客