项目管理的几个过程

1、工程管理的几个过程商务谈判1.作人的姿态作人似乎跟商务谈判不太有关系，很多技术人员相信PM 需要的是本领，是如何做好一个工程，而不是会搞好关系弄 的四平八稳的人。随着PM在中国的悄悄兴起，越来越多的PM 开始在老总的授意下参与商务谈判，和销售们一起打单子， 这就比拟实在的需要PM们去揣摩客户的心理。揣摩客户心理 需要有多方面的知识，需要深度和广度，然而，最重要的仍 然是作人。如何放下架子，降低作人的姿态，对从技术人员 转型的PM们来说，是至关重要的。降低作人的姿态需要从 多个方面去实施，最主要应该记住：人不可貌相，更不可以 地位衡量。很多公司为了保持公司形象，会统一叫员工打扮 的好看一点，看起

2、来象个白领的样子。然而，老板多半是没 有约束的。中国改革开放才二十年，很多有钱的老板实业家 文化层次都不高，往往是当大学生们只会把屁股坐在板凳上 肆意挥霍父母辛苦积攒的财富时，他们已经在各地奔波，积 累丰富的商业经验并对金钱，人生和社会的本质有了充分的 认识，形成了自己稳定的思维框架。这些人，很多都是穿着 旧旧的衣服，戴着破破的手表，说话的时候经常会带上三字 经，钻进上海的人堆里，搞不好你会把他当成民工。因为到 他们所处的社会地位，已经不需要任何华丽的外表来衬托自 己的身份，他们有的是底气。对PM来说，这是个非常危险的 挑战。虽然说工程在初期有意向时会对对方的人事和关键人 物有一定的了解，然而

3、大工程里能说的上话的人太多了。上 海人最瞧不起的就是士气，很多人谈工程的时候看到民工或 很俗气的表现不免会皱皱眉头，往往在皱眉头的时候就失去 了工程，也就是失去了市场和金钱。PM必须作到能与每一个这时候，作为公司高层，应该向全公司发表申明，正式 给PM发布工程经理任命书和工程授权书。这个动作虽然在别 人看来有些形式主义，但是对提高PM本人的士气和责任感是 有很大助力的。三.计划阶段.定义结构分工结构图（WBS）启动阶段结束后，工程进入计划阶段，也就正式进入实 施。这里概念可能有些不太对头，其实是翻译的缘故，反正 大家明白意思就行，不用拘泥于字面。WBS是一组要提交的项 目元素，用来组织定义工程

4、的总体范围，具体包括从工作内 容，资源，本钱角度考虑工程范围；建立一套系统所需要的 分层工作结构；把工程分解成易于管理的几个细目，这概念 有些模糊，其实跟资源管理器里分目录是一回事情。可以 说，WBS是计划阶段的核心。WBS会详细的分到递交件，包括 给自己人用的工程使用的过程文件，给客户用的模块和说明 文档，完成每个细目的标准以及如何把这些细目的责任分配 到具体的个人。WBS有缩进式和树状式，我这里也没方法画 图，大家参考一些工程管理的书籍，里面有详细介绍。我整 个文章只挑我觉得需要注意的地方，如非必要，对技术细节 或者工具使用不做详细介绍。WBS的细目并不需要分解到同一 水平，最下面的细目叫

5、做工作包，分包的依据是个人的责任 和可信度，也就是说到每个人头上的任务是否能落实，是否 有把握完成；还有就是准备对工程进行控制的程度，程度越 深，WBS树也就越深。由于WBS是实用性的东西，根据个人理 解也不一样，所以一个工程可能会有几个正确的WBS,看PM 的需要和最适合当前团队状态的进行选择。WBS的定义还是很麻烦的。PM要召开团队进行讨论，向成员提供与工程相关的所有 详细资料，并把WBS树分解到二层三层。然后要花上一段时 间让成员进行头脑风暴式（BRAINING STORM）思考，制订工 作产出和相应人员的职责，记录每一个工作包的完成标准。 在头脑风暴式思考时，会有很激烈的争论，PM要协

