深度思考：关于技术团队如何提效问题

前言

因为我的进入了一个新的工做环境，新的环境就意味着新的问题，一些问题是我的的，一些问题是团队的。。解决一个个问题的过程当中，必然会有一些好的方法论，值得咱们记录和沉淀。

本着对公司负责的态度，在这里，咱们不探讨公司具体业务、数据、以及相关敏感问题。我在这里只谈我的感觉和理解。

是什么阻碍了效率提高？

可能对于大多数团队来讲，都会遇到这样的问题，团队在10人之内，大概内保持必定的效率，超过10我的，沟通的成本，业务交接的成本，流程审批的成本等等，都会成为效率提高的巨大障碍。甚至我说的这些所谓的“成本”，都是大而空的话，所谓影响效率的东西，太复杂了。。

当遇到一个需求

遇到一个需求，产品先进行消化，会产出原型，ui看到的东西，出设计图，前端经过设计图，作页面，后端提供service，先后端再接口对接，测试进行功能测试，最终上线。整个流程，只要一个环节出现问题，整个业务的吞吐量就会极速降低。

假如我是一个前端，我此时会面临什么？

整个流程中，实际上是一个个个体组成的，假如我是一个前端，会面临这么一些问题：

对于需求，可能没理解透，产品出的原型图，我作出告终果，可是彻底不是产品要的东西。。

对于产品，可能产品设计出来的原型，可是我以为有问题，由于从技术实现的角度，这种设计有逻辑漏洞。。

面对ui，可能产品是对的，可是ui设计就是出不来设计图，而前端的开发周期就那么多，阻碍了前端的进度。。

到了后端这里，前端的开发依赖接口文档，后端同窗死活给不出来接口文档，缘由是啥呢？后端同窗以为产品的原型设计有问题，得和产品对接一下具体实现方法。。

到了测试这里，测试以为前端这么作不对，得达到另外一种效果。。或者测试进行测试的过程当中，发现了一个老代码的bug。。

假如我是一个新人的时候

我可能会比较崩溃，我不明白同事说的各类业务名词。。

作一个新的需求的时候，我不懂总体架构。。

测试出来了老代码的bug，我不明白究竟是我代码的问题，仍是哪里出现了问题。。

假如和你合做的后端换人了。。新的后端你感受啥都不懂的时候。。

最后总结

效率炸了。。可能20我的的团队，产出还不如10我的的团队。

大多数企业是怎么作的

这些复杂的问题，咱们甚至没办法理出来一条线，试问心里，到底怎么作？

咱们能够看看行业内，你们的共识，到底如何作？我我的先列举几条。

1，需求讨论会

这是最基本的一个解决方案，产品理清需求，定一个会议室，由产品给你们讲，接下来咱们准备作什么？有什么风险？技术能否实现？

需求研讨会，解决了很是多的问题，它尽量的让你们理解咱们作的业务，它尽量的让你们提早规避了技术风险，它也尽量的让你们处于一个频道里理解一件事情。

2，团队负责人机制

业务的进度怎么保证？如何监控到项目周期的每一个节点的阻塞点？如何协调前端、后端、产品、测试各个方面的资源？这就是团队负责人的角色。

3，标准开发流程

通常的公司的开发流程，就是我上面提到的从产品，到ui，到开发，到测试的一系列流程。定义了何时出ui图，何时出接口文档，给出排期等等。

咱们还有哪些痛点？

是的，这里要问每一个人，到底为何还有那么多的团队，效率仍是很低下？

咱们思考一些流程问题：

产品讲需求的时候，假如原型图有缺陷，何时能给出修正好的结果？

开发过程当中，产品又有新的需求变动怎么办？

ued何时给出详细设计图？假如不符合要求怎么办？

开发过程当中，若是遇到没法绕过的项目架构设计缺陷怎么办？

测试什么时候能给出测试用例？测试出老代码的bug算不算bug？

发现了没有，永远有问题困扰着咱们。

四、详细的规范流程，就是解决这些问题的办法

又有人问，什么是详细，什么又算做详细？其实这里没有答案，真正的答案在于本身的团队之中。

团队有大有小，小而精的团队，过于繁琐的流程，会制约他们的生产力。

好比如今团队很小，只有三我的，可是都是大佬，每一个人对业务都很是熟悉，都知道咱们要作什么，你们天天坐在一块儿，这个时候，其实连需求会都不须要开，只须要出个原型，随便说两句你们就懂，直接作。。

好比如今是一个大概几十人的技术团队，你们不是那么熟悉，可能业务也都不熟悉，因此，为了解决需求理解问题，咱们要开需求会，为了让需求会更有效果，咱们得让产品提早一天或者两天给出会议纲要和prd图，为了保证测试的准确度，咱们要让测试写测试用例，为了保证测试覆盖率，要有测试用例评审，为了保证项目周期进度，咱们要每一个人参与各个复杂的环节。。。

可是全部的目标只有一个，保证产出的质量和效率。

所谓的规范流程，就是经过本身团队的特性，制定出来的流程。

问题：假如咱们的业务太庞大

复杂业务的团队，常常对咱们开发人员有更高的要求，假如咱们同时并发的需求多是5个，每一个需求的前端，后端，测试，产品，都不同，咱们的需求更有可能依赖各类中台、第三方。。

