时间: 2021-07-30 09:40:55 人气: 17 评论: 0
对周期长、规模大、涉及人员多的项目来说，优秀的项目经理能对项目成功起到非常大的作用与贡献，那么优秀的项目经理一般都是怎么管控、协调项目进行的呢？本文将为你带来思考与启发。
本文是针对软件项目的开展，对于其他类型的项目，仅供参考。
最近因公司业务和组织架构调整，人手抽调不开，公司老大让我临时负责一个年度研发项目的管理。
尽管这些年一直在从事产品管理工作，但笔者在过往的工作经历中，也承担过多个软件系统项目的管理工作。
今天跟公司其他几个项目经理在沟通如何快速培养成一名优秀的项目经理，笔者这边跟大家分享一下自己在这方面的经验，希望能给从事软件项目管理工作的朋友一些帮助。也相信通过本文，能让你快速掌握项目管理过程中要点，实现项目目标，并在项目活动过程中提升自我。同时也希望阅读此文的大咖，能给出意见和建议，感谢！
我们都知道，所有形式的立项，目的只有一个，那就是项目成功，而在项目管理过程中也都围绕着这个目标开展工作。
我们要让一个项目在设定的时间、资源、范围下圆满完成任务，肯定是**有一定难度的，项目涉及的面越广，体量越大，风险也**越大。
而项目经理作为项目成败的核心人物，有着举重轻重的作用，也正因为如此，项目经理需要从以下六个方面着手，像六脉神剑一样，招招致胜！
自古以来所有新上任的官，为更好地行使管理职权，必定要先树军威。
韩信作为胯下之人，在刘邦处任将军之时，首先做的就是树军威，明军纪，刚上任就把刘邦的表弟给斩了。
司马穰临危受命之时为了树军威，不但斩了不遵军纪的庄贾，还斩杀了大王派来却乱闯军营的使者的马匹，把使者吓个半死。
项目组都是临时组建而成，一般生命周期都不**很长，而很多公司也是职能型管理方式，成员来自不同的部门，因此项目经理在上任之时，也需要树好军威，以便调动组成员。
主要有以下两方面来练成第一招：
正常来说公司都**有项目立项环节，但也有的公司为了所谓的“高效”，立项都是走个过场，项目组内部通知一下就完事了。
笔者觉得这很要不得，神秘兮兮，搞的像是要开展什么机密活动，生怕别人知道一样。
人天生就有一种对权力的敬畏，可能是几千年封建社**所形成的惯性思维吧，当然笔者不提倡所谓的“奴性”，这也是两码事。
在项目经理开展具体的项目管理工作之前，一定需要公司把立项文件以正式发文的形式“昭告天下”，这是对项目的重视，也是对项目经理树军威最好的机**。
如果有公司没有发文，项目经理完全可以要求公司正式发文，正式对项目经理任命，以免对后续工作开展不利。
相信很多企业在做组织架构时，HR部门**整理公司各岗位职责说明书，那么项目经理的职责肯定也是写的清清楚楚，而且在立项文件中**强调参照岗位职责文件。如果你的公司并没有对项目经理这一岗位的职责进行明确，那么在立项前，需要进行明确。
项目经理作为项目开展过程中的灵魂人物，对项目的结果是负有直接责任的，需要有效地推动项目进度，控制好项目风险，以达到项目目标。
同时也应赋予项目经理相应的权力，主要有：
而以上这些职权的明确，也是在帮助项目经理树军威。
只有出发，才能到达。话虽如此，但如果没有明确的目标，将**离目标越走越远。
对于明确项目目标的重要性，笔者就不赘述了，地球人都知道。但如果项目经理心里只有一个总体的目标，那在落地时必定**遇到麻烦。
项目绝不**是突然间就做好了，肯定是有个循序渐进的过程，那么如果没有对总体目标的拆解，通过一个个里程碑来作为过程中的检验标准，项目失败的可能性将**大大上升。
在立项之前，相信在公司内部完成对项目总体目标的明确，而当项目经理接手项目后，首先要做的就是对目标进行拆解，形成一个个里程碑目标，以确保项目能阶段性地输出成果，最终达到项目总目标。
同时里程碑目标，也是为了能更好地控制项目成本和风险，可简单理解为子项目，但不等同。因为里程碑目标中不输出，不代表不在里程碑中开展相应工作，因为有些技术问题的解决可能贯穿整个项目，但只**在后面的里程碑中体现成果。
里程碑目标需要包含输出时间、目标、检验指标三方面。从原则上来讲，里程碑目标由项目经理决定，后续的变更也由项目经理决定。但在实际的执行情况中，项目经理需要尽量按里程碑输出成果，不可随意变更，否则极有可能影响整个项目的成果输出。
至于里程碑输出的颗粒度，从笔者的经验来看，一个项目的里程碑不可过多，也不可过少，一般将项目拆分成2到4个里程碑比较合适。每个里程碑的成果应该具备可输出能力，且需要能够进行检验，说明白点，每个里程碑输出的东西都应具备可行上线的能力，但至于是否一定需要输出，这个可由项目经理、产品经理、项目管理委员**共同商议决定。
一个篱笆三个帮，项目经理个人能力再强，项目工作的开展也需要依赖团队每个人的齐心协力。
而对于项目经理来说，成立项目组，选任合适的核心人员，是一件非常重要的事情，这也是决定项目成败重要的因素之一。
按正常的流程，在立项之前必定**完成项目组成员的选定工作，当然也有在立项后再慢慢组建团队的情况，但无论是何种情况，选人是项目经理必备能力，也是必须经历的。
项目体量越大，涉及的面越广，项目组成员的组成也**越复杂。
我们本文主要是说软件项目工作的开展，按照常规性的软件项目人员组成，需要先完成对产品经理、架构师、核心开发人员、测试组长四个核心角色的选定。
在不同的公司中，项目核心角色可能**有不同，这个没关系，按照各自的情况来确定即可，重点是需要明确项目组有哪些核心角色，以及对应人员的选定。
在人员选定时，需要从两方面进行评估，以确保所有人员都能符合项目需求。
首先是技能要求，项目经理通过对项目目标的初步分解后，需要分析清楚关键性的项目技术难点，按以往的经验来看，这个风险看起来很小，但在很多项目中成为扼制项目进度的“大坑”。因此结合项目在技术上的需求，以此作为参考点来选定合适的人员。
看到此，有人可能**问，项目经理又不是万能的，要是无法计数上的难点怎么办？
问的好，如果由于项目经理在技术上的不足，比如该项目经理只懂Java，从未使用C#开发过项目，也不清楚相应的技术卡点，那么此时先要找一位合适的.Net架构师，然后帮你一起分析，以此来明确技术要求。
其次是素养要求，这个听着好像没什么好考虑，但笔者认为这个跟非功能性需求一般，非常重要且是必须考虑的内容。
从笔者的经验分析，在职业素养上，核心人员必须要积极主动、有责任心，能同项目经理一起去思考、分析、承担项目中的风险。
核心人员应有正能量，有一定的沟通能力，能倾听团队中其他成员的意见，让项目团队有强大的凝聚力，同时也能帮助项目经理推荐合理的项目成员，共同完成项目团队的组建。
没有规矩，不成方圆。项目组有大有小，但管理过程都是相似的，为确保项目组所有人员能正常有序地开展工作，其中关键的就是要在内部设定合理的规矩，也就是奖惩措施。
正所谓重金之下必有勇夫，在有条件的情况下，项目经理应当去争取合理的项目奖励，注意这里是奖励，而不是奖金，因为奖励方式可以有多种，包括现金、调休、旅行等等。
反过来，对于违反项目内制度，给项目开展带来不利影响的人员，也要受到响应的惩罚。包括无故不参加项目例**、项目组内部故意制造矛盾等等。
但是有一点需要注意，项目组的奖惩措施一定是“小于”且未在公司制度中明确的，避免受到多次奖励或惩罚。
对于风险防范的重要性，应该是从立项开始人人都在喊的事情，但在实际的项目中往往**存在某些风险未能很好地识别，而导致项目开展的不顺利，轻则延期，重则失败。
笔者有个真实的例子，之前朋友公司是做电力施工项目的，从接受合同到设备研发，都没任何问题，直到将设备运到实际场地时才发现，有两处的电力设备需要安装到两个很小的海岛上，那边现场无法安装吊机，人工是根本没法将电杆搬运上去，结果不但对甲方作出了高额的赔偿，还影响了公司的信誉，连这种基本的风险都没识别。
对于软件项目来说，风险也是处处都在，根据笔者的实际经验，风险的识别需要从以下方面进行分析。
每种风险之间还存在关联关系，很可能是某一个风险的发生，导致其他风险的连锁反应，有点类似蝴蝶效应，因此正确识别风险非常关键。
项目经理应当同项目组核心角色一同去分析，并制定相应的措施，以免在发生风险时能很好地应对。
这里主要是指项目进度，软件项目延期是很常见的事，因此时间风险是很容易被识别出来的。
项目经理需要做好项目详细的计划，做好WBS，并每天对计划进行跟踪，以及出现的问题进行分析。
对于在约定时间内无法正常输出成果，可通过适当地加班来补偿，对于质量问题引起的时间延期，一方面需要架构师对开发人员在技术处理上进行指导，另一方面需要加强测试力度，尽早发现质量问题，尽早解决。
项目组人员变动也是常见的问题，最麻烦的就是核心人员的变动。因此对于人员风险的防控上，项目经理需要做好人员的备份方案，以便在出现人员变动后能及时补位，尽可能地减少对项目的影响。
项目经理需要时常关注项目组成员的状态，对于存在离职等风险的员工，要能尽早识别，特别是年底、年初这样的跳槽高峰期来临之前，必须要有一定的准备方案。
另外在软件项目开发过程中的设计类资料必须要以文档形式输出并做好更新，也可以防止在人员变动后能快速接手。
如果项目经理能把项目计划、WBS做好的情况下，技术上存在的风险是很容易识别的，因为做计划、评估工作量时就**去思考所有的技术实现问题。
那么我们是否还存在其他容易忽视的技术风险呢？
答案是肯定的。
笔者曾经在负责某个产品的开发时，其中有一个技术需要依赖于第三方公司现成的技术能力，但当在项目快进入收尾阶段时，突然传来一个消息，该第三方公司因为自身技术成果涉及知识产权问题，无法实现商业化输出，这给我们的项目沉重的打击，因为我们没有做任何的备份方案，导致项目不得不延期，并重新选型、重新商务谈判、重新技术接口开发，最终项目延期了整整半年多，造成巨大的经济损失。
因此在技术上，除了需要很好地识别项目内部的技术风险外，如果存在外部依赖的，一定要做好备份技术方案，这方面也包括项目在硬件供应商的选型，一般来说都**有两到三家供应商，绝不**单一依赖。
敏捷开发的其中一个原则就是拥抱需求，其实项目目标也存在变更的可能性。这种风险是最难防控的，因为往往是投资人、老总或者突变的市场所引起的。对于此类全局性的风险，笔者认为需要从两方面进行把控：
前面也讲到，项目开展的目标是项目成功，项目经理必须携同项目组成员，不惜一切代价，确保项目保质保量按时完成。而对于项目经理而言，项目成果也是关键KPI。
从笔者的角度来看，项目过程**是比较长的一段时间，项目需要阶段性地输出成果，一方面这是实现项目成功的基础，另一方面也是像公司高层表明自己的能力。因此项目经理不能只是追求最终成果，那样不仅风险大，也不利于证明自己。
另外除了项目成功这一目标外，项目经理还需要关注项目组成员“能力提升”这一成绩。
这个是很多项目经理往往**忽视的地方。这其中藏着两个原因：
首先，万一项目失败，但项目成员的能力得到了提升，还能为公司挽回一点损失；
其次，项目经理在以后其他的项目工作中，很可能还需要跟这一波人继续合作，人都是**念你的好的，如果能让团队成员能力得到提升，那么在后续工作中肯定**更加得心应手些。
本文由 @jiongoogle 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Unsplash ，基于 CC0 协议