6、调关系， 调节气氛，从自己能考虑到的各个角度旁推侧敲，提示成员 的思维角度和方向并加以总结。尽管很麻烦，制订WBS仍然 是非常值得的。如同需求分析一样，WBS准备的越充分，编码 的进度越快。.风险管理既然是商业活动，工程的风险肯定是存在的。相信很多看 了这个帖子的朋友都经历过或大或小的风险。有些风险很容 易解决，有些那么极大地损害了利益。无论什么样的风险，都 是可以尽量防止的，所以有必要对其进行管理。由于风险的 不可预测性，风险管理非常困难，概念很难解释清楚。只能 从一些可行的角度来分析和管理。首先要识别风险。这是个难度很高的活。PM要先召开风 险识别会议，这个会议面向公司，高层，跨部门的有经

7、验的 人都将参加。然后审核由工程小组生成的风险清单并与重要 成员进行风险沟通，检查一些重要的风险源如WBS,本钱（时 间）预估，人员计划，采购管理等等。最后就要用到PM本身 在以前类似工程中得到的经验教训。鉴定之后，还需要分析。我们可以做一个粗略的定量分析 （精确的分析是不可能的）。有经验的人可以一起参与讨论， 对提交的风险进行分类。首先，根据发生的概率，一般分为 高、中、低三个等级。虽然很勉强，但至少已经量化了。然 后根据消耗的本钱，也是高、中、低。我们可以把这两类的 三个层次结合起来，可能性大、本钱高的风险就定义为不可接受。当遇到这种风险时，客户不得不修改需求或增加风险 准备金本钱。否那么

8、一旦损失不是一点点，可能会很厉害。高 中中搭配是高风险，中低低搭配是低风险，高低搭配是中风 险。针对出现的可能性，需要采取一些手段降低风险。到目 前为止也没有一个定论说有绝对好的方式，只能尽其所能的 防止。有几种方法可以考虑，第一种是将风险纳入工程管理 计划并指定负责人，由外部人员定期检查工程风险，一旦风 险发生，执行风险管理计划；第二种是保险，这种属于风险 转嫁；第三种方式有点奸，不过最保险，就是把客户拖下 水，让他们一起参与风险管理，呵呵，到时候就好说话 了：）风险管理作为工程计划之后，PM需要更新WBS,修改 日程计划和更新风险管理计划。风险预留通常是本钱的8%。.预估预估是从量化的角度

9、对工程进行评估，主要包括工作量，任务期限，人力，设备，材料，本钱等，要注意预估不是财务策略或报价。是财务策略或报价。预估其实并不是一次性工作，在整个项目过程中，预估始终需要。预估似乎没什么特别需要提的地 方，每个PM接到工程的时候自然会有预估，在工程发生变更 或进入下一阶段时也会预估。预估的作用主要还是让PM作到 心中有个底，安排计划时不至于毫无头绪。4,进度计划进度计划就是一个模块或功能要写多长时间，PM安排个日期，设立里程碑，叫程序员们不能偷懒。进 度计划是从WBS提取过来的。对PM来说，合理的安排进度计 划对工程控制和激励团队士气有着很大的作用。对程序员来 序图，甘特图和里程碑图表。上回

10、邵卫老师讲课，推荐的工 具是m$的PROJECT,这个工具我还不会用，因为没时间去摸 索。我的头倒是用的很溜了，近一个月来他就用这个PROJECT 画了一个又一个的里程碑图，不停的折磨我和同事的神经。说，进度计划毫无疑问是噩梦。显示进度计划一般有先后顺我们一般都是一边开发一边做UNIT TEST,效果上来看，因为有强大的时间压力，效率上比之前确实要提高不少，可是我 们也只能结结巴巴的赶完进度。由于TEAM里人少，我们都是 一个人做几个人的活。我每天早晨六点多出门，经过将近两 小时颠簸，八点多点已经坐在位子上，中午吃15分钟的饭， 干到晚上八点下班，到家吃完饭往往已经11点了。一个多月 我从来没

