商务谈判的执行阶段

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

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

3、向时会对对方的人 事和关键人物有一定的了解， 然而大项目里能说的上话的人太多了。 上海 人最瞧不起的就是土气， 很多人谈项目的时候看到民工或很俗气的表现不 免会皱皱眉头， 往往在皱眉头的时候就失去了项目， 也就是失去了市场和 金钱。PM必须作到能与每一个层次的人交谈，尤其是看起来比自己层次 要低的群体，哪怕是公司里扫地的阿姨。只有作到谦虚谨慎，不摆架子， 尊重别人， 才会得到别人的尊重， 才有机会赢得项目。 鼻子比眼睛高的人 只会把自己的鼻子撞扁。2. 丰富的知识面 光尊重别人还不足以赢得项目，准确的说是赢得对方关键人物的信赖。 PM般用不着陪客户喝酒吃饭，那是销售们的事情，但是 PM和客户讨

4、论 问题可能是最多的。 讨论问题的时候就是机会， 如何投其所好， 是一大关 键。金钱与美女依然是常规的敲门砖， 然而这种傻瓜也知道的办法人人都 会去做。 老板的关系也只是一个方面， 如今的大老板， 哪个没有关系？同 等条件下PM凭什么去胜过别人一筹？我一个朋友（PM打一个单子时，发现对方对什么都不太感兴趣， 费了很大力气也找不到突破口。 对方这个 人非常顺利， 金钱地位美女样样不缺。 他花了好多天和对方交谈， 以自己 的博学逐渐取得了对方的信任。 后来他隐约发现对方对数学和天文学的发 展史有所涉猎，如获至宝，回家花一个通宵的时间在网络上搜索相关资料。第二天他根本不谈项目的事情， 只跟对方大谈特

5、谈哥白尼， 布鲁诺，伽利 略这些人的生平， 整整吹了一天。 对方点头如捣蒜泥， 态度和热情都来个 一百八十度转弯， 隔天他就拿到了单子。 这是个经典的战例， 谁能事先想 到哥白尼会来帮助IT的人赚钱？这个PM靠的就是博学和由博学引申出的 敏锐的感觉抓住了机会， 让客户产生共鸣。 客户感觉他层次也很高， 而且 和自己有共通之处， 信任度大大增强， 把项目交给他放心。 如今这种例子 在商务谈判中已经屡见不鲜了。对 PM来说，并不要求在各个方面都很精 通，那是不可能的事情，只要 PM对一些流行的话题和天文地理历史各方 面的知识有个大概的了解， 在需要的时候能尽快的掌握， 才有机会创造机 遇和把握机遇

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

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

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

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

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

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

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

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

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

15、是真正的开发团队，我们叫做前期 团队。随着需求分析的逐步深入， 新的团队成员不断加入， 启动阶段结束 的时候正式的团队将建立。 对一个已经启动的项目来说， 需求分析直接决 定了项目的成功与失败。 最初的需求体现在客户的工作说明书或招标文件 及附件上。 这种需求一般比较含糊， 无法体现客户真正的需求。 前期团队 要根据自己的经验和客户沟通并引导客户进入正轨。 有时候客户会很不讲 道理或者思路僵化， 就要求按照他的思维去定一些明显错误的需求。 这个 时候团队成员要耐心和客户举事实， 谈经验， 讲道理， 用图形或模型等直 观的方式将需求描述出来， 比如常见的数据流图等。 所以说， 争论再所难 免，客

16、户有时候会吹胡子瞪眼睛拍桌子甚至会说 这个东西不要你们做了 之类的话。PM此时除了要亲身参与需求分析综合整理文档之外，还要处 理好团队成员与客户的关系， 确保关系不会恶化到无法收拾的地步。 只要 PM尽力约束团队中的成员，这个度还是很容易控制的。对快速开发和叠代开发来说， 需求和实现往往是同步进行， 开发速度快是 一大优势。对有相同或类似模式的小项目来说采用快速开发或叠代开发是 很合算的做法， 时下流行的极限编程就是针对这方面建立的思维模式。 然 而，大中型项目中有太多不一样的需求和模块。 如果不是因为项目有差异， 那么市场上就只有产品而没有项目了。 所以，大中型项目的需求要认真仔 细的去做。

