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

• 艰难的推行
• • 失败案例
  • 可能的方案
• 技术债务
• • 一个技术债务的故事
• 解决方案
• • 代码接龙游戏
  • 代码集体所有制
  • 结对编程
  • 避免台球短跑
  • 避免半成品
  • 马拉松长跑计划
• 偿还债务

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. 同时多个任务互相切换，每次切换任务都需要花不少的时间调整到应有的状态，有的时候由于切换任务不得不加班，造成不必要的消耗；

来源：疯人院的院长大人