项目经理手册

项目经理更多的是管理的工作:

•团队构建

•领导力

•执行力

•时间管理

•压力管理

•结构化思维与表达

•有效沟通

•有效的演讲技巧

•六顶思索帽

光明

象徵物

阳光

幽物

建段性YSI

代表

桑薇

悲嘏

可找假他

等找利益超免缝

象徵物白纸

2一象徵物

中立

雌

代表六IR思考帽代表客m

6ThinkingHats提供信息

表逢梯f目摞

象微物树木

天空.、象徵物

代表器黠

控制

指抑

创出新意

解决周期H檄

VL18Sep04

软件工程项目管理是一个系统工程,软件工程项目管理的主要目标是保证项目在规定时

间内高质量地完成。项目管理包括了项目组开发各阶段的人员结构的配置，质量限制的实施

方略，内部文档和产品文档的组织编写等多项工作,其中质量限制方法具有软件开发的特点。

项目开发依据进度分为需求、设计、开发、测试等各个阶段，质量保证工作始终贯穿各

阶段，同时又必需依据每个阶段特点实行相应的措施.

需求分析

从系统分析的阅历来看，这个过程往往是个按部就班的过程，一次性对系统形成完整的

相识是困难的。只有不断地和客户领域专家进行沟通确认，方能逐步明白用户的需求。从系

统开发的过程得知，系统分析时犯下的错误，会在接下来的阶段被成倍放大，越是在开发的

后期,订正分析时犯下的错误所花费的代价越是昂贵,也更加影响系统的工期和系统的质量。

在具体项目中，一般的做法有两种：一是请该领域内专家参加到系统开发的早期阶段；

二是开发系统原型，原型包括功能性的原型和用户界面性的原型，也可以是二者混合的原型，

用这些原型确认用户的需求。

监督支配

依据监督支配安排相应的资源来保证某阶段的开发质量。分析阶段的监督支配会在分析

任务之前被项目经理、项目负责人、系统分析员以及技术支持所了解。为保证分析工作高质

量进行，同时又不被过分打搅，质量监督组则主要针对《系统分析报告》进行复审，并在认

为的确有必要的状况下才召开质量狂审会说。质量狂审会议的主要参加者是项目经理、项目

负责人、分析人员和质量监督组组长。会议主要是对质量质疑，给出改进建议即可。具体是

否存在质量问题、是否须要改进，不在会议中进行探讨，以此保证了会议参加的人数较少,

会议的时间尽可能短。

系统实现，实现也就是代码的生产过程。生产的类别有组件的生产，构件的生产，应用

系统的整合，以及各种测试用例的生产。为了能够提高生产的质量，应将生产的程序人员按

职能分成两组，也就是说假如某个程序员生产了某个组件，则不能再由该程序员来生产，但

他可以生产其他组件。这样交叉生产更简洁发觉组件存在的问题。

测试指标

测试人员依据各项指标提出测试报告。指标分别包括如下几点：软件的正确性，正确性

测试主要是测试软件的功能是否被正确地实现。测试的方式主要是依据功能的要求依据给定

的输入，看是否有给定的输出，在非标称输入时，输出是否异样等。同时也可以测试软件的

功能是否实现或完整实现。

性能指标：该项目对性能的要求非同•般的软件项目。性能测试往往包含了压力测试、

攻击性测试等测试，软件所能承受的极限是多少，一般来说，软件的极限应当高出用户要求

的性能，各种指标也应当为用户所了解。

易用性：软件的运用界面在设计时，应当设法使之与功能的实现相脱离。脱离的缘由在

于易用性是通过友好的界面实现的。然而让开发人员以运用者的角度，来确定软件是否易用

是件特别困难的事情，在确定运用界面时，往往须要多次反复修改，甚至只能在软件的最终

交付之前或用户运用一段时间之后才被提出来。

需求变更管理

需求变更管理是web项目管理中最重要的一个环节，需求变更管理的有效性干脆影响项目

的成功与否。

对待变更的看法：

1、变更是不行避开的。

2、变更必需被管理。

