项目经理做项目开发管理经验总结谈

A

项目经理做项目开发管理经验总结谈

一、项目过程

根据我们项目出现的问题，我自己的总结的一些经验以及我在培训中学习得知识总结下项目中

碰到的问题和解决方案。

1.1签订协议

我们项目的协议内重要写的很模糊，范围可大可小，致使我们在后期的工作中项目越做越大，

但是项目费用是不变的。在国内的协议仿佛都是在打单时是基本上都承诺，也不会到细节，在

协议签订后启动后才发现问题。但协议中可以写明假如需求变更什么级别的怎么样，多少钱等;

签订协议也是一个很高的技巧，建议把系统的边界及功能范围和解决方案与协议一起签署，这

样客户提出的新功能就可以暂且搁置。

1.2团队建设

在立项后尽早拟定该项目的负责人及项目经理，这个人员非常关键，需要很强的综合能力，特

别的人格魅力方面。尽最大的努力将客户的人员加入到我们的项目团队来，这个人也是我们将

来和客户的统一联系人，客户指定一个人和项目组进行沟通，不能是张领导、王领导都来说几

句，假如他们意见不一致，那你只有得罪领导的选择了，所以，项目的最初就要定好规矩，项

目组只认一个的意见，有什么规定你们内部先统一再和项目组谈，我们不想卷入客户内部业务

部门之间的矛盾和政治斗争之中。很多项目经理都没有自己选择成员的权利，那么，就尽量发

挥你的影响力去寻找那些你想要的人吧。成员的组成根据项目不同，相差较大，很难有什么具

体规定，但是，一定要有精通客户业务的人，很多小项目里，这个人就是项目经理本人，大项

目里会配备行业专家（1血115仃丫expert）,这样和客户沟通起来才不会鸡同鸭讲，双方才可以

互相理解。项目经理需要了解每个成员的情况，用就要用每个员工的专长。软件行业是个非常

特殊的行业，从项目的管理以及人员的管理都有它的特殊性。

作为项目经理，其实脑子里就是几样东西：做哪些事情、做到什么限度、怎么交货、手上的资

源以及各个事情的优先级。所谓多快好省那是人类的梦想，这四个方面都是互相矛盾的，属于

典型的又要马儿跑，又要马儿不吃草的类型。考虑问题的轻重缓急方面，往往是把快放在第一

位，各方领导都会给你最后期限，所以保进度是第一位的；省是第二位的，公司的主线目的是

赚钱，假如收入不能增长的话，至少费用要控制住；好是第三位的，没办法，谁都想精益求精,

但是，没有强大的资源保障，质量只好先牺牲了；最后是多，客户的规定源源不断，如何减少

客户的盼望值，让他们从抱负回到现实也是项目经理的分内工作。

1.3需求调研

在需求调研分析阶段，项目组对客户的整体组织结构、有关人员及其关系、工作职责等没有足

够了解以致于无法得到完整需求或最终经权威用户代表确认的需求。由于项目经理和需求分析

员的工作问题以及调研工作做的不够细，客户参与限度都不高，客户方相关负责人不明确或对

范围和需求责任心不强，提出的需求具有随意性，项目前期对需求的确认不够积极；多个用户

代表各说各话、昨是今非但同时乂希望软件尽早交付；我们的做法重要注重领导的需求，基本

上都是领导说什么就是什么，致使开发出来的功能在实际使用中不是真正的使用人所需要的，

项目后期需求变化随意，导致项目范围的蔓延，进度的迟延，成本的扩大。同时在我们的结识

中是需求调研很关键，很多公司只是概念上认为该阶段重要，需要投入的时间长，但是事实上

很多公司做不到这个，总想不久进入编码阶段。并且为了赶进度总想省做某些工作，少写某些

文档，使我们无法拿出客户需求以及后来功能变化和原先功能之间的对比度。

导致上述现象的因素是我们没有全面了解所有项目干系人的需求以及对需求调研的重视限度不

够。软件开发是没有捷径可以走的，省掉的工作后面会有更高的代价回报。全面的需求来自所

有项目干系人，不同的干系人其愿望和追求的目的往往相差甚远，因此对项目干系人的愿望进

行平衡也许是相称困难的事情。

软件开发项目的目的就是实现项目干系人的需求和愿望。假如对项目所有干系人没有进行足够

的沟通和影响，使其尽也许地参与项目，则也许由于项目开始时项目范围和一些具体需求不够

完整清楚，也也许由于某个项目干系人后期由于结识的变化而提出新的需求，导致工期的延长,

