如何避免分析瘫痪？
分析瘫痪是项目的可怕黑洞。那么，如何认识到你可能处于分析瘫痪状态呢？以下是一些可能提示你的症状。
- 需求发展似乎永远持续下去
- 新版本的系统需求文档不断发布，同时也伴随着流失的感觉。
- 大量实质性变更被引入基准之后，很久才被引入到业务需求文档中。
- 为了“完整性”，所有需求都以多种方式使用许多不同的模型来记录，但是并没有增加任何清晰
- 该小组被指示，需求完成后才可进行编码。
与其发现自己正陷于分析瘫痪中，不如从一开始就避免它，您可以执行以下操作：
- 记住，你的终端产品不是需求文档，而是软件。
- 根据您的项目、时间表、团队文化等选择适当的SDLC。一些项目使用传统的瀑布方法工作得很好，而另一些则不能。
- 你的要求永远不会完美。争取“足够好”，同时确保你避免了需求上的重大差距。当需求被认为是“足够好”和你将如何定义“足够好”时，作为一个团队来决定。问：在确定发展之前，什么是可接受的风险量？确定谁将审查需求，并成为决策过程的一部分，他们是“足够好”。这可能包括业务分析师、客户、内部利益相关者、开发人员和测试人员。
- 不要用“因为”来描述事物。模拟事务是个复杂的事，避免书面语言却过于简单。
- 不要在需求部分的早期就进行UI设计。等到需求接近结束并进入SDLC的“设计”环节再开始。
这是一些能真正避免分析瘫痪的措施，但它也并不是万无一失。来源于Karl Weigers关于软件需求陷阱的一次演讲。