3、主动发觉引起变更的因素，促使变更尽可能早的出现，减低变更带来的风险。

需求变更管理的目标：

1、相关的干系人必需清晰地了解发生的变更。

2、变更处于有效的管理中。

3、尽量降低变更带来的风唆。

通过制定需求变更的流程，确保项目中的需求变更有效地进行，实现上述的目标。

需求变更流程：

1、确定需求的基准线。

通常我们会以UserCase作为需求基准线，在UserCase确认之后的任何需求变更，都须要走

需求变更流程。没有走需求变更流程的需求将不被认可。

2、首先项目经理接收到需求变更的要求。

需求变更的提出者可以是项目中的任何人包括产品经理、客服、开发人员、测试人员等。

3、项目经理评估该需求变更。

项目经理可以召集相关人员探讨该需求变更的合理性、可行性，实施的代价以及对项目的影

响。

项目经理作为项目的负责人，对项目的成功负有主要的责任。所以需求变更的决策者应当由

项目经理担当。

4、需求变更确认后由专人将需求变更记录下来（格式如下），通知给项目中全部成员。其中

以下人员对需求的变更是紧密相关的，他们必需知晓并认可此需求变更。包括（客户方代表，

需求分析师，测试人员，相关开发人员）。

需求变更表的格式：

序号

变更提出时间

变更描述

变更类型（是对原有需求的修改还是新增需求）

缘由

变更提出者

开发人员

对进度的影响（工作量）

5、相关人员接收到确认的需求变更后，做以下事情。

需求分析人员修改需求说明书和UserCase的相关内容。

测试人员修改测试用例的相关内容。

开发人员修改代码中的相关部分。

6、需求冻结

项目越到后期，需求变更对项目的影响就越大，所以在肯定时候我们会进入需求冻结阶段,

不再接收需求的变更。

1是否须要变更，做出推断

我的文章中提到：项目经理收到变更申请后，项目经理可以召集相关人员探讨该需求变更的

合理性、可行性，实施的代价以及对项目的影响。

2假如须要变更，会产生那些影响，做出相应的变更支配，包括可能影响的项目范围，进度，

费用，质量等支配

我的文章中提到；项目经理可以召集相关人员探讨该需求变更的合理性、可行性，实施的代

价以及对项目的影响。

对于确认的变更，会有需求变更记录表来描述该变更，当然你说的变更支配应当是特别全面,

但对于web项目要求的时间性考虑，我觉得一张表格也可以说明问题，简洁明白。

3确定变更的负责人

需求变更的决策者应当由项目经理担当，具体的操作者是SQA来担当，比如基线限制，变

更记录，通知相关人员。我的文章中有遗漏，没有明确这个人的角色。

5依据变更后的支配实施项目，并进行检查

对，变更后的实施反馈没有在我的变更流程中，这一点我是有考虑，但想到大部分需求的变

更最终都要经过测试环节，所以我就没特地提到。变更后的实施反馈还是比较重要的，我想

还是依据项目的实际状况对这块裁剪比较好。

web项目经理手册•项目经理须要牢记在心的话

1、项目经理不是来管人的，而是来支持人的。

解析：不光是项目经理，任何经理的职位都是如此。但现实中很多人并不是那么做，

这也是为什么他们没能把项目做成功的缘由。作为项目经理首先要端正看法，相识到这份工

作职贡的本质。

2、好的起先是成功的一半。

解析：一个好项目的失败，往往是由于前期的打算不足、支配不周密。所以在项目初

期要舍得花时间做前期的需求收集、探讨、技术打算等工作。尽管前期的工作看起来并没有

干脆产生效益，但这块工作做好了，后面的工作往往会事半功倍。否则前期打算不足，很可

能导致项目出现各种各样的问题：比如大量的需求变更等）。

3、什么样的项目最可能成功？答案是：项目越小成功的可能性越大。

解析：项目经理和相关人员要细致评估项目中feature的成本/价值比，尽可能缩小产品

的规模。

有时候项目经理可能变更不了整个项目规模，但是项目经理可以采纳各种手段来“缩小〃

项目，比如分期进行、迭代开发等。

