“我最近有些想法，想做个电商app，社交电商可以试一下......”
“说到这，这app可不能少了直播功能，引流效果绝对好。”
“那还可以加点小游戏，整个虚拟形象，种几棵树养点花也挺好。”
“还可以......”
别还可以了！别为难项目经理和程序员了，直接买个淘宝吧（不是）。
找外包做app，你需要什么？
钱和需求。并且它们是个“门当户对”的关系，有多少预算就只能做到与之相对应的功能。
即便如此，很多时候项目做着做着，也越来越不像想象中的样子了？
需求！！！
就目前我们做过的项目而言，出问题十有八九都与用户需求相关。
很多时候，最重要的东西反而最容易被忽略。对于任何软件项目而言，需求梳理都是最重要、最基础的，但软件项目中40%-60%的问题反而出在需求上面。
往往用户需求明确、变更少的项目的成功率就高，而那些用户需求混乱、变更频繁的项目几乎从一开始就注定了失败的命运。
说到这，可能还是会有疑问，”需求梳理真有这么重要？不就是让开发人员了解我要开发什么样的东西吗？“
是这样说没错，但我们往往忽略了重要的中间步骤。
需求影响项目过程的各个环节。
-> 产品原型设计（模拟真实产品，可交互）
-> 界面设计（同原型设计，都要反复修改到“这就是你想要的”）
-> 项目计划制定（如时间计划、测试计划等等）
-> 开发、测试、验收
一切的一切都跟客户提供的需求相关。
直接这样说，可能还是不容易理解。我们来看一组数据，Standish Group曾经对世界各地的5万个项目做了调查，范围覆盖各类大小型项目。其中真正成功的项目只占30%左右，并且小型的项目成功率更高。
successful：项目按时按预算完成，功能如最初的需求。
challenged：项目完成，但超预算，且功能比最初的需求少。
failed：项目失败，在开发周期中某个时候该项目被取消，或已交付但未使用 。
而历年数据显示，导致这些项目不成功的因素中，与需求有关的因素（缺乏用户参与、需求不完整、需求变更频繁、不切实际的用户期望，以及提供了不再需要的功能）总共占比在45%以上。
单独看某个项目，如果是在项目早期，修改由需求问题产生的缺陷，代价可能会比较低。一旦到了项目后期，可能就是“牵一发而动全身”。往轻了说，项目延期、预算超额；严重的，有些架构不好的软件，这一改可能就直接崩溃了。这样的结果不管是客户还是企业，都是不愿意看到的。
改bug的样子”，原作者@我的邻居全是猫
一个典型的案例就是，美国联邦调查局虚拟案件文档系统（FBI Virtual Case File，VCF）。历时5年开发，总共耗资1.7亿美元，项目需求数度剧变，四任CIO都没能把项目拉回正轨。最终，项目完全无法使用，彻底挂掉。这么彪悍的履历，可以说是烂尾项目中的战斗机了。
“
其实项目伊始，FBI的目的还是相对实际和明确的。计划在三年的时间内，将原陈旧的FBI案件文档管理系统升级，且第一年的预算仅为1400万美元。
但由于种种原因，该计划被提上了FBI的首要日程。原先的软件“升级”计划，瞬间变成一个交付日期大幅度后延、开发预算超额，并且从零开始“重新开发”的巨大项目。
项目过程暂不过多讨论。那这个项目为什么会失败？我们仅看与需求相关的问题：
项目从一开始就缺乏完整的构思，从而导致架构设计的失败。
频繁的需求变更。并且在项目进度严重滞后的情况下，依然不停地添加新的需求。
SAIC，也就是案例中的软件外包商，一直以来都尝试跟上FBI对系统提出的需求变更，并且跟FBI反复沟通，甚至指明这样会让项目失败。但FBI方面一直秉承着“试试看就知道了”的思想，来指导整个软件的开发，而未对此有足够的重视。事实证明，也正是这些频繁的变动使得项目发展的方向飘忽不定，不断延期，最终走向失败。
这个案例离一般的项目有些遥远，但场景是可以迁移的。这也就是为什么我们一直强调要重视需求梳理了。不重视需求梳理，就算项目不烂尾而仅仅是延期，错失的可不仅是时间，也可能是效率低下带来的收益低下，还可能是市场先机。
所以说，九层之台，起于垒土。梳理出来的需求是一个项目的“垒土”，不管是我们这样的软件外包公司，还是客户，想要做好一个项目，都必须要重视需求梳理过程！