11、吃过早饭，没有睡过六个小时以上的懒觉。虽然强 大的压力使我们能在短时间内掌握尽可能多的技能，开发更 多的模块，但是对我们的情绪也是有很大的影响。所以说, 工程里程碑是一把双刃剑，合理安排才能既促进效率也不至 于打击士气。团队成员士气的逐级衰落会给工程后期的开发 带来难以估计的影响，进度将会大大延缓。关于PM和团队的 问题我们后面会讲到，这里我先祥林嫂一把，然后跳过。里程志象了程志象了碑图表的特征是任务，成员和时间，任务和成员用文字标 ,时间用数字描述并辅助以图线跨度，象阶梯一样非常形,一目了然。管理起来非常方便，完了的打个钩就可以网络逻辑图是表示任务和逻辑关系的示意图，可以用先 后次序表示，也

12、可以用关键路径表示。其实把各个活动划分 为1, 2, 3, 4等阶段，每个阶段包括小活动1.1, 1.2, 2. 1, 2.2, 2.3, 2.4, 3. 1, 3.2, 3.3, 4. 1, 4.2 等，日程计 划也分四种，一般只提到从前向后和从后向前两种。从前向 后的概念就是某项活动必须相同或晚于直接指向这项活动的 的所有活动的最早结束时间的最晚时间。有些绕口，我们打 个比方：2阶段指向3阶段，那么2阶段里的4个子阶段也都 指向3。假设2. 1结束时间为1月12日，2. 2结束时间为1月22日，2. 3结束时间为1月15日，2. 4结束时间为1月20 日，那么，2阶段中最晚的结束时间是2.

13、2的1月22日，所以在3阶段中的3个子阶段3. 1, 3.2, 3. 3的最早开始时间 都不能早于1月22日。至于从后向前的例子大家自己去推 吧，我就不举了，刚才几个123打的我累死了：）工程经常 需要调整进度。在不改变工程范围的情况下，调整进度有几 种方法利药快速跟踪手段来改变任务间的关系；将串行的 任务改成并行；改变工作方法（可能改变WBS）；改变日期限 制，使关键路径上的任务开始或结束的更早。虽然方法多样化，在我看来只有一条，就是拼命的压榨 程序员的劳动力。如何压榨，还是个技巧。如前面所分析 的，需求分析恨不得多分点时间给它，压需求是不太可能； 测试阶段后期接近完工，罗里巴唆的事情一大堆

14、，忙都忙不 完，那时候PM门心思提前/按时完工，好收钱，压那段时 间似乎也不太可能。说来残酷，最能压的还是CODING,编码 阶段往往是压缩重点，总之大家埋头苦干就是了，大工程压 缩的时候程序员吃喝拉撒都在公司是很正常的事情，相信不 少人都有很深的体会，这里伤心事情也就不提了。只是我总 结一下，让未来的PM们有压榨后来人的依据，呵呵。测试前 期也可以适当的压一压，那时候人刚完工，都比拟懒散。内一般企业规模都不大，没有专门的质量控制部门，所以质 量保证和测试往往就是程序员或PM本身。其实质量保证和测 试人员的人数和素质都应该要高于程序员。在日本和CMM实 施的公司里，编码压缩是很容易实现的事情，

15、因为那些程序 员真的是技能熟练的装配工人，压起来方便的很。他们这样 培养人的目的或许就是为了压缩吧？ ！四.控制和执行阶段.软件开发真的没什么好说的，也是大家最不想谈的。平 时公司里说的够多了，我还得在这里唠叨你。需要提醒的还 是团队精神和完善的文档管理系统。SOURCESAFE这些工具有时候还是有必要使用的。经常看到有人说天才程序员不写注释什么的。我相信有这种天才程 序员，因为我碰到过几个。我爱人公司也有一个，他的一套产品的核心代码就是这个 人写的。四年过去了，外围代码改了好几次，但核心算法一 直没改。可惜这小子跟着李洪志，现在不见了。但是他的代码好像有一些注释，即使是一段时间没有注释的天才

