摘要

　　软件项目管理中的人员管理活动是一个内闭环管理的过程，本文这个活动过程，就几个方面：组织架构、梯队建设、任务调度、信息沟通和绩效考核进行了分析，介绍了一些项目管理中实际使用的方法和工具，并对这些方法进行了总结。

　　浙江联众卫生信息科技有限公司 李武胜

　　一、 前言

　　孙子兵法有云：故校之以计而索其情，曰：主孰有道?将孰有能?天地孰得?法令孰行?兵众孰强?士卒孰练?赏罚孰明?吾以此知胜负矣。翻译过来的意思就是：所以按原理对战争的情形进行分析：君主是否英明?将帅是否贤能?谁占有天时、地利?谁装备精良?军队是否训练有素?谁赏罚公正严明?根据这些便可知胜负。总结起来说，就是强调了天时、地利、人和这一直被认为是成功的三大因素的重要性。

　　如果把足球场上的比赛理解为一场战争，我们也可以找到类似的情况，作为足球王国的巴西，其国家队相对来说不上场雨中比赛，可以认为是“天公不作美”，玻利维亚把主场设在了2000米的高原上，搞得对手一个个未上场先衰了三分，可以说是“地利有三分”，而号称无冕之王的荷兰，多年来由于存在苏里南球员和本土球员之间的更衣室矛盾一直无法在国际大赛上获得满意的成绩，则可以认为是“人和”上面存在大问题了。

　　还是足球比赛，世界杯、欧洲杯等比赛的小组赛中，从规则的角度出发，为了鼓励进球，采用了三分比赛制，而为了鼓励客场进球，在计算小组排名时，客场进球价值要比主场进球更有价值。为什么，我想一定程度上是因为“主场球迷可以被视为主队场上比赛的第12名队员”缘故吧。

　　由此可见，作为最流行的团队竞赛项目的足球比赛中“人和”真的真的非常的重要。同理，同样作为团队运作的项目，在软件开发项目管理中“人”的因素也极为重要，因为项目中所有活动均是由人来完成的(至少目前。所谓的“机器编程”还没有实现)，对于项目的成败起着至关重要的作用。

　　搞清楚什么因素能够促进团队和谐、激励团队斗志，什么因素导致团队内杠、丧失动力，并能够针对存在的问题对症下药，是每一个合格的项目经理必须具备的能力。

　　二、 项目背景

　　联众医院信息系统VER3.0(以下简称HIS3.0)是浙江联众卫生信息科技有限公司(以下简称浙江联众)综合和提炼了省部级大型医院、县市级医院、乡镇医院等300余家业务流程和管理思路的精华，以及近10年医疗行业信息化咨询和项目实施的宝贵经验，而精心设计打造的新一代大型医院信息协同平台，是针对我国大中型综合性医院管理需求和未来医院集团化发展趋势而组织开发的现代医院数字化整体解决方案。HIS3.0覆盖了医院的门诊、库房、住院和临床四大块日常业务，子系统包括信息集成平台、门诊挂号收费、住院收费、医生站(门诊、住院)、护士站、药库房、临床电子病历等20个核心系统和自足服务终端、分诊台、制剂室等20个辅助系统，另外还有辅助开发平台、需求管理系统等项目组内部日常工作管理工具。

　　HIS3.0目前已经在北京协和医院、吉林大学附属一院/二院、江苏昆山中医院、浙江绿城医院等多家医院实施。在这些医院的实施过程中，我们遇到了医疗改革地区发展差异和医院管理地域差异所带来的一系列问题，例如医保的地区化、报表的个性化、发票本地化、操作个性化等。而浙江联众对于HIS3.0的要求是核心产品化，比如针对医保地区化的医保交易接口标准化、医院外设差异对应的外设接口通用化等。如何解决项目运行过程中发现的问题和平衡存在的矛盾?blog.mypm.net

　　为了更好的组织HIS3.0的开发和实施工作，解决HIS3.0产品化开发目标和个性化医院需求之间的矛盾，浙江联众专门组建了HIS3.0项目组作为常设组织，从产品部、临床开发部、质保部和工程部抽调了精兵强将充实到这个项目组中。换一句话说，HIS3.0项目组是一个跨部门的大型项目组织，很大程度上项目组的工作与各相关部门的工作密切交织。

