您的位置:首页 > 其它

敏捷开发一千零一问系列之三十四:如何弄清楚项目需求(需求开发步骤)?

2013-06-14 11:29 281 查看

这是敏捷开发一千零一问系列的第三十三篇。(在这里提问之一之二之三问题总目录也是敏捷开发用户故事系列的第十篇(栏目目录)。

问题

需求清晰到什么程度可以进行开发?一定要弄清楚需求才能开发吗?怎样才能弄清楚需求?
注意下面的分析是在基于合同的项目开发的语境中的。产品和互联网需求开发的过程,日后另有讨论。

分析与步骤

以下文字摘录于群聊天记录,未做深入修改,见谅。

项目语境

如果只分两种,那么整体上有两种项目:一种是做项目,对方要了东西,一手交钱一手交货;一种是做产品,需求不明,甚至连客户都不明,需要自己挖掘。其他的都是围绕着两种,偏向一方,比如“产品-项目型”,就是定制产品。

第一步:需求范围

首先要意识到一个问题:“弄清需求的最高目的是什么?”需求的内容很多,但对项目型开发而言,“需求 进度 质量 成本”最重要的是成本。也就是说,项目盈利 = 合同 - 成本,如果成本保不住,其他的免谈。
所以,保住项目盈利,也就是合同金额大于成本,是最重要的。
这时候,“需求的范围”比“需求的细节”更重要,也就是说在弄清楚需求范围之前,不能开始项目,或盲目开始项目。但弄清楚需求的细节之前,却可以,或至少风险不大。
所以如果我面对一个这样的项目,第一件事情是勾勒一下需求的轮廓,也就是他让我做什么不做什么。这个不定下来,连合同都不能签订的,别说项目开工了。
具体方法,就是我在博客里边写过的“业务数据+业务操作”的方法,这个是FPA里边的概念。
如果想了解更多,请参考http://blog.csdn.net/column/details/agile.html?page=2 之六及之后的文章。
如果方法正确得当,大约一天的时间可以确认十个人年的工作不成问题(需要客户头脑清醒)。
有了需求的轮廓,就可以进入下一步了。但下一步是什么?这是个问题。

第二步:优先级排序

需求中肯定有:1. 很多不明确的部分 2. 很多最后做不完的东西 3. 最后被客户改动的东西 4. 很多后来客户又提出来的东西……
因此,尝试弄清楚需求才进行开发,基本上不现实。在曾经的年代,当“客户”仅限于军队,航空,航天,气象,银行(当年的银行业务非常简单明确)……的时候,这一切还是可行的,但现在越来越不现实了。
所以第二步最好是:弄清楚需求最终交付多少,能把钱拿回来(注意我们在讨论项目而非产品)
第二步的最佳方法,是优先级排序。不过要注意方法,因为客户从来不会说自己的某些需求是可以舍弃的,但实际上可以。
有几个问题很重要:
1. 不要问“你觉得什么是可以不要的”(应该问:“你觉得什么是必不可少的”)
2. 不要问“你觉得什么是最后做的”(应该问“你觉得什么是应该先做的”)
……等等,总之实际上不难掌握。
但另外一点比较困难,就是乙方需要有人能站在“高于客户”的位置看待项目需求,从而先客户一步理解优先级。看起来很难,但未必。
因为客户看似很懂业务,但也很局限于自己的业务范围。而乙方则不同。乙方一般面对多个客户,还要理解一些方法论层面的内容,还要去研究多个竞争对手的产品,所以实际上视野要广阔得多。因此超越客户做优先级判断,并非一个真正的难题。
有了优先级,就能做到几件事情:
1. 保证最后即使延期、做不完(接近100%可能会发生),不会太影响交付和收款
2. 知道先做哪些,然后去找客户核对,然后进一步前进。
现在到了需求开发的第三步了,先回顾一下:
第一步:理解需求范围;第二步:优先级排序

第三步:开发需求

公认的好方法是原型法,但有两种原型法,一种适合瀑布,一种适合敏捷(或迭代)
抛弃型原型:在最开始的时候做一个东西,用于和客户沟通以便确认需求,然后按照沟通出来的需求进行开发。
抛弃型原型在需求确认后基本上就不用了,扔掉了。所以,可以选择各种快速工具,乃至于Excel、图形软件之类的来做。
演进型原型:原型不被扔掉,而是作为产品,自身接受客户的直接评审(应该说是“使用和反馈”更好),然后再在这个基础上修改。
实际上,整个敏捷开发中的“可运行软件”,其实就是这个演进型原型。
很难直接比较这两种原型方法哪种好。
抛弃型原型在软件开发的初期经常使用,因为那时候瀑布模型居多,而且军工、航空航天这类项目,需求一旦确定就不需要经常改动了;而且,也缺少一个现实的环境去“渐进地验证需求”,比如阿波罗登月一共才10多次,必须提前把需求和方案想清楚。
而现在的互联网开发则正好相反,演进型原型更适合。首先互联网界极难对未来做预测(看看Nokia、MS就知道了),其次“客户”或“用户”多数都是一盘散沙,收集需求的手段很有限。因此一个在市场中直接接受检验的产品,是更好的方法。
从工作产品中直接接受反馈的方法有很多。如果大家用过AppStore或者AndroidStore,就会发现用户要反馈一个问题,只需要几秒钟的时间。我们自己做的产品(就是火星人,是直接托管在网络上的管理系统),则有一个后台的记录文件跟踪客户使用过哪些功能,来了解客户的行为,以进一步进行改进。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