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

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

 

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

 

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

 

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

 

需求处理中遇到的问题：

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

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

 

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

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

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

 

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

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

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

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

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

 

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

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

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

 

需求处理

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

 

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

评论

25 楼 fantasy 2010-10-15  

我在想需求是否就是一个问题?
问题是预期和实际存在差异。那么要解决一个问题，要么改变预期，要么改变实际。
那么解决一个需求是否可以看作在解决一个问题，通过改变预期和改变实际两种方式解决呢？
改变实际就是满足客户真正的需求，给客户想要的。
那改变预期如何做呢？满足需求的最终目的是交付客户价值，为客户创造收益。那我们是否能通过改变需求的方式，最终同样交付给客户一样的价值呢？

24 楼 fantasy 2010-10-15  

ltian 写道

femto 写道

ltian说的需求分析，
是那本书?给个链接?

http://book.douban.com/subject/1228179/

就是这本书，不知道现在还有没有了，这本书也需要精读！

ltian推荐的这本书不错。

23 楼 ltian 2010-07-31  

femto 写道

ltian说的需求分析，
是那本书?给个链接?

http://book.douban.com/subject/1228179/

就是这本书，不知道现在还有没有了，这本书也需要精读！

22 楼 xiechao240 2010-07-31  

<div class="quote_title">fantasy 写道</div>
<div class="quote_div">
<p>用户需求就是能帮用户解决实际问题的一套解决方案。</p>
<p> </p>
<p>在经历过多年的企业项目之后，发现项目中最大的风险来自于用户需求的变更。需求变更产生风险的最大原因在于未做好需求处理，所以在此希望和大家探讨下企业应用的需求处理。</p>
<p> </p>
<p>先给大家举一个未处理好需求的例子：用户说要做一个实时监控的功能，要监控网络中实时发生的问题，等我们做完之后，用户才发现实时监控发生的问题数据量太大太多，根本看不过来，也不知道什么问题是重点，然后用户要求修改为监控统计数据，然后我们就又重新做了一遍。</p>
<p> </p>
<p>沉思一下。。。。。。。。</p>
<p> </p>
<p><strong>需求处理中遇到的问题：</strong></p>
<p>需求不断：用户往往今天说要这明天说要那，你不知道用户的需求何时是个尽头？也不知道应不应该满足客户提出的需求？</p>
<p>需求总变：你埋怨客户总是变更需求，用户说你是专业人士你应该能分析出我想要的，怎么一个需求搞这么久都搞不定呢？</p>
<p> </p>
<p><strong>所以需求处理人员需要具备：</strong><br>1：对产品的理解以及对对产品功能的熟悉。<br>2：对项目的理解以及对项目范围和边界的把握。<br>3：站在比用户更高的层次思考需求，因此你必须具备用户的业务知识。</p>
<p>4：善于引导用户，我们做项目目的是为给客户带来价值，而不是满足客户的需求。</p>
<p>5：分析用户：用户是技术型，管理型还是饭桶型的，技术性的喜欢抓细节，管理型的喜欢抓整体，饭桶型提不出什么需求，都会说界面不好看。</p>
<p> </p>
<p><strong>需求处理人员必须得清楚：<br></strong>1：用户描述需求时表述的那些话不一定是用户需求。<br>2：用户所说的需求不一定是用户想要的需求，描述和想象始终会存在差距。</p>
<p>3：谁是真正能拍板的用户。</p>
<p>4：需求的满足需要一个过程。</p>
<p>5：用户的需求基本都是拍脑门说出来的，很少是冥思苦想了很久。</p>
<p>6：大多数情况下，需求没有变，而是你没理解用户真正的需求。</p>
<p> </p>
<p><strong>需求分析的过程</strong><br>将用户的所提出的需求，放到用户的业务场景中去分析，分析用户是想解决一个什么问题，是否能为用户带来价值。这个需求到时候是否能真正用起来，这需要考虑用户的组织结构，部门角色，用户的推动力。<br>此需求是否属于项目和产品范围之内，不是则不做。</p>
<p>确认需求之后，思考该需求是否会存在衍生需求，然后思考下是否能否那我们产品中已有的功能变相的来满足客户的需求。</p>
<p>如果确认需要开发，需要鉴定该需求我们是否能做，做多久，做初步的可行性分析。</p>
<p><strong></strong></p>
<p><strong>需求处理</strong></p>
<p>将分析出来的需求，同用户确认，有界面的最好用原型法，假如用户不和你确认（我遇到的大多数情况是这样的），你可以发一封邮件给用户，并说请您确认下需求，假如没有异议，我们后天就按照这个开始做了。不回你就表示用户默认了。</p>
<p> </p>
<p><strong>需求归类：</strong>该需求是项目需求还是产品需求，是否能产品化？划分到产品的哪一个版本里？</p>
</div>
<p> </p>

