如何应对无休止的需求变更和残缺的文档

144
作者 sakio果
字数 7308 阅读 51评论 0

原创:杜松  产品微言    



任何项目都有一个特色,那就是项目之前群情激昂,至于过程和结果,有的怨声载道,有的劫后余生,万象丛生都很正常,越大的项目故事往往越多。


在前述的文章里面,我从项目的环境,复杂的各方利益,项目的任务分解和任务进度的制定,多个角度分析和阐述了根本原因,这些诱因最终会在项目过程中成为无休止的变更,从而让整个项目陷入不可救药的局面。


所以,需求的变动那是家常便饭,没有变更往往不正常,而变更的管理和文档的确实会进一步加剧这种现状。


     

变更,分为两种类型,其一是完全不可控因素,既是未知的,也是不能改变的。


比如,公司的经营方向发生了改变,导致项目的预算被削减(增加),从而影响项目的进度。特别是在创业型团队,老板临时改变注意,发现某个方向可能更有潜力,调转枪头也未可知。


作为一个项目的负责人(执行者),在项目启动之后,唯一的使命就是促使项目成果,或者结束项目。对未知和不可控的任何局面,都无需过多的投入精力。你能做的,就是管理那些可以被管理的内容。


那些内容是可以被管理的?(如何管理)


可控的需求变更,无非三大类:


  • 没有细化清晰的项目需求

  • 没有明确清楚的项目边界

  • 存在设计缺陷的软件结构


深究起来会发现,在项目已经启动后,真正与客户直接相关的就是第二条,由于没有明确的项目边界,从而导致用户无休止的提出各种需求和变更。


而对需求本身的理解和软件的设计,则考验产品经理和整个团队对业务的理解、把握和产品设计能力。这也是为什么我一再强调“用户故事”的原因,而这种变更则需要团队具备极强的消化能力。


1建立完整的流程变更机制并严格遵守


项目管理,本质就是对过程的管理,也就是要有完备的流程和坚决的执行,通过流程来规避可能的风险。


所以,项目的第一件就是设立一个需求变更机制。(如果你还记得之前谈到的项目启动会,项目经理一定要借助这个会议让项目的所有相关方知悉这个流程。)




这个流程有两个核心观念,也是你一定要能争取到的权力:


1、所有人都可以提出需求变更的请求,但只有一个需求的入口


这个入口必须是你,如果你争取不到这个权力,那整个项目一定会失控。任何都可以提出需求和变更,但你必须作为唯一的接口人和过滤器。


为此,你应该有足够的心里准备,你需要面对N多方的压力和“撕逼”。甚至,为了项目交付的这一终极目标,你需要有不惜得罪人的思想准备。越是大项目,越是牵涉多方的项目,风险和协调都会是指数级的放大。


只有当你具备这个权力的时候,你才能确保项目在预设的轨道上进行,也只有你才可以清晰的回答当前要做什么,能做什么,以及不能做什么。


2、只有评审过的需求才可以被执行


“不要接到需求就直接动手”。这是项目的至理名言。

你需要让整个项目团队,包括上至老板、直到程序员,也包括外部的客户,都认同、理解并遵守一个基本原则,那就是程序员不直接接受任何非PM的需求,不接收任何非经过评审的需求——所有未经过评审的需求,只可讨论,不可执行,减少(避免)张嘴就来的非必要、非紧急、非合理的无效变更。


切记:不是所有的需求都要接受,也不是所有变更都要立刻修改,一定要能敢于拒绝需求。


作为产品经理,在需求变更收集上来之后,根据需求提出方的业务进行分析后,邀请需求方、技术、设计和测试多个环节进行分析,从而判定需求对于项目的影响如何,确定是否接受变更并将变更排列优先级。

但最终一定要你拍板,这是你需要争取到的第二个权力。你不能最终决定一个需求的价值,对你而言,项目已经离失控不远了。


当然,你可以适当根据需求的范围大小,决定评审的范围,甚至可以决定需要告知的对象,这没有标准,需要灵活把握。


这里其实是有一个例外,那就是技术本身驱动的变更,比如有更好的实现方案可以带来性能的提升,这个情况,需要根据整体项目状况,结合技术本身的能力判断。


2建立完善的文档管理机制并落实到位


俗话说“好记性不如烂笔头”。

项目过程中,文档是极为重要的工具,虽然管理文档费时费力。对于产品经理(创业团队还是兼任项目经理)而言,一定要持续的追踪项目的所有需求文档,变更记录。


一定要所有的文档,形成版本机制并同步到到团队的没有给成员,你可以借助一些在线工具来帮助你完成这项功能。


要知道,但凡失控的项目里面一定有一条就是找不到需求的出路,不知道为什么要这么做,也不知道谁要求这么做,反正就是做了,然后谁也讲不清楚由来。


任何需求,都必须记录在案,甭管是否执行,需求的第一个动作就是备忘,第二步才是决定是否执行。一定要专人负责需求的梳理,跟踪和进度的反馈。


完整的需求变更记录文档将有助于你了解整个项目情况,包括执行的需求,被拒绝的需求,你需要一个“需求池”统一管理来自业务端、技术端的需求,并针对项目中出现的资源、时间等因素可以合理的进行调配。


3张弛有度,控制项目的节奏


你确定了规则,梳理好了边界,甚至也形成了流程。


下一步,你得控制好整个产品的推进节奏,合理的控制和调节需求、变更的优先级,以及资源的投放力度,什么事情该投入多少资源,什么时候该做什么事情,什么是关键路径,什么是关键角色,你必须门儿清。


你得想方设法让你的项目,在你所能控制的范围内进行,一旦超过边界,你可能需要启动后备资源予以干预,而且是在苗头开始之际。


你所有的干预手段,预防机制,都是为了确保项目按照一定的规则和秩序推进,也只有基于可控的节奏,你才能确保整个过程的质量,以及最终交付的质量。当过程不可控的时候,往往结果会很糟糕。


最后,一定要深刻的理解,需求是不断的演进和变化的,合理的规避不合理的变更方为上策。


有些时候,无论你怎样控制,由于市场的压力,总会碰到各种“无理”要求,如何看待这样的问题,就不是简单的控制问题了,这就需要更高的层面去权衡利弊,如果确实不值得,也只能放弃。

                                                                                                                                                                                                         

  
  

       产品微言

  杜松的产品笔记

拥抱变化,改变未来

 

                                                                         

经验分享
登录 后发表评论