管理｜从0开始组建一支研发团队（一）

今年5月底，我加入一家创业型公司，在我加入之前公司只有3位同事：企业负责人，HR和一位产品经理。那个时候产品的原型还没最终确定。

我加入之后的首要工作就是组建一支App的研发团队，因为我们要做的产品就是一款App的社交平台。本文我将从总结的角度去回顾我们是如何组建团队并顺利进入产品攻坚战，重点阐述我在这个过程中的所做所思所想。

一、需求原型确定

企业负责人、产品经理和我经过长时间的产品评审，终于确定了V1.0.0版本的产品原型，原型一旦确定也就是需求确定，那么接下来的工作就是进入UI设计和产品研发。

而对于一家创业型公司，在研发人员还未到岗之前必须要做的事就是研发成本评估，我们当时的成本评估是以年为维度去做的，每个季度可以允许调整一次。

二、V1.0.0版研发成本评估

成本总体图

我们的成本主要分为系统成本（各种云服务器）、人力成本（研发测试人员）、开发配置成本（开发电脑和测试手机）以及数据采集成本（我们采用的是Python开发和神箭手配合的方式）。

系统成本主要有应用服务器、RDS数据库、对象存储OSS、阿里大于、https证书、云数据库redis以及其他需要做消息推送图片鉴黄负载的各种服务器；人力成本主要有Java工程师、IOS工程师、Android工程师、前端工程师以及爬虫工程师；开发配置主要包括各种Win开发电脑、IOS开发电脑、IOS开发者账号、各种测试手机等。

成本评估之后就是确定产品研发推进计划。

三、提前确定开发规约，常规约定以及性能检测方式

JAVA方面的规约我是基于《阿里巴巴 JAVA 开发手册》编写了一份适合我们自己的规约，性能方案我是直接用Coding.net去做代码分析的，重点在检测代码的圈复杂度。

移动开发方面主要参考网易的代码规范，同时开发阶段就接入了腾讯bugly，目的倒逼app相关开发人员去减少app的崩溃次数。

服务端api这块也很早做了一些约定：返回的数据中正确值和空值的类型必须一样。举例来说，用户名的字段是｛“name”：“xxx”｝，如果名称为空时，则应该返回｛“name”：“xxx”｝。如果返回值是一个数组类型，空数据则返回一个空数组，绝对禁止返回null值（app 70%的崩溃都源于服务端接口返回null）。API版本升级时，需要注意两点：V2版本的API的Controller必须要继承V1版的Controller，这样V2版本的API只重写需要改动的API；在线API测试文档中详细标明返回内容，方便App客户端人员的调试。

四、列出所有的技术难点，并一个个去攻克

我们列出了20多个技术难点，按照紧急度&重要度做了梳理，并加上处理时间的截点。

五、产品研发推进计划

所谓的产品研发推进计划就是把产品的需求打散，按照每一个模块每个功能点去拆分评估时间，得出一个最快可以上线的时间。再然后根据产品设计的优先级去确定月计划和周计划。我在定产品研发推进计划时研发部一位同事都没有，这是一个坑，我在几位在移动研发领域摸爬滚打多年的朋友帮助下保证了坑不是太深。

在人员来齐之后，我们的产品研发推进计划在形式上依赖于禅道，我在禅道上创建team每个开发者的任务：在禅道“项目”创建产品的模块（一般是按照网站或App的tab模块去拆分创建），在对应的产品模块中创建对应的任务，每个任务对应产品经理制作的《产品版本功能管理表》中的每个功能点，并设置好截止日期、任务执行人、任务完成的预计完成时长（默认每个任务1小时，便于做项目的进度把控）。

这里需要注意的两个点，我再重复下：

1、一定要把每个功能点都记录到禅道，记住是每个功能点，特别是在时间很紧迫的时候，你无法保证你的小伙伴会认真仔细地看原型，并且还可以通过原型提取那么多功能点。

2、每个任务都需要有截止时间，没有截点的任务就不是任务。

这么做的原因主要是为了达到两个目的：保证产品研发的每个参与者明确自己的所有任务，明确每个任务的时间截点；方便产品研发负责人对产品做过程验收。

六、研发负责人的过程验收（一般为1周一次）

对于产品研发的负责人，至少每周要进行一次过程验收，特殊情况需要一天一次。

我在每周六（我们当时是9 10 6）下班前要对本周每个人的任务完成情况进行一个验收，验收的过程主要是对照禅道上的任务表进行查看。

