项目经理面试指南

简介

　　本文的目的是为应聘项目经理提供帮助。项目管理是升迁的途径，需要运用你过去的开发经验，而且薪水通常高于程序员。应聘项目经理的准备工作包括：复习一些常用的概念、术语，问自己一些在面试中经常问到的问题。
学会运用一个或多个项目管理计划编制工具。通过以上的准备，将为你应聘这个职位增加信心。
　　想好你要说的内容并准备回答涉及面广泛的问题是成功应聘的重要方面。与应聘技术职位不同的是，项目管理问题的答案往往是主观的。要牢记技术项目的项目经理的职责是组织项目成员通过完成技术任务而达到某种商业目
标。该技术任务应该是可应用或维护的，都必须满足客户/用户的要求和期望。
　　本文的目标并不是教授如何进行项目管理。这方面有许多很好的书、杂志和研讨班。本文或本文的参考书目中将列出一些。本文将介绍如何回答有关应聘问题的方法和思路。你可以根据自己的经验，观察其他项目经理，应聘
职位的岗位描述对答案进行组织。无论被问到什么问题，无论你如何回答，记住运用一个项目经理最有用、最重要的特性…….常识。

　　一、什么是真正的项目管理

　　任何成功的项目都不可能是某一个人的功劳。一个成功的项目是多个部门的众多人员共同努力的结果。这些人，组成一个项目团队，具有不同技术水平，才能，工作风格和知识。
　　项目团队需要有一个共同目标，共同的前景，并且清楚的知道他们要做的工作。该团队，无论采取何种报告结构，必须能够很好地工作和激励以达到商业目标。
　　项目经理是项目团队的领导。他/她的职责是激励团队以积极的方式完成任务。该职位需要具有技术和人际技能，需要每天关注的内容（顺序如下）如下：
　　业务
　　公司
　　项目
　　团队
　　个人

　　技术和方法的变更

　　项目经理的技能应包括技术技能和管理技能，坚实的技术基础能够在技术方面对团队起指导作用，管理技能有助于沟通和解决问题。管理技能不仅限于技术方面，还包括解决问题的能力，估算能力，编制计划的能力，人际和
沟通能力。
　　你可能已经意识到自己忽视或缺乏某些领域的知识。因此，本文的读者为：
　　没做过项目经理的人
　　已经是项目经理，但认为自己的技能已经过时的人

　　二、项目经理是什么

　　项目经理角色

　　项目管理是估算、计划编制、重组、整合、评估和修正等过程的不断重复，其中包括管理人员，用户参与和解决问题，直至达到项目的商业目的。

　　管理层需要什么样的人

　　每个经理都在找有能力完成某一商业目标的人。最困难的是要了解他们懂什么和能做是么。比较困难的是，不知道需要多少人。因此，你必须使招聘人员认为你是真诚可靠的。这不仅限于项目范围内，还包括与管理层和客户
保持联系。
　　管理是指无论在有利或不利的环境中都能应对自如。在问题没有被详细表述或没有可选的解决方案时，你必须表现出你的管理才能。如果你让管理层来解决所有的问题，那要你还有什么用，管理层正在做你做的工作呢。

　　人员管理技能

　　了解人们的心理和他们的工作方式是项目经理必需的素质之一。每个人都不同。通过了解你的和别人的工作方式，可以缓解压力，便于沟通。
　　IBM多年来的口号是“尊重每一个人”。这具体表现为了解你日常工作中接触的人。要做到这点，你必须了解你自己并且知道你是如何激励别人或对别人施加压力的。
　　阅读迈尔斯-布里格斯（Myers-Briggs）人格类型分析方面的书籍是一个很好的开端。Katherine Briggs和她女儿Isabel Briggs-Myers制作的问卷（MBTI迈尔斯-布
里格斯人格类型定向）用于帮助人们发现他们的个人风格及对团队产生的影响。该问卷是在Carl Jung的“心理类型”基础上发展而来的。此类书在书店有关自我提升和心理学的分类中均能找到。
　　你应该理解个人工作风格，并且牢记这些实践经验。以下所列的项目应该成为与人相处的第二种本能。也是每个想成功的项目经理必备的常识：
　　尊重每一个雇员（供应商）
　　虚心倾听
　　做出见识广博的决策
　　不要当众批评别人
　　了解自己的实力和做事的先后顺序
　　真诚地听取团队成员的意见和建议
　　对目标和交付产品有清楚的了解
　　在IT团队中提倡合作和信息共享
　　了解每个人的做事风格及他们的优缺点
　　表扬应以团队成员喜欢的方式，真诚地表达
　　将负面影响视为成长的机会
　　以积极的方式提供指导

　　你不能管理你无法控制的东西

　　如前所述，项目管理是执行一系列可重复的任务以完成某个商业目标。为了完成任务，你必须建立控制体系。因此，应对下列方面的问题有所准备：
　　度量方法：度量方法如果没有管理好或运用好，会产生负面影响。度量方法可以作为计划编制的“输入”，可以在项目进展过程中和结束时进行统计，为下一个项目或项目的下一个阶段提供参考。用度量方法来评估员工的绩
效是不恰当的。
　　项目计划：通过制定项目计划能够得到正在执行的任务的关键检查点。这些检查点是达到商业目标的路标。要记住项目计划不仅只对新的开发项目有用。他们在支持和维护中同样重要。许多项目经理都犯同样的错误，他们编
制一个十分出色的计划，但从不付诸实施。事实上，他们很少按计划进行工作。
　　预算：估算和编制计划的同时要做预算。许多项目经理要制作和管理他们自己的预算。如果你能使实际工作进展和计划一致，那么你的工作就会变得比较简单。大多项目管理工具都具有使费用（按小时，天，或年计）与某个
资源相关。许多公司的财务部门认为的资源费用包括企业一般管理费用。另外一些公司可能根据项目名称或用户，管理方式，员工和顾问分别计算。（对于顾问，还要考虑他们的加班费）设备费用也要单独考虑。记住还要考虑运
行项目应用所需的软件工具和硬件。（例如销售部门的彩色打印机）
　　员工工作计划：人是任何项目中有价值的。一个人可以促进项目成功或项目进展顺利，也可能对项目产生破坏。员工工作计划能对员工的成长起到建设性和实际作用。大多组织有自己的格式。但无论形式如何，下列事项必须
包括： 职责明确；客观地评价员工的优缺点；为员工提供参与制定其发展方向和对其进行评估的机会。

项目管理的奖励/压力

　　项目经理的角色是一柄双刃剑。这个职位要承担一定的压力，也会得到相应的奖励。一旦你成为项目经理，就必须对这两方面做好准备。
　　成功地完成一个系统，每个人都会得到奖励。能够帮助员工开发他们的潜能是项目经理特有的回报。在任何任务中，人都是最重要的元素。通过运用自己的管理技能造就了一个充满活力的团队，是一件值得骄傲的事。
　　人员同样是最大的压力。人毕竟会受到那些不受你控制的事物的影响。团队成员的家庭困难，彼此间的个性冲突都需要项目经理来处理。
　　任何有关应用或团队成员的事情首先要找的就是项目经理。上层领导和用户认为你是对项目拖延、需求遗漏、系统中的bug和不正确等唯一的负责人。

　　三、准备面试的方法

　　书、杂志、组织和研讨会

　　本文的参考目录中列出了许多能得到有效的管理实践信息的地方。去寻找管理方面的书籍，包括技术管理和商业管理两个方面。阅读管理大师，例如：Peter Drucker，C. A. Gallagher和A.
Maslow写的书和文章。他们提供了在任何领域都使用的管理知识。信息管理大师例如：Tom DeMarco, M. Page-Jones, Ed Yourdon, L. L. Constantine等
等提供了许多条理清楚的、经过实践检验的方法。
　　如果你要同用户一起工作，要阅读一本有关领域的专业书籍。了解业务比了解技术环境更重要。事实上，让用户参加面试过程越来越流行。要准备得更充分，可以买一本《哈佛商业评论》（Harvard Busines
s Review）这是一本很好的杂志，适用于商业读者同样也适用于IT管理。许多IT杂志例如《CIO杂志》及在参考书目中列出的书目中都有有关项目管理和人员管理方面的文章。这些杂志中还包括概括或详细的技术
性文章。
　　可以和美国管理协会（AMA）和其他商业组织取得联系，获取管理信息。值得一提的是，卡奈基梅隆大学的软件工程研究所（SEI）在90年代提出的管理软件过程，最新标准版本为SEI9000。
　　许多技术研讨会，例如数字咨询和技术转换研究所（Digital Consulting and Technology Transfer Institute）有许多不同领域的项目管理和技术研讨会。另一种
途径是通过你所在的组织。他们也许会提供有关授权、谈判和倾听技巧等的课程，所有这些都有助于你准备项目管理。

　　你应该了解的软件

　　掌握一种项目管理工具。例如微软的Project和Applied Business Technology/Project Workbench。所有这些工具都有许多有效的项目管理方法和术语字典。
　　除了上述提到的工具外，还有一个越来越流行的工具可以针对不同技术环境中的项目在计划编制、费用估算和管理方法上提供帮助。这个工具就是LBMS/Process Engineer，具有CASE界面的工具。

　　如果你使用过此类工具，把这些内容列在你的简历中。当然，不仅要掌握工具，你还必须具有坚实的基础知识和项目管理方法。
　　一个项目经理必须足智多谋。通过email进行通信已经取代了电话和邮寄备忘录。许多公司有自己的系统，还有许多公司使用Lotus Notes。无论是用何种产品，必须具有如下性能：
　　能够与处于不同地理位置的人取得联系
　　能够有效地通知团队（包括供应商）范围，进度的变更
　　能很快地解决小问题
　　要记住人们工作方式的差别，性格内向的人更愿意通过email沟通。这样他们可以有时间思考问题的答案而不是在会议上立刻做出答案。
　　作为一个项目经理，你可能会作报告（report）和介绍(presentation)。因此，需要掌握字处理软件和图形软件。这些软件在市场上都可以买到。在你的简历上列出你会使用的此类软件。