4、任何对项目的改善无关的工作都是奢侈时间。

解析：在项目过程中项目经理不要做表面工作，或者对项目本身无意义的工作。比如无

休止的会议；要求编写具体而最终没有用处的文档。

5、运用者的参加是项目成功的重要保证。

解析：运用者可以是：产品经理、需求方代表、或者客户。

在项目的各个阶段，项目经理要主动要求运用者参加到项目过程口。通过这种与运用者

不断的沟通、反馈，使得最终做出来的产品是客户真正想要的。

6、不要认为把任务交给团队成员，期间你可以不闻不问，到了完成的时间他自然会把任务

交上来。这种想法是特别错误。

解析：这样做无疑会增加项目的风险，很简洁出现该完成的任务没有按时完成，有些延

误，这样项目后续的工作都会收到牵制。

正确的做法是：当把任务支配下去后，你要定期和成员沟通完成的状况，询问是否须要

支持，这样我们才能保证任务能按时保质的完成。

7、沟通要诀：项目过程中与相关人员沟通时，不要总认为对方的动身点都是从项目利益考

虑，他/她肯定先考虑个人利益或部门利益，所以项目经理要做的是：如何把对方的个人利

益（部门利益）引导到和项目利益一样。

8、“加班”是一个危急的信号，表明肯定是某个地方出现了问题，要找出进度落后的缘由。

9、项目起先前，项目经理肯定要找出项目的决策者是谁，谁对项目的产品有最终的发言权。

10、我们交付的不是程序，而是产品和服务。

web项目经理手册-风险管理

风险管理是web项目中项目经理最重要的工作之一。风险管理是一个持续的过程，贯穿

于整个项目过程中，风险管理包括风险识别、风险估计、风险解决以及风险管理策略。

在实际web项目中，项目风险主要表现为以下状况。了解这些有助于项目经理在项目

初期就识别出这些风险，并实行措施避开或者削减它们的发生。

一、web项目风险列表：

1：需求变更风险：需求已经打上了基线，但此后仍旧有变更发生，对项目造成影响。

如何削减此类风险的发生？

（1）前期的需求探讨要具体、充分。需求文档中需求的范围要明确、功能描述要清晰。

(2)需求文档中要有demo。对于web项目，图片比文字更能说明问题。

(3)找出项目中需求的决策者(通常会是产品经理、相关职能主管、客服)，全部的需求要经

过他们的认可。

(4)客户在项目过程中的全程参加有助于降低此类风险。需求探讨、需求确认、UserCase确

认、测试阶段的客户验收等环节，都要要求客户参加。

(5)发生需求变更时，严格依据需求变更流程执行。

2、技术风险：开发过程中遇到技术难题，导致开发时间延迟或者需求不得不发生变更。

如何削减此类风险的发生？

在项目起先前的技术评估阶段，明确技术难点，提前支配人员进行攻克。假如在可预期

的时间内无法解决，可以要求需求方变更需求。

3、质量风险：对于web项目而言，质量风险主要指开发代码的质量c

如何提高开发人员开发的质量？

(1)、制定项目支配时，对开发时间的评估要尽可能的合适。合理的开发时间对开发质量的

影响很大。开发时间评估可参考【web项目经理手册-开发时间估算工

⑵、有一套严格可行的代码规范，编码时严格遵守，codereview时严格考核。

(3)、在编码前，开发人员要对框架娴熟驾驭。

(4)、•份好的系统设计文档对指导开发特别重要。

4、资源风险：项目所需人力资源无法按时到位，导致资源风险。

如何削减此类风险的发生？

这个就须要在项目支配制定的时候提前申请确认资源，并在项目过程中不断沟通协调。

二、项目风险管理的要点：

1、上述我们所说的风险管理都是指可以预期将要发生的风险，那些不行预期将要发生的风

险不属于风险管理的范畴。这也说明项目经理的阅历和学问对能否管理好风险至关重要。

2、具体明确的项目支配、以及项目执行过程中每个要点的质量保证是降低项目风险的必要

条件。

3、风险报告是项目团队以及领导了解项目风险的一个有效手段。

