个人体验~软件开发中的项目管理

个人体验~软件开发中的项目管理

广西工学院

软件开发中的项目管理

姓名：

罗鑫

学号：201*0201*072班别：计Y052班指导老师：唐新来

广西工学院

一、引言

软件开发是人类大脑智慧的结晶。软件项目开发是以人为根本，离开了人软件开发就无从谈起。并且软件开发涉及到的不是一个人，而是一个集体。一群人要做事，而且要做好事，就得有人管理。有道是：一只狮子领导的一群羊，要比一只羊领导的一群狮子更加有战斗力。所以说，一个团队的战斗力归根结底要看领导者的领导和管理能力。

这次软件测试的论文，我就软件开发中的项目管理谈谈自己的心得和看法。我有幸有几次在学校合作开发软件项目的经验。虽然说那不是商业项目，但是好歹也是学校科研处立项有经费支持的大学生科研项目。分别是《网状结构的描述、应用与研究》《排序结构算法的对比、研究、应用》《基于局域网的存储网格研究、应用》。前两个项目以及基本完成并且结项，后一个项目刚刚申请。我在其中担任的角色是，组长，组员，组长。虽然项目不大，但对我一个学生来说还是一个挺大的挑战。

二、初识软件项目管理

我最初关心软件开发过程的项目管理是大二的上学期，那时候正是我决定锻炼自己，接学校一个科研项目的时候。我有幸成为该小组的组长，下面带个几个水平不错的同学一起进行软件开发。第一次担任组长的职务很不适应。以前自己写代码野惯了，没有太多和别人合作开发的经验，所以开始的工作不知道如何开展，很乱非常乱。大家在一起讨论了几次开了几次会，都是泛泛而谈没有什么实际成果。万事开头难，我们只能在前期的一个月到两个月进行基础知识的补充。我也在这段时间中，开始致力于学习项目管理。到图书馆翻了很多书也了很多项目理书籍，但是当时根本都不懂也不理解。我就觉得书上写的应该比较对吧，所以一看到好的东西就断章取义的来用，来实践。很不幸后来我所实践基本都失败了。积累了一段时间基础知识后，我们小组算是正式开始工作了。但是小组的组织还是像以前一样无序。大家各种都在忙着自己的事情，而作为组长的我也不能有效把大家聚集起来。组内人心不齐，各种的水平有参差不齐。并且在其中还有一种怪气氛，技术如果不能压住别人的话，没有办法树立作为领导的权威。这点我深有体会作为一个组长威信不够、底气不足的话，是无法让大家信服的。大家各种都按自己的意见来办，意见根本无法统一。当然也根本无法进行协作开发。似乎这个问题也是很多开发小组的无奈，同时我也担任着软件实训的一个小组的组长。没有威信工作根本无法展开，特别是遇到一些很有个性的人，那就是更加倒霉的事情了。

所以为了确定自己的威信和权威，我将精力从软件管理中分开了而专注于软件模型的开发，这段时间我打法我的组员进行基础知识的积累和学习。经过自己的不懈努力，我自己终于做出了软件模型，在得到指导老师的肯定后。之后的小组开发我就基于这个模型来做。同时也算树立了自己的威信和权威，开始了一些很初级的分工，就是我需要什么函数，就要别人帮我做。这样我的小组才渐渐的开始算做合作起来，跌跌撞撞，惨不忍睹。在那年的暑假原来很多人的软件小组，最后也才剩下4个人了。一场激情过后的惨淡，剩下漫长的暑假重复做这编码、调试、编码、调试。经过我们不懈的努力，终于在结项的前几日完成了项目，补齐了各种软件开发文档。一场乱仗就这样结束了。

虽然项目得到了指导老师的肯定和系里头的肯定，但是我却认为这次项目还是失败了，最大的失败就是没有能够协同开发。原因有三：

广西工学院

1、分工不明确。

