前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >影响团队交付速度的那些问题

影响团队交付速度的那些问题

作者头像
用户1687375
发布2018-06-08 12:24:05
9710
发布2018-06-08 12:24:05
举报
文章被收录于专栏:较真的前端较真的前端

本文首发于饿了么前端——知乎专栏

在此感谢知乎用户——次碳酸钴 为大家贡献如此优秀的文章。

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. 通过增加「适配层」的方式提升交付速度

但是「闭门造车,出门合辙」是一种理想状态,实际很难实现。不过还有一些其它方式也可以提高交付速度,比如我自己经常使用的增加「适配层」的方式。

  1. 在开发前,根据业务需求把其中需要数据交互的部分列出来。
  2. 后端的工作是提供这些数据,无论什么形式什么字段名,怎么顺手怎么来。
  3. 前端的工作是 Mock 一套自己喜欢的接口来实现业务,也是怎么顺手怎么来。
  4. 前后端都提供自己使用的接口文档,这样开发的部分就结束了。
  5. 剩余的就是增加一个「适配层」,这一层的职责是把两边的接口映射处理好。

这个「适配层」通常以拦截器的形式实现,可以放在前端也可以放在后端(根据团队的优势约定好)。并且这个「适配层」只处理数据结构的映射,没有业务逻辑,所以不需要花太多时间就能写完。

4. 总结

  • 先思考能不能用现有资源直接解决问题,避免写代码。
  • 对质量认知标准的统一性会影响团队交付速度。
  • 「倒排期」是一种透支团队的消耗品,请慎用。
  • 所谓的联调,就是因为自己自测不充分给别人添麻烦。
  • 不妨试试其它工作方式?
本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-02-26,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 较真的前端 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档