　　寻找思想

　　任何行业都有好的项目经理和差的项目经理。你可以从两种项目经理身上得到启示（什么是应该做的而什么是应该避免的）。如有可能，问一些优秀的项目经理他们是如何做的。如果你对你的职业发展道路还不太清楚，你可
以拿一篇刚刚读过的有关文章，问问这些项目经理对此文的观点。
　　一个成功的项目经理的标志有拥有一支气氛融洽的积极的团队，上层领导的信任和用户的尊重。一致的行动是另一个标志，它是衡量领导能力的基础。优秀的项目经理应该了解每个雇员的长处和短处。他们认为失败并不是缺
点，而是一次学习机会。
　　项目经理必须建立一套专业标准。但按照一套完美的例子来进行管理却是一个失败的项目经理。这虽然说明他们的多才多艺，但更体现了他们在授权和沟通方面的能力不足。使原来想积极工作的员工变得消极的做法可以毁了
项目经理。你在技术方面的能力应该用于指导和培训员工。如果你参与编程或设计，你不是在开发你的团队，也不是在做项目经理。

　　项目计划技术

　　以下是在面试中通常会提到的有关项目计划编制的术语和图表。大多项目计划编制工具都会使用到一些或全部术语和功能。你应该复习一下有用的一个或多个项目管理工具，这有助于你进一步熟悉常用的技术和功能。
　　图表类型：
　　甘特图：用图形，特别是条形图，描述项目进度的图表。每一个条形符号代表不同的意义。例如：关键任务的条形符号及/或颜色可能与非关键任务的不同。概要任务（活动或阶段）的符号可能于其他任务不同。
　　Pert图：用流程图来表示所有任务的现行依赖关系。PERT的意思是计划评价与审查技术，是一种网络图。
　　任务列表：文本/纵向地列出项目计划。通常至少应包括以下栏目：任务编号，任务名称，开始日期，结束日期，持续时间和工作效率。
　　工作分解结构：项目任务和/或活动的结构图。
　　关键路径：是贯穿整个项目的一条路径，表明在限定的时间成功完成项目涉及的各任务间的依赖关系。调整关键路径上任务的时间进度将会影响整个项目的交付时间。关键路径方法（CRM）图是一种网络图，用于项目的进
度控制和协调项目的活动和事件。
　　可交付成果：证明一个或多个任务完成的有形事物。例如：逻辑数据模型。
　　依赖关系：任务间的联系会影响一个或多个任务的开始时间。例如：在没有弄清需求前，不能开始编程。
　　JAD/简化方法：联合应用程序设计(简化方法是90年代的术语)。一套面向结果的,大脑风暴式的,有一个共同的商业目的信息集合/分享会议。该方法是IBM公司在1970年开发的，由固定的，结构化的过程组
成，并在一个有经验的实施者的领导下进行。简化方法去掉了一些结构,然而,仍要求所有各方都必须参加所有的会议和一个有建模技术的记录员作记录。参加者们包括项目团队,管理(与用户)和行政官员。为会议的成功，每
个人必须理解和同意目的并且尽快解决他们的任务。
　　延迟：是任务的结束时间和与其相关的任务的开始时间之间的延迟时间。这允许任务结束时间和开始时间的重叠和拉长。
　　方法论：一种明确的、有组织的、可重复的、结构化的方法/技术，以完成一个通用的目的。这些技术或指南定义步骤，任务，角色，目的和可交付成果，这些是任何系统的成功的实现所必须的。
　　衡量标准：一个一致并且可重复的测量一个项目的大小和复杂性的方法。标准准备在整个项目生命期中使用许多方法中的一个。今天公司使用的流行方法是：
　　a) 功能点（Allan Abrecht）
　　b) 重要事件 (Tom DeMarco)
　　c) 加权平均
　　d) 代码行
　　里程碑：在项目生命期的一个重要的事件的结束。通常一个里程碑是在关键的路径上的一项活动。它不必是一个有形的可交付产品例如一个逻辑数据模型，但可以是用户对工作成果的肯定。
　　阶段/活动/摘要标题：概要级的概念。不是所有的项目管理工具都强调特定的阶段和摘要一级的格式，然而许多标准的开发方法用这些术语进行工作分解。
　　RAD：快速的应用开发(如果不正确地使用会有破坏作用)。通过应用程序生成器，建模和快速原型工具的使用加快开发工作的一条途径。最大的改进是在整个开发生命周期中加入快速原型。这在编码前了解清楚用户需求
提供优秀的工具。
　　资源限制：一个基于可得到的资源的数量，每个资源的技巧的水平，资源工作时间表而开发的计划和时间表。
　　范围变更：对原先设计要求的功能增加而没有对人员，时间或费用的影响进行评估。范围变更可能是一个商业用户或一个热心的程序员提出的。两者影响系统的交付并且不能被估计，分析，或记录。

面试中的表达的要点(就算问题没被问)

　　如果你没有管理经验

　　对于那些从未正式管理过一个项目的，可能是非正式地管理过的人。在那些情况中，当强调他们的技术背景优势的同时需要明确说明他们没认识到他们已掌握的那些技巧。你可以提及你是怎么不得不在没有授权的情况下领导
一个大型的开发团队进行工作的。需要强调的是没有一个稳固的技术的基础,你的工程任务和估计的决定可能被过分简单化。当你是项目的领导人，你需要提供技术的连贯避免团队超负荷工作。

　　如果你的技术技巧在未来的技术的环境中是落伍或不同的

　　你不需要理解技术环境的内部是如何工作的，但是你应该理解一般的概念和特征决定环境的能力和弱点。许多项目管理技巧是超出技术范围的。因此,如果你的技术技巧是落伍的，你仍然能强调你在技术上能负独立责任。提
及你管理的应用类型和及其商业作用。提及团队是如何有效地完成目标的。强调你的管理哲学。提到上级，与你地位同等的人，你的用户和部下是如何评价你的管理能力的，记住提起任何你掌握的商务领域知识。在面试时应该将
你对你的技能落后的恐惧抛在一旁。一旦你拥有这个工作，你将能向公司内的专家询问。在所有组织中都有各方面专家的非正式的机构。你可以到处打听一下，把他们找出来。

　　问面试官的问题：
　　即使你通过面试，得到了这个职位，你还需要信息进行估价，这时是你的好机会。如果这将是项目经理的第一个工作任务，这尤其是关键。你需要明白你的工作环境。因此，你可以问下列问题：
　　1. 公司优先权是什么？
　　2. 本项目的执行资助者是谁？
　　3. 公司使用的开发原理体系是什么？
　　4. 本项目最后期限是什么？
　　5. 有量度项目成功的方法吗？
　　6. 你的新经理将怎样保持项目信息灵通？
　　7. 你的新经理管理哲学和风格是什么？
　　8. 项目上的人们的技能水平是什么？
　　9. 你将管理的项目的范围被充分地定义吗？
　　10. 技术环境已经选好了吗？

　　面试中通常会问到的问题

　　以下是典型的项目管理面试中通常会问到的问题（期望的回答）：很多的问题的答案是主观的，面试官想知道你的观点是否和他们的及公司一致。问题的构成如下：
　　1. 项目管理软件工具知识，
　　2. 编制项目计划的技术，
　　3. 人员管理技能
　　4. 沟通技能
　　5. 原理体系知识（标准开发生命周期和项目管理）。

　　项目管理软件工具知识

　　问题1：工期和工作量之间的差异是什么？
　　答案1：工期是商业/日历上的天数，与人数和工作量无关。工作量是与日历天数无关的人的工作。例如：
　　一天的工作量对于一个一只花50%在时间在上面的人来说，他的工期就是两天。如果两个人全职工作，工期是1天，而工作量是两个工作日。
　　问题2：怎样和为什么要在编制项目计划时考虑依赖关系？
　　答案2：根据使用的软件包，依赖关系可以通过将任务及其后续任务的标识符进行关联来表示。依赖关系说明了任务之间关联/并列的要求。依赖关系可以是指在另一个任务能开始之前有一个任务必须完成。例如，逻辑模型
必须在物理模型前完成。但测试并不是要在所有编程工作完成之后才开始，如果没有完成的程序对线性测试没有影响。
　　项目计划加入依赖关系，就能找出项目的关键路径并且能够确定它对项目工期的影响。
　　问题3：你怎样将人的工作步调与计划结合？
　　答案3：根据组织使用的具体的工具，可以将资源拆成更小的资源/单位，或者可以将任务拆成更小的任务。
　　问题4：你怎样将培训，假日和个人教育时间表结合起来？
　　答案4：每个产品都有标明不工作的天数的公司/全球的日历。每个产品都也有个人的资源日历标明个人不工作的时间。如果项目需要教育和培训，应该把它们象任务那样写在项目计划上。
　　问题5：你怎样安排类似状态会议这样贯穿整个项目但只需要极少的时间和工作量的任务？
　　答案5：它的工期将和整个项目时间一样长，占工作量的百分比很小。被分配给任务的每个人花在该任务的时间占他时间的百分比极低。
　　问题6：实况报告对计划的作用以及实况与最初预计的比较有何价值？
　　答案6：根据组织使用的特定的工具，每个工具都为实况报告中输入相互独立的要素/域信息。也可以将报表进行分类，来向团队成员和其他相关团体说明关键路径的变化或时间表的调整。这些报告对已实现工作评价和作为
在计划下一个工程或阶段的输入有价值。另一个把估计和实况报告比较的有价值的用途是把范围变更对项目的影响记录下来。