风险报告的格式通常是：

web项目中有很多项目涉及到跨部门、跨公司的合作o这类项目往往比其他项目更有挑战。

对于项目经理如何做好这些项目呢？

首先让我们看看这类项R都有哪些共同的特点。

1、合作双方工作在不同地方，对项目沟通造成肯定影响。

2、合作双方隶属于不同的公司或者部门，双方的项目开发流程可能完全不同，在项目执行

过程中须要考虑到这个因素。

2、合作项目须要双方共同完成，假如一方的工作进度出现延误，那么整个项目的进度都会

收到影响。

本人依据平常这类项目的实施阅历，总结一下这类项目要想成功，须要把握的原则。

1、合作双方的领导层必需都特别重视这个项目。剃头挑子一头热的项目成功的可能性不会

高。

只有这样，项目的优先级才有保证，这样在以后项目过程中一些资源(包括人力、硬件、时

间投入)更有保证，协作起来也会更加顺畅。

2、合作双方确定好各自的接口人。双方的沟通都通过接口人进行，这样可以降低成本，提

高沟通的效率。

接口人可以分为两类：一类是商业上的接口人，一类是技术上的接口人。

3、完备的文档(接口文档、数据库文档)必不行少。

web项目双方的合作在技术方面通常采纳API接口方式交互。所以项目前期具体精确的接口

说明文档特别重要，双方开发人员之后的开发都是严格依据接口进行。

同时接口的相对稳定也是特别重要的，所以须要前期设计的时候细致全面地考虑接口规范。

4、便利的沟通工具。

对于跨地区的合作，便利的沟通工具是特别重要的。当然工具最好是免费，比如运用IMo

从沟通方式的效果来看，我觉得面对面的沟通＞电话沟通〉EMAIL（o门M）。

5、接口变更的刚好通知。

这一点很重要，接口变更应当有流程来保证，特殊是对于这种成员分散在不同地方的团队尤

为重要。

6、前期技术方案的沟通。

前期技术方案的探讨以及接口的定义，最好能当面沟通，这样效果最好。所以前期最好去一

趟对方公司商谈这些要点。

7、各自开发环境的可访问问题。解决双方开发环境的相互调用问题。

合作双方联调的时候通常须要访问对方的接口。由于双方都在各自环境进行开发，所以须要

解决这种问题。

最好的状况是：可以访问对方的环境（外网）。

最大的风险是：没有可以联调的环境，等到发布到正式环境.上再测试，这时候时间上就有点

晚了，可能会遇到一些之前预想大到的问题。所以联调的时间越提前,问题就能越快暴露出

来，整个项目的风险就越小。

联调环境的稳定也特别重要。有一次我们发觉我们的功能有问题，代码跟踪调试，结果发觉

原来对方的环境有问题，奢侈了我们很多时间。

8、由于项目的各个点是相互依靠的，所以在一些关键点上要能按时提交，否则会影响对方

的进度。

在项目支配中要具体定义各个重要的里程碑，并严格限制执行。

9、项目进度报告。

定时相互通告项目进度，重点关注项目风险。

10、熟识对方项目开发的流程。

不同公司项目的流程、角色分工不肯定相同。只有熟识了对方项FI的流程，在与对方沟通时

候才能做正确的事情。所谓知己知彼，才能百战百胜。

千万不要自己闷头开发，完全不顾对方的做事方式，然后自己想当然他们应当和我们一样。

我们常说做好项目的关键之••就是做好“沟通”，但很多人只知道“沟通〃的重要性，却不

知道怎么做好“沟通〃，所以仍旧会有很多项目由于沟通未做好而导致项目失败或者有些缺憾。

"沟通”不仅仅是说话，不是说的越多沟通就越好。要做好“沟通”关键是清晰以下两点：

我们要和谁沟通，和他（她）沟通什么，怎么和他（她）沟通。

沟通的最终目标是：让被沟通的人明白你要传递的内容，并自觉执行好你希望他做的事情。

要解决好沟通问题，我们须要把握以下两个原则：

一、利益原则