成本的增长，甚至项目的完全失败。因此，应当从项目的启动开始，需求分析员及其项目成员

就要分清项目干系人包含哪些人和组织，通过沟通协调对他们施加影响，驱动他们对项目的支

持，调查并明确他们的需求和愿望，减小其对项目的阻力，以保证项目获得成功。以下是一些

有效的措施

1、尽快熟悉项目干系人全貌

有些项目在做需求调查时，由于受进度规定等客观因素影响，需求分析员与建设单位的技术部

门交流较多，向业务管理部门和实际使用者调查不够进一步，导致软件试用后不得不再对需求

做较大调整，〃从头再来〃的部分比例很高，大大超过进度规定期间。因此，熟悉项目干系人全

貌是进行需求调查的第一步，也是需求调查的基础。在定制开发项目的项目干系人中，最重要

的是建设单位中的人事组织、业务关系。最佳是可以用组织结构图画出相关单位的组织结构；

建立调研对象通讯录以保证调研及分析期间及时的沟通。与此同时要注意项目干系人的主次关

系，以便在他们之间的需求出现矛盾时可以进行合理的取舍。

3、可视化需求调研，引导各种客户挖掘他们的需求

很多客户由于自己缺少计算机知识，无法提出完整准确、隐含的或潜在的需求。但若这些需求

不能满足将导致用户的不满。因此需求调研分析人员应善于想用户所想，不要胆怯用户的需求

多，不仅要拟定明确的需求，还要善于用启发的方式与用户探讨隐含的或潜在的需求，并结合

各种调研分析技术挖掘超过客户盼望的令人兴奋的需求。这就规定需求调研分析员要尽快完整

地熟悉相关业务，从而可以站在用户的立场看待软件需求，想用户所想，做好业务与计算机之

间的桥梁。运用可视化需求调研的方法可以很好地启发用户进一步挖掘潜在的需求。可视化需

求调研就是使用图表等工具来启发引导用户清楚地叙述需求，并且使需求更加全面完善。

对于高层领导，可以提供系统总体框架图；对于业务管理人员，可以用业务流程图来描述新旧

系统的业务流程；对于客户中的技术人员，可以用数据流图、实体关系图或UML中的各种图形

对系统进行各种角度的描述；而对于业务管理人员、客户中的技术人员、以及各层次各流程中

的用户，画出用户界面图来进行需求挖掘，是个比较有效的沟通方式。

这里特别说明一卜用户界面的重要性。用户界面的设计按理来说是软件设计的贡任，当然客户

自己对界面有特别提出规定的除外。但是，假如把它提前到需求调研时（紧接着原有系统调研

分析和系统模型完毕之后）与客户进行讨论，则可以大大改善需求调研的效果。由于这时客户

对于将来的系统还没有一个形象上的概念，或者有一个模糊的预想的概念需要表述、验证、明

嘶叱、完善化.从我们后来的项目先做界面和用户交流的经验看（系统原形应当在需求分析的

时候开发人员在分析师的指导下完毕真实环境中的开发，当然开发只是界面的功能模拟，没有

底层代码的实现），画出用户界面草图与客户进行讨论，可以大大激发他们提供更为准确全面

的需求，并且这些界面在后期的开发中也可以运用。本来收集资料，描述业务，说明系统模型

到了山穷水尽的时候，这种方法可以达成柳暗花明乂一村的效果。因此，所谓需求就是“当你

按下各种相关按钮（或输入各种相关命令）时系统做什么”，所谓设计就是“当你按下各种相

关玄钮(或输入各种相关命令)时系统怎么做”。需求的最终目的事实上是完整准确地描述系

统需要的各种接口或“界面”，及它们的互相关系或与外部环境的关系，如界面中的某个按钮

按下去时，也许产生新的界面、新的按钮、或者调用其他软件硬件完毕某些功能。自顶向下，

把这些界面及涉及到的数据描述清楚，就是一份不错的需求。

4、与其他项目小组成员共同协作、连续完善系统需求

需求文档完毕之后，并不是万事大吉，把它扔给后面的设计人员就了事了。作为项目干系人之

内的项目组其他成员，对需求的有效性也起到某种限度的验证作用。虽然软件项目的生命周期

按照各种开发模型有不同阶段的划分，但每个阶段的结束不是简朴地把阶段工作成果塞给下一

阶段的成员就可以了〃特别是高科技的软件开发项目，上一阶段的工作成果往往要通过多次的