21 楼 femto 2010-07-29  

ltian说的需求分析，
是那本书?给个链接?

20 楼 fantasy 2010-07-29  

<div class="quote_title">funcreal 写道</div>
<div class="quote_div">首先不要把需求变更看作是怨念，而是从一开始就坚定的认为需求变更是很自然的事情。 <br>然后，我们可以通过很多的方法使我们的软件变得不害怕需求变更，而是欢迎需求变更。 <br>当然这也不是三五年的功底能做好的。</div>
<p><br>恩，这也是敏捷所提倡的，拥抱变化。正如土贼说的“我们在乎的是不返工，而不是快速返工”，原文见：<a href="http://yizhituzei.blogbus.com/logs/69612929.html">敏捷关注反应多于速度</a></p>
<p> </p>

19 楼 funcreal 2010-07-27  

首先不要把需求变更看作是怨念，而是从一开始就坚定的认为需求变更是很自然的事情。
然后，我们可以通过很多的方法使我们的软件变得不害怕需求变更，而是欢迎需求变更。
当然这也不是三五年的功底能做好的。

18 楼 ltian 2010-07-23  

fantasy 写道

ltian 写道

     另外，从“需求是项目需求还是产品需求，是否能产品化？划分到产品的哪一个版本里？
然后将分析出来的需求，同用户确认，有界面的最好用原型法，假如用户不和你确认（我遇到的大多数情况是这样的），你可以发一封邮件给用户，并说请您确认下需求，假如没有异议，我们后天就按照这个开始做了。不回你就表示用户默认了。”

     用户只会提功能需求，用户不知道是否可以产品化，也不关心版本的问题。用户不会和你确认这些组件需求。组件需求一般都是项目内部评审的。用户最多和你确认功能需求，而功能需求，一般都是通过“用例”来描述的。

    10年前有一本很薄的书叫做《需求分析》，和《设计模式》是一套的，都是经典之作。里面讲需求分析讲的非常之 透。就中国的状况而言。原型法是最好的需求方法。可有效减少开发的差不多的了再推倒重来的可能。
    还有一般好书叫做《透过用例看需求》也讲的很好。

   不知道为什么，中国软件业已经有了20多年了吧，我感觉我们的理论和实践水平还在原地踏步！

多谢提醒，需求划分后再找用户讨论是我排版的问题，已经修改了。

需求和实践处于原地踏步的问题，其实我觉得咱们没有处于原地踏步的阶段，只是发展比较缓慢，主要原因是经验和能力都掌握在少数人手上，而且愿意出来讨论和改进的人就更少了，个人的积累很多，但公司的积累就很少，这样由于项目经理能力层次不齐，很多项目连项目的需求都处理不好。
另外国内比较牛的公司在这方面都做的还是不错的，有持续改进的趋势。

也许是因为我们中国人不像外国人那么傻，出力不讨好的事情估计没人干！精明的中国人，这点小算盘还是打的很精的。

17 楼 fantasy 2010-07-23  

ltian 写道

     另外，从“需求是项目需求还是产品需求，是否能产品化？划分到产品的哪一个版本里？
然后将分析出来的需求，同用户确认，有界面的最好用原型法，假如用户不和你确认（我遇到的大多数情况是这样的），你可以发一封邮件给用户，并说请您确认下需求，假如没有异议，我们后天就按照这个开始做了。不回你就表示用户默认了。”

     用户只会提功能需求，用户不知道是否可以产品化，也不关心版本的问题。用户不会和你确认这些组件需求。组件需求一般都是项目内部评审的。用户最多和你确认功能需求，而功能需求，一般都是通过“用例”来描述的。

    10年前有一本很薄的书叫做《需求分析》，和《设计模式》是一套的，都是经典之作。里面讲需求分析讲的非常之 透。就中国的状况而言。原型法是最好的需求方法。可有效减少开发的差不多的了再推倒重来的可能。
    还有一般好书叫做《透过用例看需求》也讲的很好。

   不知道为什么，中国软件业已经有了20多年了吧，我感觉我们的理论和实践水平还在原地踏步！