　　做项目计划的技能

　　问题7：你为什么制定项目计划？
　　答案7：项目计划是实现成功的系统的路线图。它提供了一种手段来通知每个人希望他们做什么及何时完成。它帮助项目经理使管理层，商务用户和支持团体了解项目状态和调整特殊的资源。逐项列记的“一览表”协助对任
何变动的影响进行迅速评估。当实况报告与计划联系起来后，项目计划为今后项目的任务划分和估算提供了有用的信息。
　　问题8：你将怎样着手做项目的计划？
　　答案8：进程安排是一门艺术。根据已知有关业务目标的事实，公司一般标准，以及可以利用的过去的经验。可以从清楚地定义范围和目标开始。把项目的风险和制约做成文件。差的估计源于对业务知识和项目范围缺乏了解
。可以从项目任务分解入手，例如先划分阶段，然后定义每个阶段的活动，再定义每个活动中的任务。识别和文档化里程碑和可交付产品。项目计划是当信息变得可以利用的时，不断细化的有生命文件。很好地记录进度的变化对
项目经理，开发团队，支持团队，以及管理层，商业用户都有益处。
　　问题9：你将怎样着手制定项目计划？
　　答案9：在适当的活动和阶段或其他的概括的标准说明下，输入确定的任务。将适当的可交付产品及里程碑和特定的任务联系起来。连接全部需要依赖关联的任务。把资源角色或资源名字加到每个任务上。应用度量结果确定
事先的任务工作量，把更多的时间用于需求收集，设计和测试。考虑所有已知的节假日，培训，休假或其他的资源停工时间。计划草案将同支持团体，管理层和商务用户一起复查，做为补充性的输入和最终的批准。
　　问题10：怎样确定人员需求？
　　答案10：不考虑资源限制进行计划开发。在任务旁边加上诸如数据模型制作者，业务分析员和用户等角色。再加上能将任务重叠起来的补充性的资源。在计划中要考虑开发团队包括支持团队和用户代表失去一个或多个资源
的情况，要在每个任务上增加15%的余量。要使项目小组的组成容易理解，要有角色所必备的技术水平的说明。
　　问题11：给项目加上测量标准有什么价值？
　　答案11：如果使用得当，测量标准是一个有价值的工具。它们提供测定开发系统的复杂性和工作量的方法。度量结果为制定项目计划提供了信息输入资源，并且是确定发展方向的有价值的历史信息。软件测量标准将有助于
开发更好的软件。不过，最好有3年的历史资料。
　　问题12：你怎样在计划中运用新技术？
　　答案12：在增加培训任务的同时要扩大工作量，缩小每个工作单元。在评价新技术在开发中的影响的过程中加上额外的原型和检查点（里程碑）。

人员管理技能

　　问题13：你作为项目经理要做的第一件事情是什么？
　　答案13：除了注意公司的发展方向并从中发现自己的发展道路外，在头脑中要建立项目经理所关注事物（商务，公司，项目，团队，个人，技术和方法论的变化）的优先顺序。因此，和部门经理开会确定优先顺序，安排用
户和职员会议，得到全部成员的状态报告和评价。重要的是能尽快处理业务，项目和个人有关的事情。
　　问题14：当你的职员减少了30 %你将怎样着手完成公司的项目？
　　答案14：首先，确定和区分项目的优先次序，哪些项目是必须在今后的18个月内完成的。把绝对的最小的总人数与每个项目联系起来。向管理者和用户说明对进度表的影响。因为两者都也许不愿意接受进度表的变化，因
此或许可以给你一些例外。
　　减掉顾问比去掉一个雇员要好。每个项目的顾问也许可以用雇员代替。坚持运用学习曲线理论并逐步减少顾问人数。可以把一些顾问的工作从一周降低到一星期中的2或3天以应付人员削减。
　　如果公司有提前退休的一览子法案，赶紧寻找一些有资历的、适用的雇员。牢牢记住失去“老资格的人”你也许就失去了有价值的知识。尽可能将一个快退休的人和新手组合在一起。
　　以满足业务目标为前提，确定剩下员工的重要性以及他们在每个项目中的重要性。使新手和经验丰富人员的比例适当。两者都是确保项目和公司不断成功的财富。
　　问题15：你的团队主要是由新手组成的，并且进度已经落后。你将做什么？
　　答案15：需要记住一个项目很少因为在截止时间内没有完成而被取消的。项目被取消，主要是诸如缺少资金，用户支持或不能满足的业务目标。
　　因此，要做的第一件事是培训，无论在室内还是室外，在课堂或通过录像带。另一种附加方法就是让资深的雇员或高级顾问充当教师。
　　举办针对个人评估和辅导的会议。帮助每个员工准确评价他们各自的优点和缺点。同时明确任务，将所有必须遵守的标准或准则阐述清楚。为每个员工提供从成功项目中得到的模板作为指南，还要允许他们发挥自己的才能。
如果需要，和他们一起工作。对任何问题或完成的任务做出迅速的反馈。
　　对于较大的任务，看看他们的计划，有助于确定他们是否了解任务的范围和目标，以便了解他们是否能完成任务。倾听员工的观点，也许他们会有完成任务的正确的方法和途径。然而也要防止雇员陷入挫折和士气低落的困境
中。
　　问题16：你将怎样和与你竞争相同职位的员工相处？
　　答案16：这是经常发生的不愉快情况。雇员总是认为他们能胜任某个职位而管理层还没有意识到这一点。因此，要进行如下调查：
　　发现员工的管理能力
　　阅读评估和状态报告
　　当雇员变得不合作时试图发现一些变通的方法并且针对这种状况进行一些个人谈话，谈话内容包括：
　　弄清楚状况；与员工一起分析他/她具有的能使他/她得到提升的资历；强调在初期协作的必要性和管理层是如何高度重视合作关系的。
　　问题17：在决策和工作风格方面你会给你手下多大的自由？
　　答案17：自由的大小取决于每个人的技能和专业水平。一个好的经理是“面向结果的”并且能创造一个能使团队广泛交流的环境。无论如何，每个员工每周需提交项目和商业目标有关的状态报告并且经理要进行审查。这有
利于加强组织建设并使每个员工致力于他们自己应完成的工作。
　　问题18：如何对待即将退休的员工？
　　答案18：即将退休的员工能提供大量的信息。一个人在把所有业务知识和关系网拒之门外时必须三思而后行。因此，要利用这些人的能力：他们在某些特殊技能方面可以作为新手的老师。明确主要的工作利益，要使项目能
充分利用这些技能，可以利用他们从非正规途径得到的必要支持（不用通过正规的，官僚的途径完成工作）
　　问题19：对一个一贯迟到的员工你会怎么办？
　　答案19：好的经理是通过结果与所花时间来评价一个员工的。然而，还需要了解迟到会在公司和团队中造成什么影响。一个人经常迟到人们会感到领导在徇私并且会影响团队的士气。这个人也许可以按期完成自己的任务但
可能会影响到别人的进度。职业特性包括可靠性。如果别人的工作进度取决于他们的工作进度，那么，他们的进度对于整个团队就很重要。
　　首先判断这些员工的模式。换句话说，是偶尔还是一贯如此。其次，明确公司有关考勤方面的政策，确定迟到及其相关处理方法。要了解该员工的工作是否与进度相符并了解与他一起工作的人对他迟到的反应。最后，必须与
他们进行客观的谈话，谈话的主题包括：
　　公司的规章制度
　　对团队的影响
　　对个人评价的影响
　　强调时间进度
　　达成谅解
　　问题20：在费用削减的情况下，你将怎样鼓舞士气？
　　答案20：钱不是仅有的激励因素。人们需要了解他们是否对项目有积极的贡献。因此，要强调拥有的自豪感并且举行业务会议，在会上让用户谈谈他们对项目组的良好印象。同时，让用户对他们的功能和业务提出一个概括
。培训是一个激励因素。因此，状况会议可以作为一个非正式的培训课程。不定期地举办有关新技术的内部研讨会。如果培训课程费用太昂贵，可以租赁技术录像带。订阅杂志，有许多技术杂志是免费的。必须记住的是，忽视培
训将使团队的精神低落。这样会影响产品的质量和数量。
　　问题21：你如何雇人？
　　答案21：首先做一个工作所需技能的描述。如果你不了解现在的需求就很难雇到合适的人。接下来要了解团队成员的个性。列出团队现在缺乏的技能或工作风格。与人力资源部门讨论所有这些情况，包括调动现有员工。当
候选人到来，针对现有工作进行面试，同时还要了解他是否具有新岗位所需的技能。
　　问题22：你将如何解决团队中的个人冲突？
　　答案22：辨别出人的不同个性。分别向员工表述每种风格的价值。当与冲突双方讨论试图分析申诉或冲突的原因时应持有客观的态度。
　　问题23：你将如何监控/管理顾问？
　　答案23：顾问也是人，也需要得到尊重。他们还需要明确的目标和任务。坚持做工作周报，将工作时间和工作完成情况联系起来。
　　问题24：你将如何管理外援？
　　答案24：和管理顾问的方法相同。不过，他们可能有一个经理来负责外包合作。首先要和这个经理一起组织日常会议。坚持做工作周报和可交付产品的拷贝。
　　问题25：你将如何同一个似乎总是不能按时完成工作的员工一起工作？
　　答案25：直到找到问题的原因时，问题才能解决。原因不一定是分析问题或解决问题的能力差。可能是一个管理方面的问题。该员工可能没有得到适当的培训，他的工作可能超出了他的能力范围。另外一种可能是这个人有
太多的事情要做而且这些事情都是最重要的或者他不清楚交付日期。如果不是上述原因，要注意观察，找出原因所在。例如当所有人遇到问题时，都会找这个人。那么，这个人的工作经常会被无数次地打断。

