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

开发是一切——何时写文档

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

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

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

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

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

了解什么是软件架构

了解软件架构的范畴，才能有针对性地去把握软件开发中的风险，从而管理好软件开发的过程。简单来说，软件架构就是应对需求所产生的“一系列决定”。软件会根据这些决定来开发。根据软件需要应对的需求，软件架构一般包含以下几个部分。

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

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

开发架构 为了满足开发时的需求所做的决定，主要是软件根据分工开发、测试验证流程等需求划分的软件层次和区域以及各种接口设计，也包含使用的软件包、组件库、开发工具，以及编译构建的方法。一个好的开发架构，可以让沟通成本降低，开发速度提高。

部署架构 现代软件系统，基本上都包括了客户端和服务端程序，如何快速、高效、稳定地部署和发布这些程序，如网络机房的分布、服务器硬件的搭配、监控和维护工具软件的安装、开发测试网络和运营网络的设置。可以获得安全性的配置，良好的部署能力，能推动软件进行更频繁、更全面的测试，从而提高软件质量和开发效率。

数据架构 数据是软件项目的核心财富，关于数据的结构，数据的存放、备份、传输会直接影响到运行性能、业务功能、部署、安全等需求。在面向对象的开发模式下，数据到对象的ORM架构也是很重要的设计。一个完整的数据架构包括了数据流图、数据字典、ORM结构（如果需要的话）、数据索引和备份机制等几个方面。

何时以及如何评审

相信大部分公司都有评审这个环节，评审可以包括方案评审、代码评审、项目专项议题的评审，比如对存留Bug的处理评审等。而这些评审，常常会变成一个挑毛病的会议。要解决评审给产品带来的负面影响，同时发挥这个活动的优点，我们需要关注以下几个方面。

评审由谁发起 相对比较好的是，由负责此项目的“领导”来召集人员评审，并且一定要有负责开发的人员参加评审。参与评审的受邀请人员可能会与方案提交者就一些问题有分歧，但提交者有最终决定权。要把权力给有能力承担它的人。这样做可以让“防止风险”的一部分人和“注重效率”的开发人员形成平等的意见交换。

什么时候做评审 应该在每个迭代、每个较大的版本开工前，或者仅仅是某个认为比较重要的决定做出前，都来一次简短的评审。如果开始时只是做一个DEMO，那么需要评审的东西也比较少，而随着不断的开发，评审也能遍历所有的开发。

做评审的方法 真正对项目有帮助的，是了解项目的需求，分析面临的难点，思考方案为何这样做，提出自己的解决方案，给项目开发者以建议和启发。多说“我建议这样解决这个问题”，而不要仅仅去说“这样做可能有问题，应该添补这样的功能”。以建设性的心态和思路去做评审，而不是以找问题的思路去做，这就是两种做法的最大区别。

分层开发，尽快运行

为了降低软件耦合给开发带来的负面影响，正确的做法是要高度重视软件开发方法，从代码风格、软件架构、设计模式、开发模式方面来提高水平。其中一个最简单有效的做法，就是分层。在经典的架构模式中，分层模式几乎是所有模式的基本模式：把代码按照你所需的范围划分层次，然后规定层次之间的耦合接口，层次之间只可单向依赖，而且尽量减少跨层耦合。划分层次的范围，由你的开发团队水平和项目的复杂程度决定。

非功能需求决定成败

世界上类似的项目非常多，但成功的占少数，失败的占多数，这种现象的背后有一个重要的原因，就是非功能需求。非功能需求具体包括：软件开发效率的相关需求，比如代码结构、代码风格、内容开发工具、自动构建部署工具；软件的质量稳定性的需求，如测试方面的需求，产品结构对于缺陷的防范，代码质量；软件的运行承载力需求，包括可用性、容灾性、可维护性、承载力、运行性能和成本需求；软件的信息搜集方面的需求，如故障上报、数据统计和挖掘。

如何才能做好这些非功能需求呢？

首先是在项目成本规划时，分配足够多的资源，比如人力和时间，去做好这个事情；其次是要尽量合理地规划和设计这些非功能需求，既不能贪多求全，也不能无所作为。

追求代码质量

代码质量不高带来的危害包括人员流动后没法接手、Bug频繁出现、效率问题难以定位、开发速度慢等。

什么样的代码才叫高质量的代码？代码质量存在一个唯一标准，就是可阅读性。可读性好的代码，结构通常更简单清晰，Bug也少；更多人愿意去阅读的代码，也会有更多的机会去改正Bug以及其他的缺陷。可读性好，也意味着你能更简单地去找到改进性能的方法，减少修改代码带来的风险。

提高代码质量的手段，最简单的两条，一是执行代码规范，二是进行代码评审。除了规范制定和评审外，组织学习代码质量的知识，提倡并奖励高质量代码的人员，也是提高代码质量的有效手段。

搭好测试这个安全网

单元测试是最原始的工程概念之一。单元测试对于互联网应用来说，一般会有一个困难，就是需要大量的“脚手架”，比如为了测试数据库操作，必须要有一段代码“重置”数据库的状态；为了测试网络打包解包，则需要用一个程序向某个网络端口发数据。而准备这些测试工具代码的时间往往会比较长，需要有足够的耐心去做，但一旦做好了，往往能让开发风险大大降低。

对于单元测试，我认为最少应该覆盖所有正确的路径，以及重点防御的错误路径。覆盖了这些重点关注的地方之后，放手重构代码就很方便了。

