作为技术人员，你愿意花时间和精力编写过程文档么？
提起技术文档或过程文档，一定会有部分甚至是大部分人认为：文档应该是文职人员该干的事情，或是到了某个阶段某个时间段统一“补”的事情。更普遍的一个现象是，对于绝大多数的技术人员，写份2页纸的文档好像比写10W行代码的功能还要困难。🤦 这种情况下你很难分辨他的对文档的认知是不该写还是不愿意写。。。 对于意愿，咱暂且不论，就讨论一下该不该吧。
先举个多年前的案例吧，当前在某企业PMO工作，多个业务部门，其中有一个移动事业部，承接的多是一整个交付项目中的移动端一小部分，功能不复杂，实现也不复杂，技术难度也相对不高，所以该部门的管理者一直以此为由，极度的不重视过程产物和技术文档。但所有IT企业都有的共性问题是人员的流动性。随着部门人员的不断变动，该部门的管理者主动找到PMO梳理规范和标准，理由是：在没有技术文档和过程文档记录的情况下，每次人员变更、项目交接，都需要他把所涉及项目的内容讲述一遍，以至于后来他自己也开始混淆、忘记一些细节。。。他自己受不了了！关键点，是作为技术人员的你，能永远记住自己现在之前的每一个时刻的设计和想法么？
当然，在我的认知中，过程文档和技术文档肯定是需要的，但需要写到什么程度、什么颗粒度、使用什么方法更有利于开发工作的开展呢？我认为这个是可以讨论、可以实践尝试的。
我们回到刚才讲过的案例，为什么人员流动时会促使这个问题的暴露？归根结底是因为无论是过程文档还是技术文档，都是对上下游工作传递的支持和支撑。那就有两种最能体现文档价值的几个场景：一是日常开发工作中，大家根据文档记录的内容进行上下游工作协同；另一种情况就是涉及人员变动时，参考文档中的记录，进行工作交接、快速了解和熟悉涉及的工作内容，尤其是业务细节、技术细节等；再有，就是涉及冲突、谈判，需要追溯过程的时候。而对于团队相对稳定的情况下，沟通方便快捷、也多样，所以文档的作用不凸显，这也是敏捷团队强调弱文档的一个条件（但敏捷也不等于没有文档，以后专题讨论敏捷与文档的问题）。无论文档的作用凸显不凸显，都不能掩盖它是必须的这件事情。
那使用怎样的方法进行文档记录和编辑呢？通常的手段是office或wps办公软件进行编辑，当然也有团队采用线上编辑的方式，甚至有专门研发的工具系统。但工具更重要还是习惯更重要呢？无论是使用怎样的工具，无论你是否愿意完成这项任务，只要有管理要求、且管理要求明确，其实你都需培养自己应对这项任务的一个工作习惯，所以我认为习惯更重要。这个习惯包括什么时机写这些文档（文档和你的技术成果之间更新的时间间隔越小越好，间隔越小越能保证文档和技术成果之间的一致性）、如何写（有统一样式、标准模板最好，以免在整体方向上、整体内容上有大的缺失）、写什么（大原则应该是根据每个文档的核心作用，围绕工作开展需要展开内容的编写，太粗对下游工作的支持力度就会弱，太细可能会造成一些维护的成本增加等问题）。
当然，讨论这些都有一个大前提，就是第一段落我们提到的关于“意愿”。了解心理学的人都知道：当一个人对某件事内心深处呈否认或抵触状态时，任何即便是合理的理由在他这也不可能会被认同。只有当你对它不否认、不抵触时，正常的逻辑思维才能正常工作，帮你做判断。所以，如果你是技术人员，你愿意花时间花精力写过程文档和技术文档么？
End
