十几杆枪如何应对几十个项目-做好需求处理

用户需求就是能帮用户解决实际问题的一套解决方案。

 

在经历过多年的企业项目之后，发现项目中最大的风险来自于用户需求的变更。需求变更产生风险的最大原因在于未做好需求处理，所以在此希望和大家探讨下企业应用的需求处理。

 

先给大家举一个未处理好需求的例子：用户说要做一个实时监控的功能，要监控网络中实时发生的问题，等我们做完之后，用户才发现实时监控发生的问题数据量太大太多，根本看不过来，也不知道什么问题是重点，然后用户要求修改为监控统计数据，然后我们就又重新做了一遍。

 

沉思一下。。。。。。。。

 

需求处理中遇到的问题：

需求不断：用户往往今天说要这明天说要那，你不知道用户的需求何时是个尽头？也不知道应不应该满足客户提出的需求？

需求总变：你埋怨客户总是变更需求，用户说你是专业人士你应该能分析出我想要的，怎么一个需求搞这么久都搞不定呢？

 

所以需求处理人员需要具备：
1：对产品的理解以及对对产品功能的熟悉。
2：对项目的理解以及对项目范围和边界的把握。
3：站在比用户更高的层次思考需求，因此你必须具备用户的业务知识。

4：善于引导用户，我们做项目目的是为给客户带来价值，而不是满足客户的需求。

5：分析用户：用户是技术型，管理型还是饭桶型的，技术性的喜欢抓细节，管理型的喜欢抓整体，饭桶型提不出什么需求，都会说界面不好看。

 

需求处理人员必须得清楚：
1：用户描述需求时表述的那些话不一定是用户需求。
2：用户所说的需求不一定是用户想要的需求，描述和想象始终会存在差距。

3：谁是真正能拍板的用户。

4：需求的满足需要一个过程。

5：用户的需求基本都是拍脑门说出来的，很少是冥思苦想了很久。

6：大多数情况下，需求没有变，而是你没理解用户真正的需求。

 

需求分析的过程
将用户的所提出的需求，放到用户的业务场景中去分析，分析用户是想解决一个什么问题，是否能为用户带来价值。这个需求到时候是否能真正用起来，这需要考虑用户的组织结构，部门角色，用户的推动力。
此需求是否属于项目和产品范围之内，不是则不做。

确认需求之后，思考该需求是否会存在衍生需求，然后思考下能否用我们产品中已有的功能变相的来满足客户的需求。

如果确认需要开发，需要鉴定该需求我们是否能做，做多久，做初步的可行性分析。

 

需求处理

将分析出来的需求，同用户确认，有界面的最好用原型法，假如用户不和你确认（我遇到的大多数情况是这样的），你可以发一封邮件给用户，并说请您确认下需求，假如没有异议，我们后天就按照这个开始做了。他不回你就表示用户默认了。

 

需求归类：该需求是项目需求还是产品需求，是否能产品化？划分到产品的哪一个版本里？

评论

5 楼 fantasy 2010-07-20  

zgsheng 写道