16、程序员 也不能保证他的内存是最好的。而且，对于一个工程的编 码，现在已经不可能靠一两个人就能征服世界了。别人的公 司都是团队，两个人比一个人强。这个头还是天才撑起的。 其实市场是可以被别人抢的。那时候再天才也没用。编码的时候讲究技术公开,程序员不要藏着掖着,对大家没好处，PM要想方法调动大家创新思维的积极性，营造良 好的技术讨论气氛，碰到技术难关的时候就容易攻破了。有 个问题需要单独对还没有PM觉悟的程序员说，其实是在调研 的时候就定了的，就是使用什么样的开发工具。没有经验的 程序员往往会拿着C+或者JAVA的资格证书或者拥有一两个 开发工具的一些经验而得意洋洋。其实老板和PM根本不看重 这个

17、，他们关心的是使用什么样的工具能尽快的到达目的。管你什么C+, DELPHI, PB还是JAVA,只要能做的出来，VFP 都可以用。我举这个例子并非说不看中工具，而是提醒想转 型为PM的程序员，第一要把工具当作工具，而不要被工具套 进去，钻研一些一辈子都用不上的技术；第二要掌握的并非 是单独的一个工具，而是流行的程序设计的思想，以及在最 短时间内掌握一门陌生工具的能力。只有建立了这样的思 维，才有可能转为PM,否那么一辈子都是技术工人，最多就是 个技术总监。.变更对任何工程，变更无可防止，无从逃避，只能去 积极应对，这个应对应该是从需求分析就开始了。对一个需求分析做的很好的工程来说，基准文件定

18、义的范围越详细清 晰，用户跟PM扯皮的幌子就越少。而需求没做好，基准文件 里的范围含糊不清，被客户抓住空子搞你一下是非常头疼的 事情，往往要付出无谓的牺牲，有时候甚至非常火大。需求 做的好，文档清晰又有客户签字，那么后期客户提出的变更 就超出了合同的范围，需要另外收费。这个时候千万不能手 软，并非要刻意赚取客户的钱财，而是不能养成客户经常变 更的习惯，否那么后患无穷，维护的本钱会让PM吃不消。在客户提出变更请求时，要建立变更申请登记表和变更 申请表，并让客户签字。当然，有时候一些不是非常关键的 模块PM也不至于一点不讲情面，该卖面子的时候还是要卖, 尤其是当着对方领导的面，千万要卖面子，但是也

19、别卖的太 干脆，不要让他们得到的太容易。需求做的不好，客户抓住 漏洞或者非常不讲道理，麻烦就大了。有时候争论会很厉 害，到非常白热化的地步，PM与客户代表几乎沟通不了。PM 在客户关系和短期利益两方面难以取舍，一般都是向客户妥 协，最终形成恶性循环。这种情况非常难办。一般这种情况 都是到了工程后期，做重大的更改几乎是不可能的事情，如 果白做就要亏钱。而这个时候如果PM跟对方高层的人关系搞 的定，可以透过对方高层把事情压住。然而由于已经到后 期，客户代表不会轻易更换，对方这次没有改成，必然心怀 不满，下回在别的模块依然会找麻烦或者在谈二期的时候动 动手脚，都是很让PM伤脑筋的事情，这方面目前还没

20、有什么 好的解决方法，所以尽可能的做好需求比什么都重要。相对 需求来说，什么WBS,风险管理，计划进度都是扯淡，需求做 好了，一帆风顺。还有一种方法就是装可怜，要装的非常的 象，在对方的领导面前装，而且不能让人看出是装的样子，要让你自己都觉得你自己是真的可怜，那么就算这次客户硬是要求改了,下回他也必然不好意思再叫你改。其实人心都是肉长的，如果可能的话，我还是不赞同使用一些手段的,但是有时候客户非常难以在短时间打动而工期又将接近，这 种情况下就要靠PM耍一些手段了。各人有各人的方式，八仙 过海，各显神通吧。PM在变更管理中需要做的是分析变更请 求，评估变更可能带来的风险和修改基准文件。.质量控制

