如何提高创业团队的软件开发效率

19年的经济寒潮似乎比前两年还要冷,大家似乎开始意识到也许接下来日子的会更加的冷。从华为到平安,身边很多小伙伴所在的公司开始进行大规模裁员;经历过一些列灰天鹅黑天鹅,从顶层到底层,人们更倾向于持悲观态度,做更为保守的预判;

从根本上来说,不管是大规模裁员还是小规模裁员,都是对组织架构的一种优化方式;一般在经理大规模裁员后,员工的心态会趋向于更加悲观,认为公司的发展会越来越差,这是感性层面的。如果从理性层面分析,能够留下来的基本都是公司里面最有实力的那部分(拉帮结派的公司除外),也就是说,某种意义上会提高软件开发的质量和效率;

在大裁员后,稳定军心是一个非常重要的举措,但是我们今天这篇文章讲的是如何提高软件开发效率和软件质量,因此对于管理方面的问题不过多阐述;一般情况下,公司大规模裁员的根本动机是为了防止企业资金链断裂而导致团队被迫解散,因为如果资金链断裂,公司拥有再优秀的员工也无济于事,一旦发生这样的事情,再想挽回基本是回天乏力;

那么如何尽可能的在大裁员后提高软件效率是一个软件开发团队最关心的问题,而关于如何做,如果只是照本宣科,很难起到真正的效果。关于提高效率的文章,网上有很多,观点基本一致也都大致正确,但是真正能够落地的却很少,究其原因,还是因为这些文章或者讲座脱离了公司所处的环境泛泛而谈,吃瓜群众看到了会觉得很牛逼,而对于真正想要解决团队问题的人来说,简直是浪费时间;

艰难的推行

提高开发效率的方法有很多,但是真正落实到位的公司有很多,究其原因,很多公司在执行的时候遇到了诸多阻力,很多公司由于无法克服这些阻力导致这些方法无法正确落实甚至根本无法推行下去;主要有两种情况,一种是执行着就慢慢变味了,变成了形式主义而得不到应有的效果而被管理层摒弃;还有一种是受到基层开发人员的抵触而根本没办法开始,因为这里面存在一个误区,那就是开发人员会认为所谓的提高效率一定是想办法压榨员工,让他们做更多的事请,让他们变得更累;

失败案例

确实,有些公司在执行这些所谓的高效方法后,开发人员苦不堪言,往近了说,我身边就有一个很鲜活的例子。他们公司属于一个跨国公司的新兴产业部门,本质上来说也属于创业团队,因为里面的管理人员还有开发人员都不具备丰富的经验。前几个月,他们公司换了一个印度的CEO。印度的CEO上任后发现公司的开发管理很有问题,开发人员迫于业务压力,不得不每天加班到晚上10点,基本上是不到10点就很少有人走,他觉得这样的工作制度很不人性化,在长期看来也没有任何好处,于是想要提高软件的开发效率。由于要照顾到高层对于不拖累现有开发进度的需要,印度CEO提出一种渐进式改良方案:取消午休制,保证员工在6点准时下班;

该方案执行后的结果想必大家猜到了,该公司员工和我抱怨说,以前还有午休,现在午休也取消了,但是加班还是一点也没有少,他正在考虑年后换一家公司,因为他对象已经因为加班的事请和他吵了无数次架了。

可能的方案

上面是一个比较典型但是相对极端的案例,绝大部分的创业团队可能没有加班严重到那样的程度,低效的开发团队在整个中国确实是非常普遍的,以致于很多开发人员在入职一家公司的时候首先问的是该公司是否有通过CMMI认证;当然咯,有一些公司花钱过了CMMI认证后加班依然存在,效率也不见得提高多少。

所以在敏捷圈的人看来,CMMI认证有时候就是个忽悠人的玩意,因为一个公司不可能因为有了一个CMMI认证整个公司就会发生翻天覆地的变化;那么敏捷培训就能力挽狂澜吗?也不是。我们公司在去年的时候老板有意向让我去找一个敏捷教练来我们公司做培训,当时我找了敏捷圈的大佬帮助我们公司做敏捷培训。后来还是取消了,原因是发现一个公司想要真正敏捷起来,寻妖整个公司从高层到基层都重视并践行敏捷之道,才能真正提高整体敏捷度,否则就跟我们去听一次励志演讲一样,听的时候很兴奋,但是完事后发现并没有多大效用;

因此最好的敏捷一定是需要一个敏捷教练在这个公司待上个一两年,充分了解了公司情况后对症下药才能完完全全将敏捷执行下去,否则都是隔靴搔痒,不痛不痒;在接触到敏捷到敏捷的推行,我发现想要从公司内部推行敏捷也不是那么容易的事请,但是绝对是最容易被管理层接受的方式(因为能够帮助管理层节约肉眼可见的成本);

