程序高手——管理决策案例讨论

某中型计算机软件开发公司之程序设计人员约有三十人，是以项目方式编组的。换句话说，这些人是依公司接案的情况，机动划分为若干个小组，案子结束后，又再重新编组。由于人员流动及各人成长的差异性，他们间的功力水平大不相同。虽然都有定期的进修课程，但或是因为时问压力，或是因为个人学习潜力，成长的情形并不很好。

L、P、O三位是大家公认的高手。其中，L、O两位不太爱帮助同仁解决问题，而P先生则心地较好，几乎是有问必答，有时为了怕讲解太多，耽误了自己的进度，甚至干脆加夜班帮别人完成工作。然而这样一来，自己的体力、时间、工作进度，甚至于家庭生活都受到影响。而L、O两位由于不太协助别人。人缘虽然不如P，但绩效比较好。个人的学习与成长也比较快。因而上级对他们两位的重视程度也日益提高。

P看到这样的结果，颇有倦勤、另谋他就之意。资浅同仁听说此事，纷纷力图挽留，甚至联名请上级出面来留住P先生。

问题
问题出在何处？你对公司高阶有何建议？

心地好的P先生帮助同事，属于个人在组织中的自发行为，同时这些自发性的行为并不包含在工作契约与正式的职位要求之中，符合组织公民行为的定义，P先生付出了很多努力，却不像LO两位受赏识，被认可，双因子理论中的激励因子未被满足，P先生比较自己和LO的回报/付出，觉得不公平，产生了公平理论中的“认知失调”和离职的想法。LPO三位公认高手是组织的创造竞争优势的重要「战略性资源」。软件公司的工作设计可参考行为学派，工作不是个人绩效考核规定的既定的，员工Y理论，工作可以再设计，加入“做中学”的培训内容以配合高成长需求的员工。

P先生是一位程序高手，具备高手的技术，同时也有其外向，注重人际关系，先人后已的性格特质。同时关注职业整体特性和个人性格有助于我们更好地分析个案和找到激励P先生的方法。

资浅新人同事们的提问，影响到了P先生的体力、时间、工作进度，甚至于家庭生活。最后的联名挽留反映出P先生的人缘，但也可能触发高层的忌讳。可以认为是P先生困境的直接原因，但新人在正常流动的公司总会存在，新人的能力如何快速达到工作的标准，是要在组织层面回答的问题。我建议调查甄别联名挽留的资浅同事们，如果大家求助P先生的工作内容确实自身能力达不到，则调整项目组工作安排，安排更简单的工作或者专门安排导师讲解。如果求助P先生的工作自身可以完成，则惩罚。

P是否好员工的关键取决于对个案材料中他是否完成了自身工作的理解，“怕讲解太多耽误自己进度加夜班帮助别人”似乎是完成了工作，但从下一句“自己的体力、时间、工作进度，甚至于家庭生活都受到影响”来看工作进度是受到影响的。软件团队高手和新人的工作效率可以相差10倍以上，安排给高手的往往是有难度的，项目关键的任务，P先生帮助资浅同事完成初级任务拖累分配给自己的关键任务，我认为不是一个好员工。当然，如果从项目集成，帮助资浅同事防止拖累项目的角度来看，P先生是为项目做出了额外贡献的。从商业伦理角度看，不应提倡帮助同事影响家庭生活。从LO两位的绩效比P好来推断，帮助资浅同事应该是影响到了P自身工作的。

在个案中软件团队，我认为是最差的团队成员决定团队绩效，软件项目是拆分任务给团队成员，最终集成到一起交付给客户，整体可用项目才是合格的。P先生帮助资浅同事，实际是默默地为项目做出了很大贡献的。P是一位组织公民中的给予者，但作为编程高手并不意味着他也擅长程序员的管理和培训。时间管理，沟通技巧和项目管理能力是P先生缺乏的。因此我认为可以挽留P先生，在沟通中理解P的委屈，认可他的付出，但不是改变他过往的绩效或做升职加薪，而是要点出P在工作上的不足与错误之处，为他安排3种培训：1）重要紧急4象限的时间管理，评估出自身工作和他人求助内容的工期和成本，优先完成自己的工作进度后，再在力所能及的范围内帮助他人。2）帮助他人时授人以渔，注重启发思路传授方法，而不是包干代办。3）合理拒绝的沟通技巧。让P觉得自己在组织中的未来是有希望的。