验收参考项：每个单个功能点一定要调通［必须］，保证每个功能点中的页面不会出现空数据（不利于验收）［必须］，根据具体情况对用户体验提些要求（比如App中在验收时发现很多按钮的点击范围太小，很难点中）［非必须］，保证整个操作的连贯性，如果有相关的功能点时逻辑要走通［非必须］。

我会对验收结果进行判断是否需要再加班赶进度。

同时我对每个组员的代码质量进行review，这块可以利用Coding.net自带的代码分析功能，有问题需要在周会上及时提出来进行讨论。

七、产品负责人的阶段性验收（一般为1个月一次）

我们每个月进行一次阶段性验收，验收的过程主要是对照禅道上的任务表、产品原型、产品效果图进行查看，这块前期需要在研发部由产品研发负责人进行内部验收，再提交到产品部和产品经理一起验收。

验收参考项：每个单个功能点一定要调通［必须］，保证每个功能点中的页面不会出现空数据（不利于验收）［必须］，根据情况对用户体验提些要求（比如App中在验收时发现很多按钮的点击范围太小，很难点中）［必须］，保证整个操作的连贯性，如果有相关的功能点时逻辑要走通［必须］（确定1-3条检测标准，即是否可以走通本月计划中的主要流程，在这过程中一般会包括“管理后台＋前台网站”或“管理后台＋App客户端”）。

我和产品经理在验收之后需要出一份验收报告，同时在验收过程中发现的bug需要及时记录到禅道上，便于研发人员及时修复。

我和产品经理对验收结果进行判断是否需要加班赶进度或紧急调整项目计划，并告知其他相关部门人员。

八、验收时的问题

1. 我们在做周验收和月度验收时经常会遇到有些小伙伴没有按时完成任务，但是也没有特别的严重，那么怎么办呢？

我定的方案是我和产品经理每天晚上对之前的任务和正在进行的任务进行每天测试，测试出来的问题相关的开发人员在第二天上午进行修复这些bug，下午和晚上该做什么就做什么，按照既定计划往前推进。他们每天把修复bug的项目打包上传，我当时用的是fir.im。

2. 因为我们在赶项目，很多时候无法避免会选择比较次的方案去实现某个功能点，当然我们在做的时候是知道有更优的方案，但基于时间的考虑，我们会选择次的那个方案。那么这种情况怎么办呢？

我的方案是我在禅道上新建了一个“研发部问题看版”项目，每个组员需要那种情况就把问题记录到这个项目下，我们在后面时间宽裕的时候再一个个去解决，不过这里需要说明的是，如果可以有更优的方案尽量就用更优的方案一次性解决，而不是每次都用次的方案。

九、如何输出相应的文档

我们都知道，在我们从0开发一个项目时，总有一些不紧急但很重要的事，其中最典型的就是各种文档的编写，比如设计文档。特别是当我们忙的不可开交时，不可能强制要求开发人员去写这些对我来说很重要对他们来说有点浪费时间的事。那么怎么办呢？

我的做法是为他们弄了一个文档范例，让他们分阶段去增加内容，比如在做A模块时，让他们增加A模块的内容，增加什么开始不限制，可以是一些思路，可以是问题点。等后面有空的时候再整理。

十、重视交互评审

页面交互例子

除了研发部本身的一些评审之外，与协作部门——产品部需要的评审主要有3个：原型评审、交互评审和UI评审。

原型评审和UI评审这个每个公司基本上都是有的，但是交互评审就不一定有啦。我之前没有经验，一开始我没要求产品部去做交互稿这块，导致我们研发人员在做功能交互的时候各种猜测，最后做出来的交互不满足要求，同时IOS和Android两位客户端的交互差别太大，不得不返工。

交互主要分为页面交互（也就是页面操作流程）和功能交互。

页面交互代表主体流程，主体流程决定代码结构，客户端一些交互流程的细微变化，对代码结构、可维护性、后面是否因流程有坑而需要重构，影响都比较大。交互阶段，比如会考虑到一些loading和过渡状态，比如开发会知道哪些是耗时的操作，从而影响到流程的可行性。从另一个角度讲也能防止开发阶段发现流程有坑从而让UI返工。

功能交互主要是指对于一些复杂的操作动效需要有一个可以参考的标准，而不是靠客户端开发人员自己猜。

总体来说，交互的意义是让研发人员对整体工作量有个大概的预估，不遗漏页面流程，对功能交互没有歧义。

我们的产品研发还在进行中，在这过程中有太多经验和教训，之后的一些感悟我还会不定期更新到这篇文章中。

欢迎一起交流学习。