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

4,586 阅读11分钟

前言

由于个人进入了一个新的工作环境,新的环境就意味着新的问题,一些问题是个人的,一些问题是团队的。。解决一个个问题的过程中,必然会有一些好的方法论,值得我们记录和沉淀。

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

是什么阻碍了效率提升?

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

当遇到一个需求

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

假如我是一个前端,我此时会面临什么?

整个流程中,其实是一个个个体组成的,假如我是一个前端,会面临这么一些问题:

对于需求,可能没理解透,产品出的原型图,我做出了结果,但是完全不是产品要的东西。。

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

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

到了后端这里,前端的开发依赖接口文档,后端同学死活给不出来接口文档,原因是啥呢?后端同学觉得产品的原型设计有问题,得和产品对接一下具体实现方法。。

到了测试这里,测试觉得前端这么做不对,得达到另一种效果。。或者测试进行测试的过程中,发现了一个老代码的bug。。

假如我是一个新人的时候

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

做一个新的需求的时候,我不懂整体架构。。

测试出来了老代码的bug,我不明白到底是我代码的问题,还是哪里出现了问题。。

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

最后总结

效率炸了。。可能20个人的团队,产出还不如10个人的团队。

大多数企业是怎么做的

这些复杂的问题,我们甚至没办法理出来一条线,试问内心,到底怎么做?

我们可以看看行业内,大家的共识,到底如何做?我个人先列举几条。

1,需求讨论会

这是最基本的一个解决方案,产品理清需求,定一个会议室,由产品给大家讲,接下来我们准备做什么?有什么风险?技术可否实现?

需求研讨会,解决了非常多的问题,它尽可能的让大家理解我们做的业务,它尽可能的让大家提前规避了技术风险,它也尽可能的让大家处于一个频道里理解一件事情。

2,团队负责人机制

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

3,标准开发流程

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

我们还有哪些痛点?

是的,这里要问每个人,到底为什么还有那么多的团队,效率还是很低下?

我们思考一些流程问题:

产品讲需求的时候,假如原型图有缺陷,什么时候能给出修正好的结果?

开发过程中,产品又有新的需求变更怎么办?

ued什么时候给出详细设计图?假如不符合要求怎么办?

开发过程中,如果遇到无法绕过的项目架构设计缺陷怎么办?

测试何时能给出测试用例?测试出老代码的bug算不算bug?

发现了没有,永远有问题困扰着我们。

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

又有人问,什么是详细,什么又算作详细?其实这里没有答案,真正的答案在于自己的团队之中。

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

比如现在团队很小,只有三个人,但是都是大佬,每个人对业务都非常熟悉,都知道我们要做什么,大家每天坐在一起,这个时候,其实连需求会都不需要开,只需要出个原型,随便说两句大家就懂,直接做。。

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

但是所有的目标只有一个,保证产出的质量和效率。

所谓的规范流程,就是通过自己团队的特性,制定出来的流程。

问题:假如我们的业务太庞大

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

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

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

我们需要有一个虚拟角色,就是项目owner,项目owner就是来把控整个项目的周期。

一般而言,项目owner有这么一些特点:对业务非常熟悉;是一线开发人员,能切身体会到当前遇到的瓶颈问题;沟通成本低,对项目中的每个人都能做到良好沟通。

问题:假如我们没有gitlab,会发生什么?

可以说,git给我们的代码管理,提供了极大的方面,如果没有这样的基础工具,那基本上没办法做多人开发的协作了。。。

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

可是有太多制约我们生产力的地方了。。

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

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

比如每次开发,只要是新的需求,我们好多相似的代码,都要重新写一遍。。

6、良好的基础设施,是提效关键

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

我们可以做自动部署平台。。

我们可以做高效脚手架工具研发。。

我们可以做组件库建设。。

我们可以做自动化测试工具研发。。

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

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

业界有不少这样的团队,很多大厂觉得自己技术很牛,无所谓用什么框架,确实,在牛人眼中,写啥都没问题。。

但是我们要换个角度看问题,技术的本质,是为了给业务做支撑,当业务非常复杂的时候,如果还是无所谓框架的话,那其实很有可能造成的结果就是无所谓沉淀。。

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

7、统一的技术体系和标准,降低开发人员的介入成本

想象一个场景,如果我们要做100个app,如果用一个统一的框架,由于业务的相关性,我们可以抽离出非常多的中台组件,提供给这些app使用。。

假如是不同的框架,做起公用的东西,就太费劲了。

在统一的技术体系中,我可以定制非常多的东西:

相似的项目结构。。

统一的代码风格。。

不用重复造轮子,所有的难点统一解决。

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

问题,假如我们的服务太杂的话,会发生什么?

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

这时候,服务a可能依赖服务b,服务b又依赖服务a,我们整个几十个应用,由于开始阶段,没有考虑的太多,导致现在一个小小的需求改动,代价都异常的大。

我们不知道,哪个阶段的数据出了问题,导致原本的应用,出现了异常。。

我们也不知道,哪些服务会有性能瓶颈,会导致服务不稳定。。

我们更不知道,我们的数据表的定义是不是规范,一个字段的删除,会不会影响其他的服务。。

8、完美的架构设计,重新焕发业务的生产力

这个我们需要重新对整个系统,进行重构。。

我们要进行业务拆分,分清楚业务的边界情况。。

我们要对架构分层,比如弄清楚什么是业务层,什么是中台层。。

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

做好整个的架构设计,才能放手去博取业务的未来。。

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

经常会有这样的一些问题,领导说怎么怎么做,底下人听着,过后就忘了。。

有时候,底下人觉得领导很SB,做事不靠谱。。

有时候,领导觉得手底下人,都是菜鸡,连一点小事都办不好。。

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

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

比如我一进入一个团队,就来了一个需求,这个项目非常复杂,结果,做砸了。。

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

本质上,是要把团队和个人的利益,尽可能的保持在同一种节奏中

一件事情,领导想到了,然后告诉大家怎么做,显然不可能成功。。不是说,领导的想法不好,而是领导的想法,如何让大家觉得好,也要让大家知道怎么做。。

本质上,我们要做到达成共识。。

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

但是核心就是处理好两个关系:团队和个人、上级与下属。

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