谁来推进整个需求？显然一个Team Leader是不够的。

五、用项目owner的方式，保证复杂需求的进度

咱们须要有一个虚拟角色，就是项目owner，项目owner就是来把控整个项目的周期。

通常而言，项目owner有这么一些特色：对业务很是熟悉；是一线开发人员，能切身体会到当前遇到的瓶颈问题；沟通成本低，对项目中的每一个人都能作到良好沟通。

问题：假如咱们没有gitlab，会发生什么？

能够说，git给咱们的代码管理，提供了极大的方面，若是没有这样的基础工具，那基本上没办法作多人开发的协做了。。。

常见的企业级开发工具包括：gitlab、wiki、rap、jira、钉钉。。解决了咱们一系列问题。

但是有太多制约咱们生产力的地方了。。

好比，每次上线，都要让运维同窗帮忙，每次发布一个测试包，可能咱们都要到某个平台手动部署一次，甚至还有些公司用上传文件的方式部署代码。。

好比咱们项目变大了，编译速度变得超级慢，该一行代码，须要等4秒左右才反应过来。。

好比每次开发，只要是新的需求，咱们好多类似的代码，都要从新写一遍。。

六、良好的基础设施，是提效关键

解决这些问题，其实本质上是基础设施的建设。。

咱们能够作自动部署平台。。

咱们能够作高效脚手架工具研发。。

咱们能够作组件库建设。。

咱们能够作自动化测试工具研发。。

以上的种种，都是基础设施。

问题：有些团队比较特殊，一些应用用这个框架来写，一些应用用那个框架来写，这个时候问题在哪？

业界有很多这样的团队，不少大厂以为本身技术很牛，无所谓用什么框架，确实，在牛人眼中，写啥都没问题。。

可是咱们要换个角度看问题，技术的本质，是为了给业务作支撑，当业务很是复杂的时候，若是仍是无所谓框架的话，那其实颇有可能形成的结果就是无所谓沉淀。。

所谓的无所谓沉淀就是，我在框架a中沉淀下来的基础组件，无法用在框架b的业务中。

七、统一的技术体系和标准，下降开发人员的介入成本

想象一个场景，若是咱们要作100个app，若是用一个统一的框架，因为业务的相关性，咱们能够抽离出很是多的中台组件，提供给这些app使用。。

假如是不一样的框架，作起公用的东西，就太费劲了。

在统一的技术体系中，我能够定制很是多的东西：

类似的项目结构。。

统一的代码风格。。

不用重复造轮子，全部的难点统一解决。

这样的话，咱们的关注点基本就在业务的层面，团队人员的业务吞吐量，就会极速的提高。

问题，假如咱们的服务太杂的话，会发生什么？

这里所谓的杂，就开始可能有一个服务，随着业务的发展，发展到几十个服务。。

这时候，服务a可能依赖服务b，服务b又依赖服务a，咱们整个几十个应用，因为开始阶段，没有考虑的太多，致使如今一个小小的需求改动，代价都异常的大。

咱们不知道，哪一个阶段的数据出了问题，致使本来的应用，出现了异常。。

咱们也不知道，哪些服务会有性能瓶颈，会致使服务不稳定。。

咱们更不知道，咱们的数据表的定义是否是规范，一个字段的删除，会不会影响其余的服务。。

八、完美的架构设计，从新焕发业务的生产力

这个咱们须要从新对整个系统，进行重构。。

咱们要进行业务拆分，分清楚业务的边界状况。。

咱们要对架构分层，好比弄清楚什么是业务层，什么是中台层。。

服务的依赖关系，如何整理。。

作好整个的架构设计，才能放手去博取业务的将来。。

问题，假如领导决定的东西，团队的人不认同怎么办？

常常会有这样的一些问题，领导说怎么怎么作，底下人听着，事后就忘了。。

有时候，底下人以为领导很SB，作事不靠谱。。

有时候，领导以为手底下人，都是菜鸡，连一点小事都办很差。。

所谓的提效，落脚点都是人。。怎么把人解决好。。

9，解决好人的问题，是提效的关键

好比我一进入一个团队，就来了一个需求，这个项目很是复杂，结果，作砸了。。

其实这是一个常见的问题，不少老员工都会出线上故障，更别说是新员工。问题的关键就是，做为一个团队，有没有对新人有相关的业务培训？甚至价值观培训？有没有为员工的成长负责？其实这是一个双向的过程，通过公司的培养，员工成长了，员工反哺公司业务，承担更大的价值。

本质上，是要把团队和我的的利益，尽量的保持在同一种节奏中

一件事情，领导想到了，而后告诉你们怎么作，显然不可能成功。。不是说，领导的想法很差，而是领导的想法，如何让你们以为好，也要让你们知道怎么作。。

本质上，咱们要作到达成共识。。

人的问题，是一个很是复杂的问题，涉及到人员招聘、人员培养、价值观、技能、性格等一系列问题。

可是核心就是处理好两个关系：团队和我的、上级与下属。

让团队与我的，频率同步，达成共识，全员参与，共同成长，才能真正作到提质增产的目的。