21、大公司有质量管理部门(QA) , QA的成员基本上都是由非常有经验的PM转型过来的老狐狸，是老总接班 人的有力争夺者。一个QA会管理多个工程，有时候甚至会亲 身参与。PM和QA有些象猫和老鼠，不停的通过报表传递一些 心照不宣的假数字。QA对PM的工作最终是有评定的：A级表 示总体在控制下；B级表示当前在控制下；C级表示有显著问 题；D级表示有重大问题。如果PM得了个D,那可不太妙, 不但世界级的QA会每个月要收报告，地区QA会一个星期找 来面谈一次，训一顿。得到A的PM是很逍遥的，基本上不会 有人来过问。在没有QA的公司，质量控制只能由经过授权的 团队成员进行，效果就要差的多了。质量管理贯穿整

22、个工程 周期，详细的可以参见CMM。.本钱管理PM经常通过控制进度和预估来控制本钱。PM 必须经常问自己，工程已经到了什么阶段？完成了多少？花 费了多少？完成时本钱是多少？挣值法的术语不少，象 BCWS, BCWP, ACWP,但是关系比拟简单，大家参阅一下相关 资料，这里不再羸述。总之，PM要管理好本钱，注意节约， 但并非是拼命剥削程序员，该花的还是要花。五.结束阶段.工程结束工程结束时，PM要将最终系统方案提交给用 户，完成工程所有的提交件，收集工程全部信息并结束项 目，完成或终止合约，签署工程结束的相关文件。工程结束 意味着可以收钱了。PM辛苦了那么多，终于可以高兴一下 了，收到最后一笔

23、款项，意味着递交件的移交和团队的解散，工程也转入维护阶段。不过收钱未必代表着赚钱，要看 工程是否按时完工。一般来说，提前完工的工程很少，但是 能赚大钱；按时完工的赚小钱；延期的要赔钱。一个人首次 承当PM,如果没有人带，多半会失败。失败没什么，所有的 PM （注意是所有，不是几乎所有）都失败过，然而失败会成 为教训和经验，推动你继续前行。在美国，每年至少有40%的 工程无法实施被搁浅。只有在工程中和生活中不断磨练，培 养自身素质和作人的基本准那么，才能成为赚大钱的PM。.工程完工会议 工程结束时，依然要开会，不过少多 To 一般跟客户要开一个，主要是确定所有的提交件都已经 被接收，对突出的个体

24、进行表扬，对外宣传成功案例，标志 并记录工程的正式结束。这时候开会很轻松，目的也很明 确，做完了大家好聚好散，或者以后有机会再合作。团队要 解散，内部会议肯定是要开的。也没什么好废话的，该表扬 就表扬，该发多少奖金就发多少奖金，毕竟大家都累死累活 的干了那么长时间。工程结束请客户出去泡温泉时PM们千万 别忘记了辛苦为你工作的程序员和工程师们，当然，如果他 们不愿意看到你的脸那么你就折现发到他们的存折上去，正 好让他们回家好好休息休息。这样下一个工程需要他们的时 候他们才会为你卖命。说出来奖金发出去似乎你损失了，其 实你赚大了。.客户满意度形势也好，历史记录也好，尽管工程结束 的时候客户满意度P

25、M心中已经有底了，但是还是有必要向客 户各个层次的工程代表发一张信息反响表，收回的信息将反 应客户的满意度。其实真正表达客户满意度的地方有很多。 第一就是付钱付的快，如果客户不满意，一分钱藏在他牙缝 里你也很难抠出来；第二就是二期，二期非常非常重要，因 为这里已经是属于一种无销售本钱的工程，又有一期的经 验，可以说二期的钱是最好赚的。这中间的感觉，只有经历 过的人才明白。层次的人交谈，尤其是看起来比自己层次要低的群体，哪怕 是公司里扫地的阿姨。只有作到谦虚谨慎，不摆架子，尊重 别人，才会得到别人的尊重，才有机会赢得工程。鼻子比眼 睛高的人只会把自己的鼻子撞扁。.丰富的知识面 光尊重别人还缺乏以

