如何做成功的项目经理
作者: 来源: 文字大小:[大][中][小]
白项目团队将会有冲突，弄清谁是利益的关系者，明白判断项目成功的四个标准：预算、进度、效绩标准和客户满意，还要为组建一个和谐的团队，充当教练、领队和冲突仲裁人。不能因为项目中的挫折而止步不前，更不能安于现状。你在整个项目实施中，是领导也是小兵。那么，做一个成功的项目经理究竟要做哪些事情，这里作者总结了软件项目实施过程中的一些经验，希望与读者共享。
如何组织开发团队
如何构建软件开发团队取决于可供选择的人员、项目的需求以及组织的需求。本文阐述了项目实施过程中各种团队组织的策略。
有效的软件项目团队由担当各种角色的人员所组成。每位成员扮演一个或多个角色；可能一个人专门负责
项目管理，而另一些人则积极地参与系统的设计与实现。常见的一些项目角色包括：分析师、策划师、数据库管理员、设计师、操作／支持工程师、程序员、项目经理、项目赞助者、质量保证工程师、需求分析师、主题专家（用户）、测试人员。
作为一个项目经理人，您是如何组织项目团队的？是采用垂直方案、水平方案还是混合方案？以垂直方案组织的团队由多面手组成，每个成员都充当多重角色。以水平方案组织的团队由专家组成，每个成员充当一到两个角色。以混合方案组织的团队既包括多面手，又包括专家。
一个重要的考虑因素是可供选择的人员的性质。如果大多数人员是多面手，则您往往需要采用垂直方案，同样，如果大多数人员是专家，则采用水平方案。如果您正引入一些新人，即使这些人员都是合同工，则仍然需要优先考虑您的项目和组织。本文描述了形成团队组织的垂直、水平和混合方案，并指出了它们各自的优缺点。本次讨论的一个重要含意是您的团队组织和用于管理项目的手段之间应构成默契；任何方法上的失谐都很可能导致项目产生问题。
垂直团队组织
垂直团队由多面手组成。用例分配给了个人或小组，然后由他们从头至尾地实现用例。
优点
● 以单个用例为基础实现平滑的端到端开发。
● 开发人员能够掌握更广泛的技能。
缺点
● 多面手通常是一些要价很高并且很难找到的顾问。
● 多面手通常不具备快速解决具体问题所需的特定技术专长。
● 主题专家可能不得不和若干开发人员小组一起工作，从而增加了他们的负担。
● 所有多面手水平各不相同。
成功因素
● 每个成员都按照一套共同的标准与准则工作。
● 开发人员之间需要进行良好的沟通，以避免公共功能由不同的组来实现。
● 公共和达成共识的体系结构需要尽早在项目中确立。
水平团队组织
水平团队由专家组成。此类团队同时处理多个用例，每个成员都从事用例中有关其自身的方面。
优点
● 能高质量地完成项目各个方面（需求、设计等）的工作。
● 一些外部小组，如用户或操作人员，只需要与了解他们确切要求的一小部分专家进行交互。
缺点
● 专家们通常无法意识到其它专业的重要性，导致项目的各方面之间缺乏联系。
● “后端”人员所需的信息可能无法由“前端”人员来收集。
● 由于专家们的优先权、看法和需求互不相同，所以项目管理更为困难。
成功因素
● 团队成员之间需要有良好的沟通，这样他们才能彼此了解各自的职责。
● 需要制定专家们必须遵循的工作流程和质量标准，从而提高移交给其他专家的效率。
混合团队组织
混合团队由专家和多面手共同组成。多面手继续操作一个用例的整个开发过程，支持并处理多个使用例中各部分的专家们一起工作。
优点
● 拥有前两种方案的优点。
● 外部小组只需要与一小部分专家进行交互。
● 专家们可集中精力从事他们所擅长的工作。
● 各个用例的实现都保持一致。
缺点
● 拥有前两种方案的缺点。
● 多面手仍然很难找到。
● 专家们仍然不能认识到其他专家的工作并且无法很好地协作，尽管这应该由多面手来调节。
● 项目管理仍然很困难。
成功因素
● 项目团队成员需要良好的沟通。
● 需要确定公共体系结构。
● 必须适当地定义公共流程、标准和准则。
项目团队士气是项目成功的一个因素
大部分项目成功的定义说的是项目如何按时完成、是否在预算内以及是否满足用户的需要。但是，在如今要找到好的软件专业人员都非常困难，更不用说留住他们的这种情况下，还需要将项目成功的定义扩展为包括项目团队的士气。可能在努力完成一个软件项目后，不料却因为压榨他们过度而失去了重要的开发人员，这样做可能会符合组织的短期需要，但它对构建一个高效的软件部门的长远利益来说肯定是有害的。衡量项目成功与否的一个重要手段是项目结束后团队的士气。在项目结束之际，项目团队的各个成员是否觉得他们从自己的经历中学到了一些知识、是否喜欢为这次项目工作，以及是否希望参与组织的下一个项目都是非常重要的。
项目规划技巧
项目计划技巧对于现今的软件开发人员来说是必需的。这里有一些帮助您有效地计划下一个项目的建议。
认识到信心来自规划的过程，而不是计划本身。
创建项目计划会迫使您早在编写代码之前就考虑如何构建您的系统——减少项目的风险，因为您已经考虑了各种策略和方法并且已经选择了最有意义的一项。您的目的不应该只是不花气力产生一个计划；它应该是一个实际可行的计划，您可以根据它来成功管理您的项目。
软件过程推动计划的开发
每个软件过程都有一个不同的集合，它包括组织团队的活动方法以及规划项目常用的技术。由于这个原因，基于 Rational Unified Process （RUP）的项目规划不同于OOSP项目的规划，而OOSP项目的规划也不同于eXtreme Programming （XP） 项目的规划。不同的过程有不同的计划。
从粗粒度的计划开始
在项目将要开始时，应该制定一个粗粒度的、确定项目高级活动和预期里程碑的计划。粗粒度的计划将组织成迭代——根据项目的大小和性质，每次迭代通常在三周到八周之间发生（四周到六周为更佳）。其中一些迭代将集中在项目初期，而很多迭代将集中在整个应用的功能部分开发，还有一些迭代集中在将您的系统转变成产品。
实施者应该是计划人员
创建项目计划的最佳人员是负责实施该计划的人员。当规划由一个人创建而由另一个人实施时，如果项目不能按时完成或超出预算，他们不太会相信计划，而很有可能会责备它。也就是说，参与项目的每个人都应该投入到项目计划的开发和进展中。
不要忘记“不该忘记的事”
计划不仅要反映需求设计、建模、编程和测试的“真实”工作，而且还应该反映辅助活动（然而仍是重要的），它包括：休假和法定假日、培训和教育、项目管理活动（如规划和人员管理）、开销（如系统当机时间、会议和回复电子邮件）、体系结构定义、测试之后的系统返工、系统交付、与重用相关的活动（如普遍化 ）。
将任何设想和约束编入文档
规划时您总要作一些假设，如能够及时获得应用程序服务器的新发行版，或可以得到熟悉您正在应用的技术和技巧的开发人员。同时，您将在一些约束下工作，如影响计划的强制截止期限或资源限制。将这些假设和约束编入文档，这样，当您实施项目的任何时候更新计划时，都可以记起您先前做出的一些“不寻常”决定。
认识到不同的资源意味着不同的计划
十名有经验的开发人员组成的团队创造出的成效要远远多于十名初学者组成的团队所创造的成效。要想更加实际的话，您的计划必须反映项目可使用的资源的真实情况。
创建现实的计划
项目组必须相信其项目的目的、估价和时间表。要做到这点，您必须真实地规划，避免规划超出您能理解的范围。仅当您打算研究未知事项时，才能容忍无知。
只规划有价值的事
IBM DeveloperWorks 网站提供了许多可应用于您项目的最佳实践。然而，根据项目的性质，不是所有这些技术都将适合于您的独特情况。要将这些最佳实践简单地看作是您放置在“项目管理工具箱”中的工具，您可以根据需要适当使用这些工具。
适当使用项目管理工具
一些项目管理工具，如 Microsoft Project，提供了重要功能， 如Gantt图表（活动时间表）的开发、规划与实际结果的比较、PERT 图表（网络图表）的开发、任务的定义、任务之间相关性的定义、对任务的资源分配和资源平衡。所有这些事情似乎象是一个好主意，并且它们通常是好主意——但它们还需要许多精力来创建和维护，而且很少为项目组提供实际价值。的确，它让一些项目管理人员感到富有成效。的确，高级管理喜欢看见您有一个计划。但是，没有一行代码是由所有这个活动产生的。规划是有价值的活动；但投入大量的时间来创建规划图表通常不是有价值的活动。
谨慎应用技术方案处理管理问题
对于在项目中遇到的问题，您确信需要用技术来解决吗？本文改编自作者所著的Process Patterns 的第五章，Scott Ambler建议改进管理，而不是新技术，可能就是您的解决方案。
还没有一种点能表明用部署最新技术中来解决通过改变管理实践去解决问题的（请参阅参考资料中 The Squandered Computer）。事实上是，您不应该将所有商业过程所得的好处都归功于支持这些更改的软件项目。没有这些新的软件或硬件，您可能会得到同样的好处。
将技术解决方案识别成非技术问题是经常重复发生在信息技术界的常见错误。这种经常发生的错误将其看成是称作 Apply Technical Solution to Non-Technical Problem（将技术解决方案应用到非技术问题）自身的过程反模式（过程反模式是一种已证明在实际运行当中并不是行之有效的方法）。
技术解决方案仅适用于解决技术问题。例如，“网络计算机”的概念仍然是计算机界中热衷的时尚。其基本概念就是通过网络计算机来替代个人计算机，组织就可以大大缩减支持计算机软硬件的开支。
研究表明，如果包括培训和支持这些计算机费用的话，那每年支持一台个人计算机的平均开支大约在 $5，000 到 $30，000 之间。网络计算机（也称之为 Java 终端，因为它们仅运行已经打包成 Java 字节代码的程序）理论上将缩减开支，因为它们仅需要简单的维护和支持。尽管做了大量的广告宣传，但迄今为止，网络计算机的销售量十分可怜。从表面上看，网络计算机试图解决的问题看起来是技术性的。但当您想到这一点的时候，问题实际已经成为管理问题之一了。
一些组织一年要花费 $30，000来支持计算机的原因不是因为个人计算机，而是由于对个人计算机的误用。这些组织不是由具有资格的专业人员来安装公共配置，而是让用户选择和安装他们自己的软件。一旦用户遇到了麻烦，组织的开支就飞涨。另外还有文件格式不相容的问题。若没有公共的软件套件，用户得浪费大量时间在同一供应商所提供的不同软件版本之间转换文件，或从不同供应商所提供的不同软件之间转换文件。基于类似的原因，当用户购买他们自己的设备时，硬件培训和支持也变得更加困难。
在这种情况下所发生的问题是与过程相关：个人计算机软硬件的管理不当。因而购置网络计算机这一技术解决方案是否能够解决问题值得怀疑。技术解决方案适用于技术问题，管理解决方案适应于管理问题，而过程解决方案则适用于过程问题。在谈完了所有内容之后，我真正的意思也许仅仅是在工作中要使用正确的工具。
基于需求的规划策略：按优先次序排序
成功的项目组认识到不能等同地创建所有的需求，因此，需要对需求进行优先次序排序并按此顺序操作。
某些需求比其它需求重要得多。例如，对于联机银行的需求来说，对帐户间资金转移的支持要比银行每月声明的 Elbonian语言版本重要得多。成功的软件团队将首先集中精力构建最重要的功能，尽可能地满足用户需求中关键的功能，而那些次关键性功能留到以后处理。需求排序使您的团队能够为组织的软件利润作出最大贡献。然而，要有效地对需求进行优先次序排序，必须考虑几个因素：商业价值、交付成本、交付日期、交付复杂程度、风险（请参阅提示“控制风险：不让风险控制您”）、与其它需求的关系、何时需要该需求。
可能的优先级别范围
只要明确的定义了优先级并且在应用上保持一致，那么使用什么优先级别范围是无关紧要的。一般的优先级别范围包括：
● 高级、中等、低级
● 必需的、条件的、可选的
● 数字的（例如，1、2、3）
如何对需求按优先次序排序
您应该让授权的个人或小组来建立并确认指派的优先权。对需求的优先级进行优先次序排序通常是一个协商的过程，它涉及到许多项目参与者，包括您的用户、用户管理、高级管理、开发人员、操作人员和支持部门。
大多数项目小组将组织成一个“配置控制委员会 （CCB）”——有时称为“更改控制委员会”或“项目筹划指导委员会” ——它由系统中关键的并且希望是知识渊博的参与者组成。通常由该小组定期开会决定任何新需求的优先级和指派（对于系统的发布或者对于在现有开发成果中的重复）。
为何对需求进行优先次序排序？
需求排序列表是输入进项目定界过程中的关键因素。项目早期，需要认识到，最困难的事之一是不要打算能交付项目参与者要求的每个功能。项目范围定义了项目组将要交付的范围。这是很重要的，因为它有助于避免“超出范围”，即，项目进展的附加的新需求。已定义的项目范围使您能协商是否有责任交付新确定的需求，并判断新需求对于交付日期／成本的增加的合理性以及讨论是否应该在后续发行版中交付该需求。缺少确定的范围，项目组将承担无法交付的风险，因为经常要向正在构建的项目中添加“再多一条功能”。
规划迭代：及时开发详细计划
项目不断进行时，需要详细规划即将实施的迭代活动。在当今日新月异的环境中，提前几个月甚至几年做详细规划是毫无价值的，但您可以对下几周（典型的迭代的时间跨度）进行成功地详细规划。
项目规划的普遍且难以置信的有效方法是从粗略的项目规划开始（请参阅“项目规则技巧”），即从项目开始时开发，然后在完成构成项目的各种迭代时缓慢发展形成。随着项目不断进展，需要更新整个粗略的项目规划，更新它以反映近来努力的实际成果以及您的团队将继续从事的下一个（或两个）迭代的规划细节。在为单一迭代开发细致的规划时，应该执行这些步骤。
实行真实性检查
通过询问并且回答一些难题来开始详细的规划工作：项目是否仍在按计划进行？您的方法是否仍有意义？您的团队是否由合适的人员组成？您是否仍有资金管理者支持？如果其中任何一个问题的答案是否，则需要解决问题，这可能意味着新（且非常短）迭代使您的团队回到正常轨道上。对处于困境的项目进行大计划是毫无价值的。
标识详细的任务
在项目开始时，体系结构和转移迭代只是列出需要实现的任务列表。然而，要规划迭代，必须评估已为它指定的需求（请参阅“基于需求的规划策略”）。随着项目发展，您将对于对个别需求有更好理解。您可能会发现，现在需要更改给迭代指定的原始需求，这些需求最初是有意义的。或许已经标识并添加了新的需求；或许已经扩展或缩减了需求；或许已经更改了优先级。不管什么原因，您会发现您需要重新定义打算在该迭代中实现的内容。根据需求，标识需要实现的任务。
标识任务相关性
某些任务取决于其它任务。例如，在部署源代码之前，必须先编写它。测试案例的开发可以在编码之前开始。实际代码的测试必须等待，直到已经编写了某些代码（尽管或许不是所有代码）为止。问题是某些任务必须在其它任务完成之后才能开始；某些任务必须等待，直到另一个任务开始了为止，它才可以开始；某些任务不能完成，直到另一个任务完成为止；某些任务不能完成，直到另一个任务开始了为止。
均衡资源
需要紧记的重要事情是，每个人一次只可处理那么多任务，并且在工作的那一天只有那么多时间。这个概念称为资源均衡，确保任务分派是合理的。 指定用 10% 的时间完成 10 项任务很可能无法完成任何任务， 而且指定用 50% 的时间完成 5 项任务的人员也不可能完成这些任务。确保现实的规划的最好方法是，让执行计划的人员参与计划开发。
保持迭代短小
迭代周期应该保持比较短。应该将大于 8 周的迭代分割，以便让您迅速将软件交付给用户。因为正在尝试弥补在先前迭代中跳过的工作（如文档编制），或者因为您的需求正在增加而没有添加新的迭代来反映这一事实，所以当项目进展时迭代长度增长是一种趋势。执行真实性检查并按照它们的结果行动，将帮助您使迭代周期保持简短。
考虑并行开发
分几个子团队来同时进行系统的不同部分始终是一种有效的办法，尤其对于系统纵向片段的开发。并行开发可以大大地缩短产品的上市时间，这是当今高度市场竞争性的一个重要因素，尽管它以增加协调工作为代价。共同的体系结构、共享知识视野、共同的开发实践、定期团队会议及共享工作场地使并行开发成为可能。