　　从目前的人员配置情况来看，HIS3.0项目组在不包括工程实施力量的情况下，有开发人员18人、产品人员5人、专职测试人员6人。岗位设置方面包括项目经理1人、开发经理1人，开发组长4人，测试组长1人，产品组长1人。加上分公司的二次技术力量，总的开发技术力量将近40人。

　　三、 我对谁负责，谁对我负责

　　盟文章其实标题还应该有一句，我应该做什么。

　　作为一个软件开发项目队伍的管理者，最不愿意看到的就是整个项目组的工作处于一种无序紊乱的状态之中，大家都不知道自己要做什么，自己和团队的其他成员要怎么协作。

　　根据HIS3.0团队的特点，我们建立团队组织架构、岗位职责说明和事务处理机制来进行团队管理和事务管理。

　　HIS3.0团队的组织架构如下图表示：

　　在上图的各个小组中，我们设立了小组长这一角色。通过上表，团队所有的成员可以一目了然的知道自己的工作关系。

　　为了明确每个角色岗位的工作职责，我们制定了每个觉得工作职责范围，HIS3.0团队的角色职责如下图(部分角色职责已经列出)：

　　项目管理者联盟文章

　　为了理顺HIS3.0开发过程中的工作流程，我们把整个开发划分为：需求、设计、开发、测试和实施5个大环节，并制定了环节之间的工作关系，以HIS3.0的发布过程为为例：

　　通过诸如此类的明确流程定义，每个团队成员都清楚的知道每个事务的处理需要按照什么样的流程，处在自己上游的环节和需要自己支持的下游环节。

　　无论是老话“一个萝卜一个坑”，还是借助流行的供应链进行解释，我们的组织机构建设的目标是：每个团队成员都清楚自己的角色和职责，整个团队都在向共同的目标努力。同时我们的每一个团队成员都需要接受一个观念：完成自己的本职工作，你只是一个合格的成员，只有超出团队对你预期的完成工作，你才是一个优秀的成员!

　　四、 养儿防老与寅吃卯粮

　　冯小刚的《天下无贼》中，贼头葛优有句大家津津乐道的经典台词：“21世纪最重要的什么?人才~~~~~~~~~~~”。什么是软件公司的核心竞争力，究竟是市场营销还是产品，我觉得都很重要，但是一点，这些都是要靠人来完成的。所有，我们认为软件公司里人是最重要的，毕竟软件公司的核心产品都是靠这些人才一点一点编写出来的，没有好的软件产品，终究会被市场淘汰。

　　软件公司在人员管理方面遇到的一个最大的问题是人员流动问题，曾经在一家公司遇到过，由于内部矛盾，一个项目组的核心技术团队全部出走，导致项目的完全停顿，最后不得不放弃，公司蒙受数百万的损失。

　　HIS3.0目前还遇到另外一种情况，由于公司在发展过程中的策略失误，好几年没有招聘新人补充到研发队伍，近年来因为发展需要，招聘了大批新毕业的大学生。整个团队的人员就是一个典型的哑铃模型，一边是有7、8年工作经验的少数核心，有技术有经验，而且都处在团队的关键位置，但是都结婚生子了，精力和干劲明显呈下滑趋势;另一边是新毕业的大学生，年纪轻，精力旺盛，但是技术和业务方面比较缺乏，完全培养起来需要一个长期的过程。这种哑铃模型潜在极大的风险，因为如果新人尚未成长起来，老员工要走，可能导致某个系统的迭代停顿。

　　为了降低风险，项目组采取了两个办法：一方面提高老员工的待遇，同时要求老员工负责新人的带领，实现技术经验和业务知识在实战过程中的传帮带，另外一方面，为了防止关键业务知识掌握在个别人手中，我们要求所有的岗位都建立AB角机制，例如门诊收费和医保接口，保证同时对于关键业务能够同时有两个以上的人员掌握。为了老员工的工作状态，调动积极性，我们还在公司的支持下，根据员工的个人职业规划，组织参加外部培训，参加国家相关部门组织的重要的、有价值的认真考试，做好老员工的后续职业发展的支持。

　　制定有规划的人才招聘计划，建立金字塔型的人才梯队，配合完善的人才培训机制，我们建立了一个稳定有序和良性发展的人才队伍，为HIS3.0的发展打下坚实的基础。

