团队管理小结一

简单点说，研发眼里的三条线。产品，研发，测试。

理想中的团队

产品：负责产品需求的确定。

研发：负责需求的实现。

测试：产品质量的把控。

现实中的团队

产品：

自己：功能不错，交互也不错。看起来高大上，竞品也不过如此。

研发眼中的产品：需求天天变，逻辑不通，逻辑混乱。简直是不经过大脑思考的产品也好意思拿出来让我们做。凑合堆上去吧，一问又一大堆需求变更来了。算了算了，我佛慈悲~~~

测试眼中的产品：需求那么差，逻辑不通，测试用例只能写正常流的，其它的压根没法写。问一下，他们还不乐意。难难难！！！关键是自己设计的产品，自己从来都不用。

研发：

产品眼中的研发：天天延期，一个那么简单的需求居然搞不定。怪不得这么多单身狗呢。。。。。。

自己：需求对付着来，产品反正烂。研发有问题，产品设计如此。

测试眼中的研发：跟神一样，需求不对居然都能开发出来。只要怼上，连测都不测，这玩意是人用的么？压根跟原型图不一样啊。bug一堆堆，产品主流程都不通。这东西能测试么？

测试

产品眼中的测试：一天都在测测测，也没见质量有多好啊。烦死了，一天天的写个测试用例老问我限制限制的。。。

研发眼中的测试：写完了不用测，直接丢测试。需求不清楚问测试。

测试眼中的测试：宝宝心里苦。没命的加班。

实际情况

我眼中的现实情况：
产品：产品需求基本照抄竞品，产品自己对产品都只是应付了事。
研发：态度消极，负面情绪满满。需求有问题，凑活完事。前端、移动端对接接口，惨不忍睹。后端消极对待，其它对接人员。开发完成不自测功能。
测试：测试前开发都没拿到最新的测试用例。没完没了的功能测试，分不清边界。

刚开始只看到bug率高，bug退回率也高。改bug拖拖拉拉。
解决方案：测试用例先行，每日bug清零。
随后发现，产品与开发测试扯皮，需求变更了。没通知到位，不管以前是什么情况，产品不会故意需求变更不通知。只是没人规范而已。
解决方案：所有产品需求下发及变更必须知会所有相关人员。必须在流程管理上留下痕迹，避免扯皮。
慢慢发现，研发内部内耗严重，前后端及移动端对接接口费劲，不和谐。深入发现，接口文档不规范。看似有接口文档，实则按文档基本没法对接。
解决方案：规范接口文档，规范编码规范。

最终开发的解决方案：

产品需求

1、所有“产品需求”由产品流转至技术总监，由技术总监下发到各个管理者。

2、技术总监会根据“产品需求”的复杂程度，决定是否召开产品需求讲解会。

3、召开产品需求讲解会之前所有相关研发必须通读产品需求。

4、产品需求讲解会，首先预约产品相关人员及研发相关人员。

5、产品需求讲解会，必须有人记录会议纪要，并归档至wiki中。

产品研发

1、接口文档先行，产品需求任务下发后，后端研发主导接口文档。前端研发根据需求任务，提出修改建议。

2、前后轻逻辑，以用户输入数据验证及UI交互为主。

3、后端重逻辑，以数据处理及业务逻辑为主。

4、研发必须完成自测与功能测试。

5、编码规范已阿里巴巴规范为主。

测试用例及提测

1、测试用例包含：接口测试用例、功能测试用例。

2、测试用例在提测前完成，提测前必须参看测试用例自测接口或功能。

接口及接口文档

1、接口采用RESTful风格。（POST，DELETE，PUT和GET四种请求方式分别对指定的URL资源进行增删改查操作。）

GET（SELECT）：从服务器取出资源（一项或多项）。
POST（CREATE）：在服务器新建一个资源。
PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。
PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性）。
DELETE（DELETE）：从服务器删除资源。

示例

GET /zoos：列出所有动物园
POST /zoos：新建一个动物园
GET /zoos/ID：获取某个指定动物园的信息
PUT /zoos/ID：更新某个指定动物园的信息（提供该动物园的全部信息）
PATCH /zoos/ID：更新某个指定动物园的信息（提供该动物园的部分信息）
DELETE /zoos/ID：删除某个动物园
GET /zoos/ID/animals：列出某个指定动物园的所有动物
DELETE /zoos/ID/animals/ID：删除某个指定动物园的指定动物

2、接口必须标明请求方式。（使用http 1.1的定义）

HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法

3、接口文档必须有详细参数的说名及使用限制。如：type：取值范围0-1，0内部，1外部。默认值为0，不传该参数使用默认值。

4、接口返回值参数详细说明。

5、接口必须单一职责。

6、接口必须让使用者轻逻辑。

代码评审

1、每周进行一次代码评审。评审内容由各个组员或各个组的管理者指定。

一般评审内容为核心业务，或新做模块的业务逻辑。
参与人员暂定：全体研发人员及测试人员。后续熟悉如何评审后适当减少参与人员。

2、结对编程的代码评审，如：前端2人，可相互进行代码评审。

3、前端、后端、IOS、安卓、每个月各进行一次代码评审。评审代码需提前三天进行公示预约参会者。

4、评审内容 fix 记入归档。

5、评审内容修正由各个管理者或技术总监进行审核。

技术分享

1、每周一次技术分享，分享内容由各个组员或各个组的管理者指定。

2、分享内容必须归档。