在互联网项目当中，相信每一个项目经理或者制作人，最头疼的就是技术部的管理。因为技术工作看起来是那么的棘手，一般人难以理解，而且技术人员大多数都似乎情商不高。管理人员既不能轻易了解技术工作的内涵，技术人员也觉得很难和管理人员沟通。特别是技术工作，难以在不同人之间交接，很多技术人员都声称无法继续别人做过的项目。这让管理者觉得技术人员特别喜欢耍大牌，而且他们要偷懒也非常容易。但正如军事中的定理，对付坦克最好的武器就是坦克，对付航母最好的武器也是航母，这条理论是通用的。要管理好技术人员，就一定要懂技术。这是任何一种其他号称完美的管理方法都无法替代的。

开发是一切何时写文档

　　对于技术管理来说，很多公司会非常注重文档。虽然开发的结果是代码，但对于管理来说，代码往往难以阅读，也很少有人擅长接手别人的系统。为了让代码不至于被丢弃，公司管理人员就祭起文档这个法宝。我认为文档是很重要的，但也发现这些文档中很典型地存在几个问题：文档和代码不同步;文档的可读性差，需要的文档没写，不需要hr369.com的文档写了一大堆;文档和代码脱节，文档很多，开发出来的成果很少。

　　我们应该何时写什么文档，这是需要有严格定义，并且有检查过程的，而不是任由大家自然发展就可以完善的。代码的编写需要按不同类型，定义好在各个阶段中所需要完成的部分。

　　设计类文档 这类文档往往在项目、模块启动的时候，大家都会想到要去写，作为讨论和最后决议的成果，显然是很自然的。然而在项目进入开发之后，碰到实际问题时，往往就不能完全按照设计的初衷去做了，所以通常设计文档就在这个时候和代码脱离了联系。但有一点是绝对可以做的，就是在重构的时候，按照现有状况，重新增加重构前的系统状况说明，然后再添加上重构后的设计。这样就把重构的设计和文档的更新结合到一起了。

　　API(应用编程接口)文档现代软件都希望能提高重用的程度，因此很多程序员都会自己构造自己的业务API，以便在之后的开发中使用。而这种业务API，也是很多分工合作的基础。这种代码的说明，会直接影响日常的开发，因此非常有必要保证和代码的高度一致性。

　　使用文档 一般来说，一个软件的使用文档必须包含以下几个：《产品版本说明》、《产品安装和部署文档》、《产品使用教程以及例程》、《产品FAQ文档》。这里面的《产品版本说明》应该在每次发版的时候，作为发布流程的一个固有环节来设计。《产品使用教程以及例程》是我认为所有文档中，最值得花大力气去写好的。《产品安装和部署文档》内容越少越好，应该让安装部署尽量智能化、自动化。