写在前面

之前在小公司当个小小的前端技术主管，就算带个2、3人的团队也觉得有很多问题需要沟通和调停，尤其是对下属的代码质量和开发进度把控上很是头疼。所以我更无法想象，像阿里、网易那样的大公司，尽千人甚至上万人的研发团队应该如何管理呢？带着学习和自我提高的心态，我放弃毕业前高薪的工资来到一家正处于上升热头的互联网公司，从一个实习生做起。放下所有架子，摈弃所谓的傲气，从零开始体验互联网公司的运转模式。下面分享一下我尽3个月来的感悟。

需求管理平台 Req

在互联网公司，每天都会有不同的需求被反馈，可能是线上bug、可能是用户体验优化、也可能是新的项目需求等等。这些需求按类别可以分为三类：日常需求、缺陷需求、项目需求。与之对应的有3个管理池：需求池、缺陷池和项目池。

需求池

需求池里可以建立简单的日常需求，这些需求一般是一对一可以指派的问题。比如运营提出的可以提高用户体验的一些优化建议、UI提出的视觉方面的修改和调整。这些问题一般不属于线上BUG，可以短期（1到2天）内修复上线的。日常需求的生命周期如下：

建需求 －> 拉分支 －> 本地开发测试 －> 代码评审 - > 预发布验证 -> 正式发布验证

缺陷池

缺陷池是给测试部门使用的。无论是日常需求还是项目发布都会有测试工程师介入测试，测试过了才能发上线。测试过程中发现的一切问题都要如是记录在缺陷池里，指明对应的责任人和处理人，并跟踪此缺陷的生命周期。缺陷按照严重性可以分为P0～P5，P0最为严重，一般发生P0缺陷，整个网站或者系统将无法正常运行，责任人和处理人需要在1个小时之内解决，如果解决不了需要立即回滚代码。如果你造成P0缺陷，那么对不起，轻则季度考核不合格，重则直接劝退。
而P级数字越大，缺陷严重程度越低。不过如果无法在规定时间内解决该缺陷，会自动上升一级。所以一旦出现缺陷，压力还是很大的，开发工程师应该在自测完全没问题之后才能申请测试工程师进行专业型测试。

项目池

一般一个需求的生命周期超过8天的必须申请立项——即成为一个单一项目进行管理。一个项目完整的生命周期如下：

需求评审 -> 产品出文档和交互 ->  UI 制作视觉稿、标注稿 ->  后端给出Mock数据接口  --> 前端编写页面，绑定数据  -->视觉UI走查 --> 前后端线下连调  --> 后端接口上线  --> 用例测试  ---> 前端页面上线  -->  用户反馈和优化

每个项目会有一个产品经理、项目经理整体跟进，如果项目成员多的会设立专门的项目室（所谓的“小黑屋“）进行开发和沟通，以提高沟通效率。

wiki文档管理平台 Doc

每个研发团队都需要有一个统一的平台来管理一些文档，包括接口的API文档、代码规范、最佳实践和技术分享等东西。在互联网公司我们不会写一大堆的word文档或者整一些PPT，所有的文档都采用markdown语法编写，简约又易于分享。

接口API文档

接口文档的作用是为了前后端解耦。现在前后端分离的开发模式已经深入人心的，如果你还发现你的公司仍然搞一大堆什么JSP、Smarty、Velocity、FreeMarker等所谓的后端模板引擎的，赶紧告诉他们已经Ou t了！前端模板引擎的性能和用户体验都远远高于后端。呵呵，可能这时远方飘飘然会传来一声不屑——胡扯，后端模板引擎的性能怎么会输给前端呢？会这么想你肯定不知道前端模板引擎强大的预编译功能——模板引擎再厉害还是会有编译过程，预编译则把编译事先做了。

好了回归主题，规范的接口API文档应该包含以下几个内容：
第一：接口的用途
第二：接口的类型、是否需要登录
第三：接口的参数列表和字段说明
第四：接口成功返回的数据字段说明
第五：接口失败返回的数据字段说明
第六：接口对应的mock数据入口

代码规范

说到代码规范，各个团队有所不同。前端、后端、客户端、测试、大数据等各有各的代码规范。代码规范的作用是统一编码风格，提高代码复用能力。这个规范可以是长期开发经验积累整理的一套编码风格。前端的话应该包括：文件命名规范、HTML文档规范、less或Sass编写规范、JavaScript编码规范等。代码规范应该随着变成语言的升级而不断更新，并且每次更新后应该对每位开发人员进行代码规范 考试。

最佳实践