同楼主一起来讨论下需求。
我们先来说一下系统。我们的软件，一般都是冠以“xx管理系统”，“xx支撑系统”导致我最初以为，只有上了软件，才能算做是有了系统。事实上，如果有一家单位，在他的管理上很精细，很制度化，拥有标准的相关文档和流程制度。那我们可以说，他们已经有了一套纸制的系统。当然，纸制系统有先天的缺失，和软件系统基本无可比拟。但是在纸制系统完善的情况下，我们去做开发，恐怕是最容易的了。因为一切需求基本都已定型，只需完善电子化之后的细节及新增功能即可。
个人理解，系统是以明确的制度、流程为基础的。即使在当前业务变化频繁的情况下，如果每次变化都是明确的、标准的，那么这种需求变更对系统伤害不大。
再来说一下我们天朝。我们天朝一向是以“以领导为本”作为管理、甚至生存之根本的。即便是在民企，也往往是领导大于制度。或者说，制度以领导为依托。当领导变更，那么制度一定也会变更。事实上，领导能确定标准的制度，也是凤毛麟角，少之又少。大多数情况下，复杂的组织机构加上层层领导，左分支，右派别，在实施过程中遇到已有标准制度于流程的单位，简直就是不可能的任务。
其实我们最可怕的是什么？如果一个单位自上而下的推行一套系统，又自下而上的热切拥抱这个系统。。呃，我在说无摩擦的完美物理情况，这个是不可能的。如果我们签下的项目在甲方单位不同派别有不同利益，甚至签合同的部门与验收部门，最终应用部门有仇恨。。呃，碰到这种就是项目经理的噩梦。。我们说几种简单合理的情况吧。
一、趁推动系统推动单位制度化、流程标准化。这个我个人碰到最多了， 部级、厅局级甚至处级单位。国企私企，好了，不去管他。这种情况下，甲方领导是和我们站在一边，为我们打气。恩，也只是打气而已。具体项目实施过程，还要靠我们自己去推动。阎王好斗，小鬼难缠。各业务部门的舒适度和安全度都可能受到影响，不作为是好的，引歪路的，拍桌子骂人的，什么样的都有。这时候的忽悠大法，我个人是和客户说，我们可以不做，但是我不做这个事自然还有人做，伸头缩头都是一刀，不如，我们试试？我们尽量在系统里给您方便。如果客户能接受，再往下忽悠系统的好处吧。不接受，只能等他缓缓气再来。
二、政治任务型。一般是集团公司推进、上级部门推进，到这一级从上到下都不认同，不认可。这种，只要销售成功，项目好歹做做吧。大家都是对付，能回款就成。需求，对付一下签字确认吧。
三、主管部门推动型。这种和甲方负责人打好关系。把需求反复的厉害讲清楚。业务进行中的新需求，额外需要，一律推到二期。保证主需求上线。
四、自发需要型。这种，呃，这种是最难的。我们不怕什么都不懂的，喜欢非常懂的。最怕半吊子。这种自发产生的需求，往往客户已经自认为有过横向比较，自认为研究的很深入，对项目介入最深。也最难说服。恩，最容易失败。这个时候项目经理的个人经验取主导性作用。需求的调研、梳理，客户的签字确认，公司领导的配合（出席各种客户认为重要的阶段性会议）。基本不要妄求给客户提供他能认可的方案，每一次需求的调研总结会议，都要步步为营，留出余地让客户推翻和反复。但是需求的主动权一定不能丢，如果已签合同，该强硬就要强硬。
没有系统总结，想到哪写到哪，本人5年政府oa经验。。其他行业不了解。

您对系统的理解非常的透彻，的确在给用户上一套系统的时候，需要非常清楚用户的业务和工作流程，以及上了我们的软件能给用户带来哪些价值？不然很难解释用户说我拿Excel就能做的事情干嘛用你的系统，或者是所上的系统在用户处很难推动其使用的问题。
其实用户都是很懒，他们喜欢安于现状，而不愿意接受变化，一个软件的推行除非是他们迫切需要，或者能正在帮他们解决问题，他们才会使用。有些情况是领导下文来推动使用，但是这样的使用效果不佳。

4 楼 sichanlandag 2010-07-20  

呵呵 确实如此啊

最近弄的外包小私活都是这样的 并不是自己说的算，当然包括如果zf的活，更恐怖～～ 一旦需求变更了，想死的心都有..

3 楼 jiangduxi 2010-07-20  

  人人都说需求是很容易导致项目失败的首要原因。但是真正知道怎么从需求来进行减少项目失败的没多少人。大部分人说客户对需求的变更大，变根大。其实你想想一个好人和一个坏人的区别：如果你想绝对的稳定的需求，几乎只有在教好书上才可能存在。好比在现实生活中要找100%纯的东西一样。

所有如果要想尽量降低由于需求变更带来的风险。
1.需求分析或者获取人员要有必要的高度或者层次进行大致分析出你要做的项目或者产品
2.对实际要上系统的公司的流程和人员素质进行大致了解
3.定位谁是真正支付和判定项目有效的人
4.很好的处理局部个人需求和上系统公司的需求。
5.最好参考要上系统公司的一些规则制定。关键时是你一些功能或者流程的准则
6.心里明白不可能满足客户的所有需求，但是要最大程度满足客户需求
7.定义一套适合的需求变更机制
8.尽量多想一些特殊情况。并且给出相应的应急策略或者方案。
9. 尽量准备A,B,C方案

2 楼 fantasy 2010-07-19  

srdrm 写道

楼主说的在理，认同！
看得出楼主做了很久了，经验丰富，也在北京啊，有机会出来吃个饭讨教讨教啊:D

呵呵 多谢夸奖，但是这些理论和经验，都是说起来容易做起来难。

1 楼 srdrm 2010-07-18  

楼主说的在理，认同！
看得出楼主做了很久了，经验丰富，也在北京啊，有机会出来吃个饭讨教讨教啊:D