为什么我说做好项目管理不容易

　　本文作者根据自己的经验，详述了项目管理中的一些难点问题，其中包括这几个方面：需求管理、版本验收管理，以及干系人的管理。
　　写这篇文章的出发点在于，曾经和朋友聊天的时候，被问到一个问题，＂你认为做项目管理最难的是什么？＂。
　　当时，我楞了一下，回答到＂最难的是在于对人的管理＂。从我朋友的表情反馈来看，很明显，他在我这里没有获得预期的答案。因为，不仅仅是项目经理，任何的管理者，都会觉得人是最难管理的，这个回答太笼统，太概括。
　　不知不觉在项目管理这条路上已经走过了4年多，这一路走来的酸甜苦辣，恐怕只有自己才有最深刻的体会，但此前我似乎也没有真正思考过，这么多年带项目，遇到不同程度的问题，踩过各种各样的坑，遭遇过很多挑战，究竟什么才是项目管理中最难的？
　　当静下心来，深入思考时，慢慢的有了些许的自我认知。本篇文章就个人的看法，谈一下我认为的项目管理中最难的几个方面：需求管理；版本验收管理；干系人的管理。前两大难点是基于事，后一大难点是基于人。
　　一、第一大难点，需求管理
　　需求是任何一个项目的源头，没有需求管理，项目管理不可能成功。可见需求管理的重要性，恰恰是因为对需求管理的重要性，以及项目本身不确定的特点，才使得需求管理是整个项目管理过程中的第一大难点。
　　1. 需求管理难点的两大原因
　　（1）原因之一：启动之初，如何从透过产品需求深度理解业务目标
　　以游戏项目为例来说，游戏的提案，或说游戏的方向一旦确定，作为项目的核心管理层，必然是想要尽快的看到游戏的demo版本，这样可以让核心管理层、团队成员直观的感知到从提案到实际可操作、可触摸的游戏核心玩法，有助于尽早的明确核心玩法。毕竟，对于一款游戏来说，核心玩法才是最根本的。用精益创业的核心思想来说，游戏的demo版本，可称之为最小可行性产品，它有4个特点：体现了项目创意、能够测试和演示、功能极简、开发成本最低。
　　基于这4个特点，又要在短时间内对游戏的demo版本的需求有一个比较精准的定位，这并不是一件容易的事情。也许有人会说，这个过程不是主策和老板的事情吗？
　　其实不然，我认为这是一个项目团队需要共同关注的事情。
　　对于老板和主策，及策划团队来说，是需要把控游戏的方向，但不同老板和的策划人员，有其自身的观点和看法，这是多样性的，也有不同的表达需求的能力；
　　对于美术团队来说，需要领会或说领悟该游戏方向的美术风格；
　　对于开发团队来说，需要清楚游戏方向敲定后使用最佳或最优的框架；
　　对于项目经理，我认为也需要深入理解该游戏方向和立项的初衷，这样才便于接下来的一系列工作展开。
　　在游戏论证的过程中，可能部分项目经理参与的并不多，但如果条件允许，我个人的建议是，尽可能争取多参与到前期的研讨和论证，清楚游戏提案形成的过程，在对demo版本进行研发的过程时，有很好的效用。
　　这部分有初步结论之后，则需要策划团队进一步落地demo版本的具体需求，而项目经理此时对需求管理的难点在于：
　　如何更好的理解游戏的核心玩法？如何更好的明确需求的优先级？如何尽快梳理系统间的依赖关系？如何更好的调配好资源，使得进度最大化？如何快速的引导团队对demo版本展开各项工作？
　　（2）原因之二，在项目执行阶段，需求的变更控制
　　互联网时代，唯一不变的就是变化。游戏项目的需求变更恐怕是在项目管理过程中被谈论最多的，尤其是互联网浪潮下的产品，游戏项目更加不例外。
　　就游戏项目本身性质而言，通常情况下，项目经理和团队成员将各项计划落实，开始执行后，每个变动，都是牵一发而动全身。这是因为，需求是源头，从开发，美术，测试整个闭环链上的每个角色，其对项目输出的成果都是不可逆的。
　　一旦决策，项目实施所出现的后果，无论是好的还是坏的，都与项目决策息息相关。因而，在负责过这么多项目的过程中会发现，在项目初期的变更，尤其是一些还未开始实施的功能系统，可能只局限于文档上的修改，而如果是到了项目实施的中后期，需求变更所带来的影响将显著上升。
　　举个最简单的例子，游戏的系统功能A，程序员已经开发到一半的时候，策划说该需求要调整，这个时候影响的不仅仅只是开发的工作量，还有美术设计，测试的用例设计，以及整个项目的目标，都会受到影响。
　　因此，对于需求的管理，需要有充分的了解。游戏所对应的每个功能系统，都需要前期经过综合、全面的分析和思考，尽量做到少的变更，尤其是尽量避免全功能的变更。
　　事实上，不仅仅是对于游戏项目，互联网大背景下的任何产品，都不可避免的会存在需求的变更，有时候并不是随我们意愿而掌控的。变更流程，只是为了更好的对需求变更进行管理，但真正的因为市场环境的变化，因为用户的需求，因为战略目标的调整，因为要匠心打造精品，必要的变更，作为项目经理，要勇于去拥抱变化。
　　这个时候关键的问题在于，项目经理是否可以灵活应变，处理好这种变化；或者说一些突发的变化，是否能够处变不惊，让变更后的需求或项目快速的进入预设轨道，这是非常值得深思的事情。
　　2. 应对需求管理之难的策略
　　需求管理的难点，在于对需求不理解，对产品意图把握不准确；在于市场的千变万化；在于无法控制频繁的变更。
　　（1）在项目启动之初，作为项目经理，要高标准要求，促进团队，尤其是策划团队，对需求进行良好的分析，拒绝标题党，拒绝参考某某游戏等一切劣质的需求
　　（2）在项目规划阶段，和主策、策划团队，及老板等管理层，充分的沟通，得到他们对需求管理的支持；
　　（3）在规划和执行阶段，要顶得住压力，切忌上演＂先干起来再说＂，在需求框架和核心需求未敲定之前不急于开工；
　　（4）在执行和监控阶段，做好变更的管理，控制好需求的频繁变更，同时控制好需求的蔓延和镀金。
　　二、第二大难点，版本验收管理
　　在敏捷思想的引领下，互联网产品（包括游戏项目）在研发过程中，都是期望尽早且持续交付有价值的版本来满足产品的期望。
　　因此对于每个迭代版本的验收，对于每个迭代研发过程中系统和功能的验收，就非常重要了。在这样的背景下，如何做好验收，是值得我们每个项目经理去认真去思考的。
　　整个过程中的验收做的好，对于中后期项目质量的管控和对游戏的目标引导，也是会显得更加的游刃有余。做好项目的验收，本身也是符合现代管理思维，保持效率和效果的平衡，这更会是一个积极有效的项目管控过程。
　　1. 版本验收管理难点的原因
　　（1）原因之一：多人并行，快节奏开发下，对单个系统的验证
　　我们是否曾经都有过这样的经历。在项目初始阶段，一切都看上去挺顺利的，但实际到了验收阶段，就频繁出问题，不是功能的缺失，就是进度的delay，甚至于需求开发完之后，和策划设计的预期差别很大。曾经和一些项目经理岗位的朋友，也聊到其所负责的大型项目，在并行开发阶段，都相比较是顺利的，但一到出版本验收的时候，代码合入就出问题；或者代码是合入好了，但版本根本跑不起来；或者说可以跑起来，但一登陆就崩溃；或是在验收过程中，不充分，不仔细，老板体验时频频挑战，测试阶段测试人员吐槽版本质量烂等等。
　　如此种种，我都将其归结为是在项目执行/监控过程中验收的问题，因为本身是一个难点，没有做好验收的准备工作，自然是问题频出。而且，到验收环节时，以某个系统功能为例，验收的难点在于，它并不是开发人员一个人的事情，会涉及到负责该系统的策划人员、美术设计师、测试人员，还有项目的主要干系人的满意度，这也就更增加了做好验收的难度。单个系统的验收难点只是其一。
　　（2）原因之二：游戏有机整合后，对游戏性及游戏目标引导的验证
　　当游戏项目的多个系统都开发完成，各系统开始有机整合，要验收游戏的完整性，验收游戏的游戏性以及游戏的目标引导，这才是更难的地方。
　　这个阶段，对项目经理来说是要求非常高的，要对游戏有一定的理解，才能推动项目团队去整合，去梳理清楚游戏的目标引导。或者至少，项目经理要知道如何去推动策划团队和项目团队去完成游戏目标引导的梳理。
　　2. 做好版本验收管理的几个关键点
　　验收的环节，是整个项目中的重中之重，因为这是从项目研发阶段到项目产出阶段的成果验证。如果验收的时候，各种问题层出不穷，那整个过程控制的再好，各个里程碑目标按预期时间达成，都是等于零。尤其是在中后期对游戏目标引导的验收，如果系统功能开发接近尾声，项目团队成员都还觉得游戏没什么好玩的，玩了一段时间没有目标，那对于团队的自信心来说，是会大打折扣的。
　　追其根本原因在于，不仅项目的业务目标未达成，还使得老板及主要干系人不满意。相反，如果验收做的好，不仅老板及主要干系人满意，团队也更有信心，而且在项目测试期间，测试人员对质量的把控也更有倾向性，项目的整体时间也更容易把控。因此，要做好项目的验收，并不是计划做好了，按计划执行，到需求完成的时候就验收就可以了。
　　（1）在项目需求开始执行的同时，策划人员需要非常清楚需求的验收标准，不仅仅是需求本身的逻辑功能，还有要清楚该系统功能需要怎样的表现效果，这点至关重要；
　　（2）在多人并行开发，大团队协同作战的时候，要做好对版本的管理。作为项目经理，我们不能想当然的理解为，程序员开发完一个系统功能，就是真正意义上的功能完成；我们更不能简单的理解为，多个开发人员对功能系统的开发，到整合版本的时候，会像是堆积木一样的叠加，无数个项目已证明代码之间的整合是一个系统而又复杂的有机整合。
　　（3）在项目计划时，要给每个系统都预留一定的策划验收时间。无数个项目已经证明，当程序员说功能开发完成了，仅仅只局限于其本身所理解的，功能的正常逻辑完成了，可以体验了，而系统功能的细节、效果、表现，往往因为各种原因被忽略。留有策划体验的时间，就可以对照需求的验收标准进行验收，提交一系列的体验意见进行修改，到满足测试标准的时候，还有相应的逻辑bug解决，这些完成之后，才可以真正的说该系统功能完成了；
　　（4）明确验收标准，光有策划投入验收不行，还要把开发自测，美术对效果负责，策划对整个需求功能和效果负责，测试对质量把控，让整个验收形成闭环，这样才可以达到预期的效果；
　　（5）在中后期，对游戏性的验收，对游戏目标引导的验收，要提前做好规划，包括正式发布版数值框架的确定，更要模拟发布上线后的数值来进行；同时，将团队纳入每天的游戏体验环节。如果项目经理对游戏有足够的理解，对游戏有足够的掌控力，会更好的驱动策划团队做好一系列的事情；如果项目经理在这方面驱动力不够，那也要推动策划团队提前做好方案，提前规划好数值，借助项目核心管理层来推动落实游戏目标引导的验收。
　　三、第三大难点，干系人的管理
　　随着在项目管理这条路上越走越远，慢慢的会从管事到管人的过渡。这有一个过程，也是顺势而为。
　　当在项目中遇到不同的事情时，深入思考的时候会发现，事情处理的背后还是人，那么管事的本质上还是对人的管理。当负责的项目越多，遇到的事情越多，思考的越多，会慢慢的发现，对人的管理是最难的。具体来说：团队内部，保持团队激情斗志和战斗力往往是最难的；向上管理，搞好核心干系人（管理层）管理、取得管理层的高度信任，并让他们满意往往也是最难的。所以，项目管理过程中的第三大难点，是对干系人的管理。（PMBOK第6版，干系人已经修改为相关方）
　　项目经理应该都比较清楚的是，对于自己所负责的项目，核心干系人（直白的说，就是老板）的满意度是非常重要的。项目成功的标准：实现项目目标，让主要干系人满意，而主要干系人满意才是重点。
　　那怎么才能让老板满意？先看一个实际的案例：
　　2015年下半年负责的JQ项目，到2106年4月份时候，项目的前期研发接近尾声，内测数据已经达标，就等着正式公测。由于我自身的乐观和对风险预估的不足，每次汇报的时候，都是告诉老板，没有什么问题，android版本准备好了，人员也可以抽离负责其他项目。事实上，因为是第一款负责的手游数据达标可以公测，对手游上线发布的特点不了解，以至于ios版本后面一堆问题，导致团队加班无限，而且还延误了公测的时间。
　　原本经常和老板汇报说一切顺利，没有问题，给老板的期望很高，结果是目标未达成，老板自然不满意。当然，老板不满意，并不全是目标未达成，而是作为项目经理，对风险预估不足，对项目上线未知又没有进行全面思考，同时，还不断的给老板传递很高的期望。
　　通过这个案例，在深入分析的时候会发现，有一个非常关键的词——期望。在给老板高期望的时候，其他各个方面的事情又没有做到位，那导致老板不满意就不足为奇了。一次偶然的机会，我在听吴永达老师讲关于干系人管理的课程时，提到了一个非常有价值的公式：
　　看到这个公式的时候，想必不少读者朋友已经发现，期望高，满意度就会低。
　　那怎么才能让干系人满意呢，两大要点：
　　（1）要点之一，提升体验
　　提升体验，简而言之投其所好，给其所要。投其所好，给其所要，并不是一味的去迎合老板们所想所要，而是在项目管理过程中，更好的去关注到核心干系人（管理层）他们中的关注的部分。
　　比如，项目一开始的时候，游戏的核心玩法、商业化；美术风格效果；项目进行中，核心系统的完成情况；再往后，整个产品的引导目标、数值框架；项目内测和正式公测后的产品数据。
　　这些都是主要干系人（管理层）重点关注的，那么我们在这个期间，作为项目经理，要主动汇总、分析、整合、汇报项目的信息，让整个项目管理过程可视化，要让管理层从项目经理这里获取到足够有用的，有价值的信息。同时，在多汇报时，也可以很清楚的让管理层知道团队的做事方式的正确性，这对于管理层来说，也是非常重要的。
　　（2）要点之二，降低期望
　　降低期望其实是对核心干系人的期望进行管理，这是一门艺术，也是让干系人满意的关键。在项目进程中，由于项目不确定的特点，项目管理过程并不会一帆风顺。作为项目经理，要时刻关注核心干系人（管理层）他们所重点关注的部分。对于他们所关注的部分，往往也是项目的重难点。对于这些重难点，项目的每个阶段是否会存在什么风险或可能的问题，这些重难点是否都有比较好的应对方案，是否会影响整个项目的进度和目标。项目经理在项目管理过程中，要多主动、且客观、实事求是的向管理层沟通和汇报项目的进度、规划和安排，承诺完成目标的同时，更要说明可能存在的风险，以便降低管理层的预期。风险是一方面，还有很重要的一点，可以及时获得核心关系人对项目的反馈，必要的时候，也可以获得核心关系人对项目的支持和帮助，以便更好的达成项目目标。
　　不仅仅是对于管理层，项目的干系人管理还有团队成员，项目其实是面向干系人管理的过程。而干系人极其期望管理是项目管理的真正难题。作为项目经理，在对项目干系人的管理方面，是一个持续的过程，也是一个不断的自我修炼的过程。