17、 我们要讨论一个问题， 究竟应该在需求分析和总体设计上花费 多少时间？我们熟悉的瀑布开发模式基本上分需求分析， 总体设计， 软件 开发，测试等几个阶段， 然而究竟应该在前两个阶段上花多少时间却没有 定论。实际项目操作的例子表明， 分析设计的时间越长， 需求设计做的越 详细， 测试的时间就越短， 返工率越低， 风险也越小， 成本越容易得到控 制。而需求分析和总体设计没有做好就急忙上马进行开发的项目在项目初期 进展顺利的时候问题不大， 到了项目后期和测试阶段一些潜伏期比较长但 是破坏作用比较大的问题就会凸显出来， 造成返工， 延长测试时间。 所以 与其把问题堆积到紧张的项目后期， 不如把时间多花点

18、到需求分析和总体 设计上。 基础夯实了， 金字塔就容易造了。 在日本公司打工的程序员们 可能都知道， 小日本的软件规范非常厉害， 他们花在需求分析和总体设计上的时间通常在 40%到 50%左右，远远超过国内软件项目的实施，效果也 要强的多。 他们总体设计的规范甚至详尽到某个过程该如何判断， 确立什 么样的条件，换言之就是把什么时候该如何写 (if.else) 语句都帮程序 员定好了。 在这样的软件规范下， 程序员更象是装配流水线上的工人， 对 一个模块或技术熟悉到一定程序就变成了完全的重复性劳动。 所以在日本 和欧美经常会有程序员是低级工作一说， 很多人不明就里， 对国内程序员 也照搬，对国内

19、的程序员来说是很不公平的。 在国内，只会照抄别人代码， 一点都不懂创新， 凡事依靠别人， 快下班就盯着表看的程序员是不少， 这 种人一般很难有什么前途。 但是，优秀的不断进取的程序员也很多。 由于 国内没有象CMM这样的软件规范或者很少，所以这类优秀的程序员不少都 是干着系统分析员甚至PM的活，拿着程序员的工资。这类程序员虽然在 起步时会吃很多亏， 而且是主动找亏吃， 然而几年之后与前一种程序员的 社会地位会出现明显的分化。当上进的程序员们作为PM进行商务谈判的时候，前者还在各个公司里频繁跳槽，跳来跳去都不满意。有些扯开了， 回到我们的话题。日本的软件规范与CMMT惊人的相似，其中至少有35%

20、以上都是几乎一模 一样的。 最近经济不景气， 东京倒闭了 160 家软件公司， 这个数字是今年 6 月份的，还在不断增加。这些公司纷纷抢滩上海，招收技术人员。如果 去这样的公司应聘就要考虑清楚了，进去可以学到他们的规范和质量控 制，可是要想从程序员成为系统分析员或 PM比登天还难。往往一个程 序员进去干了好几年， 对自己的那一块熟的不得了， 而对隔壁同事所做的 东西一窍不通。拒传华为正在尝试CMM4华为印度研究所已经通过 CMM),对在华为工作的程序员们来说可谓福祸难料。当然，已经作到PM或 QA或者热爱CODING勺朋友例外。 需求分析本身也存在着时间分配的问题。 第一遍需求分析花的时间会最

21、长， 分析员们在客户的各个部门之间几乎把 腿都跑断， 把口水说干， 就是为了确立一个初期的需求模型。 所有的文档 将会提交给PMI进行复审并签字，不合格的打回重做。反馈表随之将提交 给客户， 第二遍第三遍等等等等接踵而来， 与客户反复讨论和磋商， 反复 提交文档和表格，目的只有一个，明确需求。当PMI最终合并了所有文档并确立需求之后，最终生成的需求文档将提交给客户的各部门负责人签 字。这些文档将作为合同的附件添加， 以便在将来项目变更或者碰到重大 问题时和客户扯皮的重要依据。需要说明的是， 客户并非都是蛮不讲理， 但是说实话， 颇有无奈， 国内目 前的项目大多数客户为了不让自己的钱白花， 经常

22、变着法子提需求。 在启 动阶段明确需求并签字， 无论最终情况如何， 一份详尽的书面文档可以解 决很多口头承诺或概念模糊的文档带来的许多问题。 详尽的需求分析有 一个额外的好处就是对一些双方都很陌生或者从来无人尝试的领域将是 一个决定是否进行项目的判断标准。 有时候，这种大项目在签单时双方都 没有绝对把握保证可以出成果， 一旦在需求分析阶段发现难以逾越的技术 难关，就会放弃项目。典型的例子就是NMDN际导弹防御系统。上世纪八 十年代初美国搞星球大战计划，拖跨了苏联。大家对那段历史有些含糊， 很多人认为苏联人上了美国的当。 其实并不完全如此， 苏联人的情报机构 无孔不入， 并非那么容易上当受骗。

