首页>>技术前沿>>网站/软件行业动态软件开发团队是体现软件公司业战斗力的最小组织单元，很多情况下我们张口闭口谈团队协作精神。但是每个软件开发人员工作时的状态和心态截然不同，在一个团队中吃“大锅饭”难免有人懈怠，让其他软件开发人员心生不平。软件公司如何明确软件开发人员任职资格标准、制定更合理晋升机制，实现能者多劳多得，同时杜绝慵懒懈怠?本文一起来听听这些软件开发技术大牛的一手经验。
搞管理的得懂技术，搞技术的得懂管理。晋升可以分开，如果软件公司不大，都是合在一起的。我觉得大于100的软件开发公司就有必要搞清晰的任职资格标准和考核体系了。团队大了就可以搞，小团队没必要。这个体系建立与维系，需要耗费很多的人力物力，至少要分成三个以上的团队，每个团队达到25人以上才有意义。
给每个人明确现在能达到什么，通过如何努力能达到更高一个级别，每个级别对应的待遇是什么样的。如果长期看，小团队还是也应该规划的，一个人不可能在一个位置呆一辈子，像我们公司，最短的都呆了5年以上了，一个萝卜一个坑。我们现在200多人，所以虽然确实会耗费人力、物力。但是，无论向上，还是向下，能达到公平，公正，公开，透明。很多公司没有把 T和M系列分开，所以为了涨工资，只能先给个经理、高级经理，但是实际上这个人不一定适合管理，甚至下面可能都没有兵。
框架对大多数公司来说太大了，但是普通、优秀、卓越不好区分。按结果考核，比如我们定了一个项目，如期保质保量完成，这一项就考核通过。可能要把握一个度，客观+主观。系统建设不会一直有任务，日常运维可以外包，建议把人员重点放在安全和数据分析上。
我觉得工资还是要和级别挂钩的，你能力再强，不升个经理级别(或技术经理)的话，你的贡献也达不到经理级别，当然薪水也就不该到经理级别。老实说，一般的内部IT，技术牛与很牛差距不是那么大，真正自己做产品的单说。要分管理与技术两条线吧，对于不想管人的，但技术够牛，也是可以拿高薪的。我觉得工资还是要和级别挂钩的，你能力再强，不升个经理级别(或技术经理)的话，你的贡献也达不到经理级别，当然薪水也就不该到经理级别。」这不适用于技术大牛吧，有一种情况，有人技术很强，但完全不会管理，但是作为技术攻坚，能力突出。
内部IT不需要技术太强，要了解公司业务需要什么样的技术。管理与技术两条线更合理。就是晋升途径的问题，一条是行政线，一条是技术线。不喜欢管理的技术大牛可以给他另外一些职称，达到经理或副经理的级别，拿这种级别的工资。互联网公司可能需要的技术大牛多，需要不断创新技术，一般企业信息化的软件开发公司对技术大牛的需求不多，多为IT应用。技术层面可以简单分为三个层次：1、熟练使用现成产品和工具;2、在现有产品和工具的基础上，可通过产品自身的命令或自己写，变成脚本，实现部分自动化或半自动化;3、具备较强的开发能力，可根据需求灵活的实现不同的技术方案。
内部IT和产品研发区别对待。引入ITIL服务体系和系统，提升IT服务与运维效率，自然人的效率就提升了。技术线就是走技术大牛路线，攻坚某一个技术防线，管理线多考察沟通、协调、项目管理、情商等。另外一种是部分，都是技术线，要求技术线的领导任职资格是技术必须强，必须能知道手下日常工作，管理方面不做明细的要求。运维也不需要技术太强，因为他工作的面太窄，不需要走大牛路线。真正的大牛肯定不会满足一直从事运维工作，运维要的是安全稳定不出差。
技术大拿搞研发对路，别的不对路。由软件开发的部门储备技术大牛，IT应用与运维部门更多侧重管理、协调与技术支持，一般管理岗和工程师岗就够了。每个领域如果研究很深入的话，都可以成为技术大牛，不论是开发、运维、还是IT，主要看你使用的是什么类型的技术，通常能有机会处理一些高并发、大集群、上P级数据，有实操经验，基本在中型公司都能当个小头。IT跟产品研发不太一样的地方，咱们除了跟机器打交道以外，有大量时间都要跟人打交道，所以对沟通、协调能力要求会比其他技术岗要高。企业内部的IT，一方面是建立新的业务支撑能力;另一方面是保障这个能力的持续、稳定运行。个人感觉两方面都是需要技术高手。
KPI也有局限性的，现在的大企业开始做模糊KPI了。现在的企业变化太快了，年初的KPI目标年底可能已经都变了。所有的内容肯定无法做到100%量化和客观，但尽力往这个方向靠，相对来说，评价标准比较明确，数据来源客观，如果对向下的话，员工对考核结果应该不会有太大异议。这个涉及的范围比较广，根据实际的关注点调整就可以了。基于考核结果，再制定职级体系和晋升通道。每个公司的的关注点不太一样，有些公司重IT的服务意识、态度、效率，有些公司重应用服务的稳定性和可用性，有些比较重数据分析和收集，看实际需要来配置KPI吧。
考核是把双刃剑，用好了避免管理上的漏洞，让团队螺旋式向上成长。用不好可能会影响大家的积极性，抹杀大家创造性。所以，我现在也是加了主观，客观的通过系统数据分析(UV、页面响应等)，主观的比如让客服部门给产品经理打分，对于产品上线的功能是否真正满足了客户的需求评分(一般满意、满意、超预期等)。绩效考核关键还是在于执行，对员工来说是否公平很重要。搞得太复杂，执行起来费时费力，不一定会有好效果，抓住几个关键点就行。能定量定性的，用KPI。对于敏捷交付的，不容易定性、定量的用OKR。
【全文完】
版权声明:
1、弈聪软件网站内容中凡注明“来源：XXX（非陕西弈聪网站）”的作品，转载自其它媒体，转载目的在于传递更多信息，其中涉及的网站建设，网站优化，APP开发，微信小程序开发，大数据平台开发，区块链技术开发等软件开发技术细节并不代表本站赞同支持其观点，并不对其真实性负责。对于署名“陕西弈聪”的作品系本站版权所有，任何人转载请署名来源，否则陕西弈聪将追究其相关法律责任。
2、本站内容中未声明为“原创”的内容可能源自其它网站，但并不代表本站支持其观点，对此带来的法律纠纷及其它责任与我方无关。如果此内容侵犯了您的权益，请联系我方进行删除。
企业动态