利益原则解决的是"和谁沟通"的问题。

项FI起先阶段我们要识别出与项H有利益的人（即项目干系人），确定他们需求和期望，然后

采纳合适的沟通策略。

项目的干系人是指参加项目，或其利益在项目执行中或成功后受到主动或消极影响的个

人和组织。这些人是项目过程中须要着重关注的人群，很多项目出了何题都是由于忽视了（或

者是忘了）其中某些人。

项目干系人通常包括：

0项目发起人、出资方。（项目决策者）

0部门职能经理。（资源供应方）

0项目团队成员。（项目执行者）

0产品运营。（产品的运营者、运用者）

0客服人员。（客户接口）

为了更好地把握这一原则，我举荐项目经理在项目起先阶段运用以下表格。

序号项目干系人其对项目的主要期望在本项目中的利益程度

（H,M,L）对项目的影响程度

（H,M,L）与其沟通的策略

1

2

3

4

5

二、闭环原则

很多项目经理在实际沟通中经常会是这样的：某某某这个事情你做一下，或者发个邮件给某

某，期间也不闻不问，期望到时候那个人就会按时提交任务。这种状况往往会发生问题。

正确的沟通环节应当是一个闭环。具体的过程应当是这样的：

1、项目经理和项目干系人沟通事情，征询他们的看法。（双向沟通）

2、达成一样看法，确认action列表。（责任、任务落实到具体的人）。

3、执行过程中要跟踪执行状况，确认执行人是否须要帮助，同时有助于识别是否存在潜在

的风险发生。

4、执行结果的检查。

沟通结束前要留意总结、回顾，以及action,以确保沟通的效果。

三、良好的沟通技巧会有助于沟通。

1、当你不知道怎么给出建议，或者如何回答的时候，建议你采纳提问式的回答，比如“你觉

得怎么做会好呢？〃等等开放式的问题，这样有助于发挥大家的主动性，创建性，最终获得

良好的效果。

2、沟通过程中尽可能少的打断，不要匆忙下结论，不要立即针锋相对地驳斥对方。

3、要适当运用幽默。

3、主动地赐予反馈。

4、了解沟通者的风格，以便更有效的沟通。

四、沟通的表现形式事实上是很多的，绝不要局限在面对面对话，像会议、email等都是沟

通的具体表现。所以上面所说的原则和技巧都可以这些环节中采纳。

在项目中假如把握好上面所说的原则，再加上自身沟通的技巧，肯定会对项目的成功起

到特别大的帮助。记住和正确的人正确地做正确的事情。

1.不要丢失激情

人们在启动一个新项目时往往很简洁踌躇满志。但是要想在长期内都保持这种充足的精

力及激情却很难得。要知道，想有好的结尾，光有一个好的开头是不够的。

2.不草率

记住，您起先得越早，您完成得就越晚。在一个项目周期里，不适当的支配编制会让您

耗费过多的成本。不要因为压力的关系就匆忙起先，从而忽视了遵循基本的项目管理方法。

3.不要总说是

企图预先就排列好项目所具有的全部功能就好比是列好“烹饪”一个项目的菜谱，这个项

目必定会超过预算并且有一个负的投资回报率。要学会有所选择。这也算是一门艺术，而且

随着时间的磨砺，您在这门艺术上的造诣会越来越高。向项目赞助人展示必需的重要因素,

并且让他们知道您为什么想抛弃那些不必要的因素。通常表面上看起求小而不重耍的因素往

往会耗费您大量的时间和资金。

4.在政治冲突中不要偏袒任何人

保持中立。

5.不要忘了沟通

假如沟通不是您的强项，就在您的项目小组中找一个擅长这个的人。假如您总是忙于这

个项目的技术方面，那就很简洁会忽视沟通这件事了。确保您或您信任的某个人能与关键人

物保持沟通。

6.不要把错误的人支配在错误的岗位上

一个苹果就是一个苹果，即使您把它描成橙色或是在它上面裹上七彩纸。

7.不要让小组中的任何人透支体力

我们都必需在这或在那加班加点，但是千万别让任何一个人持续加班而没有休息。这样

