软件团队的人员管理_软件公司人员管理

人员管理良好，是团队高效完成工作目标的基础。良好的团队文化和氛围，明确的团队目标和任务，确定的角色职责，有效的沟通机制，合理的绩效考核和激励，学习成长机会，有竞争力的薪资等，都有利于于团队的人员管理。有的在前面分享主题中已经说过，有的会在后面涉及，本次主要讨论和人员管理相关的方面：团队的人员层级划分，定期沟通，团建活动，薪酬，绩效考核，离职事宜，不合适人员辞退。

人员层级划分

团队人员的角色职责不同，工作能力不同，为了高效管理，管理者需要对团队成员进行层级划分。一般可以划分三个层级： 核心人员，主要人员，一般人员。核心成员会给予更好的资源优待，更多的自主性，以确保他们能够充分发挥作用。以此类推，主要人员资源分配和关注次之，一般人员更少。如何判定人员层级？

1， 从技能和经验看，核心人员通常拥有丰富的技能和经验，对项目的关键部分有深入的了解并能够提供重要的贡献，也常具有更高的创新和解决问题的能力，在遇到难题和复杂问题时能够迅速找到解决方案。主要人员拥有必要的技能和经验，能够承担比一般人员更多的任务和责任。

2， 从工作责任看，核心人员通常担任关键职位，如项目经理、技术架构师或高级开发人员，他们负责制定计划、决策重要问题、核心代码编写和指导团队成员。主要人员通常负责执行项目计划，进行开发和测试等工作。 一般人员进行一些辅助，简单的开发。

3， 从团队角色和地位看，核心人员通常是软件团队中的重要成员，拥有更高的地位和影响力，他们的意见和建议得到更多的重视。主要人员在团队中也拥有重要的地位，但比核心人员更多的是执行任务。 

4， 从工作态度看，核心人员积极主动，往往具有更高的职业意识和责任感，对于工作任务的执行更为认真专注，值得信任，也具有不断学习和追求卓越的态度，能够自我驱动。

综上所述，区分核心人员、主要人员和一般人员，有助于提高团队的管理和协作效率，从而更好地完成项目任务，提高软件开发的质量，也可以更好地管理和激励不同层次的团队成员。核心人员和主要人员通常需要更高的待遇和激励来保持团队的稳定性，并为团队的整体质量、产出和效率提供推动力。

定期沟通

        软件开发人员一般比较内向被动，平时沟通有限，所以定期沟通是个很有效的渠道。建议最少每个月底进行一对一沟通，沟通的主要内容如下：

1，本月工作总结和评价：总结他的本月主要工作任务进展和结果，对做的好的方面进行肯定，给予鼓励，需要改进的给出建议。

2，下个月工作任务和目标：明确工作任务和目标，了解成员对工作的理解和认识，避免目标和任务的偏差。 

3，解决员工的问题：主动询问员工在工作和生活中出现的问题。如果及时发现并解决这些问题，可以减少员工的烦恼和压力，提高其工作效率和生活质量。

4，听取意见建议：主动询问团队成员对整个团队相关的改进意见或建议，觉得适合的则听取采纳，不仅有利于团队协作，也促进员工的参与感，让他们感觉到自己受到重视，增加他们的归属感。

以上，定期月度沟通的主要内容，但也不止于这些。平时一些工作态度或工作方式上积累一些小问题，不值得当时专门单独去谈的，也会在月度沟通上提一提。还有些非工作问题也闲聊一下，增加亲近和信任，缓解压力，建立良好沟通的桥梁。有时也会沟通技能成长情况和职业规划，给予一些指导和建议。 在实践中，可能会存在经常沟通内容差不多，不管询问问题和意见，都表示没有，评价内容也都基本一样，觉得这样沟通意义不大，但不要放弃，哪怕偶尔沟通中发现一些问题或意见也是非常值得的。曾经，我有几个月没有坚持月度沟通期间，团队里有人提出离职时，知道真实离职原因后，觉得当时能够坚持进行月度沟通，可以及时发现并解决问题，从而避免人才流失。在定期沟通中，也的确提前发现并劝阻了一些人员的离职。如果觉得沟通内容相似，可以进行快一些，几分钟就完成一个人员的沟通，但不能没有。 

总之，与员工定期沟通可以增强团队与成员之间的互动和信任，提高员工的工作热情和士气，从而促进公司的发展和壮大。

