前言
在很早以前看过一篇有点心灵鸡汤的文章，文章标题是《月入 3 千和月入 3 万有什么区别》，文章的具体内容不太记得了。特地去百度了一下，有了最新的微信截图版，内容差不多，如下：
同样，看另外一个案例：
有两位行政助理接到领导任务，要买3张次日去北京的动车票，以参加展会。
这两位行政助理查了车次，发现没票。
第一位行政处理直接回复领导说，太晚了，目前没票，只能再刷刷，看看后续有没有票放出来。
第二位行政处理找到领导，说明情况后，提出4个备选方案。
方案1: 用抢票软件继续刷票，同时找票贩子加价，大概每张加价100元，下午应该能拿到。
方案2：换个地点倒车，可以买到票，但时间会多出4个小时，价格每人多200元。
方案3：改乘飞机，每个人会多800元，但时间能缩短1个小时。
方案4：包车过去，总体会贵1000元，时间会多出4个小时。
先不说是否标题党，是否杜撰的，从需求方的角度来看，是不是都会喜欢第二个人一些。为什么呢？
因为他们多做了一步或者两步，多想了一些，让事情和结果更完整。
什么是交付能力
这就是我们要说的交付能力。 所谓交付能力，就是指能提供具有可用性、完整性成果的能力。一个人的职场价值，很大程度上由交付能力所决定。
从我们的实际工作中来看也有存在没有完整交付的情况，通常其表象是需求模糊，信息未对齐、沟通效率低、质量不高造成返工等等。
原因客观分析有很多，但是归根到底还是人的问题，人的意识问题和态度问题。我们做一件事情，要有头有尾，头一般都有，但尾不一定，而且大家对于这个尾的定义不一样，这就是我们这里要说的结果，要说的交付。
对于一个开发同学，一件事情的交付绝不仅仅是把代码写完。在代码高质量的基础上，完成多场景的自测，多次的 Code Review，完善的文档，对性能的评估，对安全的评估；在完成以上这些后提交给联调的同学，积极主动的解决联调中的问题，再一起完成提交给 QA同学，积极的解决反馈的 BUG，上线的时候一起值守，持续观察线上日志，完全没有问题就告一段落；上线后看有没有相关告警，关注业务的数据，等数据出来，再次迭代，这才叫完整的交付。
研发各端交付标准
研发各端具体交付要求如下：
后端交付标准
对于后端同学，稳定靠谱是基本要求，后端完整的交付包括：
- 优雅的架构设计和编码；
- 完善的设计文档和接口文档；
- 完整且可快速 MOCK 的接口协议；
- 多场景的自测和多次的 Code Review；
- 性能 / 安全等非功能性的评估；
- 积极主动的联调配合和问题解决；
- 上线过程各环节的推进和关注；
- 关注线上问题及业务数据。
前端和移动端交付标准
对于前端和移动端同学，界面还原和更好的产品 sense 是基本的要求，其完整的交付包括：
- 优雅的架构设计和编码；
- 完善的设计文档；
- 高保真的界面还原；
- 多场景的自测和多次的 Code Review；
- 界面性能 / 系统安全等非功能性的评估；
- 积极主动的联调和问题跟进；
- 上线过程各环节的推进和关注；
- 关注线上问题及业务数据。
QA 交付标准
对于 QA 同学，虽然现阶段不涉及业务的开发，但其交付的重要度会更重一些，因为 QA 同学的交付对象是用户，是我们研发侧最后的一道防线。QA 同学的交付包括：
- 比产品和开发更熟悉整体业务流程；
- 输出完整而全面的测试用例文档；
- 积极主动的跟进测试中的问题，严格要求质量，确保需求达到上线的要求；
- 跟进上线发布流程，线上回归，确保主线路和当前需求正常；
- 有理有据的测试报告，对过程中的问题进行回顾，并下次迭代；
- 对线上问题敏感，归档记录线上的问题，跟进到解决。
总结
最后，在高质量高效完成需求的基础上，思考当前模块有什么问题，技术上可以做一些什么改进，提升工作的质量和效率，当出了一个问题后，能够快速定位问题，解决问题，并为后续规避此类问题提出系统性的解决方案，这是更高一级的交付，我们称之为掌控。