交付是一种基本的态度

前言

在很早以前看过一篇有点心灵鸡汤的文章,文章标题是《月入 3 千和月入 3 万有什么区别》,文章的具体内容不太记得了。特地去百度了一下,有了最新的微信截图版,内容差不多,如下:

同样,看另外一个案例:

有两位行政助理接到领导任务,要买3张次日去北京的动车票,以参加展会。
这两位行政助理查了车次,发现没票。

第一位行政处理直接回复领导说,太晚了,目前没票,只能再刷刷,看看后续有没有票放出来。

第二位行政处理找到领导,说明情况后,提出4个备选方案。

方案1: 用抢票软件继续刷票,同时找票贩子加价,大概每张加价100元,下午应该能拿到。

方案2:换个地点倒车,可以买到票,但时间会多出4个小时,价格每人多200元。

方案3:改乘飞机,每个人会多800元,但时间能缩短1个小时。

方案4:包车过去,总体会贵1000元,时间会多出4个小时。

先不说是否标题党,是否杜撰的,从需求方的角度来看,是不是都会喜欢第二个人一些。为什么呢?

因为他们多做了一步或者两步,多想了一些,让事情和结果更完整。

什么是交付能力

这就是我们要说的交付能力。 所谓交付能力,就是指能提供具有可用性、完整性成果的能力。一个人的职场价值,很大程度上由交付能力所决定。

从我们的实际工作中来看也有存在没有完整交付的情况,通常其表象是需求模糊,信息未对齐、沟通效率低、质量不高造成返工等等。

原因客观分析有很多,但是归根到底还是人的问题,人的意识问题和态度问题。我们做一件事情,要有头有尾,头一般都有,但尾不一定,而且大家对于这个尾的定义不一样,这就是我们这里要说的结果,要说的交付。

对于一个开发同学,一件事情的交付绝不仅仅是把代码写完。在代码高质量的基础上,完成多场景的自测,多次的 Code Review,完善的文档,对性能的评估,对安全的评估;在完成以上这些后提交给联调的同学,积极主动的解决联调中的问题,再一起完成提交给 QA同学,积极的解决反馈的 BUG,上线的时候一起值守,持续观察线上日志,完全没有问题就告一段落;上线后看有没有相关告警,关注业务的数据,等数据出来,再次迭代,这才叫完整的交付。

研发各端交付标准

研发各端具体交付要求如下:

后端交付标准

对于后端同学,稳定靠谱是基本要求,后端完整的交付包括:

  1. 优雅的架构设计和编码;
  2. 完善的设计文档和接口文档;
  3. 完整且可快速 MOCK 的接口协议;
  4. 多场景的自测和多次的 Code Review;
  5. 性能 / 安全等非功能性的评估;
  6. 积极主动的联调配合和问题解决;
  7. 上线过程各环节的推进和关注;
  8. 关注线上问题及业务数据。

前端和移动端交付标准

对于前端和移动端同学,界面还原和更好的产品 sense 是基本的要求,其完整的交付包括:

  1. 优雅的架构设计和编码;
  2. 完善的设计文档;
  3. 高保真的界面还原;
  4. 多场景的自测和多次的 Code Review;
  5. 界面性能 / 系统安全等非功能性的评估;
  6. 积极主动的联调和问题跟进;
  7. 上线过程各环节的推进和关注;
  8. 关注线上问题及业务数据。

QA 交付标准

对于 QA 同学,虽然现阶段不涉及业务的开发,但其交付的重要度会更重一些,因为 QA 同学的交付对象是用户,是我们研发侧最后的一道防线。QA 同学的交付包括:

  1. 比产品和开发更熟悉整体业务流程;
  2. 输出完整而全面的测试用例文档;
  3. 积极主动的跟进测试中的问题,严格要求质量,确保需求达到上线的要求;
  4. 跟进上线发布流程,线上回归,确保主线路和当前需求正常;
  5. 有理有据的测试报告,对过程中的问题进行回顾,并下次迭代;
  6. 对线上问题敏感,归档记录线上的问题,跟进到解决。

总结

最后,在高质量高效完成需求的基础上,思考当前模块有什么问题,技术上可以做一些什么改进,提升工作的质量和效率,当出了一个问题后,能够快速定位问题,解决问题,并为后续规避此类问题提出系统性的解决方案,这是更高一级的交付,我们称之为掌控

发表评论

电子邮件地址不会被公开。 必填项已用*标注


*

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>