团建活动

团建是很多公司都会进行的，本来是好事，但由于安排得不合理，一提起搞团建，大家深恶痛绝。经常把团建活动安排在周末，占用大家宝贵的周末时间。有的团建活动是类似徒步戈壁滩等让人很累很辛苦的事情，名其名曰挑战自己，现实当中人们在工作和生活中的挑战已经不少了，还让人没事找事去受虐。

我觉得要搞团建，就需要明确本次活动的目标。如果是为了增加团队人员之间的协作，就没有必要搞团建，平时一起做开发任务，就是最好的锻炼协作。如果是在增加不同团队之间的协作，搞一些团建项目还是很有用的。如果是为了放松，缓解团队压力，那么一起吃吃饭，唱唱歌，打打牌，打打游戏，或者不占用周末时间的旅游。如果为了促进沟通，专门开茶话会，话题随便聊，增加相互了解。

薪酬

薪酬的重要性不言而喻，业内一般是固定薪酬的月薪和几个月的年终奖，有的还会有项目奖，大公司或者有潜力的公司会给核心员工分配股票期权。

 多数开发人员的主要收入是固定薪酬的月薪，为什么不像其它行业采用好像更有激励效果的绩效工资为主呢？首先，因为软件开发是复杂且高度协作的，个人的绩效很难量化，效益滞后明显，不能像工厂里面的工人简单地通过计件来算，也不可能像销售那样通过明确的销售额来算，所以很难采用绩效工资，这是最关键的原因。其次，软件开发具有一定创造性，并不是简单重复的，因此，需要在相对稳定轻松的环境下才能具有更好的创造力和效率，而像每个月高频率的绩效压力反而会让工作效率下降，这也是为啥很多公司的绩效考核周期为 1 年，最短的也就半年的一个重要原因。

年终奖能提高团队的稳定性，降低离职频率。一般的软件企业的年终奖是 1 到 3 个月薪资额，基本是在招聘时约定好的。大的互联网软件企业年终奖可高达 6 个月，但一般是根据绩效考核结果浮动具体额度。项目奖也是比较常用的奖励方式，在项目立项时最好能规划好整个项目的奖金额度，从而对项目团队起到激励作用。如果项目周期太长，超过 一年的就不适合项目奖金制，还不如年终奖。如果项目周期短频快，也会存在类似绩效工资的问题。不管怎么样，考核绩效发奖金，不可能让团队的每个人都觉得满意，高频率这样反而不利于整体团队的稳定和工作效率。对于多数软件团队而言，项目奖制要慎用，更适合那些很紧急重要的项目使用，年终奖方式更合适。

股票期权是个长期激励机制，能更好的激励和留住核心人才，有条件地给予激励部分股东权益，使其与企业结成利益共同体，从而实现企业的长期目标。如果公司股票价值不太好，很多人不认可，还是干股更加合适。现在一些小公司经常使用股票期权套路，不但没有让参与的员工获得收益，反而还被套牢。还有的公司，对购买股票期权的，比没有的，调薪幅度和奖金明显更低，因为股票期权让员工付出购买成本，绑定得更死，不能轻易离开，所以可以少给一些其他方面的福利。当公司信用有限或前景不明朗时，最好采用干股方式激励。

建立合理的岗位薪酬等级，良好的调薪制度，不形成薪资倒挂，紧跟市场薪资水平，保持竞争力。一般的公司会根据工作经验，技术能力建立大致的岗位等级和薪酬范围，例如分为初级、中级、高级、资深，每个等级再细分为上中下，每年根据绩效和成长的技能由研发经理组织做一次评估调整。

岗位等级薪资每年要根据市场进行调整，否则，薪资逐渐失去竞争力，引起团队的不稳定，而且也必然形成薪资倒挂，相同能力等级岗位的新招的比老员工高得多。有许多公司的薪酬倒挂情况严重，一方面是因为本身薪酬体系复杂，衡量标准不够清晰，导致调整到市场薪资程度有一定的滞后性，另一方面即使发现了，也不愿意主动调整，毕竟薪资倒挂的后果是逐渐发生的，只要这个过程付出的代价小于总体调薪的成本还是划算的，所以很多公司到了许多老员工甚至核心员工离职时才会引起重视，从而进行调整。但我认为，从研发角度而言，从离职交接再到招聘新员工适应融入，整个成本很高，并且严重影响整个团队的积极性，应尽早采取措施来避免。