多谢提醒，需求划分后再找用户讨论是我排版的问题，已经修改了。

需求和实践处于原地踏步的问题，其实我觉得咱们没有处于原地踏步的阶段，只是发展比较缓慢，主要原因是经验和能力都掌握在少数人手上，而且愿意出来讨论和改进的人就更少了，个人的积累很多，但公司的积累就很少，这样由于项目经理能力层次不齐，很多项目连项目的需求都处理不好。
另外国内比较牛的公司在这方面都做的还是不错的，有持续改进的趋势。

16 楼 ltian 2010-07-23  

     另外，从“需求是项目需求还是产品需求，是否能产品化？划分到产品的哪一个版本里？
然后将分析出来的需求，同用户确认，有界面的最好用原型法，假如用户不和你确认（我遇到的大多数情况是这样的），你可以发一封邮件给用户，并说请您确认下需求，假如没有异议，我们后天就按照这个开始做了。不回你就表示用户默认了。”

     用户只会提功能需求，用户不知道是否可以产品化，也不关心版本的问题。用户不会和你确认这些组件需求。组件需求一般都是项目内部评审的。用户最多和你确认功能需求，而功能需求，一般都是通过“用例”来描述的。

    10年前有一本很薄的书叫做《需求分析》，和《设计模式》是一套的，都是经典之作。里面讲需求分析讲的非常之 透。就中国的状况而言。原型法是最好的需求方法。可有效减少开发的差不多的了再推倒重来的可能。
    还有一般好书叫做《透过用例看需求》也讲的很好。

   不知道为什么，中国软件业已经有了20多年了吧，我感觉我们的理论和实践水平还在原地踏步！

15 楼 ltian 2010-07-23  

十几杆枪，几十个项目。我看要发挥，一不怕死，二不怕苦，下定决心，排除万难，争取胜利的大无畏革命精神才行啊！不知道团队的领导如何在这个比较现实的社会激励员工去这么干。还有的问题是：干几个月可以，常年干可以吗？要知道：飘风不终期，骤雨不终日。估计项目干完，得有人跳楼！

十几杆枪，几十个项目。唯有扩大队伍，规范管理才能解决。从能够几十个项目来看，说明公司前期做的不错，开端很好，如果这时候贪图小便宜，不舍得成本招人，干砸产品，丢了市场就是战略性失误了。

总之，看待这个问题，从战术上看和战略上看会得出截然不同的结论！

不妥之处，请楼主指正！

14 楼 Openhearted 2010-07-23  

学习了，楼主分析得不错。。。

13 楼 fantasy 2010-07-23  

王者之剑 写道

我认为需求分析要站在用户的立场上
系统设计要站在团队的立场上

作为Leader，要对手下人的水平以及公司的待遇能招到的人的水平有充分的认识。
我认为任何事情的成功和失败在一开始基本就决定了。
一个需求，交给能力不够的人去做，只会越做越乱。

系统设计一个很重要的地方就是要把业务分成一些比较合适的模块，我不关心那些设计名词，我认为你如果是一个系统设计者，你领导的人水平比你差，他们只能思考一个模块。
这才是要细分的根本原因。

如果一个新需求的变更跨越几个模块，别说这样的事情不会出现，你还不亲自出马，难道不会死得很难看。

您总结的这句话我很喜欢，“需求分析要站在用户的立场上，系统设计要站在团队的立场上”
能做到因地制宜，合理分配，将团队中的流程和角色有效的协调起来，让专业人做专业事，势必事倍功半。
由此延伸到，团队里招人一定要有目的性，一定是流程上的某个角色缺人进行招聘，不能因为感觉上人手不够，项目多和需要发展团队这样的目的而招人。
人月告诉我们招更多的人，会做更多的事，是一个神话。
那么假如团队已经是现成的了，那就根据团队的成员来设计战略和角色。

12 楼 zwhc 2010-07-22  

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

呵呵，千错万错，总是你的错。

11 楼 王者之剑 2010-07-22  