会让人不健康。

8.不要找借口

假如您犯了一个错误（每个人都会犯错误），承认错误并刚好改正。

9.不要眼高手低

10.不要忽视问题

警惕小问题发展成大问题。一旦忽视了它们，您可能回头就陷入逆境。

11.不要遗忘心中的蓝图

我们必需在过程和资源之间保持一个微妙的平衡点。确保项目中全部的工作能在合适的

时刻汇合，并且达到项目所希望的最大目标，这是我们的职责。

12.别遗忘您的小组成员

记住让他们充溢斗志，并且刚好给他们充电。

13.不要把全部功劳据为己有

正如哈瑞・杜鲁门曾经说过的，假如您得不到别人的付出，您还妄想成功，这就犹如痴

人说梦。

误区1：在项目的需求分析阶段，开发方与客户方在各种的问题的基本轮廓上达成一样

即可，具体细微环节可以在以后填充。因为无论起先时有多么细致，以后对需求的修改几乎

是必定的。分析：这是一种特别危急的思想。事实上很多软件项目失败的最主要的缘由就是

需求阶段对问题的描述不够细致，导致后来预算超出或者时间进度达不到要求。正确的做法

是：在项目需求分析阶段，双方必需全面地尽可能细致地探讨项目的应用背景、功能要求、

性能要求、操作界面要求、与其他软件的接口要求，以及对项目进行评估的各种评价标准。

并且，在需求分析结束以后，双方还要建立可以干脆联系的渠道，以尽早地对需求变动问题

进行沟通。

误区2：软件项目的需求可以持续不断的变更，而且这些变更可很简洁地被实现。分析•：

的确，在具体实际中由于种种缘由客户方很难在需求分析阶段全面而精确地描述全部问题。

随着开发进度的推动，往往会有一些需求的变更。而现代软件工程理论也利用软件的敏捷性

特点通过各种方式来适应这种状况。不过，这并不表明“软件项目的需求可以持续不断的变

更，而且这些变更可很简洁地被实现〃。实践表明：随着开发进度的推动，实现软件需求更

改所须要的代价呈指数形式增长。假定在需求分析阶段实现需求更改须要花费1倍的代价;

那么，在系统设计和编码阶段，须要花费1.56倍的代价;在系统测试阶段须要花费1020倍

的代价;在软件版本发布以后，甚至可能要花费60100倍的代价。由此可见，在项目开展过

程中，软件需求的变更应当尽量早地提出。这样才可能花费少，简洁被实现。

误区3：软件程序主要由代码组成，因此编码阶段是整个软件项目的最重要的阶段，应

当给与大量的时间，并且集中主要的资源。分析：与以前相比，由于软件的规模和困难度的

增加，以及半自动化软件代码开发平台的出现，现代软件项目管理的中心发生了转移一一不

是着重编码阶段，而是着重系统总体/具体设计阶段。一般说来，在现代软件项目管理中各

种资源的合理安排比例是：项目论证、风险评估阶段3%,项目需求分析阶段8%,系统总体

/具体设计阶段45%,编码阶段10%,系统测试阶段34%。

误区4：为了便于代码的维护修改，在系统的具体设计阶段文档工作应当做到写出全部

程序的伪码。分析：通常伪码的最大作用是对程序的算法流程进行描述，便于人们深化了解

程序的功能和实现过程。可见，在肯定程度上伪码的确有利于对程序代码的维护和修改。但

是，我们知道为了保证项目文档和程序代码的一一对应关系，维护程序代码的时候同时须要

对项目文档进行维护。伪码和程序代码是特别接近的，对伪码进行维护的话，相当于进行了

2倍的程序代码维护。工作量是很大的。所以切合实际的方式应当是对一般的程序文档做到

程序流程图即可，对于涉及了较困难算法的才须要伪码。

误区5：既然在项目人员配置中设置了特地的测试人员，那么软件全部的内部测试工作

全部应当由测试人员完成。分析•：软件程序测试可以分为“白盒法"和"黑盒法〃两种方式。由