沟通才干更为清楚地被下一阶段成员接受，其有效性、合理性也要被下一阶段的工作所检查，

通过检查有时也有必要对上一阶段的工作结果进行相应的调整，需求更是如此。因此，无论是

同一阶段不同人员之间，或是不同阶段人员之间都应根据需要互相协作，互相配合，共同完毕

软件开发任务

5、《功能规格说明书》，这个是我们项目中最大的失误，致使后来客户的改动让我们很被动。

《功能规格说明书》反映了客户提出的所有需求功能，我们也是按照《功能规格说明书》来开

发的。后期客户的变化都可以和《功能规格说明书》对比，具体怎么变更按照我们的变更流程

来做.《功能规格说明书》作为产品需求的最终成果必须具有综合性：必须涉及所有的需求.

开发者和客户不能作任何假设。假如任何所盼望的功能或非功能需求未写入软件需求规格说明

那么它将不能作为协议的一部分并且不能在产品中出现。并且注意以下几点：

(1)完整性

每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的

所有必要信息。不能漏掉任何须要的需求信息。漏掉需求将很难查出。注重用户的任务而不是

系统的功能将有助于你避免不完整性。假如知道缺少某项信息，用“待拟定”作为标准标记

来标明这项缺漏。在开始开发之前，必须解决需求中所有的“待拟定”项。

⑵对的性

每一项需求都必须准确地陈述其要开发的功能。做出对的判断的参考是需求的来源，如用户或

高层的系统需求规格说明。若软件需求与相应的系统需求相抵触则是不对的的。只有用户代表

才干拟定用户需求的对的性，这就是一定要有用户的积吸参与的因素。没有用户参与的需求评

审将导致此类说法：“那些毫无意义，这些才很也许是他们所要想的“”其实这完仝是评审者

凭空猜测。

⑶可行性

每一项需求都必须是在己知系统和环境的权能和限制范围内可以实行的。为避免不可行的需求,

最佳在获取需求（收集需求）过程中始终有一位软件工程小组的成员与需求分析人员或考虑市场

的人员在一起工作，由他负责检查技术可行性。

（4；要性

每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以

理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输

入，如使用实例或别的来源。

⑸划分优先级

给每项需求、特性或使用实例分派一个实行优先级以指明它在特定产品中所占的分量。假如把

所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制。

⑹无二义性

对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽

量壬每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法涉及也需求文档的

正规审查，编写测试用例，开发原型以及设计特定的方案脚本。

⑺可验证性

检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来拟定产品

是否的确按需求实现了。假如需求不可验证，则拟定其实行是否对的就成为主观臆断，而非客

观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。

⑻一致性

一致性是指与其它软件需求或高层(系统，业务)需求不相矛盾。在开发前必须解决所有需求

间的不一致部分。只有进行一番调查研究，才干知道某一项需求是否的确对的。

⑼可修改性

在必要时或为维护每一需求变更历史记录时，应当修订文档。这就规定每项需求要独立标出，

并与别的需求区别开来，从而无二义性。每项需求只应在文档中出现一次。这样更改时易于保

持一致性。此外，使用目录表、索引和互相参照列表方法将使软件需求规格说明更容易修改。

(10)可跟踪性

应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟

踪性规定每项需求以一种结构化的，粒度好的方式编写并单独标明，而不是大段大段的叙述。

6、需求变化

项目的需要变化是肯定有的，并且变化一般都很频繁，我们怎么应对客户的这种需求变化呢，

以不变应万变。一方面在前期的需求调研要做好，尽也许的替用户考虑，达成功能质量满足最

大化。需求调研前期的《目的与范围》和需求调研末期的《功能规格说明书》都要跟客户签字

确认，这样既能保证我们所理解的需求就是客户所要的，也使得项目末期跟客户验收时有据可

依。在项目中期是发生需求变更是很常见的，这时要做好需求变更管理流程。需求变更表，小

的变更自己掌握，客户规定的变更有开发人员和设计人员共同商讨后提交项目经理，项目经理

预估变更损耗工程时间，在一定阶段一起提交给客户，大的变更直接提交客户，并旦要把需求

变更对项目产生的影响让客户知道，把球尽也许的踢给客户，让客户在进度、功能、资源三者

中取舍出一个平衡来。对需求进行分类评级，关键部分不能改动的做特别确认（如系统架构等,

假如改变等于从头再来）。同时完毕客户签字确认，当然假如能将这部分写成协议细节中去是

最佳。以下是我认为变更的环节：