23、实际上当时美国国防部已经开始着手NMD系统软件的需求分析，前后耗资数亿美圆，耗时两年，仅仅是做需求 分析，终于发现存在着在当时技术上无法达到的高度，随后项目被放弃。3. 项目启动项目启动要确定项目计划， 与客户一起实施第一次项目审核， 确认并对一 些产品和服务向下包厂商下订单。这个时候的 PM会忽然发现有开不完的 会，一天开三到四个会议是很正常的事情。 这些会议有与客户的会议， 与 下包厂商的， 有团队的， 有公司高层的。 团队的会议主要是建立正式的团 队，提供团队成员的角色和职责， 提供绩效管理方法， 向成员提供项目范 围和目标。与客户的一个主要会议将是项目启动会议。在这个会议上 PM 会与

24、客户确立正式的交流渠道， 项目综合描述，让项目参与人员相互了解， 建立以PM为核心的管理制度。还有一些零零碎碎的东西甚至包括办公场 地的大小， 电话多少部， 所有人的联系方式等等都要在会议上确立， 并做 会议记录。这都是些非常琐碎的事情，听起来婆婆 * ，却是非常必要， 缺一不可。大概就是所谓三军未动，粮草先行吧。这时候，作为公司高层，应该向全公司发表申明，正式给 PM发布项目经 理任命书和项目授权书。 这个动作虽然在别人看来有些形式主义， 但是对 提高PM本人的士气和责任感是有很大助力的。三. 计划阶段 1. 定义结构分工结构图（ WBS）启动阶段结束后， 项目进入计划阶段， 也就正式进入实

25、施。 这里概念可能 有些不太对头， 其实是翻译的缘故， 反正大家明白意思就行， 不用拘泥于 字面。WBS是一组要提交的项目元素，用来组织定义项目的总体范围，具 体包括从工作内容， 资源，成本角度考虑项目范围； 建立一套系统所需要 的分层工作结构；把项目分解成易于管理的几个细目，这概念有些模糊， 其实跟资源管理器里分目录是一回事情。 可以说，WBS是计划阶段的核心。 WBS会详细的分到递交件，包括给自己人用的项目使用的过程文件， 给客 户用的模块和说明文档， 完成每个细目的标准以及如何把这些细目的责任 分配到具体的个人。WBS有缩进式和树状式，我这里也没办法画图，大家 参考一些项目管理的书籍，

26、里面有详细介绍。 我整个文章只挑我觉得需要 注意的地方，如非必要，对技术细节或者工具使用不做详细介绍。WBS勺细目并不需要分解到同一水平， 最下面的细目叫做工作包， 分包的依据是 个人的责任和可信度， 也就是说到每个人头上的任务是否能落实， 是否有 把握完成；还有就是准备对项目进行控制的程度，程度越深，WBS树也就越深。由于WBS是实用性的东西，根据个人理解也不一样，所以一个项目 可能会有几个正确的 WBS看PM的需要和最适合当前团队状态的进行选 择。WBS勺定义还是很麻烦的。PM要召开团队进行讨论，向成员提供与项目相关的所有详细资料， 并把W BS树分解到二层三层。然后要花上一段时间让成员进