检查:
　　典型活动：交付后的三到六个月对目标成本，开发工作，可见/不可见收益进行检查。
　　典型交付：实施总结报告。
　　问题34：制作原型应该在项目生命周期的那个阶段？
　　答案34：贯穿整个项目。眼见为实。因为它是验证功能，业务规则，用户需求数据和测试的一个好工具。值得注意的是，原型不会成为粗制滥造的产品。原型需要较好地维护。原型应能在过程和数据不完全的情况下，显示
各个窗口和窗口间的导航关系。
　　问题35：在项目生命周期中，基于客户端/服务器端开发与基于大型机开发的区别是什么？
　　答案35：基于客户端/服务器端开发的项目需要额外的任务编制各部分的计划。各部分计划中必须包括对事件，数据和网络位置的检查。必须根据用户的要求决定服务器/客户端的分布。在服务器/客户端环境中，要运用
外观建模技术和制作图形界面的原型相结合和方法。
　　问题36：在一个维护项目中如何管理和保证质量？
　　答案36：维护本身就含有负面意义。许多公司认为维护工作是不好的，第二位的。费钱的，并且是对现有应用的不断修改。必须懂得维护也有它的生命周期。因此，应建立一个围绕维护活动的控制和质量工作的计划。新的
开发计划包括交付产品和每个任务分配的时间。项目计划应考虑到需求变更的情况。这样可以使项目经理和用户看到变更对项目进度的影响。
　　维护阶段/活动有：
　　变更的确定（是否会造成产品问题，是否增加了新的功能，或技术平台的变更）
　　正式记录变更，
　　变更确认并初步估计变更的大小，
　　对现有变更进行优先级排序，
　　变更分析，
　　对变更进行编程，
　　对变更和变更对系统产生的影响进行系统/回归测试，
　　用户确认变更，
　　产品递交，
　　生产。
　　问题37：面向对象的开发与传统的开发方法在管理技术上有什么不同？
　　答案37：面向对象的项目团队人员较少，团队成员不需要有太多创意。重要的是技术和个人的角色。每个成员需在项目的不同阶段承担不同的角色。因此，每个成员必须了解他们自己的优缺点。围绕一个或多个人员的角色
有：
　　设计师（系统的整体结构）
　　抽象工程师（类和类族）
　　应用工程师（完成和组装类和类之间的消息）
　　由于传统的开发方法，个人角色是不能互换的。软件开发是个人的努力的结果。即使是由最优秀的，最聪明的人组成的团队，如果他们不能为共同的目标而工作，那么就是最简单的项目也不能成功完成。
　　问题38：你如何在处理雇员关系，项目管理，文本工作之间分配时间？
　　答案38：人是最宝贵的财富，因此需要花费最多的时间。然而，项目经理必须关注事物的次序应该是：
　　商业目标，
　　公司的目标，
　　项目，
　　团队，
　　个人，
　　技术和方法的变化
　　问题39：什么是PM-CMM?
　　答案39：人员管理能力成熟度模型。PM-CMM和CMM都是卡内基.梅隆大学的软件工程研究所开发的概念模型。PM提供了人力资源管理的组织方法。五个层次是：
　　随意的：人员管理没有连贯性，
　　可重复的：组织在人员管理方面有一些政策方针，
　　明确的：将人员管理与业务特点相结合，
　　可度量的：对人员管理可进行目标量化，
　　优化：有组织地致力于不断地提高人员管理水平。

　　小结

　　一个成功的团队是指由不同技能、才华、工作风格和知识的成员组成的士气高涨的团队。项目经理的职责就是将这些人组成团队并激励他们。本文通过复习一般性的概念、术语和面试中经常会问到的问题，为面试做准备。你
可以根据你有关如何成为一个好的项目经理的知识和经验，对答案进行整理。不管怎么回答，尽量给你所应聘的组织留下印象。应以一种积极的态度面对。应侧重于人员管理，同时还有一个良好的技术背景。应具备应有的常识、
自信、倾听和作决定的能力。

沟通技巧

　　问题26：你将怎样使用户参与和了解项目的每个阶段？
　　答案26：贯穿整个项目的原型是得到用户肯定的方法。让用户对有形和无形的利益进行研究，以做出成本效益分析。和用户一起开发测试数据，测试大纲和验收标准。e-mail里程碑状态报告和更新/修改的项目计划
。在项目进行阶段性检查时的同时对可交付产品进行检查。
　　问题27：你将如何发现和解决内部和外部问题？
　　答案27：从所有可能的资源获取实情并客观地记录下来。然后在相关方参与下，尽量自己解决问题。如果这种方法无效，按照组织的管理结构提出问题并参照可能的解决方法。
　　问题28：你将如何得到供应商的一贯支持？
　　答案28：虽然供应商是在管理范围之外的，但也可以将他们包含进来，如果他们：得到尊重；了解业务目标；预先购买；将供应作为计划的输入，这样会对他们产生影响；参与设计，因此，在项目的早期阶段就应该考虑供
应商的管理。确保他们了解业务目标和工作的利益。
　　问题29：如何处理“是否能破除一些规矩”现象？
　　答案29：单纯为了技术而采用某种技术是不能说服用户或领导的。任何人都可能抵制那些会改变现状的变化。然而，如果将技术与商业利润联系起来，用户会支持你的建议。
　　问题30：你如何应对不同的商业用户，如果他：
　　a) 拒绝确认需求
　　b) 经常改变主意
　　c) 不肯花时间
　　d) 坚持不现实的截止日期
　　答案30：无论客户有多难应付，都应该记住正因为他们我们才有工作做。他们是客户。必须以高度的职业精神，完全尊重他们。
　　因为他们不能了解我们的工作正如我们不能完全了解他们的那样，沟通变得比较复杂。因此，我们要花时间作规划并解释其中包含的内容。用户需要感到他们没有浪费时间，正在取得成果，并且他们的意图被很好地理解。制
作原型是一个有用的工具。它提供了一幅用户能理解的、灵活的图画。
　　另外，对工作风格的理解也很重要。拒绝承认或不断地改变想法可能源于对问题缺乏理解，或是对未来的担心。
　　用户往往不愿意花时间与IT人员交谈并认为这样做是浪费时间，因为IT人员过分关注他们自己的任务。应该对过去交付产品的历史进行检查。如果用户来了多次但并未发看到有价值的输出，他们将拒绝花更多的时间。在
这种情况下，你应该做你擅长的商业领域的项目以期得到用户的尊重。
　　召开一个历时一小时（并且要限定在该时间范围内）的需求讨论会来讨论特殊的问题。会议结束时应让用户知道下一步该怎么做（并要取得共识）。用户的观点被记录在“会谈纪要”上。这些会让用户感到他们的意见已被听
取并且允许他们更改错误。
　　一个项目被取消往往是由于没有经济合理地达到用户的业务要求。如果在项目的整个过程中，一直保持与用户的有效沟通，他们将看到他们的要求正在逐步达到。项目很少因为延期而被取消。要注意范围变更。在原有的截止
日期上增加额外的任务，将会产生不现实的截止日期。
　　问题31：在一个不编程，就认为你没在工作的环境中，你如何开展工作？
　　答案31：如果用户认为你了解了他们的业务目标，他们就希望早些开始编程。以一种他们能够理解的形式制作需求文档，提供一种开放的沟通方式，并让他们知道你了解什么，你正在做什么。通过项目计划，状态报告和原
型同样能够表明项目的进展。通过让用户审查需求，原型和状态报告的形式，让用户参与项目。

　　方法论知识

　　问题32：生命周期是什么，它的作用是什么？
　　答案32：一个开发或维护生命周期是描述一个特定项目的开始，中间环节和完成的方法。一个生命周期包含了完成特定目标的所有步骤，任务和/或活动。每个活动可能有一种特定的方法。例如,制作数据模型可能会按照
James Martins建模方法。对象建模可能会采用Ivan Jacobson方法。生命周期通过运用所有方法来完成业务目标。
　　问题33：描述你的项目计划中应包括的阶段、活动和可交付产品。
　　答案33：项目计划中应包括如下阶段（不是以瀑布/线性次序）：
　　项目管理：
　　典型活动：很多人忘记加入诸如开发和维护项目计划，状态会议和报告，评估的资料收集和汇报，制作演示资料和向上级和用户进行演示等诸如此类需要花时间的，内部的项目管理活动。
　　典型交付：项目计划，状态报告，评估报告（例如：有多少个功能点）
　　需求分析：
　　典型活动：范围定义，成本利润初步分析，建议。
　　典型交付：范围文档，物理和逻辑分析，实体关系图，成本利润分析，商业规则申明，任务定义和概要说明。
　　设计：
　　典型活动：建立开发和测试环境，制作逻辑模型，技术系统设计，执行计划。
　　典型交付：逻辑数据模型，事件模型，对象模型，网络模型，物理设计，适合开发环境的规格说明，经过修改的规格说明书，测试计划，流程图。
　　开发：
　　典型活动：编码，单元测试和制作用户文档。
　　典型交付：测试说明书，过程手册，程序。
　　测试：
　　典型活动：软、硬件测试，线性测试，系统测试，集成测试，回归测试和平行测试。
　　典型交付：测试结果，问题报告和跟踪纪录。
　　实施和支持：
　　典型活动：第一阶段成果打包；培训。
　　典型交付：问题报告过程。

技术问题之外，

工行本身的管理问题

以及国内银行业信息系统落后的沉疴

事件原因直指IBM：软件存在缺陷