考虑改变个人和团体激励措施之间的平衡。在这个软件开发团队中，工作的成功需要员工紧密合作、互相协作，属于程度最高的交互式互赖，在团体激励措施上放更大的权重。以项目整体的成功来做考核，而非单人任务的完成情况，是有利于P这种类型的员工的。从软件管理者的角度来看，为了避免吃大锅饭，出现资浅同事滥竽充数的问题，往往会倾向于把任务拆得更细，比如新人要问问题可以创建工单，方便P的这部分帮助工作计入业绩，也有利于进一步分析改善新人提问的质量。这里需要说明的是仅做一个提问的记录，P的解答不一定仅在线上，也可以是线下。

从团体动力学的群体内聚力方面来看，P先生的善行有助于形成互相帮助的团队氛围，提升群体内聚力，增强了关系导向型同事对团队的归属感，因此资浅同事会在P萌生去意时试图挽留。管理者在做工作设计时总是更倾向于通过对事的工作说明书和对人的工作规范不断细化，想要掌控所有的工作内容。但在实操中，所有的工作内容很难穷尽，或者说考核所有工作内容的成本很高。这就需要在团队内鼓励为了项目成功而做出份外工作的P先生的行为。

P先生与资浅同事们属于社交性高，团结性低的网络组织文化类型。大家如同亲人，互相关怀帮助，但可能存在对于绩效差的资浅同事放任容忍，以及联名挽留时让管理层忌惮的组织政治问题。LO两位不太协助别人但绩效较好，公司绩效的导向是重视个人工作，属于社交性低，团结性低的孤岛文化。建议通过加大集体考核比例，重视培训和知识留存等方式将组织文化向社交性高，团结性高的自治文化方向转化。

新进人员的水平参差不齐，建议在招聘阶段设置准入的最低标准，保证新进人员的水平是在一定水准之上的。成长的速度因人而异，涉及学习潜力和教导方法，建议在新人转正阶段设置门槛，淘汰个人学习潜力不达标而拖累P先生的。软件项目的工期往往给定期的进修课程造成时间压力，建议公司对进修课程的实际效果做评估和调整内容。整体而言，软件开发是一门实践性很强的技艺，在实际项目中锻炼，“做中学”是很好的方式。没有长期计划，仅考虑短期生存的组织不需要培养员工。

直接雇佣程序高手是一个可行的选项，但出于团队梯队结构，市场招聘难度和成本的考虑不一定能做到。这也跟公司战略和市场地位有关，谷歌微软字节腾讯这样的高利润，用户量大的公司会直接雇佣程序高手，个案中的中小软件企业很难做到。导师制度是很好的建议，导师的绩效受其所带新人的业绩影响。每个人不一定是好老师，也不是应该做好老师，而是应该给大家选择不做导师的权利。LO两位不太协助同事，可能是当前绩效制度的引导，也可能是本身的性格或者兴趣不在这里。

建议类似MBA学生选择毕业论文导师，形成一种双向选择程序员导师的机制。导师选择适合自己教导方式的新人，新人选择口碑好的导师。P先生是高手，人缘好，熟悉同事特点，可以在按照公司结案不断成立的临时小项目组中尝试架构师的角色，划分项目结构，按照项目组成员现状特点拆分任务，以及解答难题。如果该公司的新人培训工作做得好，在业界形成口碑，可以吸引更多优秀的候选人，形成良性循环。

如果我是一名接受P帮助并且希望挽留他的同事，我会找到自己的上级，举出项目上具体的案例和数字，力陈P先生对项目和组织的但未计入他本人绩效的贡献，建议改进现有的绩效制度。与资浅同事们约定好互相帮助，遇到大家都解决不了的问题再去求助P先生，让P有空做好个人任务和兼顾家庭生活。与P先生沟通规劝，保障自身工作进度之外再去帮助他人。联名挽留P反而可能引发管理层对P的猜忌，起到反作用。只有到最后关头，其它方式都没用的时候，才可以用这一招。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！