26、赢得工程，准确的说是赢得对方关键人物的信赖。PM 一般用不着陪客户喝酒吃饭，那是销售们 的事情，但是PM和客户讨论问题可能是最多的。讨论问题的 时候就是机会，如何投其所好，是一大关键。金钱与美女依 然是常规的敲门砖，然而这种傻瓜也知道的方法人人都会去 做。老板的关系也只是一个方面，如今的大老板，哪个没有 关系？同等条件下PM凭什么去胜过别人一筹？我一个朋友 （PM）打一个单子时，发现对方对什么都不太感兴趣，费了 很大力气也找不到突破口。对方这个人非常顺利，金钱地位 美女样样不缺。他花了好多天和对方交谈，以自己的博学逐 渐取得了对方的信任。后来他隐约发现对方对数学和天文学 的开展史有所涉猎，如获

27、至宝，回家花一个通宵的时间在网 络上搜索相关资料。第二天他根本不谈工程的事情，只跟对 方大谈特谈哥白尼，布鲁诺，伽利略这些人的生平，整整吹 了一天。对方点头如捣蒜泥，态度和热情都来个一百八十度 转弯，隔天他就拿到了单子。这是个经典的战例，谁能事先 想到哥白尼会来帮助IT的人赚钱？这个PM靠的就是博学和 由博学引申出的敏锐的感觉抓住了机会，让客户产生共鸣。客户感觉他层次也很高，而且和自己有共通之处，信任度大 大增强，把工程交给他放心。如今这种例子在商务谈判中已 经屡见不鲜了。对PM来说，并不要求在各个方面都很精通， 那是不可能的事情，只要PM对一些流行的话题和天文地理历 史各方面的知识有个大概的

28、了解，在需要的时候能尽快的掌 握，才有机会创造机遇和把握机遇。.强大的沟通能力胸中有万千墨水却不知如何表达其实是比拟少见的，但 并非绝对没有。每个人的人生轨迹都有所不同，思维受环境 的影响也各有差异。包括象我们目前这个班级里的一些未来 的MSE们，一定有比拟内向或者不太爱表达自己观点的人， 这些人比拟被动，往往很难承当起谈判的重任。从今天开 始，这类人就必须重新学习如何说话，如何大声的争论。沟 通，并不仅仅是大声说话，而是在表达自己观点的同时发现 问题并综合整理加以解决。除此之外，沟通的能力与社会经 验息息相关，与PM的见识联系紧密。在日常生活中，PM就要 多留心，多思考，当别人想到某个层次的

29、时候要争取比别人 考虑的更深。当然，也有一些不够踏实的朋友把沟通和吹牛 当成了完全的一回事情，在和客户交流的时候口假设悬河的说 一些不着边际的话。这种人，碰到不懂，不太认真或者好奇 心强的客户是有一定市场的；而有水平，负责任的客户往往 会觉得这种人不可靠，一般不会把单子交给他。PM需要把握 好这个度，吹是肯定要吹的，只是吹牛的时候一定要有基础 的去吹，对从来没涉及过的领域或者根本不懂的东西轻易不 要发表意见，挑选自己熟悉的方向合理的进行发挥，适当的 留上一两手，给对方高深莫测的感觉，效果最好。.优秀的售前团队 这个团队一般是由总经理发起并组建的，通常不指定PMP,对团队的成员如SALES, P

30、M, SA, ENGINEER们的团队合作提出了比拟高的要求。一般公司在接下一个单子进行到一 定程度的时候，PM往往会尴尬的发现协议上销售代表们对客 户的一些承诺是几乎做不到或者根本做不到的事情。这种情 况非常多，销售的任务是拿下单子，我听到的销售们说的最 多的就是没问题或者NO PROBLEM但是当我听到客户的 要求和销售的回答时我总是心惊肉跳，很不自然。销售是非 常辛苦的，为了建立客户关系，尤其是空白的市场是很不容 易的，往往为了一个单子会牺牲非常多。在这种情况下，和 销售进行协调自然而然的又落到了 PM的头上。在销售和客户做承诺之前，PM要主动的跟销售交流，提供粗略的总体设计 框架和技术