　　五、 重视我们作出的承诺

　　暴雪公司毫无疑问是世界最好的游戏公司，其游戏的玩家遍及全世界。魔兽争霸系列、暗黑破坏神系列、星际争霸系列、魔兽世界，暴雪出品在全球游戏圈内大名鼎鼎、如雷贯耳，“暴雪出品，必属精品”这也是在广大游戏玩家中的不破真理。然而，为了暴雪公司为了游戏的精益求精(别和微软掺和在一起)，几乎每个暴雪游戏的发布时间都被推迟(俗称跳票，或者叫放鸽子)，一些玩家甚至诙谐的说：“游戏界最大的谎言是什么?暴雪将按时发布!”。

　　但是，HIS3.0的客户不是游戏玩家，而是医院，负责救死扶伤的医院。我们系统将直接影响医院业务的开展，不仅仅是每日数十上百万的收费，还涉及成千上万的来医院求医问药的病人。因此，浙江联众非常注重给医院的发布周期承诺，HIS3.0的每个项目组成员都10分清楚的知道每个版本的发布周期和需要升级的医院。HIS软件的专业性要求我们重视自己的承诺，并具备严肃的责任感。我们不相信这种观点：软件业的不同之处在于，让软件开发人员彻底的坚守自己的承诺是不可能的。我们更加倾向于：不要强迫团队成员作出领导所希望但是看来却不现实的承诺，否则任务真的无法按时完成的时候，受伤害的是整个公司。

　　在制定发布计划时，我们会先确定一个内部发布日期和外部发布日期，外部发布日期提交给我们的客户。然后从已收集确认的BUG和需求列表中进行筛选，筛选的原则是根据重要性和紧迫程度而二维表如下图分析取得：

　　根据上表定出所有的需求优先级之后，我们制定内部发布范围，其中部分必须完成的形成外部发布范围告知客户。

　　当遇到肯能导致无法按时发布的问题是，我们的第一选择是，通过任务的再分配，变更任务的执行者。在HIS3.0这样大型的团队中，开发人员由于能力上的差异，有的开发人员能够提前完成自己的工作，此时，可以把别的工作量过大的开发人员的任务分解一部分出来，安排给工作已经完成的开发人员，大家互相配合，保证发布计划的完整执行。

　　当发布过程中确实遇到可能导致无法按时发布的任务时，我们还可以采用裁剪计划表的做法，就是宁可放弃原定的某些新功能，也要保证版本的按时发布。裁剪的顺序是从D到A的反向。在变更发布清单之前，对于已经告知客户的外部发布范围的事项，我们一般通过与医院协调的方式来达成谅解。

　　我们给每个团队成员经常贯彻的一个观点是：一个人的完美工作不代表项目组整体的完美工作，项目组赢得的每一个客户赞誉是对每一个团队成员工作的最好嘉奖。

　　六、 心有灵犀一点通

　　如果说软件开发是一个沟通的博弈，那么项目的进展速度与要化多长时间才能把信息从一个人的头脑中传递到另一个人的头脑有关。项目成员要化多长时间才能发现公司中对他有用的信息?客户的需求需要消耗多少能量才能传递到每个成员呢?这个沟通活动又消耗了我们多少时间和金钱等成本呢?在信息传递的过程中，我们怎么保证没有被曲解?我想每个项目经理都需要认真考虑这些问题。

　　唐朝诗人李商隐在《无题》中留下千古名句：“身无彩凤双飞翼，心有灵犀一点同”。虽然事实上人与人、人与组织、组织与组织之间无法做到这一点，但并不妨碍软件开发团队对于改善沟通的要求，在HIS3.0团队里，沟通的方式很多：邮件、QQ、文档、会议、面对面交流等等。我们对于沟通的要求是：即时、准确、高效率、低成本。什么样的场合采用什么样的沟通方式需要因时因地制宜(不合理的使用沟通方式一方面造成资源浪费，另一方面还有造成工作失误)。

　　即时沟通

　　在HIS3.0项目组中，为了提高团队成员信息交换的速度，项目组在日常工作制度中做了明确要求：在工作环境许可的情况下，所有的团队成员每日工作开始必须先开启邮件并保持邮件的畅通，所有成员的QQ都加入项目组专门的QQ群，简单的消息统一在QQ群里发，重要的消息一律要邮件;所有成员的手机无比要求保持开机状态。