单元测试应该是属于代码的一部分，和源代码一起存放。自动构建时也应该进行检查输出结果。提交代码时都会自动运行单元测试，当“版本树”需要合并“分支”时，单元测试尤为重要，而最重要的是在分支上建立的单元测试。这些测试会大大加强系统的稳定性，因为检验了“合并”功能产生的代码—这些代码是最容易出错的。

自己掌控开发方向

开发工作往往被需求变化“牵着鼻子走”，需求往往会有很多来源：产品策划的想法、老板的意见、用户的反馈、数据统计的结论等。提出的各种需求，往往会对开发团队造成很大压力。这些问题都需要我们对需求做出有效的管理。然而我们应该如何去搜集、记录、过滤、实现这些需求呢？

我们需要很好地搜集记录需求。有的团队会设立两面故事墙，任何方面的需求，都可以减缩成一个故事，写到一张便签纸上，贴到故事墙上，专人处理，而不会石沉大海。

有的公司会试图把这个事情用电子化流程来做，但电子化流程有个显著的缺点，就是为了更多地自动化处理，会加入大量的字段，对于故事这种还未谨慎定义过的东西，要认真填写太多的资料，无疑会给使用者造成额外的负担。

告别救火队员

在产品进入运营期间，最牛的程序员似乎总是在充当救火员，各种各样的突发事件、棘手问题中，我们的“高手”往往疲于奔命，永远都在做一些补救的措施。有经验的人员一直没空做开发，因此大量的代码由那些水平较差的人来完成，反过来埋下了更多的问题。然而，如果不是忙着亡羊补牢，我们的资深程序员就可以把更多的精力放在开发上，这些有经验的程序员所生产的代码，又会进一步降低出故障的概率，这才是走向良性循环的方法。

为了减少运营期间的压力，在系统设计时，就要特别注意关于可维护性的非功能需求。运营事故当中，因为部署错误所导致的占很大一部分，因此降低部署错误需要做到：全代码包发布，每个发布版本要包含所有的可执行文件；所有的服务器上部署的配置文件和数据文件都必须做到完全一致，降低更新文件的复杂度。本机IP地址应该用代码从网卡上直接读取，但应该提供可以配置的选择，预备多个IP的服务器使用；只使用命令行方式来启动不同功能，如选择配置文件路径、输入不同功能进程或服务器的配置；程序支持关闭、重载配置这两个信号。在处理这两个信号时，都不应该让使用者感觉突然“掉线”；开发用于安全关闭程序、重载配置的脚本或功能；开发用户自动重启所部署进程的脚本，以及配置开机自动启动所部署的进程；每个进程都不应该强行锁定某资源，必须要能做到一份安装复制多进程并行运行等。

每天发版

如果你想知道项目每一天的开发进度，你就必须要做到每天发版，测试每天的工作进度，如果要顺利地每天发版，就必须建立一个持续集成的系统。一般来说持续集成系统会有以下的先后步骤：单元测试—自动构建—自动部署—集成测试—自动发布。

单元测试关键是要能坚持覆盖所有新加入的代码；自动构建是由构建脚本、构建服务器、持续集成系统几部分组成。

对于美术、产品或者别的非技术人员，添加的数据往往也需要有自动部署的工具，而且因为通常他们产生的文件比较大，每次的全体打包然后覆盖，可能会非常没效率。虽然事情要做得完美不是很容易，但绝对是物有所值。

版本列车

我们时常只是对技术工作有版本管理的过程，而对于其他环节，常常停留在最原始的状态。我们需要在整个项目开发的每个环节，都进行合理的项目管理。在多个项目的经验积累之后，提出了全过程的项目管理的概念：版本列车。

版本列车的含义是按照项目的工作流程，为每个有产出的环节都定义一个版本“车厢”，然后按照工作流程的先后依赖顺序，形成一个完整的“版本列车”。第一个工作环节负责版本号，然后在这个版本号之下填充版本内容。当工作完成，此版本的工作内容则带着版本号进入下一个“车厢”，依此类推。

这样做的好处是，每个环节的每份产出都可以明确地知道其进度位置，安排在什么时候做。对于需要提前准备市场推广或者别的工作部门，有一个非常明确的长期计划。对于进度管理来说，各个部门也能知道整个项目的当前状态。

论功行赏（绩效评估）

不管是对被评的人，还是对评价别人的来说，绩效评估都非常难做。因为很多工作并非能很准确地列举出一二三来，工作任务也可能有大量临时变更。太过主观会让人觉得草率；非要去依据可量化的数据，又过于死板和片面。但没有一个公司敢不做考核，所以说绩效评估是“明知山有虎，偏向虎山行”。

绩效考核应该重点关注的是做了什么事，而不是做得怎么样。这个让很多按“结果”管理的老板很不接受。绩效考核应该是推动别人去做某件事的工具。对于已经明确的方法或者子目标，通过这种细化的方式去指导下属工作。因为是需要事后算账的，而且是量化的，所以下属会对这个事情很认真，同时那些不好量化的事情，管理者也很难执行绩效考核。所以“去做某些事”，是绩效考核最好的目标。

通过考核结果提供正式的工作方法意见。绩效考核本身有个反馈的过程，这个反馈的过程应该提供给下属针对每个具体事情的建议。这种具体地，单独地，一对一地指导，会提高团队的稳定性，而且也让团队成员获得“受关注”的感觉，这种感觉是形成高效团队的重要工具。

考核不能代替目标，不能阻碍目标，而应该是一个沟通工具。目标达成情况是考核的客观指标，但不应该作为主要绩效考核指标。最简单的绩效考核指标就是收入或者利润率。但这种简单指标除了在动机上提高下属的工作热情外，并没有从方法和经验上帮助团队成员。有效的考核应该是引导下属按照更有经验的方法去实现目标。