6月28日上午，工行某直属一级分行信息科技部员工陆续收到内部通报邮件。该通报就6·23事件的情况及原因作了基本描述，但对事件影响范围、内部处理能力判断均语焉不详。

通报称，“6月23日上午，数据中心(上海)监控发现主机CPU利用率升高，经分析判断与6月23日凌晨实施的主机DB2数据库软件升级版本有关(从V9升级到V10)，在紧急回退升级系统软件版本后系统运行恢复正常。”同时，工行总行信息科技部将该事件直接原因归为IBM公司提供的软件产品存在缺陷，并称这点“经IBM公司正式确认”。

近日，中国工商银行(601398,SH;1398,HK)信息科技部就6月23日工行系统故障事件(以下简称“6·23事件”)正式作出内部通报，这份通报称，工行数据中心(上海)主机系统出现故障，是由于IBM提供的主机DB2V10版本内存清理机制存在缺陷引发。

6月23日上午，全国多地中国工商银行柜台、ATM、网银业务出现故障，持续近1个小时。作为服务2.92亿个人客户及400多万公司客户的全国金融服务巨头，工行此次故障波及北京、上海、广州、武汉、哈尔滨等多个大中型城市。

当日，工行将该事故对外模糊描述为：“中国工商银行部分地区因计算机系统升级原因造成柜面和电子渠道业务办理缓慢。”这也是迄今为止工行就6·23事件向用户发布的唯一公开解释。

IBM公开官方资料显示，工行与IBM的合作始于1997年，至今16年之久。针对通报中提及的“经IBM公司正式确认”，记者联系多位IBM相关负责人，但均未得到回应。

工行IT运维能力遭质疑

这份内部通报由一位不愿透露姓名的工行在职员工提供。该员工表示，自己并不太满意这份解释：“对灾难备份只字未提，有意将管理问题规避为技术问题。”

通报也提及了一些管理问题，但表述颇为模糊，通报称，“(数据中心上海)没有按照‘第一时间恢复生产’的要求采取果断措施及时进行回退，并且回退过程不坚决，耗时较长。”

银行的灾难备份系统，是指银行对本地数据中心的数据、业务系统、软硬件等资源进行同城或异地备份，以确保发生某些不可预测的灾难后，重要信息系统的数据安全的一种预防措施。

据中国银行[0.38% 资金 研报]业监督管理委员会(以下简称“银监会”)发布的《银行业金融机构信息系统风险管理指引》，银行业金融机构应制定信息系统应急预案，并定期演练、评审和修订；全国性数据中心要实现异地灾备。

日前，国内最大的灾难备份服务商万国数据CEO黄伟在接受福布斯中文网采访时表示，“银行的IT系统永远面临信息安全的挑战，但悲哀的是，银行在IT系统和灾难备份中不计成本，但遇到这样的大面积的安全问题依然无法在短时间内恢复系统。”他认为，长久以来国内银行的IT系统运作是在给这样的事件埋下伏笔，他最后指出，“在国内银行，IT系统的搭建更像是给上级和银监会看的‘政绩工程’。”

2008年，现任银监会副主席郭利根曾就多起国内银行信息科技风险事件发表讲话。他说，工行等国有银行是国内在IT技术和风险管控上都比较先进的银行，它们的问题频发，“充分暴露出我国银行业信息系统的脆弱性。”

他指出，基础建设滞后、软硬件及核心技术受制于人和系统管理粗放是当时银行业信息科技建设存在的主要问题，“特别是在业务连续性规划、业务恢复机制、风险化解和转移措施、技术恢复方案等方面，存在明显的‘短板’。”

整整五年过去，工行6 23事件证明了这些问题仍旧没有得到有效解决

历时11个月，逾2000名员工，28万个测试案例，执行80万次。

这些冰冷的数字，均是平安银行业务系统从起步到收官的关键字。

“新业务系统要在周末两天内完成上线并投入到实际的生产使用，我们需要在48小时内完成3200多条指令，动作的顺序和动作的关联度，一个细节也不能错。” 平安银行系统整合项目管理委员会常务副主任孙芳滔说，“这就好比奥运会开幕式上，该打光的时候灯要亮，该奏乐的时候音响要打开，否则整个流程就乱套了。”

“本次整合的工程量之大、复杂程度之高、周期之短是我以前从来未曾遇过的。系统整合推进到去年9月之时，我才稍微有点底气。”孙芳滔言及此时亦难掩其当初的心有余悸。

2013年1月14日，平安银行发布公告，称其业务系统已于1月13日顺利完成整合。系统上线，历时三年的平深整合迈进一大步。

1月18日，平安银行业务系统整合项目管理委员会常务副主任孙芳滔和肖云、项目管理办公室主任孙炳莹接受了本报记者的独家专访，还原两大银行系统整合过程。

平安银行一中层人士亦对记者直言，业务系统整合可能是两行整合所有项目中最重量级的，也是最繁琐最复杂的。但新系统能否为平安银行未来发展创造奇迹，还有待考验。

IT、业务双主线协同

“项目组越快完成系统的整合，两家银行就可以越早在一个平台上去构建未来新的业务增长点与产品开发，这是系统整合最重要的意义。”孙芳滔补充。

“客户导向”是项目组在进行系统整合时考虑的首要原则。肖云对记者解释，“现时平安银行大多数的新系统均是两行旧系统的‘结合体’，是在原系统的基础上作出修正与完善的。当然也有小部分业务系统需要我们作重新的设计与开发。”

此外，据前述中层人士透露，降低运营成本是另外一大目的。

平安集团董事长马明哲一直将平安后援中心称作中国平安的“中央厨房”，为集团旗下各个子公司研究并配备各具特色的“招牌菜”。

这就意味着，在后援技术中心的支持下，各不同的客户需求均能通过统一的后援中心进行信息处理，有助提高集团交叉销售和协同经营的能力，同时在形成规模经济后有助其节约成本。

着眼微观，贯穿平安银行业务系统整合的两个最主要组成部分为业务部门与IT部门。而这两类部门，则“两两配对”组成了若干个工作组。

“业务条线与IT技术条线之间的关系犹如一组齿轮，缺乏了对方的支持和配合，谁也运转不起来。”孙芳滔如是对记者说。

“业务部门人员的划分依据是平安银行的主营业务，其中包括公司、零

售、信贷、资金等条线，以及两个主要中后台的支持——财务部门和运营部门。这是六个最主要的工作组。”孙炳莹称。

记者了解到，在系统整合开始前，业务部门与IT部门早于2011年便开始着手两行系统对标的工作。对标工作，指项目组人员对两行系统之间进行差异化分析，这是落实整合方案的首要前提。

据PMO项目组人员介绍，去年2月份前项目组人员已完成对标工作。2012年2月份到6月，是项目组进行需求分析、方案评审、技术开发的阶段。

“直至6月底系统开发工作方才基本完成，项目组人员都舒了一口气。殊不知，真正的挑战是从那时候才发起的。”孙芳滔回忆其当时的情景。

去年6月25日至8月22日，在完成程序设计后，IT组技术员工开始进行系统的“首轮自测”， 通过模拟测试以监控结果是否能达到业务人员所提出的要求标准。

而同期的业务组别人员亦开始着手用户验收测试（简称UAT）， UAT分为两部分：一为系统功能的UAT，一为数据迁移的UAT。

孙芳滔对记者表示，“7月中旬到12月，总行调动了近400名人力，5轮用户验收测试（UAT）下来，共完成了25万个测试案例的编写与测试，累计执行73万多次。”

系统功能的UAT是指，业务组人员待IT组完成程序设计后，开始进行系统功能的用户验收测试，也就是我们常言的“客户体验”。

而数据迁移的UAT，是指业务条线人员要把银行全部客户的所有明细资料，包括过往的交易明细、银行卡的属性、客户的详细数据等，从旧系统迁移到新开发的系统上。多位业务员反映，这是本次业务整合进程中工作量最大、难度最大的单体项目。

“‘用户验收测试’（UAT）旨在发现新系统中存留的问题，故每位业务条线人员在完成每轮UAT后需总结一份用户性能验收报告，以便作进一步的完善。”孙芳滔进一步解释。

要完成一轮系统产品的完善，业务人员与IT人员要作将近30万个案例分析。

风险预演

在用户验收测试（UAT）阶段，项目组共计5轮执行了73万多次案例的编写与测试。

为何要对如此海量的案例执行5轮测试？怎样的测试结果方能通过？是否有硬性指标对此作出界定？

孙芳滔解释：项目组将系统缺陷分为两类分级。第一类被定义为“可能影响客户交易”的重要缺陷，第二类为非交易性的缺陷。

“‘金融交易案例通过率为100%，非金融交易案例通过率达99.9%’是UAT通过的硬性指标。”他称。

多位IT条线员工直言，“项目组内严格规定‘问题不能过夜’：重大缺陷必须当天解决，最不济也要在当天提交解决方案，一般来说，当天要是出现重大缺陷，我们就得自认倒霉了。”

“从2012年6月初到12月末，所有组别的产品共经过两轮SIT和六轮UAT。”孙芳滔直言，“哪怕有一组在途中掉队，就意味着全盘的项目计划被打乱。”

为避免前述的“要打光时灯没亮”的尴尬场景，项目组从9月份起，分别做了1轮沙盘推演、5轮实战演练与1轮回退演练，其中3轮为全行演练。

记者另了解到，自8月到12月，项目组需同期安排零售、公司、运营、信贷、财务、资金六大条线一万多名员工参与为期四轮的系统操作培训。

“没有培训与预演，就无法对系统上线日的潜在风险作出警示，更遑论风险预防。”肖云对记者说，“这正是项目组坚持将三千多条指令从头到尾地演练数次的缘由。”

