项目经理手册

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

●团队构建

●领导力

●执行力

●时间管理

●压力管理

●结构化思维与表达

●有效沟通

●有效的演讲技巧

●六顶思考帽

软件工程项目管理是一个系统工程，软件工程项目管理的主要目标是保证项目在规定时间内高质量地完成。项目管理包括了项目组开发各阶段的人员结构的配置，质量控制的实施方略，内部文档和产品文档的组织编写等多项工作，其中质量控制方法具有软件开发的特点。

项目开发根据进度分为需求、设计、开发、测试等各个阶段，质量保证工作始终贯穿各阶段，同时又必须根据每个阶段特点采取相应的措施。

需求分析

从系统分析的经验来看，这个过程往往是个循序渐进的过程，一次性对系统形成完整的认识是困难的。只有不断地和客户领域专家进行交流确认，方能逐步明了用户的需求。从系统开发的过程得知，系统分析时犯下的错误，会在接下来的阶段被成倍放大，越是在开发的后期，纠正分析时犯下的错误所花费的代价越是昂贵，也越发影响系统的工期和系统的质量。

在具体项目中，一般的做法有两种：一是请该领域内专家参与到系统开发的早期阶段；二是开发系统原型，原型包括功能性的原型和用户界面性的原型，也可以是二者混合的原型，用这些原型确认用户的需求。

监督计划

按照监督计划分配相应的资源来保证某阶段的开发质量。分析阶段的监督计划会在分析

任务之前被项目经理、项目负责人、系统分析员以及技术支持所了解。为保证分析工作高质量进行，同时又不被过分打扰，质量监督组则主要针对《系统分析报告》进行复审，并在认为确实有必要的情况下才召开质量复审会议。质量复审会议的主要参与者是项目经理、项目负责人、分析人员和质量监督组组长。会议主要是对质量质疑，给出改进建议即可。具体是否存在质量问题、是否需要改进，不在会议中进行讨论，以此保证了会议参与的人数较少，会议的时间尽可能短。

系统实现，实现也就是代码的生产过程。生产的类别有组件的生产，构件的生产，应用系统的整合，以及各种测试用例的生产。为了能够提高生产的质量，应将生产的程序人员按职能分成两组，也就是说如果某个程序员生产了某个组件，则不能再由该程序员来生产，但他可以生产其他组件。这样交叉生产更容易发现组件存在的问题。

测试指标

测试人员按照各项指标提出测试报告。指标分别包括如下几点：软件的正确性，正确性测试主要是测试软件的功能是否被正确地实现。测试的方式主要是按照功能的要求按照给定的输入，看是否有给定的输出，在非标称输入时，输出是否异常等。同时也可以测试软件的功能是否实现或完整实现。

性能指标：该项目对性能的要求非同一般的软件项目。性能测试往往包含了压力测试、攻击性测试等测试，软件所能承受的极限是多少，一般来说，软件的极限应当高出用户要求的性能，各种指标也应当为用户所了解。

易用性：软件的使用界面在设计时，应当设法使之与功能的实现相脱离。脱离的原因在于易用性是通过友好的界面实现的。然而让开发人员以使用者的角度，来确定软件是否易用是件非常困难的事情，在确定使用界面时，往往需要多次反复修改，甚至只能在软件的最后交付之前或用户使用一段时间之后才被提出来。

需求变更管理

需求变更管理是web项目管理中最重要的一个环节，需求变更管理的有效性直接影响项目的成功与否。

对待变更的态度：

1、变更是不可避免的。

2、变更必须被管理。

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

需求变更管理的目标：

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

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

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

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

需求变更流程：

1、确定需求的基准线。

通常我们会以User Case作为需求基准线，在User Case确认之后的任何需求改变，都需要走需求变更流程。没有走需求变更流程的需求将不被认可。

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

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

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

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

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

4、需求变更确认后由专人将需求变更记录下来(格式如下)，通知给项目中所有成员。其中以下人员对需求的变更是紧密相关的,他们必须知晓并认可此需求变更。包括（客户方代表，需求分析师，测试人员，相关开发人员）。

