软件工程避坑指南（一）——需求调研
做软件项目，为了不被甲方拖入无尽的深渊，在初期需求工作上就要稳扎稳打，躲避陷阱。
先做计划再去调研
调研之前，要了解目标用户的群体类型、组织架构、主要业务职责，确定系统建设需要哪些群体参与，同时在沟通过程中要了解用户的信息化经验。
需求调研，应该要求用户选择一段相对集中的时间。制定需求调研计划时，应当包含计划调研时间、地点、调研单位/部门、主题等，而且计划要留有一定的灵活性，以便用户协调安排。
调研时要重点记录用户的组织架构、工作流程、现有信息化系统使用情况、现有业务痛点、工作关注点，以及用户自己提出的有效需求。
先提方案再做确认
如果用户信息化经验丰富，能够提出一套实施方案，那么可让业主先梳理系统总体需求、主要功能模块，并且与开发单位进行一次或多次沟通，确定主体框架，然后以此为基础，组织后续需求调研工作。
对于几乎没有信息化经验的用户，即便去现场进行调研，可能也得不到多少有价值的信息。对于这种情况，可以先按自己的理解，提前制定一套或多套方案，启发用户思路，从而主动引导用户需求。
现场留证据！
每一次调研都应当进行记录，保留证据，证明需求工作翔实有效。
前往调研时，应派人保留现场照片、录音，并用签到表完整记录在场人员（含单位部门、职务、联系方式等）。
每次调研要立即形成现场记录，记录当次调研工作的主要调研内容，为后续需求分析工作提供有效依据。不要拖到第二天或更长时间以后才整理，否则容易丢三落四。
打破神话
对于缺乏信息化经验的用户，对软件工程会有以下几个常见的误解：
- 软件系统可以解决一切问题！
- 软件开发又不像硬件那样大张旗鼓，根本不需要那么多费用。
- 增加某某某功能，不就是加个按钮的事儿吗？
- 系统原型都做好了，开发应该很快了吧。
- ……
因此，在与用户交流的时候，既要让他们相信开发人员有能力解决问题，又要向用户讲明实际情况，让用户意识到软件虽然看不见、摸不着，其复杂度不亚于硬件或其他类型的工程。
不要随意承诺
在调研期间，不要随意答应用户的需求，哪怕是看起来很容易解决的问题，或者群众意见强烈的问题，也只是先将他们的需求记录下来，回去再对用户提出的需求进行评估，因为其中有可能会涉及到利益问题甚至体制问题，并不能靠软件解决。承诺一件事情，后面却发现做不到，这样会失信于人，而且硬着头皮干，轻则提高无效成本，重则卷入复杂利益关系，解决不了问题还要得罪用户。
基于同样道理，不要随意答应在系统中预留东西，以免因标准模糊导致后续扯皮。
不必完全满足用户需求
如果能当场判断出用户需求不合理，就应当现场积极回应，有理有据地否决用户需求，或要求用户将需求调整至合理范围。例如：
- 性价比低（对用户而言作用不大，但开发成本过高）：否决——软件工程是工程，所以也受“项目铁三角”质量、进度、成本三要素制约。
- 用户管理方式问题：系统顶多是在现有制度框架下稍作优化，根本问题需要用户自行解决——软件系统是管理方式的体现，所以优化系统之前要先优化管理流程。
- 含糊的需求：引导用户将需求具体化，例如提供详细的业务资料，进一步明确用户群体、系统输入、系统输出。如果用户无法提供更详细的信息，则进行否决——软件系统无法实现一个模糊的东西。
- 未确定的需求：要求用户尽快确定需求，如果在指定期限内无法确定，系统只能先不实现，后续根据成本选择补充开发或走需求变更流程——软件系统无法实现一个未确定的东西。
- 将简单问题复杂化的需求：分析用户的实际痛点，引导用户以解决问题为目标，要求用户做出一些妥协，采用更加合适的方案来解决问题——软件系统的根本目的是解决问题，而不是制造新的问题。
对于有一定意义，但仍然存在风险的需求，可以要求用户进一步提供支持，例如二次调研、提供指定资料、提供人员参与需求过程等。同时也要让用户意识到，只有用户充分配合开发人员，软件开发人员才能确定系统需求。
约定好如何变更需求
没有不变的需求，哪怕你“干一票就走”，也不一定能躲掉用户的需求变更。需求变更控制得不好，后面容易卷入到无限的事务之中，难以脱身。
为了将需求变更控制在可接受范围内，必须和用户建立一套明确的、规范的需求变更流程，强化需求变更控制，让用户为需求变更承担成本。只要超过特定时间节点（需求评审通过），需求就处于冻结状态，后续的需求变更无论大小，必须走约定的流程，以此让用户意识到，软件工程与其他工程一样，需求变更也会产生成本，影响交付进度和交付质量，而且提出需求变更的节点越晚，变更代价越大，由此产生的费用绝不可能是捞钱骗钱。
需求变更的管理是一项复杂而细致的工作，后面将进行专题讨论。