- 相关推荐
互联网公司如何管理研发团队
需求管理平台 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
这个几乎每个公司都有，就不介绍了。
规章制度
保密。
人事流程
请假、考勤、打卡、离职、入职等。
场地申请
会议场地、项目室申请。
会议通知
会议开始前会定时通知与会人员。
组织架构
研发团队是互联网公司强大的'后盾，“养“着一群技术人员。这些人员不仅更具岗位职能进行划分。还有一个更重要的分法是根据工作性质进行分配。
业务部
负责新业务开发和旧业务的维护。
基础部
负责开发服务化工具和大数据分析。
系统部
负责系统架构设计和新技术研究。
运维部
负责服务器管理和维护。
质量保证部
我们的测试工程师同胞们。
【互联网公司如何管理研发团队】相关文章：
互联网UED团队如何管理？07-10
初创互联网公司如何进行团队建设？07-10
请问互联网公司里研发和产品/运营/策划之类的待遇如何？07-10
如何去管理销售团队04-16
互联网科技公司如何招聘？07-10
职场上如何管理好团队08-04
如何管理一个团队07-11
大家对各类互联网公司的印象如何？07-10
互联网创业公司如何起步更好？07-10