但是公司内部推行敏捷的效率显然不如有一个敏捷教练在公司待上一两年全程指导公司实现敏捷来得直接。他需要解决很多问题,每个环节都至关重要,只要有一个环节不通过,那么内部推行敏捷就不容易推行下去,为什么这么说,大家听我娓娓道来;

技术债务

以上的问题我们可以用一个词总结,那就是”技术债务“,技术债务很多人都懂,但是并不一定了解技术债务的边界,我自己对于技术债务有自己的理解;

技术债务也是债务的一种,既然是债务,那么债务的主体是很明确的,也就是我们完全可以列举出团队当前状况下的所有技术债务;技术债务是当时知道应该去做但是优于其他方面的局限而没有去做的事。这些事情需要留到以后去做但是一直还没有做,这种事情就叫做技术债务。技术债务一旦还清了就不存在了,就跟我们还清了借款需要撕掉借条一个道理;如果当时并不能确定需要这么做但是没做的事请不能算作技术债务,典型的如系统架构的过度设计,在这里我把脱离了实际业务需求的设计都叫做过度设计,怎么理解呢?很久以后可能不会去做的事自然不能算作技术债务。

当然我这么说可能还是有点抽象,不同的团队所面临的技术债务有所不同,我们可以通过下面一个小故事加深对技术债务的理解;

一个技术债务的故事

从前有一个创业公司,这家公司创立于互联网鼎盛时期,我们知道在互联网发展好的时候,一个经过3个月培训的同学出来就能去一家互联网公司拿到较好的工资;那些技术水平靠前的技术人员的工资自然水涨船高。处于成本控制和小步试错的考虑,公司决定组建了一个研发部门负责公司软件产品的研发,而研发团队基本都是从学校选拔出来的好学生,到这里一个研发团队形成了;

创业团队都很兴奋,为自己即将从事一个伟大事业,创造一个伟大产品而自豪;·我曾经采访过他们中的团队成员A,据A的回忆,大家像打了鸡血一样拼命工作,加班是常态,但是大家都毫无怨言,反而觉得是一种荣耀;

不过慢慢的,大家发现了一些问题,软件开发的速度变得越来越慢了,需要做的维护工作也变得越来越多,就如一些程序员说的,编写一个功能引入无数Bug,解决一个Bug,新增很多Bug。而随着开发周期的迭代,整个软件系统变得臃肿不堪,有的时候甚至为了解决一个简单的Bug花费数天时间。而在每一个功能开发完成后,如果测试部门不经过一个月测试,根本无法将软件分发给外场;

项目组长最先发现了这个问题,他想尽办法想要让每个周期的项目按时完成,但是只能通过不断的加班解决解决,一部分开发人员由于无法承受繁重的加班,提出了辞职。在这个时候项目组长惊讶的发现,整个项目功能已经达到了很庞大的情况,新招入的开发人员想要维护原来的系统变得困难许多,一些对于老开发人员来说一个小时就能解决的问题,新的开发人员需要花费一两天的时间才能够解决。

项目组长找到新成员了解情况,新成员告诉组长,项目代码想要看明白不容易,一些简单的业务逻辑写的很复杂,似乎没有一个整体的思路。而他在看的时候必须根据当时写代码人的思路慢慢把代码理清楚。由于开发这段代码的人已经离职,而又没有留下相关的文档。在解决一个Bug的时候,首先需要搞懂里面的业务逻辑才能发现里面埋下的坑,这个跟排雷一个道理。小日本在一片荒地上埋了一颗炸弹,但是谁也不知道这颗炸弹埋在哪里,只能出动数十人进行地毯式扫描,这样的效率显然是低下的。对于埋雷人来说,只需要几分钟就能埋下一颗雷,而对于排雷的人来说则需要花费很长的时间;

项目组长总结了一下整个开发团队中存在的问题:

  1. 整个代码系统的代码质量偏低,无统一的编码风格,导致编写的代码只有编写者本人能看懂,别人无法维护,在编写者离职或者离开岗位时间留下的问题无法得到快速响应;
  2. 开发人员缺乏自测意识,每次开发出来的产品需要大量的测试人员长时间参与测试才能把版本发布出去,这也导致了测试团队臃肿却经常加班,测试部门苦不堪言且一直在抱怨人手不够;
  3. 部门之间沟通成本太高,我上次开发一个xxx模块,想要另一个部门配合,他们管事的老大一直推脱,搞得事情很难推进下去。
  4. 文档缺失,上一个人写的代码乱七八糟,看起来很痛苦,最主要的是还没有文档,我在看的时候真的很痛苦,问其他人也都说不是自己搞得不太清楚,那我就只能硬着头皮按照自己的思路啃代码,猜对了还好,猜错了又给自己挖了坑;
  5. 大量的重复代码和无用代码没有被清理,严重干扰代码的阅读速度和问题排查速度;
  6. 每个人负责自己的一小块代码,想要寻求他们帮忙的时候都不愿意帮忙,哪怕是遇到了和他们负责的模块耦合的代码,他们也都是想尽可能的把锅甩开;
  7. 系统架构陈旧甚至是无架构,导致在大的需求开发时候捉襟见肘,很多功能无法有效的结合到一起,导致更多的代码耦合和更多的代码纠缠;
  8. 需求不明确就开工,每次东西做到一半上头不放心就过来询问进展,干涉计划的执行;
  9. 同时多个任务互相切换,每次切换任务都需要花不少的时间调整到应有的状态,有的时候由于切换任务不得不加班,造成不必要的消耗;