怎么知道市场薪资标准？首先，可以通过在招聘新员工时获得，根据被面试者的能力和期望，进行一些统计，可以得到参考的薪资标准。其次，在招聘网站上查看，搜索岗位技能，浏览给出的薪资范围，以做参考。最后，可以问问从事该行业的朋友，了解现在的薪资市场。结合以上多种途径，就可以判断团队内实行的薪资标准是否调整和怎么调整。

薪酬调整建议一年固定一个时间段去调薪，一般是年底做完绩效考核后，把年终奖和调薪一起做完，频率高一些可以一年调薪两次。不要像有些公司只要员工不向老板提涨薪，就从不涨薪，由于软件开发人员很多比较内向腼腆，不会主动寻找涨薪，而是直接跳槽，那时候再谈加薪就很被动了，得不偿失。当然，调薪不是涨薪，虽然多数会调高，但也会根据绩效不调，甚至下调。不管采用什么调薪方案，做得再公平公正，也不可能让每个人都满意，所以首先确保让核心员工满意，其次尽量让主要员工满意。

调薪结果出来后，需要团队主管和每个人进行单独沟通。绩效沟通和调薪沟通一定不要放在一起进行，肯定先是绩效沟通，然后根据绩效确认的结果，才开始启动调薪的流程，所以绩效和调薪沟通有一定的间隔时间。并且绩效先进行沟通，可以使得的调薪期望更合理，后面再沟通调薪和奖金的结果就更加自然。调薪沟通中，如果发现对方对调薪结果不满意，就问问对方的期望和原因，然后尽量进行详细解释，并重点说明要达到这种期望，新的一年你应该在工作中做到什么，有什么改进等等，好让对方知道实现途径 。

薪酬是做好工作的下限，是必要条件，不是充分条件。薪酬没有竞争力，其它方面做得再好，也很难把人才留下。有竞争力的薪酬，在工作中遇到困难或委屈时，还能坚持继续。例如，维护老旧腐化犹如屎山的代码，严重的加班，领导的严苛，开发人员无论多么不情愿，但一想到现在拿到的是市场上很难给到的高薪，大概率就会坚持下去，相反，如果是低薪的，肯定不干了，华为的狼性文化就是以高薪为基础的。只靠高薪是不足以激励人们长期高效地工作的，由于人性中的适应性，调薪后无论多么满意，它给你带来的喜悦和激励，一般就持续一周，顶多也就在一个月后完全消退。因此，要进行长期激励高效工作，还需要其他更多的因素：明确的工作目标和任务，开放的沟通和反馈机制，有价值的工作内容，公平公正的管理，良好的团队文化和氛围，提供相应的培训和发展机会，公开的表扬和肯定，节假日福利等等。

绩效考核

 上面多次说过，软件团队要做好绩效考核很困难，因为软件开发工作是高度复杂的，很难只用量化指标来衡量。以下是主要原因：

1. 缺乏标准化指标。不同的公司或项目可能会有不同的标准和需求，因此很难制定通用的绩效标准。即使是在同一公司或项目中，由于问题复杂性和技术栈的不同，绩效衡量标准也会有所不同。 

2. 程序员工作类型多样。程序员从事的工作涉及的技术领域广泛，包括代码编写、测试、维护、协作以及解决问题等等。因此，绩效衡量需要考虑这些不同的方面，并权衡它们的不同重要性。 

3. 质量与数量难以平衡。程序员的主要工作是编写高质量的代码，而不是单纯完成任务量。而高质量的代码往往需要更多的时间和精力，有时会导致其任务量较少，但是对整个项目的贡献却不可忽视。 

4. 个人因素影响较大。绩效评估不仅需要考虑代码质量，还需要考虑个人的其他因素，如工作态度、工作效率、团队合作能力等。这些因素都会影响一个人的绩效评估，但很难量化和标准化。 

5. 开发周期长。在开发项目中，由于开发周期较长，所以需要通过中期目标来衡量绩效。但是，由于需求和技术随时可能发生变化，中期目标的制定和衡量也会变得复杂。 

虽然无法量化，但可以定性，定性的结果也够用于调薪和奖金。虽然短时间的工作，无法给出准确的绩效，但随着一年时间的积累，每个人绩效的差距就显著了，也都能形成基本的判断。考核的主要方面可以分为：工作量、质量、团队合作和沟通能力、工作态度。