此外，一知情人士对记者透露，IT项目组为防止整合过程中系统更新不成功，或出现重大问题、不可控的故障，设置了“系统回退”的程序。

“其原理有点类似于电脑设置中的‘一键还原’。”孙芳滔向记者坦陈。

“万一系统切换出现故障导致整合不成功，须预留约20个小时以准备‘系统回退’工作，确保周一正常营业是首要任务。”孙芳滔称，“实际上，业务系统在周日（1月13日）上午已经投入正常运作中。”

随着银行系统整合收官，全新的平安银行作为中国平安旗下重要的业务板块开始扬帆起航，借助平安集团的综合金融优势，新银行必将取得1+1＞2的成效

　　“银行的经营、管理、服务都离不开信息系统。在银行整合上，人员、政策、制度、流程的整合，最终必然落脚在系统整合的基础上。”

　　2013年1月14日，随着平安银行业务系统的整合上线，历时三年的平深整合全面告捷。此后，新平安银行420多家网点的1900多万零售客户、20多万公司客户，开始在相同的业务系统上办理、享受统一的银行产品和服务。

　　按照平安银行系统整合项目管理委员会常务副主任孙芳滔的说法，这场具有“收官战”意义的信息革命，将使得新银行可以在一个统一的平台上构建未来新的业务增长点。在此理解上，2013年1月14日之后，平安银行终于打开了未来业务增长的空间，翻开“迎接大未来”新篇章的第一页。

　　平深整合一直被喻为国内银行业史无前例的巨大工程，业务系统的整合更是难中之难、重中之重。在这样一个没有任何先例可循的项目中，平安银行如何在最快时间周期内实现两个原来差异极大的业务系统的统一？又如何管理推动如此庞大繁杂且不容出错的整合项目？如何将系统整合带给客户的影响最携？如何保证系统运行的稳定性、准确性？如何调配原两行内不同业务条线的若干路人马？

　　历时仅11个月，逾2000名员工；28万个测试案例，执行80万次；短短48小时内，完成3200条投产指令……平安银行用这一系列数据，给出了最深刻的答案。

　　换“心”手术

　　一直以来，由于其高难度与高风险性，银行核心业务系统升级换代都被比喻成“心脏”大手术，其涉及千丝万缕的繁复工序，稍有不慎将导致项目失败。

　　即使艰难，却不得不为之。在银行IT应用系统总体架构中，只有有了核心业务系统这颗“心脏”，各应用系统才可以“活”起来，应用系统之间的“血液”才可以顺畅地流通，最终支撑银行业务发展战略的实现。

　　平深整合三年来，虽然实现了架构、人员、产品、服务、环境等一系列整合工作，但作为两行整合最具“收官”意义的业务系统整合只要一日未完成，两行的整合则无法划上最圆满的句号。

　　在如此重要且艰难的项目上，选择最适合的方案则显得至关重要。

　　原两行在运营模式、业务、产品和流程方面有较大的差异性，这种差异性落到业务系统上的差别就更大。就运营模式而言，原平安银行是集中运营模式，原深发展则是分行运营模式，如果系统整合的同时又进行流程再造，则难度太大、时间周期长、给客户、产品推广和业务层面带来的影响将非常大。

　　“我们需要考虑的是，如何最有效、最快速、最安全地把原有的资源进行‘择优摒劣’地整合。”在平安银行业务系统整合项目管理委员会常务副主任肖云看来，“在系统选择和优化的过程中，如何为客户提供服务，对所有客户的影响降至最小，‘客户导向’是我们在选择系统时候考虑的首要原则。”

　　举例来说，一笔普通的贷款业务处理过程包括客户申请、客户经理基本资料的建立和审查、信审人员贷前审批、出账审批、运营人员放款、利息和拨备计提、贷后管理、还款等步骤，涉及的系统包括柜面终端、网银、信贷、核心、催收、不良资产管理、报表等，在新的系统上，只有所有的流程与系统都保持高度的一致性，才能给客户带来一致的体验。

　　为此，平安银行决策层前期经过深入研究，选择了一套务实、可控的方案，即在2012年率先实现相同的业务运行在同一系统上，先整合系统再提升功能的整合目标，以在最短时间内满足一个银行、一个产品、一个系统、一种体验的业务需求。

　　同时，结合原两行各自的业务优势和系统特点，提出了基于原平安银行新兴心系统群，整合零售业务；基于原深发核心系统群，整合公司、资金业务的整合策略。这套充分利用现有系统资源的整合方案为系统整合赢得了大量时间，也最终保证了项目的顺利完成。

　　11个月攻坚战

　　对银行来说，业务系统整合是一项长期且艰巨的工程。从以往的经验来看，国内一些银行完成核心系统升级就需要2-3年的时间，但平安银行仅在11个月间就顺利了完成了项目。

　　2012年2月14日，平安银行执委会听取系统整合项目启动汇报，这意味着该行系统整合的工作开始全面展开。为保证对项目进行精细化管理，紧接着的2月22日，平安银行随即召开项目管理委员会第一次会议，确定了项目指导委员会、项目管理委员会、PMO(项目管理办公室)的三级垂直项目管理组织架构，设置了公司、零售、信贷、资金、运营、财务、IT支持保障组7个专项工作组，明确工作目标与工作原则以及各组人员分工与职责任务，并在每组分设了业务与IT的PMO全职专员共同开展工作。

　　这其中，工作组由项目管理委员会统一领导，工作组和工作组、业务人员跟IT人员之间是相互协同的，正是这种既有垂直领导，又有横向交叉的矩阵式管理体系有力地保证了后续工作的顺利开展。

　　此后，历时近5个月的需求分析、方案评审、技术开发工作依次展开，到2012年6月底基本完成系统的开发工作。

　　期间，各业务组和IT开发人员，反复论证和协商，共完成109个子项目、313份需求的分析和开发工作。

　　项目需求、开发、测试等工作需投入大量人力。为此，平安银行各部门均抽调骨干参加项目工作。业务部门共投入人员近500人，科技部门在维持日常生产运维的同时，全力投入项目工作，原两行科技参与项目人员近千人。平安银行还特别出台了分行借调人员专项政策，各分行通过提前招聘新设网点员工，有序开展新员工招聘、培训、借调等工作，为项目组置换出业务骨干人员，共借调全行400多人；尤其是各分行运营条线，通过取消休假、调整轮班等措施，为项目输送了近300名一线柜员。

　　2012年6月25至2012年12月2日，平安银行又马不停蹄地进行了2轮系统集成测试(SIT)、3轮用户验收测试(UAT)及13轮数据迁移测试。

　　用孙芳滔的话说，“真正的挑战从这个时候才开始１

熬出来的测试验收

　　“系统的设计不可能一蹴而就，必须经过一轮又一轮‘发现问题——完善缺陷’的深入测试，才能设计出相对成熟的业务系统。”熟悉银行IT技术的肖云掩不住脸上的疲惫，“测试阶段，大家都是熬出来的。”

　　由于银行的IT系统呈现网状结构，一个环节出了问题，其它环节就会受到影响，而银行的业务又是直接面向客户和市场的，所以每一个环节都必须环环相扣，容不得丝毫马虎。所以，对系统进行高标准的联调联试就显得至关重要。

　　此次系统整合共进行了11轮高标准测试，分为系统集成测试(SIT)和用户验收测试(UAT)。

　　一开始是2轮系统集成测试(SIT)，测试的是主要系统的基本功能和性能，即这个系统在处理业务时在功能上做得完全对，还要在性能上做得足够快，能满足几万乃至几十万客户同时在线的需求。这部分测试从2012年6月25启动，2012年8月22日结束，两个月时间内共执行3.2万个案例测试。

　　而用户体验测试(UAT)则主要是从用户角度测试系统响应是否正确，是否好用。测试越到后期要求越细。期间，破坏性测试，压力测试等专业测试形式全部都需要顺利过关。UAT测度从2012年7月16日开始到2012年12月2日结束，历时5个月，共完成了25万个测试案例的编写与测试，共累计执行73万多次。

　　不仅如此，平安银行设定的测试标准非常严苛。在测试中，发现问题或缺陷分为交易性缺陷和非交易性缺陷两类及多个层级。如“100元”写成“100.01元”就是非常严重的L1层级的交易性缺陷，投产时不能有任何L1方面的缺陷。如测试中遇到这种问题必须当天解决，务必做到“问题不过夜”。

　　测试过程管理也是非常严格的。测试期间，每天晚上7点都要开检视测试会。每天提交一份系统缺陷的测试报表，每个部门都需要出具业务验收报告，系统做得对不对，便不便捷，快不快，还有哪些问题需要落实，都要加班加点地解决。

　　6轮演练考验执行力

　　系统功能性能和数据迁移的用户测试做完后就意味着系统达到上线要求了。但是，就像奥运会开幕式需要彩排以确保万无一失一样，平安银行新系统上线只有短短48小时，同样需要在规定时间规定地点按照规定的动作百分之百达到规定的要求。这就需要在系统上线前进行演练。

　　演练共进行了1轮沙盘演练和5轮实战演练，每一轮都必须解决相应的问题。比如系统上线的那两天什么时候做什么？这种安排对不对？有没有遗漏？

　　通过对上线执行流程的反复推导、清理，最终项目组清理出这两天要完成的3400多条上线指令，即要做3400件事情。

　　演练是最考验项目组织、实施能力的环节。为了不影响银行日常经营，演练只能在一天营业结束后加点加班进行。期间，平安银行在营业结束后共进行了三轮全行演练，参加演练的柜台就达到6000人。如何保证每个人做的都是对的呢？这就需要一个严密的指挥系统。为此，IT部门专门为此次整合项目做了一个银行业前所未有的上线指挥系统，在演练中发挥了重大作用。