技术债务

解决方案

既然问题出现了就应该解决,怎么解决呢?项目组长思考了三天三夜,找了很多方法,经过筛选,终于确定了执行方案。组长把他想到的这些方案命名为Plan Six,分别是:

  1. 代码接龙游戏;
  2. 代码集体所有制;
  3. 结对编程;
  4. 避免台球短跑;
  5. 避免半成品;
  6. 马拉松长跑计划;

在这里插入图片描述在这里插入图片描述

代码接龙游戏

成语接龙我们知道,那代码接龙是什么呢?简单来说就是让团队成员坐成一圈,从第一个团队成员开始,每一个成员花15分钟编写一段该成员觉得有问题/有亮点的代码,然后把电脑传递给下一个成员,让下一个成员指出该代码中存在的问题或者亮点,并记录下指出的问题或者亮点;这样走一圈后,统计一下亮点和问题点,然后由团队所有成员一致讨论决定需要采纳的建议项加入到团队编码规范中;

这样做有两个好处,对于之前没有形成统一编码规范的公司而言,这种通过全民参与的方式可以提高团队成员的参与感和集体意识;如果强行规定势必回遭到部分团队成员的抵触而很难执行下去或是积累怨恨。第二个好处是可以慢慢形成统一的编码规范并促成良好的团队文化,即使有人员变动,也能减轻下一个接管代码的人的压力;

代码集体所有制

相对于代码接龙游戏来说,这一个计划大概是比较难执行的一项,因为一般公司为了管理方便,会让不同的人负责不同的模块以便于各司其职在出现问题的时候也方便找到对应的负责人。但是我们知道,代码分工制有很多的弊端,最显著的就是容易形成甩锅文化,用”各家自扫门前雪,哪管他人瓦上霜“来形容简直在准确不过了;

其实这种甩锅文化还有一个很严重的弊端,那就是震出了问题想要找到负责人不见得会容易很多,很多时候管事推脱责任就花了不少时间,大家在遇到问题的时候第一时间不是想着解决问题,自然就想不到一个合适的解决方法;特别是遇到紧急情况需要占用下班时间或者休息时间的时候,这个问题就凸显出来了;这种情况下基本就只有项目负责人和对应模块代码负责人在加班解决问题,大家可以想象一下这个场景,是不是很悲壮很凄凉;如果次数一多,还有谁愿意加班呢,没加班的会幸灾乐祸,反而不利于团队成员之间建立良好的关系,也没办法形成良好的团队文化;

当然这个是文化上的,还有实际工作上的弊端,因为每个人负责自己的以某三分地,基本是没有动力去了解和学习其他人负责的业务模块,在很大程度上每个模块的开发人员就像盲人摸象,无法对整个系统有一个整体全面的了解,因此在理解需求的时候很容易画蛇添足造成不必要的时间浪费。另外,这种方式也容易导致各个代码模块的负责人根本不知道其他人的代码编写的时候思路是怎么样的,在遇到团队成员突然离职的时候想要解决离职小伙伴留下来的坑就比较辛苦了,单是读懂代码就让人很是头疼;

因此执行代码集体所有就很重要了,我列举出来以下几点好处:

  1. 有利于代码审查的推行,因为代码审查的时候看完全不懂的业务模块是非常吃力的一件事,也没有办法产生代码审查的实际效用;
  2. 有利于形成很好的代码编码规范,促进编码文化的推行;
  3. 有利于降低团队成员离职导致问题无法解决的风险;
  4. 有利于加强团队成员的凝聚力,让大家觉得团队是一个整体,出现问题的时候可以互相帮助,由于代码模块责任变模糊,即使是加班也是一个团队在加班,不会让团队成员觉得孤独。另外大家为了让团队更轻松,会一起想办法补齐团队的短板,最终会形成一种正向反馈,把团队王更好的方向推进;

结对编程

结对编程是一个很有意思的事请,但是大家发现这件事情在执行的时候有很大的难度,原因是企业管理层普遍觉得结对编程是一件消耗人力的事请,其结果未必有那么好,或者是完全的认为完全没有任何好处;也就是说,本来可以一个人解决的事情,变成了两个人在一起解决,效率自然是降低了;

