敏捷宣言里有一句“工作的软件胜过详尽的文档”，似乎工作中文档也是冗余的，以下有两个常见场景：
1、完成一篇概要设计，但是开发过程中，这篇设计不足以指导编程工作，还不如直接去问PO来的直接，彼此之间沟通还顺畅。最后这篇概要设计成为摆设，没人看。
2、完成一篇详细设计，但是开发过程中，发现有很多细节没考虑到，有些部分需要大改，最后实现的内容与详细设计有很大的出入，别人看了文档反而容易误解，大家惊呼这篇文档是毒药
上述两个场景是工作中非常常见的场景，包括我接触到的敏捷教练也会问我“有人会看这篇文档吗？有人会维护这篇文档吗？”。因此，大部分人都会觉得“看起来工作中沟通更重要，文档似乎没啥用”
我对此的看法是“因地制宜”。
1、前面也说过了，我所做的是行业软件，这类别软件的需求是很明确的，因此一般不会改变太频繁（我现在也在接触互联网软件，这里面的需求变化实在太快了）。
2、行业软件的质量要求非常高，经常要求精确管理。
3、对于新的系统，我不是一个合格的PO，对于需求的把握，无法让人信服。同时也无法让团员信任我
第3点如果做不到，团队是不可能高效的，因此我需要一篇详尽的文档向我的客户证明（领导团队、研发团队、测试团队、维护团队、市场团队）。
我最后完成了一篇我认为还不错的详细设计文档，分享一下这篇文档的漂流历险记：
1、花费了一个月的时间，我与设计、测试、维护、市场等多方频繁沟通，同时专研现有的代码，最终完成了详细设计文档初稿。（在项目启动前一个月开始详细设计，此时无需人员到位）
2、依据这篇文档，我和领导团队反复沟通，确定了人力安排、进度管理、风险评估等多项项目前期工作，最后证明依据这篇文档得出的评估非常符合实际情况，我的客户（领导团队）对于沟通的效果非常满意
3、这篇文档得到维护和市场的肯定，因为他们知道需求落地了
4、在研发过程中，我鼓励研发团队成员与我沟通，如果是设计上的疑问，我则会拿出详细设计文档与之沟通（有参照物，沟通效率会得到极大提升，同时沟通的效果可以确定落实到该文档上）。同时我会鼓励团员思考“你觉得应该怎么做？”，如果团员的想法合理，我则鼓励其修改文档，美其名曰“咱们不能一辈子当码农，得学会设计~”。事实上这样的沟通效果非常好，我从中发现了两名有影响力的团员，另外有两名团员的成长也非常快，这四个人的工作效率很高，超出平均一倍以上。对于这四个人来说，他们形成了依据文档思考并落实到文档中的习惯，同时变更是得到PO的肯定的，他们无需关注其余沟通事宜（其余事情PO搞定），因此工作惯性不会被打断。最后这篇文档被反复修改（影响并不大），但是它在不断加强团队的沟通效果。我的做法目的是让文档的作用发挥的淋漓尽致，要让它成为沟通的催化剂，而不是摆设。
5、对于测试团队来说，一般是不关注研发写的代码的。其设计用例的基础是设计文档以及过往的测试用例，对于重构来说，最好是使用已有的测试例直接覆盖即可。但是对此我并不满足（因为加入的三名测试同事也是新员工，哎），我鼓励这三名测试同事根据以往的用例以及设计文档来编写新的用例（每周根据新增用例数以及发现的问题数，全员通报表扬）。其实我的目的是鼓励测试同事与我沟通，一方面从测试角度发现设计文档的缺陷，另一方面则对测试的进度更加可控。最后这三名测试同事的工作效果也非常显著，我愣是为测试部门培养了三名干将（稍稍自夸一下^_^）
上述的分享，其实想表达我的看法“文档的作用也是因地制宜，因人而异的”，上述的分享或许并不适合互联网软件（文档不得改死），但是对于行业软件来说，其是一个逐步积累的过程（不可能每次都推到重来），文档起到传承的作用，其效果不容忽视。