谁做需求、谁做设计、谁管理、谁写文档基本上都是乱的。要不没有人做、要不都是我自己做的。整个项目做下来我完成了超过80%的代码，70%的文档。我可以一点不客气的说、整个软件基本上都是我一个人在做。如果从作为程序员这个角色来看，这无疑是个荣耀，一个成果。但是我作为一个软件小组的组长，出现这样的情况是严重的失职和失败。且不说组长大材小用了，组员们那些大批人力资源白白浪费掉了，毕竟一个人的精力是有限的，项目做完同时也让我身心疲惫。

2、交流严重不足。

分工不明确有很多原因。其中一个原因是因为我和我的组员交流不够，组员与组员之间的就更加缺乏交流。缺乏交流的所导致的严重后果是，我不明白组员们的想法，组员们不明白我的想法，组员于组员之间都不知道对方在做什么！初步的分工后，各种写各的代码，且不说编程风格了，光是变量和函数的命名在代码集成的时候都可以要人命。各自有各自的一套命名习惯。很多变量和函数的作用原本是相同的，但是因为命名的原因就不得不花很多的精力来检查和修改，极度的浪费时间和资源。而且由于交流的不足，我做代码集成的时候，很多人的代码根本都无法集成进去，我不得不重新自己来写过。

3、文档完全无用。

可以说从项目开始到测试完成，都没有产生任何文档。文档是在最后要结项的时候补的，这样的文档完全无用，完全失去了做文档的意义。文档的作用就是用来指导和驱动软件开发的，现在我们做的文档完全是为了“做文档”而去写的。

三、从另外一个角度看软件项目管理

我的第二次的学校的科研项目课题是《排序算法的研究应用》。这次是我班的龙国力同学带队的。我作为组员加入其中，担任该项目的软件设计人员。在参与这个项目的同时，我同时从组员的角度来看软件开发的项目管理，并且从中总结学习经验。

这一次项目开发，我是组员，当然轻松很多了。我可以把时间放在设计软件的框架上面。从一开始我就明确自己作为一个设计员的责任和任务。项目开发有点磕磕碰碰，但是都是技术上遇到的困难。在整个软件开发上有条不紊的进行着。这主要是得力与龙国力同学的领导，还有一点就是我作为组员的积极配合。我们小组的组长的有权威，我和其他组员都很信服。同时我作为组员积极的配合组长进行工作的展开，经常交流，经常反应最新的情况。这次项目的分工很明确，组长考虑到各个组员的水平不一。所以在分配任务的时候充分的考虑了这一点。组长：龙国力负责软件的界面框架设计、实现、各种排序算法的整合。组员：罗鑫负责软件内核框架设计和实现，并且辅助界面框架设计。其他组员：分别负责各种不同类型的排序算法的实现。在小组例会的时候，把我以前小组遇到过的问题和大家交流。会议一般都是由组长组织，每次开会都有明确的会议内容和这阶段的分工明细。会议的时间也不长，很有效率。

对比之前我带的项目，这次无疑比上次成功了很多。我之前带的项目基本上是自己做、没有明确的分工、缺乏与组员之间的交流、我的想法也无法到达下面的组员、组员的想法也很少反映到我这里。所以项目一做下来，累都累死人。这次我是作为组员加入项目的，我认识到如果组长不分配任务给我不明确我的任务的话，我作为组员就不知道应该如何做起，也

3

广西工学院

就一直无所事事了。所以组长为了充分利用我们各个人的特点，对我们进行了任务分配，明确我们各种的任务，这样大家就有了努力的方向。同时作为组员我也充分的配合组长的工作，积极和组长交流，明确自己任务的同时也尽量的帮他分担相应的工作。组长就可以更加专心的致力于对软件开发的进行全局性的规划。.

这次项目我作为组员得到以下几点体验：1、相信和支持组长。

相信和支持自己的组长。论他的能力是否比你差，你都要去支持。毕竟每一个人的都是有自己擅长的一面和不擅长的一面。软件开发的组长，是一个团队的核心也是一个团队的灵魂。作为组员应该支持和信任自己的组长，支持并且主动承担一些工作，这样组员于组长之间有了良好的合作气氛，对软件开发百利而无一害。2、明确自己的能力、工作和职责。