第一步：客户提出变更内容

•客户提交的变更必须基于书面形式

•客户提交的变更必须有充足理由

•假如变更被拒绝，对业务的负面影响

•假如变更被接受，对业务的正面帮助

第二步：为能否实现变更作评估

•从实现方式上考虑新的变更可否实现

•对于较复杂的情形，辅以简朴的说明。欲详述，可作附件解决

•对于简朴情形，例如页面布局更改，则无须说明

第三步：可以实现看进度

•进度几乎是绝大部分项目关注的第一要素

•对于活动级别的进度影响

•对于项目整体工期的影响

第四步：变更成本

•人力相关的变更成本

O是否需要额外的项目组成员

O项目组需要增长的工时数

是否正常工时（工作日加班、节假日加班）

•项目工数报价

非人力成本

・软硬件费用

•资料费用等

第五步：质量和风险

变更对质量的多方面影响

•分阶段影响（需求、设计、编码、测试、维护）

•可靠性、安全性、可维护性、可用性等

也许对团队士气的负面影响

•也许引发的间接任务市工期的负面冲击

•开发方的成本承担也许超过力所能及的范围

第六步：需求变化的拟定

6.2架构设计

撰写具体设计是一个逐步细化、进一步的过程。没有人能一次就设计出完美的东西，需要及时

的沟通，涉及与客户的反馈，与其他项目组成员的讨论，这样有助于减少开发时偏离需求的风

险。也就是说，在开发之前题，是建立在设计者的想法有客户的确认和开发人员的理解的基础

之上设计撰写人必须与系统分析员反复讨论，以透彻理解用户需求；

一项需求也许有多种方式实现，设计者必须与系统分析员拟定该需求将采用何种方式实现，将

达成何种效果，以消除将需求映射为设计的歧义；讨论过程中还也许会发现需求有不完备甚至

错误的地方，在需求重新拟定后设计者需修正设计。设计文档必须写清楚各个模块/接口/公共

对象的定义，列明程序的各种执行条件与盼望的运营效果，还要对的解决各种也许的异常。此

外没计文档应当遵循一定的写作模式与版面风格，使用统一的术语或惯用语，使得小组成员很

容易理解。以上这些活动综合起来将是一个很细致、很耗时的工作过程。就个人所知，一些公

司（I勺具体设计通常是由程序主管或少数核心的程序员撰写的，他们通常也是系统架构的重要作

者或维护者。由于他们在开发团队中技术最为精湛，对架构最为熟悉，他们最有资格评价现有

架沟是否能适应新的用户需求，采用何种方式实现需求对架构的冲击最小。但是由少数人来负

责所有的具体设计也许导致开发过程中的瓶颈甚至是设计的错误。当任务比较集中的时候，设

计者也许忙得透但是气，而负责实现的同事反而在等米下锅，比较清闲。于是为了让自己不成

为抱累进度的“罪人”，某些设计者就会采用一种快捷方式来交付设计：他们会与系统分析员

进行初步的讨论，然后撰写一份粗糙的但仍然叫做具体设计的文档，把它交付给负责实现的同

事，再通过讨论、即时通工具、电子邮件等方式解答对方提出的疑问。但由于具体设计自身不

完备，他们不得不花费更多的时间和精力与负责实现的同事沟通；并且他们却很也许忘了把这

些交流的成果更新到具体设计中去！（或许是他们太忙，没有足够的时间，又或许是他们认为

既然产品已经实现，那么具体设计也就不必维护了。）其结果很也许是当产品开发出来后，我

们才发现它跟用户规定的完全两样！原木在具体设计阶段就应当发现的需求漏洞与在那时应当

拟定的技术方案在实现阶段甚至测试阶段才暴露出来，而这时大家往往有木已成舟的感觉，改

动的难度比设计阶段高数倍甚至十倍以上，毕竟任何再牛的人都有自己的局限。

对于以上问题我提出全员设计，全员设计的含义就是把具体设计的工作进行适本地分解，把它

们分摊到小组内其它同事身上，让大家都参与设计。这可以说明如下：

当一组用户需求基本拟定下来后，程序主管需要估计需求的相关性、需求的优先级、设计的难

易限度、设计的工作量等，将该组需求分解为一或多项设计任务，并指定给适当的同事。参与

设计的每个人必须负责至少一项设计的撰写任务。设计者从系统分析员处获得具体的用户需求,

并与系统分析员反复沟通以透彻理解用户需求。他还要分析系统架构及产品的已实现与/或已规