31、难关以及能考虑出的工作量，而不是等出了问题 再被动和销售在老板面前互相推委责任。在组建团队的时 候，PM要根据团队里每个人的素质和任务进行因人置宜的信 息传递。优秀的售前团队合作是接单的重要保障。在商务谈 判的实际操作中，存在着各式各样的问题，PM的职责和要求 绝非以上几点所能描述详尽。根据环境，政策，人文，关系 等各方面的不同情况，PM的不同成长经历，每个PM最终都会 建立自己对商务谈判的看法和经验。但是有一点可以肯定， 这是PM成为PM的第一道关，也是最重要的一关。接不到单 子，PM将失去存在的意义。与销售有所不同，PM在该阶段的 任务除了接单，还要尽可能的客户关键人物的资料并与 对方各个

32、阶层的负责人建立良好的客户关系，以便在工程实 施时充分调动资源。二.启动阶段.工程的一些基本概念工程三要素有多种版本，各不相同。实际操作中多分为范围，本钱与进度，其中最重要的莫过于范围。我们把工程 最终生成并提交给用户的产品和文档统称为递交件。谈判的 时候一定要确立递交件的标准和要求，也就是范围。尽管商 战的时候不可防止的客户会不断提高标准和要求，而承诺的 款项却不会有一分钱的增加。但是这个标准对每个公司来说 都有一个底线，一旦超过了这个底线，那工程就肯定是亏 的。除非是为了二期有利可图或者是为了搞好关系，否那么范 围超过底线的时候情愿不做，再厉害的PM在这种情况下也是 无能为力。建立范围需要

33、的就是PM的多年的实战经验，在大大小小的工程中用血泪换来的一些体会。在这个时候，很能 表达PM与技术人员的区别。本钱就是客户容许付的款项，与 我们的投入本钱并不是一回事情。进度就不用多描述了。工程如何成功？也有一些关键的因素。个人的理解也不尽相同，通常包括以下几个方面：界定工作目标及工作任 务；老板或高层的支持；优秀的PM和开发团队；充足的资 源；良好的沟通；对客户的积极反响以及适当的监控和反 馈。这里要注意的就是资源和高层的支持。一个上规模的公 司总是同时会有很多工程，可是再大规模的公司资源也缺乏 以保证每个工程都能组建最合适的开发队伍或拥有最好的环 境。这时候各个团队或者部门之间不可防止的

34、会发生资源争 夺战，摩擦再所难免。这时候对PM的作人再次提出挑战。除 了高层对PM工程的重视程度，如果PM平时在公司与同事相 处的好往往能使很多别人看起来很棘手的问题迎刃而解。相 反，一个不会作人的PM由于人缘差，即使高层强压别的部门 或团队配合，别人也会能拖就拖，延缓工程的进度和质量。 有时候，这种内耗对工程和PM来说是毁灭性的。对客户的积 极反响也比拟关键。一般来说PM已经被工程里大大小小的事 情搞的筋疲力尽，要PM去主动要求客户配合是很吃力的事 情。然而，这个时候，越是困难，越是觉得累，越是要去主 动。客户往往也不是特别的积极，主动与客户联系沟通和测 试能及早发现问题。从风险控制的角度来

35、说，问题发现的越 早，风险越小，损失也就越小。积极的态度可以带动客户的 积极性，在工程完工的时候，客户对你的感激往往是难以用 语言描述的，这对以后接单或者做二期三期会打下良好的基 础。因为在和别的新客户谈判的时候，新客户自然会找你的 老客户了解情况，这时老客户随意的一句话顶的上你很费心 的十句。该工程具有商业行为的几个重要特征，包括消费来源、参 与者、成功的关键因素、财务目标和风险。.启动阶段的主要任务根据PMI的解释，接单之后工程自然转入启动阶段。启 动阶段PM的主要任务是率领总体架构设计师和系统分析员收 集尽可能详细的数据，确立尽可能详细的需求，进一步确立 详细的工程范围，预估资源，确立其