工作量以评估者自己为标准，把被评估的人员一年内完成的任务，换算成自己来做大概需要花多少天，不同任务的难度加一个系数相乘，然后得到累计的一年的工作量天数。再根据对应等级程序员应有的工作量，做一个比较，定性地评估出优、良、一般、差。

质量则通过平时反馈的缺陷率，检视代码时看到代码质量，根据对应等级程序员应有的质量，做一个定性的判断：优、良、一般、差，总结一下优缺点。

 团队合作和沟通能力，从与其合作的同事、项目经理及其主管中得到反馈，做一个定性的判断：优、良、一般、差，总结一下优缺点。 

工作态度也做一个定性的判断：优、良、一般、差，并总结说明。工作态度的主要考虑方面为：1. 责任心，程序员需要对自己的工作负责，尽可能地避免出现错误，确保代码质量和项目进展；2. 自我激励，程序员需要热爱自己的工作，不断学习和探索新的技术和工具，以提高自己的技能；3，执行力，程序员需要有很好的执行力，按时按质完成工作任务；4，耐心，程序员需要有耐心，面对复杂的问题和工程，不轻易放弃，持续努力探究解决方案；5.敬业精神，程序员需要具备敬业精神，积极主动地解决问题，并为公司和团队的发展做出贡献；6.高效率，程序员需要有高效率的工作能力，优化代码和工作流程，将完成时间缩短，提高工作效率。

 根据以上方面的评估结果，再综合评估出总的绩效。其中工作量和质量占的比重最大，最少占到 70%，一般工作量和质量考核差不多，其它方面的考核也不会差的，这四个方面都会相互影响的。不可能出现工作量优秀，但工作态度、协作沟通能力很差的情况。如果任何一个方面的评估是差的，总体绩效结果就是不合格。 如果在工作量、质量评估优秀，其余的任何一个方面是优秀的，那么总体评估一般也是优秀的。总体的良好和合格酌情评估。

依据上面的绩效评估机制来组织考核，具体流程如下：

1， 让大家写年度总结，主要内容是自己今年做的任务，取得的成绩，提升的工作能力和明年计划。

2， 把写完的总结发给团队所有人，让大家查看，这样既起到了相互监督避免不实信息，又能让大家提前根据绩效评估机制做出一个初步的评估。

3， 组织大家开会一起评估绩效，每个人轮流讲解自己的年度总结，有不清楚的地方，其余同事可以随时打断提问，当一个人讲解完成后，大家也没有疑问，就开始所有人依据上面的绩效考核的四个方面，对这个人给出绩效结果和详细的评价，对实在不了解的方面可以写无，自己也要写自己的考核和评价。在写考核时，大家要保持一定间距，相互做好保密，避免干扰。每个人都被评估完后，收上所有考核评价。

4，在最终考核时，参考大家给出的考核评价信息，重点参考与之合作密切人员、项目经理和被考核人自己给的绩效评价，做一下综合分析，给出最终考核结果及评价。主管一定要有自己的思考和分析，不能用简单的对每个人的加权运算得到结果，每个人对其他人的评价都有局限性，需要主管判断其合理性。

5，把考核结果和团队中的项目经理再次评估。项目经理对人员在项目中的表现情况很了解，也为了支持项目经理管理好项目，也必须让项目经理有一定的话语权，因此需要再次认真听取项目经理的意见。

6，绩效考核的结果和评价发给领导，对领导有疑问的地方详细解释，听取领导意见，再修改，直到认可。

7，和团队成员进行绩效沟通。沟通时，先说绩效结果，然后再说评价，对好的一面鼓励，肯定其价值。待改进的方面提出具体改进措施。再询问对方意见和建议，具体的问题给出解释。在沟通过程中，对待团队成员需平等对话，尊重他们的意见和思想，听取他们的反馈和建议，避免一味地批评和指责。 大多数情况下，这种绩效的认可度还是比较高的，毕竟也有对方自己参与考核，也知道是大家一起做的考核，误差应该不大。 如果成员对某些考核不认同，但的确有理，并能影响到考核结果，那么该纠正就纠正。

离职