船没有导航的设备是无法遨游于大海之上的，人也是一样，程序员也一样。如果没有具体的工作和明确的职责，人就无法展开工作。到头来只能这做做那做做，最后一事无成。别人眼里头看看来此人就是在消极待工。3、及时反馈进度。

组员和组长总会意见出入的时候，组员无法确切的理解组长的意思，组长也无法确切的了解组员的进度。经常出现组长想做个飞机，组员却做成了坦克。组员这时候又不得不返工，浪费人力也浪费时间。所以要及时的反馈自己的进度、根据组长的意思及时修正、最大限度的满足组长提出的要求、同时也减少自己返工重做的次数。

同时我从组员的角度看软件项目管理，我有以下心得：1、组长要相信自己的组员。

作为组长要敢于善于听组员的意见，也要敢于善于把重任赋予别人。要充分的营造一个和谐的合作气氛，减少组员和组长之间的沟通阻碍。2、分工要明确。

组长要根据个人的能力进行分工，明确组员们的任务、职责和完成时间。尽量把工作摊开来，让自己能够很专心的对整个软件开发进行规划，掌握全局。3、任务跟踪。

对于每个组员分担下去的任务，要及时检查和纠正。定期召开例会，检查和跟踪当前的项目进度。

四、初试锋芒

经过前两次的项目之后，自己逐渐有了一点点项目管理的经验了。我自然的就迫不及待的想在具体的项目中进行实践。所以我又去唐老师那里接了一个项目《基于局域网的存储网格系统的研究于应用》这个项目刚刚申请，还没有完全启动起来。同时现在正好进行清华IT的实训，我接着担任一个实训小组的组长，我的组员就是本宿舍的人。分组没有找到想要的合作伙伴，但是好歹本宿舍还有一个两个不错的合作伙伴。一开始

4

广西工学院

拿的牌不算太好，甚至有点烂。我就在思索如何把不好的牌打成好牌。

宿舍都有些问题人物、懒、游戏、什么都不管、实训也不参加。对于这些人，我只好放弃，他们能进来做事那最好。不能的话就算了，反正我的底线是他们不能影响到整个实训的项目开发。

我开始对我的小组做了以下工作：1、角色分配。

通过对每个人的性格，水平，人缘进行相关的分析和思考后，我将我的组员们进行角色分工。分为两组：软件开发设计组（组长：吴天柱）软件测试小组（组长：李海强）。选定这两个人为小组组长是有原因的，吴天柱：有一定的项目开发经验并且和我合作过、相当值得信任并且有很强的责任感。所以我让他担任设计开发组长，通过他来督促和管理他该组的组员。李海强：没有太多的开发经验，但人缘很好责任感强。所以我让他担任测试小组的组长，通过他督促和管理该组的组员。

2、任务分工。

我将各个任务肢解，对两个组长分配大任务，并且限定完成任务的时间。两个组长得到的都是比较大的任务，所以他们就得再次分工，把具体的工作分配到各个组员身上。同时我也限定了每组组长必须在限定的时间内上交想要的文档。这样从上到下就把任务分配下去了。

3、营造协作环境，付重任与人。

为了营造这种交流环境，我把交流协作的中心放在两个小组的组长身上。通过他们两个为中心进行交流。对于软件的需求分析和软件结构的设计，我只是提出自己的设想和方向，规定一些必需要达到的要求。首先让我的两个组长理解我的基本要求，然后让他们在保证我的基础要求之上，自己进行具体的设计和规划。最后在将他们的设计进行再分工。这样他们就有了充分的自由发挥的空间。这样就有了一定的弹性空间，让大家的意见能够充分的整合在一起。

4、规范文档驱动软件开发。