需求变更表的格式：

序号

变更提出时间

变更描述

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

原因

变更提出者

开发人员

对进度的影响（工作量）

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

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

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

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

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) 客户在项目过程中的全程参与有助于降低此类风险。需求讨论、需求确认、User Case确认、测试阶段的客户验收等环节，都要要求客户参与。

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

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

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

在项目开始前的技术评估阶段，明确技术难点，提前安排人员进行攻克。如果在可预期的时间内无法解决，可以要求需求方变更需求。

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

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

(1)、制定项目计划时，对开发时间的评估要尽可能的合适。合理的开发时间对开发质量的影响很大。开发时间评估可参考【web项目经理手册-开发时间估算】。

(2)、有一套严格可行的代码规范，编码时严格遵守，code review时严格考核。

(3)、在编码前，开发人员要对框架熟练掌握。

(4)、一份好的系统设计文档对指导开发非常重要。

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

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

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

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

1、上述我们所说的风险管理都是指可以预期将要发生的风险，那些不可预期将要发生的风险不属于风险管理的范畴。这也说明项目经理的经验和知识对能否管理好风险至关重要。

2、详细明确的项目计划、以及项目执行过程中每个要点的质量保证是降低项目风险的必要条件。

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

风险报告的格式通常是：

web项目中有很多项目涉及到跨部门、跨公司的合作。这类项目往往比其他项目更有挑战。对于项目经理如何做好这些项目呢？

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

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

2、合作双方隶属于不同的公司或者部门，双方的项目开发流程可能完全不同，在项目执行过程中需要考虑到这个因素。

2、合作项目需要双方共同完成，如果一方的工作进度出现延误，那么整个项目的进度都会收到影响。

本人根据平时这类项目的实施经验，总结一下这类项目要想成功，需要把握的原则。1、合作双方的领导层必须都非常重视这个项目。剃头挑子一头热的项目成功的可能性不会高。

只有这样，项目的优先级才有保证，这样在以后项目过程中一些资源（包括人力、硬件、时间投入）更有保证，配合起来也会更加顺畅。

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

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

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

web项目双方的合作在技术方面通常采用API接口方式交互。所以项目前期详细准确的接口说明文档非常重要，双方开发人员之后的开发都是严格按照接口进行。

同时接口的相对稳定也是非常重要的，所以需要前期设计的时候认真全面地考虑接口规范。

4、便利的沟通工具。

对于跨地区的合作，便利的沟通工具是非常重要的。当然工具最好是免费，比如使用IM。从沟通方式的效果来看，我觉得面对面的沟通>电话沟通>EMAIL(or IM)。

5、接口变更的及时通知。

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

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

前期技术方案的讨论以及接口的定义，最好能当面沟通，这样效果最好。所以前期最好去一趟对方公司商谈这些要点。

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

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

最好的情况是：可以访问对方的环境(外网)。

最大的风险是：没有可以联调的环境，等到发布到正式环境上再测试，这时候时间上就有点晚了，可能会遇到一些之前预想不到的问题。所以联调的时间越提前,问题就能越快暴露出来，整个项目的风险就越小。

联调环境的稳定也非常重要。有一次我们发现我们的功能有问题，代码跟踪调试，结果发现原来对方的环境有问题，浪费了我们很多时间。

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

在项目计划中要详细定义各个重要的里程碑，并严格控制执行。

9、项目进度报告。

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

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

不同公司项目的流程、角色分工不一定相同。只有熟悉了对方项目的流程，在与对方沟通时候才能做正确的事情。所谓知己知彼，才能百战百胜。

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

我们常说做好项目的关键之一就是做好“沟通”，但很多人只知道“沟通”的重要性，却不知道怎么做好“沟通”，所以仍然会有很多项目由于沟通未做好而导致项目失败或者有些遗憾。

“沟通”不仅仅是说话，不是说的越多沟通就越好。要做好“沟通”关键是清楚以下两点：我们要和谁沟通，和他(她)沟通什么，怎么和他(她)沟通。