　　准确传递

　　在某个娱乐节目中曾经看到，主持人给出一块白板写上某个词，例如“跳舞”，台上的参与者一个接一个用形体表达试图传递给下一个参与者，每次都了最后一个，总会出现风马牛不相及的结果，这就是一个沟通过程中信息失真的问题，在软件开发中，来自客户的需求信息失真的情况也是有发生，结果严重浪费了有限的资源，甚至造成严重的工作失误，给公司造成不可挽回的损失。

　　为了提高沟通的准确度，我们希望记录文档，但是书写详细的文档向来遭到普遍开发人员的抵触，一是书写文档乏味枯燥，二是由于一的原因，没有认真书写的文档，可读性差，利用价值大打折扣，三是没有同步更新以前书写的文档，利用价值更低，更加让人迷惑，甚至有误导的风险，这点属于普遍性问题。

　　为此，我们引入XP编程中简略文档(Minimal Documentation，指开发过程中不必书写很详细的文档，只要书写较少关键性的文档就可)。例如，来自于客户的需求，一般只需要把需求场景，客户实际业务操作，同类软件的实现等信息描述清楚即可，而BUG则描述怎么操作产生，便于开发人员快速诊断，而开发人员完成事务的时候，需要填写修改说明，描述修改的位置、涉及的变更、需要编译哪些系统等。所有的此类信息可以邮件附件发送、或者附件在测试管理平台URTracker，或者配置管理工具SAW中。项目管理者联盟文章

　　“好记性不如烂笔头”，有了文档，哪怕再简陋，也比后来事后纠缠于理解错误是如何发生的要好。

　　提高效率

　　软件开发项目最重要的沟通形式是召开会议。开会是每个软件项目团队都需要经常做的一件事情，HIS3.0日常也需要召开很多沟通会议，比如项目组全体会议、阶段总结会、进度与计划报告会、项目协调会、小组周例会等等。如何提高会议沟通的效率，我们一般有三点建议：

　　一、明确会议主题，别扯远了;

　　二、确定参与人员范围，别把不相干的人也扯上;

　　三、尽量采用站立式会议(尤其是时间很短，议题不多的例会)，人站着精神和注意力要好，而且不用安排会议室椅子之类杂七杂八的事情，多快好省办实事!

　　信息辐射源(Information Radiator)是在一个人们经过都能看到的地方显示信息，而看图总是最简单直观的显示方式。HIS3项目组采用大白板作为项目组的信息辐射源。在项目组集体办公室的墙上，我们放了一块白板，把它一分为二，一边清楚的给出了HIS3.0的内部发布计划和版本发布范围中需要修改的需求。不干胶便签(黄色便签)，一个便签上写一个需求，把它们先都放在左面，每修改好一个需求，以产品部确认为准，把修改好需求的便签移到白板的右面。这样项目组成员都很清楚目前进度，已经修改了多少需求，还有多少需求没有修改，如果遇到有计划外的需求要添加进来，可以用红色的便签或绿色的便签(取绿色通道之意)。如此一目了然，非产清晰，大家也都时刻清楚整个项目的进展状态。

　　降低成本

　　沟通的成本包括直接成本和间接成本，直接成本比较好理解，就是为了沟通某一个问题所花费的资金，例如安排产品工程师现场调研客户需求，需要花费的差旅费和出差补贴，开发人员和工程人员电话沟通某个问题需要花费的公司电话费等，医院系统切换现场人员的每日用度，等等。

　　在昆山中医院上线期间，项目组派出的人员合计将近40名。现场切换系统运行初期，我们在院方的支持下，统一使用对讲机进行联系，极大的方便了现场沟通(以前医院上线，大家都是靠打电话，容易占线)，而且成本也很低(大家的电话可都是漫游的，省钱了)

　　间接成本则是沟通过程中花费的产地、时间等需要进行折算的费用。下面是我们的一个间接成本的折算例子：

　　假如一个程序员每分钟的成本为1元，在解答问题时多花1分钟，那么就会增加1元的项目成本。一个开发人员站起来走到产品工程师跟前，来回2分钟，就会多增加2元成本。我们二号楼营销中心人员到一号楼八层，来回一次假定是10分钟(因为等电梯的时间较长，需要等4次电梯，二号楼下来一号楼上去，一号楼下来二号楼上去)，一天有多少个人次呢?假定20人次(来开会、财务报销、盖章、协调等)，那么增加200元成本，一年工作天数是220天，一年增加成本44000元，不算不知道，算了吓一跳。

