工作随手一记 － 做出来的给4000，写出来的给6000

当然，标题中的4000和6000，只是一个示意。



文档，似乎真的是搞技术的一大软肋。

最近在从ant迁移到maven，安排一同事编写两份文档：一个是迁移步骤step by step；另一个是M***EN的入门教程。教程还好说，基本上用PPT顺下来，介绍基本概念和用法即可。而迁移步骤这份文档，我前后安排三个人按照文档进行演练，然后让他根据演练过程中遇到的问题对文档进行修正，以期达到对照文档，各个模块的负责人可以基本完成迁移的目的。修改了四遍，其实主要的内容已经写的很清楚了，可总觉的顺下来缺了点什么，最后我还是忍不住帮助做了最终的完善，其实没加什么东西，主要就是：

1、承上启下的衔接句。

2、对假设条件的显式声明，比如：假如M***EN的安装路径为XXXX。否则，读者很难理解settings.xml在什么位置。

3、增加交叉引用。比如：pom中的ArtifactId，应该填写xxxx，具体参见1.2节的协商结果。

4、对于感觉文字不易描述清楚的地方，增加获取进一步帮助的途径。比如：提交CVS的路径，需要根据模块的groupid和artifactId以及模块之间的继承关系共同确定，如果无法确认自己应提交的路径，请与XX联系。



每次开会问开发人员，你的目标是什么，大家都会回答：先提高技术，然后做设计，做项目经理。总之，没有人自甘落后，至少我还没有听到有人这么说过。如果再追问：怎么取得进步？很多人会回答：要提高分析问题的能力，也有人回答：要把技术做强做透。



然而，在接下来的日常工作中，很多人并没有把在做的事情当作一个实践理想的机会。反正在我所接触的大部分人里，要求他们抛开编程语言分析问题，比如写文档，似乎是一件很为难的事情。我如果说：你把今天咱们讨论的想法细化一下，整理一个文档出来。那么我往往得到的是一个寥寥数言的notes，并没有在我们谈话之外太多的内容，更像是会议纪要。但如果我说：你接下来把这个想法细化一下吧。我往往很快会得到一个demo，这个demo里的确有很多值得探讨的想法。



虽然通过demo来验证一些想法挺好，但如果面对的是一个大系统，不可能方方面面都先demo了再细化。写文档的难度，其实还是反应了分析问题的能力欠缺，然而，越是这方面欠缺，越应该在实践中弥补，而不是回避文档。美好理想与日常工作无法统一，是一个很矛盾的现象。



如果有这样一项规定：会做demo的给4K/月，会写文档的给6K/月，是不是能够扭转这个局面呢？