沟通的最终目标是：让被沟通的人明白你要传递的内容，并自觉执行好你希望他做的事情。要解决好沟通问题，我们需要把握以下两个原则：

一、利益原则

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

项目开始阶段我们要识别出与项目有利益的人(即项目干系人)，确定他们需求和期望，然后

采用合适的沟通策略。

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

人和组织。这些人是项目过程中需要着重关注的人群，很多项目出了问题都是由于忽视了(或者是忘了)其中某些人。

项目干系人通常包括：

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

?部门职能经理。(资源提供方)

?项目团队成员。(项目执行者)

?产品运营。(产品的运营者、使用者)

?客服人员。(客户接口)

为了更好地把握这一原则，我推荐项目经理在项目开始阶段使用以下表格。

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

(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行业人员的流动是无法控制的，现在项目的执行应该更加注重团体的力量，应该更多的考虑公司整体技术水平和核心技术能力。例如形成公司自己的专家知识库，类/函数库，第三方控件库，拥有自主版权的开发平台等。另外，实际上程序员萌生去意的原因很大程度上不是薪水，而是缺少激励和尊重。这需要项目经理使用“老土”一点的办法，找适当的时机对程序员做一做思想工作，向其描述项目的美好未来，让其感受关心和尊重。总之，要从多方面着手保证项目的顺利开展，而不是简单地加薪。

软件开发过程的监督和管理

软件开发项目具有建设范围难界定、技术含量高、人员流动快、协作性强、开发成功率低等特点。目前国内对软件项目的监理制度尚不规范，对软件开发仍然缺乏有效控制。因此由企业的信息技术管理部门设立软件监督岗位，加强对软件项目的开发过程管理，就显得非常必要。

软件监督的主要职责是在项目的进行过程中，协调业务需求部门和软件开发方的关系，监控软件开发任务的执行情况，给开发人员和管理层提供反映软件过程质量的信息和数据，提高项目透明度，从而保证项目按照计划实施，实现预期目标。软件监督应具备以下三方面的基本素质:

●具有较强的工作责任感和良好的沟通能力;

●熟悉业务管理流程，掌握软件开发流程、开发规范以及相关标准;

●具有软件开发项目的建设和管理经验，掌握项目管理知识;

软件监督的工作任务主要有:

●确保软件按照业务需求方确认的范围进行开发。

●保证软件开发进度符合双方确认的计划指标。

●保证软件开发过程中存在的不符合要求的问题能够及时得到沟通和处理，必要时需要将问题反映给管理层。

●确保项目组中软件开发人员队伍相对稳定。

●保证软件开发过程和开发出来的软件符合相应标准和规范。

●收集软件开发过程中的成功经验，为企业提供软件开发过程的有效控制方法和规范。

1.监督管理的范围

《需求分析说明书》是对软件开发范围的书面表达依据。由于《需求分析说明书》往往是采用软件设计的术语编写，因此常常令计算机背景知识较少的业务需求方难以理解，也就很难发现需求报告中与实际需求不符之处，更难提出建设性的意见。

软件监督要对软件开发范围进行管理，首先要确定双方都能认可的《需求分析说明书》。如要求软件开发方对《需求分析说明书》做出进一步更详细的解释，编制业务模型，以便用户方准确地理解《需求分析说明书》的内容，能及早地发现需求与实际的偏差。这也是对需求分析工作的总结与确认。

在项目需求分析阶段，双方必须全面地、尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求，以及对项目进行评估的各种评价标准。

《需求分析说明书》完成后，软件监督应组织项目组与业务需求方共同讨论，听取业务需求方的意见和建议，并进行相应的修改完善。各方确认《需求分析说明书》内容后，需在说明书上签字确认。

在软件开发过程中，双方应严格按照签字确认的《需求分析说明书》中规定的业务范围进行开发。有些需求可能在项目初期很难确定，在开发过程中需要不断地加以修正，项目软件监督要及时与用户充分沟通，建立可以直接联系的渠道，共同进行需求确认，保证项目范围可控。