　　不仅如此，3400条指令要在短短48小时内顺利执行完毕，对平安银行更是前所未有的挑战。比如上线那两天某台关键设备坏了，或者某地停电这种低概率的事情都可能会导致系统上线失败。因此应急预案非常重要。为防止整合过程中系统更新不成功，或出现重大问题、不可控的故障，项目组为此设置了“系统回退”功能，其原理有点类似于电脑设置中的“一键还原”功能。

　　方法很简单，就是对上线前的数据做一个备份，并设置若干个回退点，一旦出现问题，则可利用系统回退功能恢复到新系统上线前的原始状态。事实上，系统正式上线那天，平安银行还特别预留了20个小时作为回退时间，以防突发情况。

　　数据迁移比拼耐心

　　新业务系统搭建好了以后，需要将原两行客户数据从旧的系统中迁移到新的系统上，且需要保证客户信息不变，甚至连过往交易明细、卡的状态、卡的功能等客户信息全部都要跟原来一样，还要保证这些数据能正常使用，这就是数据迁移。

　　数据迁移是两行系统整合项目重中之重、难中之难。数据迁移的难点在于，其涉及到两家银行客户数据的整合，要将数据结构不同、系统架构不同的数据进行清理，分别在原两行的系统群中完成迁出、迁入，且两家银行的历史较长，所以账户清理工作量非常庞大。

　　在数据迁移攻坚阶段，项目组成员在承受巨大压力的同时通宵达旦，第二天又继续坚守岗位的情景司空见惯。有的同事家里孝生病了，为了不落下进度，也跟着其他测试人员一起加班加点；有的同事连续一两个月时间连轴转，每天晚上加班到十一二点也习以为常。

　　数据迁移的工作从2012年6月份开始于用户验收测验同步开展，到2012年10月份又与演练同步进行，直到2012年12月2日完成数据迁移，一共经历了6轮专项测试、5轮演练、2轮性能测试，完成了1500多份数据核对业务报表的核对工作、103项数据清理工作。

　　“数据量最庞大的千万级零售账户的数据迁移工作，其复杂程度比一次春运有过之而无不及。”孙芳滔感叹道。

　　系统成功上线

　　经过前面多轮的测试和演练工作，平安银行系统上线最终于2013年1月12日至13进行整合上线，至今该新系统已平稳运行近一个月时间。

　　系统整合上线后，新系统未出现重大的漏洞或错误，没有一个客户“上错车”、“下错站”。这意味着，平安银行新业务系统已经经历了市场的检验。

　　随着业务系统整合上线顺利完成，该行所有网点将通过该系统为原两行客户提供各项金融服务，这使得原两行的产品、服务、定价、客户权益、流程实现了真正意义上的统一。客户在原两行的信息实现统一管理，客户资产合并计算，并根据合并计算后的资产享受银行高端和优质的服务。客户在原两行的任意网点均可获得一致的、优质的产品与服务。