于运用“白盒法”对测试人员各方面素养的种种要求，在进行程序测试时测试人员总是最优先

运用“黑盒法”。他们的工作方式往往是先对程序进行“黑盒法”测试;假如测试没有通过，不得

己这才考虑对程序代码进行"白盒法"测试。明显，这种对“白盒法”有意无意的“躲避"，对软

件的牢靠性和稳定性构成了威逼。如何解决这个问题?一方面须要提高对测试人员的要求，

另一方面也须要程序员完成部分的“白盒法〃测试（事实上，程序员往往也是进行“白盒法〃测试

的最佳人选）。

误区6：软件项目管理只是相关技术部门的事情，与公司其他部门无关。分析：在竞争

日益激烈的今日，软件项目规模大、困难度高而且时间要求紧迫。要想提高公司的软件项目

管理水平，这就须要提高公司的整体参加意识，须要公司各个部门协同作战。例如须要会计

部门帮助进行项目预算，财务管理和费用限制;须要探讨部门（技术委员会）指派专家帮助进行

各种风险评估，供应技术指导;须要后勤部门供应各种保障。

误区7：在开发进度滞后的状况下，可以聘请更多的程序员加入到开发团队中，通过增

加人力资源来赶上进度。分析：在留意团队开发的时代，开发方应当依据目前的软件项目管

理水平慎重考虑这个做法。假如新加入的程序员对目前软件项目的应用行业有肯定了解，并

且可以很快适应了开发方的项目管理方式、软件开发风格、团队协作氛围;那么“新人”的加

入是有益的。否则，可能会“好心好意做坏事〃。因为尽管其个人实力很高，但是为了使其与

大家一起协同工作，开发团队不得不分出人手对其进行与项目有关的技术/业务培训，更重

要的（也是难度最大的）是还要引导其融入团队。这可能须要花费开发团队很多时间和精力，

很有可能使项目进度更慢。

误区8：技术骨干应当成为项目的项目经理，项目经理肯定是全部项目成员中薪水最高

的。分析:在〃软件作坊"时代，这是一种普遍运用而且效果不错的方法;而在〃软件工厂”时代，

这种方法却带来各种问题，有时甚至干脆导致项目失败。究其缘由这主要是因为随着现代软

件开发分工的细化，对项目经理的要求也发生了根本的变更一一最留意的不是其对某项专业

技术的驾驭程度，而是其组织、领导、协调开发团队的实力（当然，可以两者均突出最好）。

至于项目经理的薪水问题，这和定薪制度有很大关系。通常，项目经理执行的是管理人员的

薪酬体系，而其他人员执行的是技术人员的薪酬体系。项目经理的薪水在项目成员中是比较

高的，但不肯定是最高的。有时候，为了激励技术人员，项目中的技术骨干得到的酬劳比项

目经理要高。

误区9：只有项目经理以及部门主管才会关切项目整体进度，程序员只关切自己的开发

进度。分析：这是一种“官僚”的想法。事实上程序员作为团队中的一员，他不仅仅是在打一

份工，更重要的是在参加•件”作品〃的创作。在体会工作的辛苦的同时，程序员更重要的是

要享受创作的快感。项目经理不应当漠视程序员对“成就感”的追求，应当向每一个人具体描

述最终“作品”将会如何奇妙和令人兴奋，并且在到达最终目标的路上设立一系列的里程碑。

每当项目整体推动到一个里程碑的时候，项目经理应当把这个消息告知每一位项目成员。事

实上，这不仅仅可以让全部的项目成员享受到阶段成功的喜悦，还可以激发大家更大的工作

热忱，提高工作效率。

误区10：为了保证项目接着，为了留住核心程序员，加薪吧。分析•：加薪可以说是很

多企业在挽留程序员时所运用的常用方法。这一招可能短暂奏效，不过往往是人留下来了，

但副作用也来了一一加薪的人未必见得多干活，没有加薪的人却起先消极怠工了。其实，项

目的进行过多地依靠程序员的个人技术是"作坊"时代沿袭下来的“陋俗〃。既然IT行业人员的

流淌是无法限制的，现在项目的执行应当更加留意