不管怎样，团队成员总因各种情况要离职， 面对离职，得有个正确的态度。有许多主管，面对离职，很生气，觉得不应该。或者很冷漠，既然要离职，没必要关注了。又或者，现在离开影响很大，所以想尽办法挽留，挽留后再找人代替，能代替后，就不再重用，迫使离职等等。 我觉得，离职人员对曾经的工作基本是负责的，交接也是正常的，那么他离开我欢送，他留下我欢迎，也欢迎后面再回来。如果留下，那么表示已经解决了不稳定的因素，和往常一样对待。如果无法挽留，则做好交接，办理好离职手续，离开时公开感谢工作上的付出并表达祝福。这样后续有啥需要协助的也方便，同时也让团队的其他人感觉到宽容、融洽，在离职时也更有利于说出真实原因，从而更好的挽留。

在面对离职事宜时，首先是要进行离职沟通，得到真实原因。再根据原因判断，如果值得挽留则好好沟通，不值得挽留也知道了问题所在，尽量避免类似的情况。 有些情况下，不愿意说出真实原因，说一个合情合理的借口，例如不好意思，或者图省事不想多交谈。平时如果团队气氛融洽真诚，面对离职时都是友好的，那么多数情况下还是愿意说出真实原因的。如果是假的理由，不断追问沟通，就会发现难以自圆其说，从而可能使其说出真实理由。然后，再判断是否要挽留，只要其绩效还可以，说的理由有可能解决还是尽量挽留的，毕竟换新人成本很高。即使不想挽留，也要说一些挽留相关的话，让对方感觉到重视，方便做好交际相关工作。 如果确定要挽留，对方说的原因是误会，则好好解释，消除误会。如果工作任务问题或不符合职业规划的，则尽量给其调整一下任务，安排符合他职业规划的任务。如果是找到了下家，给出的原因就是要为更高的薪资，换个不同的软件公司从而学得更多等等，那么详细了解一下新公司的情况，站在对方，真诚根据他的目标帮忙分析一下相关的利弊，看看是否合适？如果是更好，那么问问对方什么条件可以留下，最后对方给出的条件不过分，符合现有软件团队薪资结构和能力范围，则向领导申请，当然条件差一点点还可以再谈谈，没有问题后就可以留下。如果给出条件从团队现有情况来看不可能满足，或者的确新公司更有利于他的发展，那么就祝福对方，然后开始沟通安排交接细节，尽量交接得越快越好，知道的人越少越好，避免对现有人员的心理干扰。 离职的人员，可以再建一个微信群，帮他们加入进来，可以随时了解一些软件市场情况，也算一个人力资源的维护。

在我的实践中，没有因离职时挽留下而不久又提出离职的，和以往一样在好好工作。即使离职了，工作中有什么问题，也能很好的咨询和支持。有的离开我们团队一两年后，又想加入，成功加入后，他们比其余人员更加稳定，并且有些成为了团队核心。

辞退

团队管理中，对一些违规人员，屡教不改，或长期不能胜任工作人员，最终要走向辞退。或者，有些人员给予了很多帮助，实在无法跟上公司和团队的发展。或者，团队发生重大调整，不再需要一些人员时。对于后两种情况，要好好沟通，做好解释和安抚，按照劳动法给予补偿。对于第一种，往往要做好更多的前期工作，尽量避免到辞退的地步。

对一些不是很严重的违规情况， 像不服从合理的任务安排，或上班偶尔摸鱼等工作态度的事情，可以给三次机会。第一次私下谈谈，描述一下看到的违规的事实，询问对方原因，需要帮助的给与帮助，如果是不能谅解理由，则给予警告，避免下一次。第二次还是发现类似事情，沟通后，没有另有隐情的，则通报批评。第三次，则进行劝退，充分说明原因是按规定办法，尽量让其认可，否则就得辞退。除了项目特别紧急外，人力不够，不得不容忍一段时间后，安排好了相关替代人员后，再进行劝退。其余情况尽量不要容忍，及时沟通解决，否则会影响整个团队效率，危害甚大。不过一般经历了上面严格招聘、试用，再加上良好管理和日常沟通，一般很少出现这样的情况，如果出现了多沟通沟通，一起来解决。如果实在解决不了，工作态度无法改善，还是要当断则断。

总结

软件开发复杂、高度协作、创造性强，因此软件团队的管理也更加复杂。以上从人员层级划分、定期沟通、团建活动、薪酬、绩效考核、离职及辞退方面做了分享，但实际当中还有更多因素，不同的公司规模，业务场景，开发模式，对应的团队管理也有不同的方法，希望自己的分享能够给大家启发。