【23xiu.com-爱上秀-教育信息门户网】
在互联网项目当中，相信每一个项目经理或者制作人，最头疼的就是技术部的管理。因为技术工作看起来是那么的棘手，一般人难以理解，而且技术人员大多数都似乎情商不高。管理人员既不能轻易了解技术工作的内涵，技术人员也觉得很难和管理人员沟通。特别是技术工作，难以在不同人之间交接，很多技术人员都声称无法继续别人做过的项目。这让管理者觉得技术人员特别喜欢耍大牌，而且他们要偷懒也非常容易。但正如军事中的定理，对付坦克最好的武器就是坦克，对付航母最好的武器也是航母，这条理论是通用的。要管理好技术人员，就一定要懂技术。这是任何一种其他号称完美的管理方法都无法替代的。
开发是一切——何时写文档
对于技术管理来说，很多公司会非常注重文档。虽然开发的结果是代码，但对于管理来说，代码往往难以阅读，也很少有人擅长接手别人的系统。为了让代码不至于被丢弃，公司管理人员就祭起文档这个法宝。我认为文档是很重要的，但也发现这些文档中很典型地存在几个问题：文档和代码不同步;文档的可读性差，需要的文档没写，不需要hr369.com的文档写了一大堆;文档和代码脱节，文档很多，开发出来的成果很少。
我们应该何时写什么文档，这是需要有严格定义，并且有检查过程的，而不是任由大家自然发展就可以完善的。代码的编写需要按不同类型，定义好在各个阶段中所需要完成的部分。
设计类文档—— 这类文档往往在项目、模块启动的时候，大家都会想到要去写，作为讨论和最后决议的成果，显然是很自然的。然而在项目进入开发之后，碰到实际问题时，往往就不能完全按照设计的初衷去做了，所以通常设计文档就在这个时候和代码脱离了联系。但有一点是绝对可以做的，就是在重构的时候，按照现有状况，重新增加重构前的系统状况说明，然后再添加上重构后的设计。这样就把重构的设计和文档的更新结合到一起了。
API(应用编程接口)文档——现代软件都希望能提高重用的程度，因此很多程序员都会自己构造自己的业务API，以便在之后的开发中使用。而这种业务API，也是很多分工合作的基础。这种代码的说明，会直接影响日常的开发，因此非常有必要保证和代码的高度一致性。
使用文档—— 一般来说，一个软件的使用文档必须包含以下几个：《产品版本说明》、《产品安装和部署文档》、《产品使用教程以及例程》、《产品FAQ文档》。这里面的《产品版本说明》应该在每次发版的时候，作为发布流程的一个固有环节来设计。《产品使用教程以及例程》是我认为所有文档中，最值得花大力气去写好的。《产品安装和部署文档》内容越少越好，应该让安装部署尽量智能化、自动化。
了解什么是软件架构
了解软件架构的范畴，才能有针对性地去把握软件开发中的风险，从而管理好软件开发的过程。简单来说，软件架构就是应对需求所产生的“一系列决定”。软件会根据这些决定来开发。根据软件需要应对的需求，软件架构一般包含以下几个部分。
逻辑架构 主要是为了明确“功能性需求”而做的设计，针对需求以及需求变化作为架构目标所做出的关于代码之间的划分、耦合、关联的决定。采用合理的逻辑架构，将会大大降低需求变更对开发的延迟作用。逻辑架构最直接指导代码中互相耦合的情况，仔细设计好耦合的规则，会让后续开发事半功倍。
运行时架构 运行时架构是为了满足运行期的质量需求，所做出的关于对象行文、进程结构、通信协议、数据结构等方面的决定。运行架构一旦确定，等于大部分的“实现”代码都确定了，设计有足够扩展性和可用性的运行架构，可以为后续工作节省时间，也降低了系统在运行期对开发工作的干扰。
开发架构 为了满足开发时的需求所做的决定，主要是软件根据分工开发、测试验证流程等需求划分的软件层次和区域以及各种接口设计，也包含使用的软件包、组件库、开发工具，以及编译构建的方法。一个好的开发架构，可以让沟通成本降低，开发速度提高。
部署架构 现代软件系统，基本上都包括了客户端和服务端程序，如何快速、高效、稳定地部署和发布这些程序，如网络机房的分布、服务器硬件的搭配、监控和维护工具软件的安装、开发测试网络和运营网络的设置。可以获得安全性的配置，良好的部署能力，能推动软件进行更频繁、更全面的测试，从而提高软件质量和开发效率。
数据架构 数据是软件项目的核心财富，关于数据的结构，数据的存放、备份、传输会直接影响到运行性能、业务功能、部署、安全等需求。在面向对象的开发模式下，数据到对象的ORM架构也是很重要的设计。一个完整的数据架构包括了数据流图、数据字典、ORM结构(如果需要的话)、数据索引和备份机制等几个方面。
何时以及如何评审
相信大部分公司都有评审这个环节，评审可以包括方案评审、代码评审、项目专项议题的评审，比如对存留Bug的处理评审等。而这些评审，常常会变成一个挑毛病的会议。要解决评审给产品带来的负面影响，同时发挥这个活动的优点，我们需要关注以下几个方面。
评审由谁发起 相对比较好的是，由负责此项目的“领导”来召集人员评审，并且一定要有负责开发的人员参加评审。参与评审的受邀请人员可能会与方案提交者就一些问题有分歧，但提交者有最终决定权。要把权力给有能力承担它的人。这样做可以让“防止风险”的一部分人和“注重效率”的开发人员形成平等的意见交换。
什么时候做评审 应该在每个迭代、每个较大的版本开工前，或者仅仅是某个认为比较重要的决定做出前，都来一次简短的评审。如果开始时只是做一个DEMO，那么需要评审的东西也比较少，而随着不断的开发，评审也能遍历所有的开发。
做评审的方法 真正对项目有帮助的，是了解项目的需求，分析面临的难点，思考方案为何这样做，提出自己的解决方案，给项目开发者以建议和启发。多说“我建议这样解决这个问题”，而不要仅仅去说“这样做可能有问题，应该添补这样的功能”。以建设性的心态和思路去做评审，而不是以找问题的思路去做，这就是两种做法的最大区别。