　　为了降低成本，除了前面提到的普遍采用邮件和QQ联系方式，我们还对项目组成员的办工场地及座位安排进行了专门安排。比如，项目经理坐在最显眼的位置，大家抬头就都可以看到，所有的小组采用四角合围的方式安排在一起，方便彼此的沟通。产品组安排在团队的中央位置，因为开发人员找他们的可能性最大，而质保部安排在一个独立的区域，便于安静的开展测试。合理的人员座位安排最大可能的降低了目前的沟通成本。但是有时项目成员多，一个办公室坐不下，或不得不采用分布式开发，如沈阳分公司的开发人员，有没有好的解决方案呢?澳大利亚的Cha rles Herring运用技术来模拟“在场和知晓”：人们坐在同一建筑的不同地方，他们的电脑上有话筒和网络摄像头，在屏幕上有一些小窗口。显示着来自其他人的摄像头的画面。他们想要给每个人一种“他们坐在一个组里――在场”的感受，并且能够知道其他人都在做什么。因为思想不必通过空气来传播，而是可以通过感觉(主要是听觉和视觉)来传播，通过技术模拟出信息对流的效果。当然，这一技术不能模拟触觉和动觉。我们准备在下一阶段采用上述办法来增强远程沟通的效果。

　　七、 人是要吃饭的

　　前两天有个开发人员请假了，他老婆要生了，我们都打趣他说，“兄弟你这下子没机会喝酒吃肉了吧，省着点给女儿买奶粉吧!”，那仁兄回了一句，“只有等公司加薪了!”。

　　我想起了另外两句话，一句是“革命不是请客吃饭”，另一句是“人是铁，饭是钢，一顿不吃饿得慌”。这是软件开发公司遇到的人员薪资问题的常见问题的形象说明。

　　在同一个开发团队里，最好的和最差的程序员(或者说有经验的和刚毕业的)其生产效率的差距可以达到数10倍之多，然而在传统的薪酬体系里却没有一种能提供如此大范围的薪水差距。但是如果不能很好的叫绝这个问题，问题非常严重，轻的话会造成项目组内成员间心理不平衡导致的工作对立情绪产生，重的可能会导致项目组的人员剧烈变动，甚至项目组的破裂和项目的最终失败。项目管理者联盟文章

　　该如何平衡这种差距呢?我们认为：一些与薪资相关的问题，其实是工作分配或者开发技能的问题，可以尝试通过将薪资、技术等级以及工作难度三种进行搭配，通过量化评估，建立一个比较合理的薪资体系。如下表所示：

　　在上表中，我们发现，8中非理想状态中，仅有一种可以通过增加薪资解决，有5种不需要调整薪资，但需要调整技术水平和任务难度来回到平衡。剩下的两种需要调整任务难度或技术水平，同时调整薪资。因此很明显，在这8中不良的情况中，调整薪资能够药到病除的只有区区三种。

　　通过归类所有的团队成员，我们对每一类员工都需要设计出不同的个人发展计划和薪资策略，通过分析薪资、能力和任务矩阵，最终朝着双赢的目标调整，效果相对来说比较合理。但是不要错误的理解成任务的分派是以薪酬等级为标准，实际上薪酬对分派任务没有直接影响，理想的薪酬应该是优化的任务分派的结束。我们的目标是是所有的团队成员都处于双赢的核心位置，并且保持他们一直处于这个位置。我们要关注的是员工的个人发展计划与他们的薪资水平之间的耦合关系，关注于能够帮助我们更好的维持和发展团队。提高团队成员生产率的有效做法。

　　八、 结束语

　　有的人把软件开发视为一门艺术，那么项目管理就是一门管理艺术家的艺术了，我们的人员不会留着大胡子、长头发以显示自己的个性，但是如何把这些充满才华横溢而又个性迥异的IT技术人员组成一个团队，发挥每个人的优点和特长，像机械的齿轮一样密切咬合协同工作，使整个项目组象一个捏紧的拳头一样，确保软件项目按计划稳定运行，是软件开发项目经理的核心工作。