划部分，理解架构的设计理念，理解产品不同模块之间的协作关系，理解架构与产品之间的约

束和依赖。当然对系统架构和产品的分析不也许穷尽每一个细节，只要分析与即将开发的模块

相关的内容即可。

一顼设计任务，它也许需要多个程序员完毕。比如用户界面或网页由某位或某组同事负责，而

业务逻辑组件则由另一位或另一组负责，数据库部分则乂由其它同事负责♦。设计者必须考虑他

们的立场，以各方面都相对容易理解的方式写清楚重要的模块/接口/对象定义，明确相应的调

用规则与重要逻辑解决。假如某项设计任务所涉及的内容太专业化，设计者并不熟悉相关的内

容（比如某位C#程序员并不熟悉如何编写一个存储过程），他可以用描述性的文字说明该部分

的没计规定，并知会相关的同事补充。其它同事在补充时可以对这些描述性的文字重新整理，

以更加确切地表达设计内容，更符合文档的书写惯例。在设计文档完毕后，设计者必须把他提

交给程序主管或由程序主管指定的程序员审阅。个人推荐由其它程序员而不仅仅是程序主管来

审阅。不用紧张等待多个人的审阅意见是否也许导致一份设计滞留很久。大家可以并行地工作,

不必是A审阅后才干B审阅。可以交叉审阅，即A的设计由B、C审阅，B的设计由A、C审阅等。

审阅意见可以用多种方式（如讨论、即时通工具、电子邮件）反馈给设计者，设计者负责汇总

这些意见并修正设计。以个人的经验而言，通常设计交付审阅后半天内就可以收到反馈意见了。

设计通过反复地修正直至没有人再提出修正意见，这时就可以由程序员实现了。以个人的经验

而言，一份设计通常两、三轮反馈后就可以定稿了。假如多次反馈后仍不能定稿，极有也许是:

a）需求尚未明确，各个方面（涉及客户、系统分析员或设计者）对需求的见解不统一

b）技术或系统架构存在严重的限制，无法用较方便的方式实现

全员参与设计好处、风险与不合用的团队如下：

6.2.1全员设计可以带来以卜明显的好处

1.有助于平衡工作量，加快开发进度。具体设计的任务分解后，程序主管或核心程序员可以有

更多的时间解决其它的事务，比如关注软件的开发质量或改善系统架构。具体设计的撰写任务

分解后它们可以并行地撰写，这将极大地提高设计撰写的进度，节约时间。

2.有助于培养程序员的大局观。每位撰写设计的程序员不再仅仅只关心自己负责实现的模块，

他必须从更高的层次考虑和理解设计。

3.有助于加强同事之间的交流与协作。设计者需要与系统分析员、其它程序员、审阅者进行反

复的交流和沟通，事实上每份设计都是多人协作的成果.更多的沟通有助于集思广益，有助于

避免一、两个人的倾向性意见导致错误的设计。每位设计者都需要对自己撰写的设计负责，他

还要向其它同事的设计提供审阅意见或技术建议，彼此的工作是互相支持和依赖的，这有助于

减少“只扫自家门前雪，不管别人瓦上霜”的想法。

6.2.2推行全员设计的潜在风险

1.在某种意义上，全员设计也许增长交流的成本。两个人之间有一条交流途径，三个人之间最

多有三条，四个人之间最多有六条。途径越多，信息量就越大，而这些信息不见得都是有用的

信息。具体设计的任务分解后，不可避免地有更多的人参与交流和沟通，大家要花更多的时间

来理解别人的想法，也也许要花更多的时间向别人阐述自己的观点。特别是在并行撰写具体设

计的过程中，系统分析员反而也许成为另一个瓶颈了。但从总体上来看，在设计阶段花费适当

的弋价发现更多的问题，比在实现阶段或测试阶段再发现问题，仍然是划算的u

2.分解后的具体设计也许引入冲突的设计内容。由于设计由不同的程序员撰写，他们考虑问题

的角度和思维的方式不也许完全一致，这增大了不同的没计内容之间的计算口径或交互方式不

一致的也许性。这需要设计者们尽也许遵循一致的设计原则，也需要审阅者们尽也许找到这些

不一致的地方。

3.并不是所有的程序员都适合参与设计。很明显，例如刚入职的同事就不适合参与设计，他们

对系统架构还缺少足够的结识。此外兼职的同事也不适合参与设计，他们的工作方式也许无法

保证及时提交设计文档与参与讨论等。

6.3沟通

在预目的开