　　随着银行系统整合收官，全新的平安银行作为中国平安旗下重要的业务板块开始扬帆起航，借助平安集团的综合金融优势，新银行必将取得1+1＞2的成效。(

一度被紧急叫停的平安银行业务系统整合即将重启。记者昨日独家获悉，平安银行业务系统全面整合一事已获银监会批复，整合时间初定于2013年1月12日-1月13日。这是平安银行和原深圳发展银行整合的关键一步。此前，平安银行已经完成了名称统一、支付业务等多层面的整合。

这场本拟于12月7日开始的整合行动曾在12月6日被紧急叫停。

“当时为应对72小时奋战，杯面、零食等 ‘储备物资’都准备好了。”平安银行一负责IT项目的员工笑称。12月5日，平安银行发布公告称，12月7日12时至12月10日12时期间，原深发展银行与原平安银行的业务系统将进行整合上线，以实现网点、自助设备、网上银行、电话银行、手机银行、业务系统等所有服务渠道的统一。上线期间，两行所有网点和渠道将暂停办理业务。

系统整合推迟疑云

12月7日，平安银行发布紧急公告称，由于近期客户交易量增加，为保障客户办理业务的便利，决定将系统整合延期进行。

坊间传言，因整合前夕技术出现了重大漏洞，才导致平安不得不紧急叫停。

然而，在平安银行一内部人士看来，这是无稽之谈，“系统整合曾做过多次全国性测试，重大的技术漏洞早就被攻克了。”

深发展与平安银行之间的业务系统整合工程，于今年2月至3月份才开始着手进行。

“整合的提法传了很久，但今年春节前，深发展和平安一直处于角力，争论到底是沿用原深发展系统还是沿用原平安系统。”平安银行一知情人士透露。

平安银行与原深发展分别有其独立的IT团队，而平安IT的基础设施较原深发展更具优势。“平安银行的IT系统主要外包给平安集团旗下的平安科技和平安数据科技处理。这和集团内部的产险、寿险、信托等公司的IT系统均一脉相承。”前述内部人士透露。

3月份银行内部终于达成共识，对公业务沿用原深发展系的ICS系统，零售业务沿用原平安系的FCR系统。

FCR核心系统最主要的特点在于采纳了开放式的架构和高度的参数化配置功能。开放式的构架正符合平安集团综合金融的战略需求：它能支持业务规模几何级的扩张，同时可以顺利将银行IT系统嫁接到集团的IT架构中。

“未来的客户沉淀重心将落在小微金融上，可预见平安银行的零售业务会在一段时期内迎来快速扩张期。这也是银行内部坚持将零售业务与FCR核心系统挂钩的原因。”一IT项目组人士坦言。

“FCR与ICS目前仍是两个独立的系统，领导层的意思是先按照对公、零售的业务导向，完成这两大核心系统的整合。而FCR与ICS之间，科技、运营和开发团队的整合将是下一步整合工作的重中之重。”前述IT员工补充。

“如无意外，明年1月份将完成核心系统的整合，实现业务需求与IT系统的基本衔接。”另一知情人士亦对记者称，“接下来仍有大量新系统的建设需求亟待满足，同时防范已整合环节的‘排异现象’。约在2014年年中才能完成IT系统的全面整合与良好运行。”

“若1月份的整合不能如期进行，恐怕会推迟到明年4月份。这可不是我们所期望的。”平安银行一中层人士坦言。

“系统回退”防风险

“这是场关键的战役，希望能平稳度过。”平安银行一位运营员工言语中透露着隐忧。“实话说，系统的合并还存有瑕疵。此前在系统测试过程中，曾出现未得到客户授权的情况下，偶尔把少数客户账户直接注销的情况。若这种情况出现在系统合并过程中，T日过后网点可能会面临投诉。”他说。

“C点”是平安银行内部员工对“系统整合切换点”的简称。“T日”则是指平安、原深发展系统切换的当天。

记者了解到，除核心系统外，平安银行内部仍有数百个应用系统需要选型，具体的IT项目将达6000个之多。

据介绍，系统整合管理流程要求每个项目从起步到收官，必须有明确的责任人，以确保项目顺利完成。参与系统开发、整合等员工总数不少于2500人。

“参与对公业务ICS系统整合的，除超过500名原深发展系员工外，还有600-700名外包员工。”原深发展系的一IT员工对记者坦言，“平安科技参与FCR系统整合的员工规模，不会比参与ICS的员工少。估算参与系统开发、整合等全程工作的人员数量超过2500名。”

此外，记者从一IT项目组人士处得知，平安银行本次系统全面整合前夕，设置了一个“系统回退”。“这是为防止整合过程中，系统更新不成功，或者出现重大问题、故障，可以利用‘系统回退’恢复到原始状态，这有点类似于电脑设置中的‘一键还原’。”该人士称，“万一系统切换、整合不成功，也要确保银行周一正常的开业经营。”

“无可否认，项目的建设和上线蕴藏着风险。但以IT驱动业务转型的发展方向已是大势所趋，也是未来银行压缩成本、提升运营绩效的必经之路。”前述平安银行一中层人士如是对记者说。

业务系统的上线是商业行为、是内部的事情，不需要银监局批，并强调延迟上线皆因客户的激增，系统没有任何问题，将尽快启动整合。

作为平深整合的收官之笔，平安银行业务整合上线一直备受公众关注。

按照原计划，12月7日起，平安银行将进行为期三天的业务系统整合。然而，行动启动前数个小时，平安银行发出公告，取消该项计划，解释为“近期客户交易量增加，为保障客户办理业务的便利，决定将系统整合延期进行”。

据《理财周报》报道，平安银行业务系统整合叫停，因12月6日平安集团内部出现了银监会相关负责人来访，并临时召开叫停会议。

平安银行相关人士则表示，叫停并非源于银监局，而是平安银行内部。12月初，考虑到年底客户交易量的显著增加，为保障客户办理业务的便利，平安银行主动延期了业务系统整合时间，为客户年底集中办理金融业务需求让路。

上述相关人士强调，“1、业务系统整合上线不需要银监局批；2、延期出于对客户的考虑，错开高峰期；3、已提前对系统整合进行了多轮测试，包括全国性的详细测试也进行了多次，没有任何问题；4、12月31号一过，将尽快启动整合。”

据报道，平深整合的重启日期初定于2013年1月12日和13日。

不过，平安银行发来的回复仅表示：“具体的时间银行内部仍在慎重研究中，但我们已做好充分准备，经过多轮、详细、全面的系统测试，确保系统的平稳、安全过渡”。

回复称，未来的系统整合上线时间选择将遵循尽快启动，对客户影响最小的两大原则，在客户结算高峰期过后，平安银行将尽快启动业务整合上线，尽早为客户提供统一、优质、高效的金融服务。同时，银行会在上线时间的选择方面下足功夫，争取将对客户的影响降到最低

• 在这里可以跟大家说一下，我就曾经在产品发布权限不在测试这里部门的情况下，成功的让研发决定推迟发布了大约一半以上的项目,。大多数的测试部门主管，很难顶住来自项目/技术经理的压力是有理由的，因为他们根本不了解你做了哪些工作。有时候一些情况下，看似不可能的事情任务要想做成完成，关键要看在于事情的技巧，。流程表示了只是一个大方向的东西，而且，你永远也无法将责任推卸给流程也许是对的，更多情况下，作为测试主管，需要但将做事的方法与风格可以影响到推广到测试流程的推广中。
• 在测试互联网项目时，还有一个更重要的就是如何保证性能。
• 也许大家会说不就是性能测试并不是单独存在的。其实不是完全正确，如果有充足的优秀高手人力资源做性能测试当然很好，但性能测试也不能完全保证所有的项目完全没有性能问题都完美无缺，因此，项目投入期间，同时性能测试是一个这个费时费力的工作，所以往往都是一般在资源不足的情况下开展的。作为测试主管，更应该，要学会判断那些相对更加重要的问题项目影响面会更广，需要集中做性能测试。这时你也许会问，那么会有人问其它相对不太重要的项目与问题怎么办，？其实做过性能调优的人都知道，大部分的性能问题都是由于一两个弱智的SQL语句导致的，所以可以从流程上加强对SQL查询语句在I/O问题的跟踪与评审,，从而避免大部分性能问题。
• 上面分析了不同公司根据上文的分析，不同类型的产品在测试流程上的是有很大差异的。这时，也许大家你也许可以把握测试流程大的方向了，但真正是否适合现有的测试团队与研发团队，则仍需要精心的调整，。当我遇到问题的时候，第一时间往往有时候不是去寻找流程不对的问题，而是通过现有资源与执行的方法可能需要着手来微调一下你的测试流程，直到发现问题的所在，并纪录下来，最后整合到原来设定的流程中。
• 这样的情况大概常常发生：比如说在需求上的处理，可能会有很多的测试人员会经常指责需求人员撰写的文档非常粗糙不详细，无法进行测试，。好像在我的记忆中，需求人员常常就是被骂的得灰头土脸，但是经过这些年在测试岗位上的工作，我才渐渐发现，其实有时候需求人员更需要鼓励, 鼓励是比职责更加有效的工作方式。这可能是一个放之四海皆准的工作态度。，指责只能加深对立，。其实在验收需求时，由于当时大家也只是知道一个大概我们的需求人员也只能从大致上把握核了解，可能大多数情况下是：原则上没有问题就通过了，。但然而，这种不负责任的态度却是给我们在做的测试工作带来相当多的麻烦。也只有在这样的时候，这些问题才能真正暴露出来，从而使测试设计时就会发现很多问题并没有写清楚，。一般情况下，很多测试人员这时就多半会放弃手边的工作，并消极地认为认为无法做工作无法继续下去。，等东西出来，并将问题最终归结到是需求给的不详细，而大加指责。
• 从我对测试主管工作的记事以来，就在印象中保留了这样的一幕。记的刚进一家公司时，我团队中的人员就开始经常会有下属跟我说抱怨，公司的需求工程师让我们太失望了。需求如何如何不好，然而，多少有些经验的我，当时我是把几家国内我服务过的顶尖公司情况作了一个简单的对比，的需求跟公司的需求人员的需求做了比较这时才发现，发现，原来我们公司的需求人员还是做的得不错的，。让测试人员把心态调整过来是测试主管的另外一件事。试问，，如果是你做需求作为需求工程师，是否会比他们做的好吗得更好?？有了这样的基调，就可以让然后建议测试人员去总结不清楚的地方，给需求人员一个相对比较具体和明确的意见，这样顺利的了解了需求。
• 其实有时候不是流程不对流程在这其中并没有太多值得指责的地方，而是相互的理解与支持,换位思考而对流程的执行态度，却是更加关键的。我们不得不学会如何换位思考，并更多地从他人的角度来看待这些问题。
• 同样的问题还出现在还有需求变更上，很多测试人过不了这一关，。总是他们指责研发人员，让研发那些本来就已经恼火的软件工程师更加火冒三丈。换位思考一番，其实不难了解，，其实需求变更对研发工程师来说是更大的麻烦，。他们需要修改设计，、代码，相较而测试只要需改测试用例，他们的工作确实更加麻烦。简单来说，就ok了，其实大家要分析什么样的需求变更最可怕，而不是眉毛胡子一把抓,其实测试对需求变更并不可怕，怕的是只有在提交时才发现，导致测试时间不够，才会真正让测试人员心慌。这时需要从研发流程上保证变更及时的通知到测试就可以了行，。也许有人会说你也需要说：，说的倒很容易，如果研发不按照你的要求做怎么办！其实这里你只要用我所采用的方法是用数据说话，在项目进行时统计发生过多少次这样的事情，让研发管理层知道，让项目组之间有一个比较，。一方面，如果是一家公司重视质量的公司，必然会引起重视；另一方面，从质量管理部门角度本身出发，也应该推动公司重视质量。，随着时间的增加，需求变更给测试人员的反馈一定会有下降的趋势，。关键是测试不能抓住鸡毛就一直揪着不放宽容一些来看待身边的同事，要允许别人他们犯错，对于解决问题本身来说会大有裨益。只要趋势是好的就可以了。同时如果出现这样的情况并且极大影响到了测试进度，则要与研发部门沟通清楚,，如果研发不认可的情况下还可以请上级进行评估一下。
• 上面说的是不同态度在同样流程下的实现不同结果,下面主要讲一下关于自身资源是否胜任做流程上规定的事情，某些工作，也许并不一定是测试部门的优势，而另外一些，则需要根据测试团队的基本能力和资源进行评估。比如像性能测试、SQL的trace、自动化功能测试、单元测试集成、游戏性测试。其实这些流程上的关键点，可能大多数从功能测试上来一路走来的测试人员是无法做的到，这时要善于利用资源，不一定要测试做，可以从通过流程上保正有人来做积极调动其它部门的同事。，或是找有能力的人来做，测试可以进行监控。其实这种技术含量高一点的测试，对人的因素要求更大高，可以借助研发团队一起来做会有更好的效果，。记的第一次做Oracle数据库性能监控时，就是请的Oracle的DBA专家帮助设计了性能参数，成功的地进行了关于Oracle应用的性能测试。现在国内的测试人员普遍的技术水平不高，严重的限制了测试的发展，希望测试的同行能真正的提升测试技术水平，把这些高难度的测试做起来，而不是仅仅只是工具上玩玩，。只有真正提升测试团队的技术含量，这样别人才会更信赖你，这也是我这么多年来的一点经验。如果你对开发很精通，、同时又精通对测试颇有研究，、善于诊断性能与架构上的问题，、经常会帮助研发部门解决一些他们无法解决的事情，、同时又还懂的如何做测试管理，并了解研发人员的心态，那就真得的找不出你还有不成功的理由了任何理由让人不对你刮目相看了。

 

项目生命周期中有三个与时间相关的重要概念，我发现很多人对这三个概念理解不准确，更不知道如何进行控制。因此把这三个概念论述得比较准确的一段文字贴出来，帮助大家理解。

　　这三个概念分别是 检查点（ CheckPoint ）、里程碑（ Mile Stone ）和基线（ Base Line ），他们一起描述了在什么时候（ When ）对项目进行什么样控制。

　　检查点

　　指在规定的时间间隔内对项目进行检查，比较实际与计划之间的差异，并根据差异进行调整。可将检查点看作是一个 固定 “ 采样 ” 时点，而时间间隔根据项目周期长短不同而不同，频度过小会失去意义，频度过大会增加管理成本。常见的间隔是每周一次，项目经理需要召开例会并上交周报。

　　里程碑

　　完成阶段性工作的标志，不同类型的项目里程碑不同。里程碑在项目管理中具有重要意义，我们用一个例子说明

　　情况一你让一个程序员一周内编写一个模块，前 3 天你们可能都挺悠闲，可后 2 天就得拼命加班编程序了，而到周末时 又发现系统有错误和遗漏，必须修改和返工，于是周末又得加班了。

　　情况二实际上你有另一种选择，即周一与程序员一起列出所有需求，并请业务人员评审，这时就可能发现遗漏并即 时修改；周二要求程序员完成模块设计并由你确认，如果没有大问题，周三、周四就可让程序员编程。同时自己准备测试案例，周五完成测试；一般经过需求、设计确认，如果程序员合格则不会有太大问题，周末可以休息了。 第二种方式增加了 “ 需求 ” 和 “ 设计 ” 两个里程碑，这看似增加了额外工作，但其实有很大意义首先，对一些复杂的项 目，需要逐步逼近目标，里程碑产出的中间 “ 交付物 ” 是每一步逼近的结果，也是控制的对象。如果没有里程碑，中间 想知道 “ 他们做的怎么样了 ” 是很困难的。其次，可以降低项目风险。通过早期评审可以提前发现需求和设计中的问 题，降低后期修改和返工的可能性。另外，还可根据每个阶段产出结果分期确认收入，避免血本无归。第三，一般人 在工作时都有 “ 前松后紧 ” 的习惯，而里程碑强制规定在某段时间做什么，从而合理分配工作，细化管理 “ 粒度 ” 。

　　基线

　　指一个（或一组）配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态。基线其实是一些 重要的里程碑，但相关交付物要通过正式评审并作为后续工作的基准和出发点。基线一旦建立后变化需要受控制。

　　重要的检查点是里程碑，重要的需要客户确认的里程碑，就是基线。在我们实际的项目中，周例会是检查点的表现形式，高层的阶段汇报会是基线的表现形式。