27、行头脑风暴式 (BRA INING STORM思考，制订工作产出和相应人员的职责， 记录每一个工作 包的完成标准。在头脑风暴式思考时，会有很激烈的争论， PM要协调关 系，调节气氛， 从自己能考虑到的各个角度旁推侧敲， 提示成员的思维角 度和方向并加以总结。尽管很麻烦，制订WB3仍然是非常值得的。女口同需 求分析一样，WBSB备的越充分，编码的进度越快。2. 风险管理既然是商业行为， 那么项目的风险必然存在， 相信阅读这个帖子的朋友不 少人都经历过或大或小的风险。 有些风险很容易解决， 有些风险则大大损 害利益。 不论什么样的风险， 能避免尽量避免， 所以有必要对风险进行管 理。由于风险的不可

28、预知性， 风险管理难度很大， 概念也很难讲清楚， 只 能从一些可行的角度去分析，进行管理。首先要识别风险。这是个难度很高的活。 PM要先召开风险识别会议，这 个会议面向公司， 高层，跨部门的有经验的人都将参加。 然后审核由项目 小组生成的风险清单并与重要成员进行风险沟通， 检查一些重要的风险源 如WBS成本（时间）预估，人员计划，采购管理等等。最后就要用到PM本身在以前类似项目中得到的经验教训。识别之后要进行分析。 我们可以进行粗略的量化分析 （精确分析是不可能 的事情）。有经验的人可以一起参加讨论，把提交出来的风险进行分类。 首先按发生的可能性分，一般分成高，中，低三个级别，虽然很勉强，但

29、是好歹也有个量化了；然后按耗去的成本分，也是高，中，低三级。我们 可以把这两种类别的三个级别进行组合， 碰到可能性也高， 成本也高的风 险就定位为不能接受。 碰到这种风险只好让客户修改需求或者增加风险预 留成本， 否则一旦亏起来不是亏一点点， 有可能赔的很厉害。 高和中， 中 和中的搭配都是属于高风险， 中和低，低和低搭配属于低， 高和低搭配属 于中。针对出现的可能性， 需要采取一些手段降低风险。 到目前为止也没有一个 定论说有绝对好的方式， 只能尽其所能的避免。 有几种方法可以考虑， 第 一种是将风险纳入项目管理计划并指定负责人， 由外部人员定期检查项目 风险，一旦风险发生，执行风险管理计划

30、； 第二种是保险，这种属于风险 转嫁；第三种方式有点奸， 不过最保险， 就是把客户拖下水， 让他们一起 参与风险管理， 呵呵，到时候就好说话了： ) 风险管理作为项目计划之 后，PM需要更新WBS修改日程计划和更新风险管理计划。风险预留通常是成本的 8%。3. 预估预估是从量化的角度对项目进行评估， 主要包括工作量， 任务期限，人力， 设备， 材料，成本等， 要注意预估不是财务策略或报价。 预估其实并不 是一次性工作， 在整个项目过程中， 预估始终需要。 预估似乎没什么特别 需要提的地方，每个PM接到项目的时候自然会有预估，在项目发生变更 或进入下一阶段时也会预估。预估的作用主要还是让PM作到

31、心中有个底， 安排计划时不至于毫无头绪。4.进度计划 进度计划就是一个模块或功能要写多长时间，PM安排个日 期，设立里程碑，叫程序员们不能偷懒。进度计划是从 WBSI取过来的。 对PM来说，合理的安排进度计划对项目控制和激励团队士气有着很大的 作用。对程序员来说， 进度计划毫无疑问是噩梦。 显示进度计划一般有 先后顺序图，甘特图和里程碑图表。上回邵卫老师讲课，推荐的工具是 m $的PROJECT这个工具我还不会用，因为没时间去摸索。我的头倒是用 的很溜了，近一个月来他就用这个 PROJEC画了一个又一个的里程碑图， 不停的折磨我和同事的神经。 我们一般都是一边开发一边做 UNIT TEST，

32、效果上来看， 因为有强大的时间压力， 效率上比之前确实要提高不少， 可 是我们也只能结结巴巴的赶完进度。由于 TEAM里人少，我们都是一个人 做几个人的活。 我每天早晨六点多出门， 经过将近两小时颠簸， 八点多点 已经坐在位子上，中午吃 15 分钟的饭，干到晚上八点下班，到家吃完饭 往往已经 11点了。一个多月我从来没吃过早饭，没有睡过六个小时以上 的懒觉。虽然强大的压力使我们能在短时间内掌握尽可能多的技能， 开发 更多的模块， 但是对我们的情绪也是有很大的影响。 所以说， 项目里程碑 是一把双刃剑， 合理安排才能既促进效率也不至于打击士气。 团队成员士 气的逐级衰落会给项目后期的开发带来难以

33、估计的影响， 进度将会大大延 缓。关于PM和团队的问题我们后面会讲到，这里我先祥林嫂一把，然后 跳过。 里程碑图表的特征是任务， 成员和时间，任务和成员用文字标志， 时间用数字描述并辅助以图线跨度， 象阶梯一样非常形象， 一目了然。 管 理起来非常方便，完了的打个钩就可以了。网络逻辑图是表示任务和逻辑关系的示意图， 可以用先后次序表示， 也可 以用关键路径表示。其实把各个活动划分为 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 等，日程计划也分四种，一般只提到从前向后和从后向前两种。从