其实对于大部分的创业团队来说完全执行结对编程是不理智的,其结果必然是相当高的边际成本和相当低的工作效率,那为什么创业团队还需要结对编程呢?

其实是打开的方式不对,如果能和利用好结对编程,必然能够产生事半功倍的效果。首先我们需要搞明白结对编程相对于单个人编程有哪一些好处?仔细想一下就知道,很多时候,单个开发人员会存在一些思维盲区无法从坑里面跳出来或者遇到一些比较复杂需要持续费脑子的情形,如果死磕未必能把东西倒腾出来。倒是两人在一起讨论就完全不一样了,原本沉闷的气氛就会被带活,一些很难想到的解决方案会被想到或者一些很细节的问题就会被考虑到;

在这种情况下,结对编程具有无可比拟的优势;

避免台球短跑

首先我解释一下什么是台球短跑,我们在打台球的时候,如果一杆子用力过猛,那么台球会在球桌上反复撞击而在短时间内无法确定台球会在什么时候停下来,等到停下来时需要迅速跑到合适的位置进行下一杆。但是高手不会这么做,他们通常会在出杆的时候就知道下一杆甚至是下下一杆球会停在那里,需要怎么打。因此他们在每次球停下来的时候就准备好打下一杆了;

开发也是一样,如果上一个月用力太猛会导致在开始下一个月的时候需要花最少一个星期搞清楚要做什么怎么做的问题,而等到做完的时候已经是月底了,这个时候又需要在下一个月开始的时候抽出时间确认需求,这样势必陷入一个恶性循环,开发人员痛苦不堪。

如果能控制好每一个月的工作量,给每个月的开发留一个星期的时间用来明确下一个月的需求,就能在一定程度上避免这个问题。不仅如此,开发人员也会在交付末尾的时候尽可能多的测试保证较复的质量,而且有了这多出来的一点时间,开发人员在了解了下个月的工作之后会主动的提前开始任务,进入工作状态。很显然,这种主动的效果相比于被动接受任务会好点的多,而且效果不会更差,只会更好;

避免半成品

《凤凰项目》这本书里面有一个很核心的观点,那就是要尽可能的避免产生半成品,我们把程序开发想象成一条流水线,一旦出现半成品,那么这个产品就没办法交付,而在后期由于需要照顾到这个半成品需要抽出更多的时间来完善这个半成品。我们先不讨论这么来回切换需要花费不少时间再熟悉开发的这个模块,由于半成品在当时会被管理者忽视认为已经完成导致开发人员需要从仅有的开发实践中抽出一部分时间来完成这个半成品,这显然会影响这个开发人员的效率和质量;

半成品是不合格的无法交付的产品,如果不能交付那么就是个废品,这就是资源的浪费。很多公司不自知,导致每次上线的时候交付的都是半成品,到最后一个拿得出手的产品都没有,而开发人员也很委屈,他们很努力的工作,加班到深夜,最后没有得到应有的回报和尊重,最终势必会造成很严重的后果,很多公司就是这样被搞垮的;

马拉松长跑计划

简单来说就是要有自己的规划,当然这个不容易做到。很多创业公司说,我们需要思考的是如何让我们公司能够更长久的活下去而不是做一些锦上添花的事请。如果创业阶段不能够卯足了劲往上赶,又拿什么和别人比,拿什么产品脱颖而出。

诚然,这是很现实的因素,但是并不是说创业团队就一定要时时刻刻紧绷神经。就像加班这件事情,偶尔的加班和996能够增加团队的您距离,但是时间长了呢,团队的士气一定会下降;这就像《曹刿论战》说的”一鼓作气,再而衰,三而竭“。古人都明白的道理我们不可能不明白;如果立足于公司的长远发展,就不能寄希望于加班和打鸡血,毕竟创业团队能拿出丰厚报酬奖励加班的公司很少,为了公司的长远发展,还是尽量制定有节奏的开发计划,这样易于执行也利于整个团队思考提高效率的方法;

就像那个每个月从地主借钱劳作并把成果低价卖给地主然后从地主家购买物资的老夫人一样,如果他不能每天给自己节省一点钱那么它就永远摆脱不了贫穷的民运。如果开发团队没有时间提升自己,那么团队水平就没办法跟上业务的发展需要而出现很遗憾的结果;

偿还债务

方案已经想好了,那么如何落实这些计划并偿还债务呢?项目组长想到了一个相对可行的方法,他把计划的执行分为以下几步:

Step1 :止血
Step2:维持现状
Step3:还债
Step4:持续集成

那么,就让我们拭目以待吧。

参与评论 您还未登录,请先 登录 后发表或查看评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:博客之星2020 设计师:CSDN官方博客 返回首页

打赏作者

疯人院的院长大人

打赏我一杯豆浆

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值