最佳实践是指针对某个问题总结出的最佳的处理方式，可以是代码片段、设计模式或框架设计等。每次项目完成之后应该做这样的总结工作，梳理一下项目的脉络和技术实现，思考性能优化和用户体验细节提升的技巧，然后积土成山，并长期维护和更新，构建团队自己的技术栈。

技术分享

技术分享应该以专题的方式进行，理论上团队每个成员定期都应该做特定专题的技术分享，并和各自的绩效挂钩。分享方式很简单，演示文稿和markdown文档，如果是技术实践应该还有配套的demo代码，最好在小组的周会上进行，鼓励讨论和反驳，一起进步。最后这些分享资料以期刊形式进行整理和出版，构建团队的技术栈。

开发管理平台

开发管理平台主要用于开发过程中的所有流程的把控和个人质量统计。这个平台应该和需求管理平台以及代码管理平台联通，协同使用。

个人缺陷管理

该模块可以反应开发者目前的代码质量水平，统计扣分情况。上面说了代码缺陷等级分为P0～P5，开发者一旦出现缺陷会被统计在缺陷池里，并以扣分的形式呈现在这里。并且扣分排名前30名会上榜，全公司的开发人员都可以看到，互相督促。

开发任务跟踪

该模块里会呈现开发人员当前的任务队列，每个开发任务的生命周期只要没有走完，都可以申请发布计划或取消发布，任务一旦发布成功该任务就会从列表里隐藏。

发布计划

开发任务一旦成功生成发布计划，会自动从trunk里产生新的分支，并给出新生成的分支号，然后开发者把代码切到该分支，在此分支上进行新的开发。

代码评审 codeReview

开发者一旦完成本地开发并自测没有问题，申请发布前必须先经过上一级的代码评审。代码评审包括编码风格审查，代码执行效率、业务逻辑实现的性能等多方面的排查。评审通过了才允许继续发布。否则打回上一步，问题修改完成后继续提交评审。

代码发布

代码评审通过后，会进入当天的发布队列。

发布队列

平台管理员每天在规定时间把发布队列里的发布计划进行预发布操作，即把分支合并到trunk。

预发布

代码正式发布前先进入预发布环境。预发布环境和正式环境一模一样，测试人员需要把本地的hosts配置成预发布的IP地址。然后进行预发布验证。验证如果不通过会被打回，开发人员需要在30分钟内进行修改，问题解决后管理员会重新合并代码，继续预发布验证。超时或无法解决问题，回滚代码。该发布计划失败。

正式发布

预发布验证没问题了，发布队列里的任务会进入正式环境。测试人员需要把本地hosts配置成正式的IP地址。然后进行正式发布验证，一般不会再出现问题。

紧急发布

每天进行发布的时间是规定的。过了规定的发布时间如果还需要发布代码的，需要走紧急发布。紧急发布每个开发人员都有次数限制，一般如果存在未知风险或涉及核心代码的，不允许紧急发布。

代码回滚

如果正式环境出现问题，在规定时间内开发人员无法解决的，必须回滚到上一个版本。

代码管理平台 gitLab、SVN

每个开发团队都需要一个代码管理工具，svn或者git 是目前常用的工具之一。如果使用svn则只需要提供两台svn服务器（正式和预发）。如果使用git则需要搭建gitLab作为代码的私有仓库。

分支管理

开发统一拉分支进行开发，然后合并到trunk。并且trunk上一般开发人员没有写的权限，保护trunk的安全。

版本控制

各分支之间允许合并和回滚，由开发人员自己管理。

团队管理平台 team

每个小组应该成立一个team平台进行管理。在这个平台上可以查看队伍各个成员之间的工作情况（日报、周报、项目进度等）

日报

每日一报，写一下今天做的日常需求，如果是项目，就写一下项目的进度。

周报

每周一报。本周工作总结和下周工作计划。

项目进度

开发管理平台各自的任务的生命周期应该同步到这里。方便你的leader进行查看和工作汇报。

员工管理平台 oa

这个几乎每个公司都有，就不介绍了。

规章制度

保密。

人事流程

请假、考勤、打卡、离职、入职等。

场地申请

会议场地、项目室申请。

会议通知

会议开始前会定时通知与会人员。

组织架构

研发团队是互联网公司强大的后盾，“养“着一群技术人员。这些人员不仅更具岗位职能进行划分。还有一个更重要的分法是根据工作性质进行分配。

业务部

负责新业务开发和旧业务的维护。

基础部

负责开发服务化工具和大数据分析。

系统部

负责系统架构设计和新技术研究。

运维部

负责服务器管理和维护。

质量保证部

我们的测试工程师同胞们。

注意：本文不要随意转发哦 ^_^