交付是一种基本的态度

前言

在很早以前看过一篇有点心灵鸡汤的文章，文章标题是《月入 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. 对线上问题敏感，归档记录线上的问题，跟进到解决。

总结

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