36、他方案并获得进入下一 阶段的批准。在这个阶段，随着需求分析的深入，PM也开始 在公司内部进行人员挑选和资源争夺，着手组建自己的工程 团队。工程即将进入计划阶段。在收集完数据之后，PM要和客户开始明确工程的大小,本钱,本钱,规格,期限等重要特征并将其写入合同文本，同时准备内部的包括预算，衡量标准等文档，建立工程的评估标 准。接下来就是需求分析。由于专业的原因，我们这里仅讨 论软件工程工程的需求分析（以下简称需求分析）。需求分 析的主要参与人员有PM,总体架构设计师，系统分析员，熟 悉业务流程的客户。PM统领的团队这时候还不是真正的开发 团队，我们叫做前期团队。随着需求分析的逐步深入，新的 团队成

37、员不断加入，启动阶段结束的时候正式的团队将建 立。对一个已经启动的工程来说，需求分析直接决定了工程 的成功与失败。最初的需求表达在客户的工作说明书或招标 文件及附件上。这种需求一般比拟含糊，无法表达客户真正 的需求。前期团队要根据自己的经验和客户沟通并引导客户 进入正轨。有时候客户会很不讲道理或者思路僵化，就要求 按照他的思维去定一些明显错误的需求。这个时候团队成员 要耐心和客户举事实，谈经验，讲道理，用图形或模型等直 观的方式将需求描述出来，比方常见的数据流图等。所以 说，争论再所难免，客户有时候会吹胡子瞪眼睛拍桌子甚至 会说这个东西不要你们做了 之类的话。PM此时除了要亲身 参与需求分析综

38、合整理文档之外，还要处理好团队成员与客 户的关系，确保关系不会恶化到无法收拾的地步。只要PM尽 力约束团队中的成员，这个度还是很容易控制的。对快速开发和叠代开发来说，需求和实现往往是同步进行，开发速度 快是一大优势。对有相同或类似模式的小工程来说采用快速 开发或叠代开发是很合算的做法，时下流行的极限编程就是 针对这方面建立的思维模式。然而，大中型工程中有太多不 一样的需求和模块。如果不是因为工程有差异，那么市场上 就只有产品而没有工程了。所以，大中型工程的需求要认真 仔细的去做。我们要讨论一个问题，究竟应该在需求分析和 总体设计上花费多少时间？我们熟悉的瀑布开发模式基本上 分需求分析，总体设计

39、，软件开发，测试等几个阶段，然而 究竟应该在前两个阶段上花多少时间却没有定论。实际工程 操作的例子说明，分析设计的时间越长，需求设计做的越详 细，测试的时间就越短，返工率越低，风险也越小，本钱越 容易得到控制。而需求分析和总体设计没有做好就急忙上马 进行开发的工程在工程初期进展顺利的时候问题不大，到了 工程后期和测试阶段一些潜伏期比拟长但是破坏作用比拟大 的问题就会凸显出来，造成返工，延长测试时间。所以与其 把问题堆积到紧张的工程后期，不如把时间多花点到需求分 析和总体设计上。基础夯实了，金字塔就容易造了。在日本 公司打工的程序员们可能都知道，小日本的软件规范非常厉 害，他们花在需求分析和总体

40、设计上的时间通常在40%到50% 左右，远远超过国内软件工程的实施，效果也要强的多。他 们总体设计的规范甚至详尽到某个过程该如何判断，确立什 么样的条件，换言之就是把什么时候该如何写(if.else)语 句都帮程序员定好了。在这样的软件规范下，程序员更象是 装配流水线上的工人，对一个模块或技术熟悉到一定程序就变成了完全的重复性劳动。所以在日本和欧美经常会有程序 搬，对国内的程序员来说是很不公平的。在国内，只会照抄 别人代码，一点都不懂创新，凡事依靠别人，快下班就盯着 表看的程序员是不少，这种人一般很难有什么前途。但是， 优秀的不断进取的程序员也很多。由于国内没有象CMM这样 的软件规范或者很少，所以这类优秀的程序员不少都是干着 系统分析员甚至PM的活，拿着程序员的工资。这类程序员虽 然在起步时会吃很多亏，而且是主动找亏吃，然而几年之后 与前一种程序员的社会地位会出现明显的分化。当上进的程 序员们作为PM进行商务谈判的时候，前者还在各个公司里频 繁跳槽，跳来跳去都不满意。有些扯开了，回到我们的话 题。员是低级工