从实训开始，我就严格的安装整个软件开发的流程一步步往下做。每一阶段都会有相应的文档产出，同时文档一直在迭代在修改。我们小组在做需求分析的时候，需求分析文档经历过3到4次迭代，来适应新的需求变化。文档的页数从原来的20多页一直增长到最终的40多页。同时各种计划和分工统统文档化，项目计划，某阶段的项目分工，等等都统统以文档的形式记录和传达。文档记录了过去一阶段的工作成果，同时也指引我们未来的工作。

5、人员危机处理。

实训小组可能出现的最大危机，就是人员危机。参加实训的人的积极性，一天比一天下降，从原来都去听课，到现在很少人听课。这一点我在组队之初，就考虑到了这一点。整个实训项目的进度不能因为几个懒惰的人而中止，所以我在角色分配的时候给有责任心的人，赋予重任就是这个原因。实训进行下去到最后，必然就是那几个有责任心的人撑到最后的。至于对其他那些人，能鼓励就鼓励他们多参与，若不能的话，就随他吧。不可能为了几个人，而耽误其他有心学习的人的实训。

5

广西工学院

目前我们实训小组的现在正在概要设计和详细设计阶段。前一阶段所做的工作，产生相应的《需求报告说明书》《项目计划》都得到了实训老师的肯定和好评，小组有条不紊的继续前进。我相信我们认真的坚持做下去，会有很大的收获的。

五、结语

以上的一些感想和体会，都是通过反思和总结这一年多来的我参加的各种学生科研项目和实训中得到的。可以保证文章完全的真实性，虽然我所想的和专业的软件项目管理还是有很大很大的差距，但是那也是我通过很多次的实践得到的。其中也经历了很多劳累和心酸，毕竟这是通过自己努力得到的东西，在我自己看来还是弥足珍贵的。

扩展阅读：软件开发项目管理中的人员管理

