凡事预则立，不预则废。笔者见过一些失败案例，复盘的时候很大一部分原因要归咎于需求管理。
笔者认为需求管理包括两层含义：1、项目立项前期收集需求。2、项目实施过程中的需求变更问题。
需求是一个项目的源头，地基没打牢固，后面建房子肯定要返工返修，严重的甚至会倒塌，出现重大责任事故。这也是很多情况下项目组加班加点忙活了几个月，结果没有做出成绩，老板觉得工作量不饱满，成员吃力不讨好，项目经理也失去了威信的原因。
根据笔者的经验，需求收集分为几种情况：1、针对公司自研项目，需求主要由领导及产品经理输出，产品经理整理出来。2、针对非自研（ODM、OEM）项目，需求主要由市场人员及产品经理去发掘，产品经理整理出来。这里特别要指出的是：需求要有应用场景，项目就是要做的刚刚好，不要镀金。笔者前期经历的一个上网卡项目，2G信号不稳定，研发团队经过1周时间终于定位并解决了该问题，结果发现销往日本的上网卡根本不需要2G信号，团队为了一个“非问题”折腾了1周时间。
说到需求管理，不得不说需求变更管理，这个是做项目过程中最头疼的事情，相信每位项目管理人员都会遇到。和几个公司的高层沟通的时候，他们普遍反馈需求变更太频繁了，项目经理及团队成员疲于应对，对项目进度根本没有把控，项目做的最后做出了一大堆没必要的功能，而真正需要的功能还没实现。其实绝大部分的项目都会发生变更，主要是基于当时的认知及项目过程中的外部环境变化所导致。变更不可怕，可怕的是不知道要不要更变，变更了那些内容，变更了多少次。
变更管理好，更能体现项目经理的价值。笔者认为，变更首先需要记录下来，然后找对应责任人讨论变更对项目的影响（包括：项目交期、项目预算等），拿着变更影响找领导沟通，最终和领导达成一个合理的项目交期、预算。需求有变更，要么增加资源，要么增加费用，要么增加时间。只要沟通方式得当，其实很多需求变更后面都会不执行了，也就是对需求人引导式沟通。
好了，今天的需求管理就分享到此。
网友评论