我认为需求分析要站在用户的立场上
系统设计要站在团队的立场上

作为Leader，要对手下人的水平以及公司的待遇能招到的人的水平有充分的认识。
我认为任何事情的成功和失败在一开始基本就决定了。
一个需求，交给能力不够的人去做，只会越做越乱。

系统设计一个很重要的地方就是要把业务分成一些比较合适的模块，我不关心那些设计名词，我认为你如果是一个系统设计者，你领导的人水平比你差，他们只能思考一个模块。
这才是要细分的根本原因。

如果一个新需求的变更跨越几个模块，别说这样的事情不会出现，你还不亲自出马，难道不会死得很难看。

10 楼 王者之剑 2010-07-22  

我好像没有碰到过这样的问题，我的方法就是尽快搞定。

时时刻刻告诫自己：我是专业人士没有我搞不定的问题。
1.用户的真实需求（理解业务，深度挖掘用户需求）
2.新需求对现有功能的影响（系统分析，不断优化系统设计）
3.该需求给用户带来的好处（利益分析，决定需求实施优先级）
4.编码实施（不忘重构）

我没有办法的是怎样让用户多掏钱和怎样让老板给自己更多钱。

我觉得软件设计开发者有这样一个信念很多问题就迎刃而解了。这就是：
凡是软件能做的事不要让人（用户）去做。

象我刚出来工作时接触的一个项目，该项目导入分析1G的数据要2小时。
并且报表有些不对。用户为这个项目已经花了4万。(不是我公司做的）

我一看用户使用的是IBM服务器，有4G内存，不就是些业务分析，做报表吗。
仔细的阅读了用户提供的相关资料，认真分析设计以后，搞定的结果是15分钟。
而且就是差了一分钱也能查出来。

为用户一个月都可以找回几十万（用户一个月的收入都是几千万的），以前这些钱都作为正常损耗不存在了。因为没算清楚嘛，别人少给了钱，你有什么依据？

当时需求分析完成以后，我就对老板说，这个东西我虽然一个月就可以搞定，最少得要10万。
结果老板只要了七万。其实就算客户肯花二十万，他未必找到合适的人搞得清楚。

因为后来我走了，客户升级，公司仍然让一个人（可能更多）去搞，搞了一年仍然BUG不断。
以为这个东西简单嘛。

9 楼 lobbychmd 2010-07-22  

shybo 写道

学习了，小弟是一码工，正在开发的项目已经接近尾声了，MD需求变了，用户推翻自己提出的需求，要求改，真是一场噩梦，先前的工作基本白做了

实现新的需求，不要丢掉旧的，加若干参数控制，并给参数配上注释文档。坚持若干年，你的软件就是同行业软件的翘楚了

8 楼 shybo 2010-07-22  

学习了，小弟是一码工，正在开发的项目已经接近尾声了，MD需求变了，用户推翻自己提出的需求，要求改，真是一场噩梦，先前的工作基本白做了

7 楼 一蓑烟雨任平生 2010-07-21  

就楼上的例子，你先要做的是了解业务客户的业务目标设定，比如这个功能的业务，是一个服务业务，业务的职能是问题分级处理的过程管理，业务的要求是不是说一键完成一天的工作？应该没有这么简单吧。比较标准的做法：把业务流程做一次梳理，让业务提出改善目标，将问题处理的时间由原来的多少缩短到多少，各级任务的处理及时率提高到多少。业务如果靠手工已经做不到，需要IT支持，那么看IT要在哪些地方做功能。
这些是每个系统上之前首先考虑的内容，大家目标一致后，边界就会很明确，需求到后来发生偏离的现象就可以有效控制。

6 楼 fantasy 2010-07-21  

系统能帮用户提高工作效率。用户希望自己做的事情少而业绩高。这也是我们系统存在的价值。
举一个例子。用户以前需要每天看着我们的系统上做安全监控，发现问题后打电话和发邮件通知相关的负责人处理这些事情，而我们的系统做了一个自动化的改进，根据问题的级别和发生次数判断是否发送工单，通过IP分析应该由谁处理工单，然后将工单直接发送给相关负责人，并做邮件和短信的通知，这样就将用户从监控的枯燥中解放了出来，引起用户很大的赞扬。
说白了，每个用户都希望一键完成一天的工作，而自动化就是实现这个理想化的过程。