如何组织开发团队做成功的项目经理

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