从学习需求文档到设计开发

最近参与开发一个新的项目，经理给我们调研好的需求文档，我们参考文档进行开发。

由于刚参加工作，对实际的软件开发过程不熟悉，但公司的管理流程又不是很规范，所以

遭遇了很多的困惑，一时不知如何去做。最后，尝试着慢慢的把这个项目开发完成，这个过程

的痛苦。 而然读到温伯格先生写的《成为技术的领导者》一书，发现里面的第三章解决了我对

如何“从学习需求文档到设计开发”的疑惑，

现摘录如下：

仔细阅读任务规范。成功或失败往往取决于对问题定义的细微差别。
尽管对问题有一个整体、全面的了解非常必要，但这种对全局的正确认识
往往是从一个关键的细节开始的。解决问题型领导者们认识到了这一点，
并且特别关注这类细节。而神游者们则恰恰相反，他们对这类细节感到厌烦，
一旦他们找到似乎有效的解决方法，他们就会迅速转向其他的问题。对于
最糟糕的神游者而言，解决方案的最终用户仅仅是一群令人讨厌的家伙。
鼓励团队成员仔细阅读任务规范。通过阅读任务规范可以获得大量的信息。
仅仅依靠一个人来阅读任务规范是远远不够的。一个成功的解决问题型领导者
知道如何组织一个好环境，让所有的工作人员都全力以赴阅读任务规范。
参与问题的初始定义以消除争论。除非并且只有当所有的团队成员对
问题有了统一的认识时，解决问题的努力才会有意义而不至于导致无谓地浪费。
大部分冗长的争论其实是由于人们对问题理解的差异所引起的，而不是解决方案的
不同。解决问题型领导者要能区分一个争论究竟是基于对问题定义理解的不同还是
基于对解决方法上的差异。
从客户那里澄清任务规范并获得额外的信息。即使是书面的材料也无法对一个
有价值的项目进行充分、全面且绝对正确的描述，但有些人宁可与手头现有的材料
进行长时间的纠缠，也不愿去与别人讨论。其实有时候只要通过一次简单
的交流就可以取得很好的效果。
在工作进行了一段时间，并对某些需求的含义有了更好的认识后，我们
应该再回顾一下任务规范。对于一个复杂的问题，我们不可能一开始就对
它有完全的认识。但我们总是认为自己的理解是正确的，许多灾难性的失败
往往就源于此。所以我们强烈建议要定期对问题的假设条件进行复查。
成功的领导者会在工作中建立对自己理解的问题进行连续检验的机制。虽然
他们很自信，但他们对自己在智力上的局限性也有清醒的认识。