34、前向 后的概念就是某项活动必须相同或晚于直接指向这项活动的的所有活动 的最早结束时间的最晚时间。有些绕口，我们打个比方： 2 阶段指向 3 阶 段，那么 2 阶段里的 4 个子阶段也都指向 3。假设 2.1 结束时间为 1 月 1 2 日，2.2 结束时间为 1 月 22 日，2.3 结束时间为 1 月 15 日， 2.4 结束时 间为 1 月 20 日，那么，2 阶段中最晚的结束时间是 2.2 的 1 月 22 日，所 以在 3 阶段中的 3 个子阶段 3.1 ，3.2 ，3.3 的最早开始时间都不能早于 1 月 22 日。至于从后向前的例子大家自己去推吧，我就不举了，刚才几个 123 打的

35、我累死了：） 项目经常需要调整进度。在不改变项目范围的情 况下，调整进度有几种方法： 利用快速跟踪手段来改变任务间的关系； 将 串行的任务改成并行；改变工作方法（可能改变 WB$;改变日期限制， 使关键路径上的任务开始或结束的更早。虽然方法多样化，在我看来只有一条，就是拼命的压榨程序员的劳动力。 如何压榨， 还是个技巧。 如前面所分析的， 需求分析恨不得多分点时间给 它，压需求是不太可能； 测试阶段后期接近完工， 罗里巴唆的事情一大堆， 忙都忙不完，那时候PM一门心思提前/按时完工，好收钱，压那段时间似 乎也不太可能。说来残酷，最能压的还是 CODING编码阶段往往是压缩 重点，总之大家埋头苦

36、干就是了， 大项目压缩的时候程序员吃喝拉撒都在 公司是很正常的事情， 相信不少人都有很深的体会， 这里伤心事情也就不 提了。只是我总结一下，让未来的 PM们有压榨后来人的依据，呵呵。测 试前期也可以适当的压一压， 那时候人刚完工， 都比较懒散。 国内一般企 业规模都不大， 没有专门的质量控制部门， 所以质量保证和测试往往就是 程序员或PM本身。其实质量保证和测试人员的人数和素质都应该要高于 程序员。在日本和CMM施的公司里，编码压缩是很容易实现的事情，因 为那些程序员真的是技能熟练的装配工人， 压起来方便的很。 他们这样培 养人的目的或许就是为了压缩吧？！四. 控制和执行阶段1. 软件开发 实

37、在没什么好说的， 也是大家最不愿意谈的， 平时在公司里 谈的已经够多的了， 还要在这里受我唠叨。 需要提醒的依然是团队合作精 神和完善的文档管理制度。SOURCESAFE些工具有时候还是有必要使用 的。经常看到有人说天才程序员不写注释什么的。 我相信有这种天才程序 员，因为我碰到过几个。我爱人公司里也有一个， 他们的一套产品核心代码就是这个人写的， 4年 过去了， 周边代码换了好几茬， 核心算法始终没换过， 可惜这小子跟了李 洪痔，如今已经不知所踪了。 但是他的代码似乎也要有点注释的， 没有注 释过段时间再天才的程序员也不能保证他是最有记忆力的。 而且，对一个 项目的编码来说， 靠一两个人打天

38、下如今是不可能了。 别人的公司都是团 队，两人智慧胜一人， 这头还在靠一个天才支撑门面， 实际上市场可就别 人抢了去，那时候再天才也没用了。编码的时候讲究技术公开，程序员不要藏着掖着，对大家没好处，PM要想办法调动大家创新思维的积极性， 营造良好的技术讨论氛围， 碰到技术 难关的时候就容易攻破了。有个问题需要单独对还没有 PM觉悟的程序员说，其实是在调研的时候就定了的， 就是使用什么样的开发工具。 没有 经验的程序员往往会拿着C+或者JAVA的资格证书或者拥有一两个开发 工具的一些经验而得意洋洋。其实老板和 PM根本不看重这个，他们关心 的是使用什么样的工具能尽快的达到目的。管你什么 C+，

39、DELPH，I PB 还是JAVA只要能做的出来，VFP都可以用。我举这个例子并非说不看中 工具，而是提醒想转型为 PM的程序员，第一要把工具当作工具，而不要 被工具套进去， 钻研一些一辈子都用不上的技术； 第二要掌握的并非是单 独的一个工具， 而是流行的程序设计的思想， 以及在最短时间内掌握一门 陌生工具的能力。只有建立了这样的思维，才有可能转为PM否则一辈子都是技术工人，最多就是个技术总监。2. 变更 对任何项目， 变更无可避免， 无从逃避，只能去积极应对， 这个 应对应该是从需求分析就开始了。对一个需求分析做的很好的项目来说， 基准文件定义的范围越详细清晰，用户跟 PM扯皮的幌子就越少。

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

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

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