`
fantasy
  • 浏览: 513718 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论

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

阅读更多

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

 

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

 

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

 

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

 

需求处理中遇到的问题:

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

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

 

所以需求处理人员需要具备:
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分析应该由谁处理工单,然后将工单直接发送给相关负责人,并做邮件和短信的通知,这样就将用户从监控的枯燥中解放了出来,引起用户很大的赞扬。
说白了,每个用户都希望一键完成一天的工作,而自动化就是实现这个理想化的过程。

相关推荐

    项目综合案例分析5-质量控制.pptx

    在本案例中,我们分析了两个与项目质量管理密切相关的案例,重点探讨了需求管理和项目实施过程中的质量控制。 首先,案例分析十二关注的是在需求不明确的情况下进行项目开发的质量问题。这种做法对软件质量的影响...

    IT项目运维资料-3.2 项目移交记录(售前-售后).docx

    ### 十、项目移交资料列表 - **说明**:项目从售前阶段向售后阶段过渡时需要移交的各种资料,包括但不限于: - **项目招标文件**:项目的招标文件。 - **技术方案**:项目的整体技术方案。 - **产品清单列表**:...

    几百几十加减几百几十说课稿.docx

    《几百几十加减几百几十》是一节数学课程,主要教授学生如何进行三位数的加减运算。课程基于之前学习的两位数加减两位数,旨在巩固基础并为将来学习多位数的笔算做好准备。课程的教学目标包括让学生掌握几百几十的笔...

    如何做好一个网站(利用开源项目)

    《如何做好一个网站(利用开源项目)》这篇文章,虽然简短,却蕴含了作者十几年开发经验的精华,对于初学者或是想要提升网站开发技能的人来说,无疑是一份宝贵的指南。本文将深入解析文章中的关键知识点,帮助读者更...

    刚做好的十个字的led屏模拟有程序.zip

    标题 "刚做好的十个字的led屏模拟有程序.zip" 提示我们这可能是一个包含LED显示屏模拟程序的压缩文件,而描述进一步确认了这个压缩包里有与LED屏幕相关的程序。LED屏幕通常用于显示文字、图像或动画,在各种场合如...

    测试工程师笔试题 100%有用 需求的赶紧下载

    而大型项目的团队则可能包含数十甚至数百名成员。 - 团队成员的角色包括但不限于项目经理、测试工程师、开发人员等。 ### 7. 软件质量标准 - 软件质量标准是指衡量软件质量的一系列指标或准则。 - 全面的质量标准...

    信息系统项目管理师考试15年真题无答案版【05-19年】.rar

    这份资料的核心内容包括以下几个方面: 1. **项目范围管理**:如何确定项目边界,制定项目范围说明书,控制范围变更,以及如何进行范围确认和范围核实。 2. **项目进度管理**:如何制定项目进度计划,分配资源,...

    项目管理沟通案例分析.pdf

    项目交接时的沟通建议千万不要取消,哪怕只是短短的半个小时或者十几分钟,也要把项目的关键事项讲清楚。与内部资源的沟通是非常重要的,不要因为是公司内部就可以疏忽。在进行客户调研时要充分沟通,尤其是关键干系...

    风光储充一体化综合智慧能源项目项目方案(风光储充)(113页 WORD).doc

    本项目的实施方案主要包括以下几个方面: 1. **风力发电系统**:根据风速、风向等参数选择合适的风力发电机型号。 2. **光伏发电系统**:根据日照强度、面积等因素确定光伏组件的配置。 3. **储能系统**:根据负载...

    几十套简欧(二房三方)施工图.zip

    《几十套简欧(二房三方)施工图.zip》是一个包含多套简欧风格住宅设计方案的压缩文件,主要适用于建筑地产、土木工程领域,同时对高等教育中的建筑学专业学生及进行毕业设计的学子们具有重要的参考价值。...

    C#与halcon的检测项目修改工具设定界面.zip

    这个压缩包文件包含了一个名为"第十四讲做好的"的源码文件,这很可能是项目的一个模块或者示例代码,用于展示具体的实现细节。 首先,C#是一种面向对象的编程语言,广泛应用于开发Windows桌面应用、Web应用以及游戏...

    十几米高模板钢管支撑系统施工方案.pdf

    综上所述,此施工方案详尽阐述了十几米高模板钢管支撑系统的施工步骤、材料选择、质量控制和安全措施,旨在提供一个高效、安全、质量优良的施工流程,以保证崇义县腾飞佳苑1#-12#楼工程的顺利进行。

    武汉市青山区城市综合体(5星级酒店)项目可行性分析.docx

    项目初步规划方案结合了当前市场趋势和需求,旨在打造一个集商业、酒店、办公于一体的综合性项目。方案重点考虑了以下几个方面: - **建筑设计**:采用现代化的设计理念,确保建筑外观与周边环境协调统一。 - **...

    大学生创新创业训练计划项目开题报告.docx

    本项目将专注于以下几个核心方面: 1. 市场调研:对目标行业进行深入的市场分析,了解行业动态、消费者需求和竞争态势。 2. 产品/服务设计:根据市场调研结果,设计具有创新性和实用性的产品或服务。 3. 商业模式...

    5152单片机proteus仿真和源码刚做好的十个字的led屏模拟有程序

    根据提供的文件信息,我们可以深入探讨以下几个关键的知识点:5152单片机的基本概念、Proteus软件的功能与应用、LED显示屏的工作原理及其在单片机系统中的应用,以及如何利用这些工具进行项目开发。 ### 一、5152...

    电子商务个性化营销工具项目可行性分析报告.docx

    项目实施通常分为几个阶段,包括需求分析、系统设计、开发测试、上线部署等。每个阶段都需要明确的目标和时间表,以确保项目按计划推进。 **团队构建:** 成功的项目离不开一支专业且高效的团队。团队成员应具备多...

Global site tag (gtag.js) - Google Analytics