敏捷开发一千零一问系列之三十四：如何弄清楚项目需求（需求开发步骤）？
这是敏捷开发一千零一问系列的第三十三篇。（在这里提问，之一，之二，之三，问题总目录）
问题
分析与步骤
项目语境
如果只分两种，那么整体上有两种项目：一种是做项目，对方要了东西，一手交钱一手交货；一种是做产品，需求不明，甚至连客户都不明，需要自己挖掘。其他的都是围绕着两种，偏向一方，比如“产品-项目型”，就是定制产品。
第一步：需求范围
首先要意识到一个问题：“弄清需求的最高目的是什么？”需求的内容很多，但对项目型开发而言，“需求 进度 质量 成本”最重要的是成本。也就是说，项目盈利 = 合同 - 成本，如果成本保不住，其他的免谈。
所以，保住项目盈利，也就是合同金额大于成本，是最重要的。
这时候，“需求的范围”比“需求的细节”更重要，也就是说在弄清楚需求范围之前，不能开始项目，或盲目开始项目。但弄清楚需求的细节之前，却可以，或至少风险不大。
所以如果我面对一个这样的项目，第一件事情是勾勒一下需求的轮廓，也就是他让我做什么不做什么。这个不定下来，连合同都不能签订的，别说项目开工了。
具体方法，就是我在博客里边写过的“业务数据+业务操作”的方法，这个是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，就会发现用户要反馈一个问题，只需要几秒钟的时间。我们自己做的产品（就是火星人，是直接托管在网络上的管理系统），则有一个后台的记录文件跟踪客户使用过哪些功能，来了解客户的行为，以进一步进行改进。