如何做需求管理？这8个tips你需要知道（下）

lsekfe

5、需求开发
　　需求确认之后，进入开发阶段。从需求评审到最后验收，是一个闭环流程。详见下图：

需要特别说明的是，需求在开发阶段，需求评审、需求可行性论证、需求的方案设计、技术方案评估，都需要开发和美术的leader一起参与评审，并对结果负责。在需求评审的时候，产品、开发、美术和测试相关的人员都需要参加。
　　需求的源头确认了，那么在需求进入开发阶段的源头，也需要多次核对并确认。正所谓磨刀不误砍柴工，千万不要认为这个时间花了，还不如提前接入写几行代码。一旦出现被催进度，尽快启动开发的时候，项目经理一定要顶得住压力，把前面的准备工作做足。
　　以一个需求为例来说，我们看的是整个需求的完整开发周期，也就是从需求评审->需求开发->需求验收->需求测试->需求完结。
　　需求开发的源头就是需求方案的设计，详细工作量的评估，需要层层把关，对结果负责。试想，如果为了省这个几天的时间，结果导致需求开发完成之后，出现一堆bug，最后验收效果不好，测试过程坎坷，看着前面省了一点时间，但其实整个需求的开发周期都拉长了。
　　在软件质量里面有一句话：质量是设计出来的。测试人员是质量最后的“守门员”，不要把所有的质量问题都留在最后测试环节。
　　所以技术方案，详细工作量评估（WBS）这些准备的越充足，一方面是有利于跟进执行；更重要的是有利于保证验收环节和测试环节的顺利。
　　为了确保验收的效率和测试的顺利，在整个需求开发流程里面，我们还额外新增了自测用例的评审，开发某个需求自测联调结束之后，开发人员需要跑10%-20%的自测用例，通过率需要达到90%及以上，才能正式转产品验收。
　　当产品验收的体验问题输出之后，需要快速拉起开发、产品、测试一起对齐，落实体验优化，在体验单解决完90%及以上之后，才会正式转测试。
　　6、搭建可视化
　　需求管理的过程需要透明化，可视化。市面上已经有很多好的工具。项目经理需要善于借助工具来搭建搭建可视化，建立需求自动化运转流程。
　　一个好的工具，可以让我们在对需求管理时事半功倍。我们用的TAPD工具非常的强大。
　　因为每个公司的项目管理工具可能不一样，所以这里不做细述。但用工具需要是为了更好地去提升效率。
　　通过工具，让整个项目管理过程更加的可视化，透明化。项目经理要详尽一切办法，让能够可视化的都尽量可视化。这也是项目经理的核心价值之一。
　　至于工具的使用，需求单状态的流转，从宣讲开始，逐步的培养团队养成这样的习惯，这些并不是难事。
　　同时，建立相应的规则，加以约束，避免部分成员不遵守。对于还有部分经常性不遵守的成员，则在项目管理过程中重点关注，以引导和教育为主。
　　7、应对变更
　　世界著名作家、大思想家斯宾塞.约翰逊曾经说过“世界上唯一不变的，是变化本身”。
　　作为项目经理，我们在带项目的过程中，需要有一个认知：市场驱动型的项目，变是永恒。面对变化，项目经理需要拥抱变化，宜疏不宜堵。
　　不否认的是，很多项目经理怕项目过程中出现变更，甚至想方设法制定各种流程，试图来控制变更。
　　从我自身的角度来说，我认为这都是不成熟项目经理做的事情，或者是初级项目经理会做的事情。
　　而一位合格的项目经理，成熟的项目经理，是需要懂得怎么去拥抱变化，有效地引导和控制变更，做好预期管理。
　　怎么来更好地应对变化呢？这里要分几种情况来看：
　　1）项目的范围蔓延和镀金
　　这是项目经理需要重点关注的，范围蔓延和镀金也是项目推进过程中变化的一种情况。当出现范围蔓延或镀金的时候，会慢慢蚕食项目的资源，或者原本产品需求没有的，额外新增了一些功能，使得原本的计划不断地偏移，团队各种加班赶进度，抱怨声音不断。
　　这种情况我认为是需要控制的。项目经理需要高度的敏感，一旦识别项目范围蔓延或出现镀金的情况，要及时地进行管控，确保项目在正常的框架内运行。因为资源是一点点被蚕食，可能会不知不觉中进行，当量积累到一定程度的时候，可能会对原有计划有很大的影响。
　　2）项目执行过程中出现的需求变更
　　一个项目计划已经按照既定的要求制定好了，并在有序的进行执行中。在做着做着的过程中，发现一些需求的细节需要补充，或者在自测用例评审的时候，发现需要增补一些功能点。
　　这种情况在实际执行过程中是非常常见的，项目经理不要急着去阻止这些需求，成熟的做法是和团队一起沟通对齐这些新增需求需要花费的时间，然后评估需求的影响面和必要性（或者敏捷谈到的价值）。有了这些数据之后，再去和管理层沟通，给出相应的方案，最终让管理层和团队一起来决策是否需要走变更流程。
　　如果走变更流程，就重新刷新计划，更新好之后同步全员，按新的计划执行；如果沟通的结论是可以放到后面再安排，则按原计划进行。这里我个人会倾向于开发过程中出现的这类需求细节的调整，尽可能的一次性到位的安排处理。
　　3）项目执行过程中，有插入新的需求情况
　　这在很多项目中是非常常见的，插入的需求可能大多来自于老板，领导。老板们的需求自然是要重视的，但如果放任这种情况持续的发生，需求的管理会逐步失控，而且团队的满意度会直线下降，对项目经理的认可度也会大打折扣。
　　根据我自己的经验，遇到这种情况，偶尔出现一次，管控好预期，应该问题不大。插入的需求或许是业务侧本身的需要，但需求的增加，表明范围的扩大，铁三角中，人和时间都不变的情况下，这个插入的需求必然是会影响已经制定的计划的。这种情况下怎么应对呢？
　　如果时间和人都不变的情况下，对于插入的需求，可以重新把之前的需求拿出来一起沟通对齐优先级，重新排优先级就好，千万别给老板拍胸脯保证，可以内部消化掉，因为很有可能赶时间完成的需求和预期有很大的偏差，而且团队成员也加班加点，不买账。
　　如果是时间可以调整，那新增的需求，在当前的人力资源情况下，整体评估完成时间，更新计划，同步老板和团队，按新的计划进行。
　　如果范围和时间不变，新增的需求可以协调其他人力支持，项目经理也需要更新项目的情况，同步老板和团队。
　　如果项目经理可以做决策的情况下，以上都可以，但为凸显项目经理的更加专业和稳重，可以将各种方案呈现出来，最终由老板去做选择题，拍板决定使用哪个方案。
　　对于偶然的情况，以上的策略都是可行的。但如果作为项目经理，你发现已经出现2-3次这种插入需求的情况，甚至未来还会持续的时候。项目经理需要和管理层“约法三章”了，要从源头梳理并重新建立相应的规则，制定插入需求的处理方式。不要认为老板提的需求，项目经理就无条件地去执行。老板也是怕欠人情的，多次提需求，使得项目推进过程出现变化，甚至延期，那就有必要从管理层入手来解决这个频发插入需求的情况。
　　4）项目目标出现变化
　　项目目标出现变化，必然会导致项目的范围出现变化。
　　项目经理要对目标有清晰的理解和认知，要能够根据日常的沟通，尤其是管理层的沟通中，获取有用的信息，以便判断是否对目标有影响。
　　当然，通常情况下，如果是因为市场的变化，因为政策的变化，使得项目目标要进行调整，这个时候管理层也会主动发起相关的会议，和项目的核心干系人进行沟通对齐。
　　但切记，管理层的信息对齐只是一个信息的传达，作为项目经理，需要果敢的应对这种突发的变化，要清楚的知道该如何开展下一步的工作。
　　事实上，本身也不复杂，当目标出现变化时，就又回到了前面第二、三大要点，重新明确目标，界定范围。
　　因为目标已经变了，再按原来的计划执行下去，做得越多，可能错的也就越多，所以，需要即刻展开范围的梳理和界定，然后重新制定计划。
　　学习ACP的朋友，这个时候也需要灵活地进行变通，理论知识是说一个迭代内是不允许变更的，但实际项目执行的过程，当出现目标变化，需要果断的叫停一些已经做的需求，哪怕是这个需求即将做完。
　　在应对变更时，项目经理需要根据实际情况，发挥自己的专业性，对项目重新梳理，尤其是范围，在重新制定计划之后，还需要特别的和管理层对齐预期。
　　项目的特点是渐进明晰，实际推进项目的过程中，哪怕是风险管理做得再好，也还是会出现一些突发的情况。因此，变更的情况在这里也不能一一枚举。
　　一位成熟的项目经理，就是当项目出现突发情况时，能够在团队面前处变不惊，并且有思路、有逻辑的展开和推进各项工作。所以，变化是永恒的。拥抱变化，管理好预期，是应对变更的重要原则。
　　8、产品能力
　　最后一个要点，产品能力，是说项目经理需要具备一定的产品能力。以互联网项目或游戏项目为例，在负责这一类项目时，可以不懂技术，但我认为是需要具备一定的产品能力，需要真正的懂业务。
　　当项目经理具备一定的产品能力，能够更充分地理解需求，把握产品意图。因此，项目经理要能够或者多培养自己从产品层面思考，让项目的推进能够更加贴合产品的最终形态，这样更有利于对项目的把控。
　　在我的认知里面，项目经理绝不仅仅只是排排计划，管管风险，和管理层沟通沟通。项目管理中，需求管理要真正的做得好，项目经理是需要理解业务的，需要花一定的精力下沉到业务线中，要对产品有自己的理解和认知。
　　具体的产品能力包括但不限于需求的理解和分析能力、产品意识（产品体验和竞品分析）、运营数据分析能力、用户思维等。
　　当项目经理具备一定的产品能力，真正的懂业务，对业务有自己的理解，在实际推进项目的过程中，也会更加有底气。
　　在和团队成员沟通对齐目标时，不用担心自己不懂技术而没有共同沟通的频道，一切以目标为出发，就是最好的手段之一。