本文首发于饿了么前端——知乎专栏
在此感谢知乎用户——次碳酸钴 为大家贡献如此优秀的文章。
1.对业务方的实际需求调研不够充分,造成需求频繁变更
之前的文章「我只是想在页面上加个链接」(地址:https://zhuanlan.zhihu.com/p/30468160)中描述过这个问题,本篇不展开。
2. 没有定好目标,没有想好「做到什么程度」
2.1. 团队契合度
当接手一个需求时,如果需求方是可以讲道理的,那么我通常会问「满分 100,这东西我们要做到多少分?」
也许有人会觉得奇怪,明明能做到 100 分,为什么不做到?你们这不是消极怠工吗?说好的品质为王呢?
其实可以这么想,考试有那么多科目,如果把所有精力都投入一个科目确实可以拿高分,但是其它科目就要挂了。不如尽可能地让所有科目都及格来得实际。
说白了就是一个局部最优与全局最优的问题。但是这和交付速度有什么关系呢?
不知大家有没有遇到这种情况。项目的 deadline 马上就要到了,还有很多功能没完成,然而却有人在给已经完成的功能调优。比如「那个控件在 Android 4.4 的垂直居中问题我调整了一早上」、「那个动画太生硬了,我调了一下贝塞尔曲线」等。
贝塞尔曲线
而且不光是在临近 deadline 时才会有这种现象,整个项目的开发过程中都充斥着这种现象,只是临近 deadline 时容易观察到。于是整体算下来,我们浪费了很多时间。
当然,每个人心中对事物的评分标准是不同的,不可能有统一的标准。比如你可能认为 60 分的产出必须没有那种垂直不居中的问题,而我可能认为这是可以容忍的。在一个团队内,大家的评分标准越接近,这个团队的契合度就越高,交付速度也会越快。
2.2. 关于「倒排期」
项目开发有个这样的守恒定律:
(时间, 资源, 质量) = 1
当资源固定时,我们能够掌控的只有时间和质量,根据实际项目需求,找到一个平衡点就行。
此处的「根据实际项目需求」有个非常典型的例子就是「倒排期」项目。正常的项目是资源固定,由开发人员来预估质量和时间。而所谓「倒排期」项目就是时间维度固定
所以「倒排期」项目对开发人员而言就是调整预期的质量以赶上交付时间。当质量维度无法再降低时,就需要动到资源维度,那可能就需要加班。
降低质量和加班都会造成其它负面影响。降低质量会导致那些真正追求品质为王的开发人员不愉快,而加班则会导致所有人不愉快。这也是为什么长期「倒排期」的团队离职率高的原因。
如果团队的人员变动频繁,团队的契合度又怎么能高?那么交付速度只会进入越来越低的恶性循环。
作为提需求的那一方也应该反思这一点。实际上很多到排期都是为了装逼给老板看的而已。不如干点实事?装逼误国,实干才能兴邦嘛。
3. 开发人员之间没有定义好职责与边界
3.1. 自测是本职工作
很多团队都存在这样的问题,联调需要的时间和开发需要的时间几乎一样。为什么?沟通有这么困难?
实际上这不是沟通的问题,是工作方式的问题。只要看看联调过程大家都在干什么就知道问题出在哪儿。
一个项目如果前端先开发完毕就会是这样:
前端:页面写好了,给个接口造点数据我试试
为什么不自己 Mock 数据给自己测,一定要等到联调?即便 Mock 数据,为什么只测主流程,分支和异常流程呢?
而如果是后端先开发完毕会变成这样:
后端:接口写好了,页面给我,我测一下
为什么不自己 curl 一下?为什么只看成功还是失败,不看里面的字段名和数据对不对?为什么不测一下异常?
然后到联调阶段就会这样:
前后端都没有充分自测,这个原本可以各自并行消化掉的时间被串行地叠加在联调阶段。
「闭门造车」这个词我想大家应该都很熟悉(一般是用来骂人的)。但那是断章取义的解释,完整的应该是「闭门造车,出门合辙」,意思是按照统一规格,即使关起门来制造车辆,使用起来也能和路上的车辙完全相合。说白了就是只要大家按照文档来,那就根本不需要联调。
3.2. 通过增加「适配层」的方式提升交付速度
但是「闭门造车,出门合辙」是一种理想状态,实际很难实现。不过还有一些其它方式也可以提高交付速度,比如我自己经常使用的增加「适配层」的方式。
这个「适配层」通常以拦截器的形式实现,可以放在前端也可以放在后端(根据团队的优势约定好)。并且这个「适配层」只处理数据结构的映射,没有业务逻辑,所以不需要花太多时间就能写完。
4. 总结