软件开发项目管理中的人员管理联盟会员：李武胜（blueicesoul）原创发布时间：201*-11-5点击：7521PMB：0【收藏本文】摘要软件项目管理中的人员管理活动是一个内闭环管理的过程，本文这个活动过程，就几个方面：组织架构、梯队建设、任务调度、信息沟通和绩效考核进行了分析，介绍了一些项目管理中实际使用的方法和工具，并对这些方法进行了总结。浙江联众卫生信息科技有限公司李武胜项目管理培训一、前言孙子兵法有云：故校之以计而索其情，曰：主孰有道?将孰有能?天地孰得?法令孰行?兵众孰强?士卒孰练?赏罚孰明?吾以此知胜负矣。翻译过来的意思就是：所以按原理对战争的情形进行分析：君主是否英明?将帅是否贤能?谁占有天时、地利?谁装备精良?军队是否训练有素?谁赏罚公正严明?根据这些便可知胜负。总结起来说，就是强调了天时、地利、人和这一直被认为是成功的三大因素的重要性。如果把足球场上的比赛理解为一场战争，我们也可以找到类似的情况，作为足球王国的巴西，其国家队相对来说不上场雨中比赛，可以认为是“天公不作美”，玻利维亚把主场设在了201*米的高原上，搞得对手一个个未上场先衰了三分，可以说是“地利有三分”，而号称无冕之王的荷兰，多年来由于存在苏里南球员和本土球员之间的更衣室矛盾一直无法在国际大赛上获得满意的成绩，则可以认为是“人和”上面存在大问题了。转自项目管理者联盟还是足球比赛，世界杯、欧洲杯等比赛的小组赛中，从规则的角度出发，为了鼓励进球，采用了三分比赛制，而为了鼓励客场进球，在计算小组排名时，客场进球价值要比主场进球更有价值。为什么，我想一定程度上是因为“主场球迷可以被视为主队场上比赛的第12名队员”缘故吧。由此可见，作为最流行的团队竞赛项目的足球比赛中“人和”真的真的非常的重要。同理，同样作为团队运作的项目，在软件开发项目管理中“人”的因素也极为重要，因为项目中所有活动均是由人来完成的(至少目前。所谓的“机器编程”还没有实现)，对于项目的成败起着至关重要的作用。搞清楚什么因素能够促进团队和谐、激励团队斗志，什么因素导致团队内杠、丧失动力，并能够针对存在的问题对症下药，是每一个合格的项目经理必须具备的能力。二、项目背景联众医院信息系统VER3.0(以下简称HIS3.0)是浙江联众卫生信息科技有限公司(以下简称浙江联众)综合和提炼了省部级大型医院、县市级医院、乡镇医院等300余家业务流程和管理思路的精华，以及近10年医疗行业信息化咨询和项目实施的宝贵经验，而精心设计打造的新一代大型医院信息协同平台，是针对我国大中型综合性医院管理需求和未来医院集团化发展趋势而组织开发的现代医院数字化整体解决方案。HIS3.0覆盖了医院的门诊、库房、住院和临床四大块日常业务，子系统包括信息集成平台、门诊挂号收费、住院收费、医生站(门诊、住院)、护士站、药库房、临床电子病历等20个核心系统和自足服务终端、分诊台、制剂室等20个辅助系统，另外还有辅助开发平台、需求管理系统等项目组内部日常工作管理工具。bbs.mypm.netHIS3.0目前已经在北京协和医院、吉林大学附属一院/二院、江苏昆山中医院、浙江绿城医院等多家医院实施。在这些医院的实施过程中，我们遇到了医疗改革地区发展差异和医院管理地域差异所带来的一系列问题，例如医保的地区化、报表的个性化、发票本地化、操作个性化等。而浙江联众对于HIS3.0的要求是核心产品化，比如针对医保地区化的医保交易接口标准化、医院外设差异对应的外设接口通用化等。如何解决项目运行过程中发现的问题和平衡存在的矛盾?为了更好的组织HIS3.0的开发和实施工作，解决HIS3.0产品化开发目标和个性化医院需求之间的矛盾，浙江联众专门组建了HIS3.0项目组作为常设组织，从产品部、临床开发部、质保部和工程部抽调了精兵强将充实到这个项目组中。换一句话说，HIS3.0项目组是一个跨部门的大型项目组织，很大程度上项目组的工作与各相关部门的工作密切交织。从目前的人员配置情况来看，HIS3.0项目组在不包括工程实施力量的情况下，有开发人员18人、产品人员5人、专职测试人员6人。岗位设置方面包括项目经理1人、开发经理1人，开发组长4人，测试组长1人，产品组长1人。加上分公司的二次技术力量，总的开发技术力量将近40人。三、我对谁负责，谁对我负责项目经理博客其实标题还应该有一句，我应该做什么。项目经理圈子

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

根据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、文档、会议、面对面交流等等。我们对于沟通的要求是：即时、准确、高效率、低成本。什么样的场合采用什么样的沟通方式需要因时因地制宜(不合理的使用沟通方式一方面造成资源浪费，另一方面还有造成工作失误)。

即时沟通

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

项目管理者联盟准确传递

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

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

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

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

blog.mypm.net提高效率

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

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

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

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

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

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

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

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

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

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

bbs.mypm.net七、人是要吃饭的

前两天有个开发人员请假了，他老婆要生了，我们都打趣他说，“兄弟你这下子没机会喝酒吃肉了吧，省着点给女儿买奶粉吧!”，那仁兄回了一句，“只有等公司加薪了!”。我想起了另外两句话，一句是“革命不是请客吃饭”，另一句是“人是铁，饭是钢，一顿不吃饿得慌”。这是软件开发公司遇到的人员薪资问题的常见问题的形象说明。

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

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

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

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

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

友情提示：本文中关于《个人体验~软件开发中的项目管理》给出的范例仅供您参考拓展思维使用，个人体验~软件开发中的项目管理：该篇文章建议您自主创作。

来源：网络整理 免责声明：本文仅限学习分享，如产生版权问题，请联系我们及时删除。

《个人体验~软件开发中的项目管理》由互联网用户整理提供,转载分享请保留原作者信息,谢谢!
链接地址：http://www.bsmz.net/gongwen/722202.html

• 上一篇：招聘岗位职责说明与要求(1)
• 下一篇：软件项目开发工作流程