该帖子同步发自：(riverstone的博客  访问该博客)

　　在IT公司中，管理层和“自命清高”的技术人员之间的沟通和协调永远是一个值得讨论的话题，先后从事过技术和管理工作的资深产品经理韩伟分析了技术人员的管理之道，包括何时以及如何评审、分层开发、尽快运行、追求代码质量等。

　　韩伟首先分析了管理层和技术人员之间的代沟：

　　在互联网项目当中，相信每一个项目经理或者制作人，最头疼的就是技术部的管理。因为技术工作看起来是那么的棘手，一般人难以理解，而且技术人员大多数都似乎情商不高。管理人员既不能轻易了解技术工作的内涵，技术人员也觉得很难和管理人员沟通。特别是技术工作，难以在不同人之间交接，很多技术人员都声称无法继续别人做过的项目……要管理好技术人员，就一定要懂技术。这是任何一种其他号称完美的管理方法都无法替代的。

　　开发文档的问题是一个老问题，韩伟根据文档的不同类型谈了自己的看法：

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

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

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

　　其次，韩伟认为，了解软件架构的范畴，才能有针对性地去把握软件开发中的风险，从而管理好软件开发的过程。根据软件需要应对的需求，软件架构一般包含以下几个部分：

　　逻辑架构：主要是为了明确“功能性需求”而做的设计，针对需求以及需求变化作为架构目标所做出的关于代码之间的划分、耦合、关联的决定。采用合理的逻辑架构，将会大大降低需求变更对开发的延迟作用。逻辑架构最直接指导代码中互相耦合的情况，仔细设计好耦合的规则，会让后续开发事半功倍。

　　运行时架构：运行时架构是为了满足运行期的质量需求，所做出的关于对象行文、进程结构、通信协议、数据结构等方面的决定。运行架构一旦确定，等于大部分的“实现”代码都确定了，设计有足够扩展性和可用性的运行架构，可以为后续工作节省时间，也降低了系统在运行期对开发工作的干扰。