导语

作为一个中台的开发，我们会经常思考交付产品的过程，如何让我们自己交付的产品维持在一个比较高的品质。我们组在最近一段时间的项目实践中有了一些积累和心得，在这里做一个记录和回顾，希望能给到其他团队一些帮助和启发。

1 背景

1.1 为什么需要高质量交付

• 对于受付方：需要拿到一个符合自己预期的产品，这个产品解决自己实际的问题的过程中可以顺畅使用。 做过甲方的同学都会或多或少有这样的体会，即便自己已经描述的很清楚，对方做出来的东西往往也还是有很多不如人意的地方。即便有一些条条框框的约束，在一些体验细节上，还是会和自己想要的有所偏差。
• 对于交付方：在自己产品落地的过程中保持信心，并收获正面的反馈和评价。 做过服务器开发的同学或许都有相关的经验，在上线一个产品的时候都是非常紧张和焦虑的，担心不知道哪个环节就会出问题, 失眠和头痛也是经常会发生。

1.2 谁来做高质量交付

那么一个产品有那么多人员参加，谁来承担这个高质量交付呢？

一个大格局的答案当然是：“所有人”， 在项目中的每个人都应该对最终的交付品质负责，

但人人负责等于人人不负责，我们还是要去明确这个具体的分工。

常规方式

• QA：最正统，最重要的项目质量把关人员，项目交付环节的最后一道闸门；
• 产品经理：这个角色会在更全局的角度去把控交付质量，通常也是和目标客户沟通最多，最能把握方向的人；
• 策划设计：和产品经理类似，策划人员是最了解设计意图，设计细节的人员，在体验方面也是最有权威性

虽然传统的团队即使技术研发只要做好自己的部分，也有其他成员保证交付质量，但是我们的团队也有自己的一些问题.

我们团队遇到的问题

• 保密项目: 除了开发团队其他QA同事无法获得对应权限，所有的质量把关和测试只能在很小的范围内实施 。
• 异地配合: 项目组，产品同学和我们研发团队都不在一个城市，沟通配合有很多困难，需要各个环节高度自治的同时保持信息通畅。
• 居家办公: 我们上海团队也因为疫情，长时间没有办法一起办公，这对最终的产出结果更为不利。 基于这些问题，我们也在思考如何从技术研发本身出发，去做好高质量交付这个事。

技术研发的高质量交付

• 充分发自驱性，做好自己的技术研发工作的基础上，站到更高的角度去看待自己手上的产品；
• 可以寻求外部配合，但不简单依赖外部力量，在自己的研发内部形成质量把控的闭环；
• 换位思考，多从使用者，其他职能的角度去思考，而不只是给自己划定的框架里面自我设限。

2 衡量标准

2.1 什么样的产品交付算是一个好的交付

• 用户满意：用户达到了使用预期
• 领导满意：满足部门的战略目标
• 自己满意：对自己交付充满信心

通常一个产品交付都要满足 用户 领导 自己 三个维度，大部分情况也是按照这样的顺序优先级以降，

但我们在实施过程中需要反过来，首先要做到要拔高自己的自我审视标准，

需要做到自己满意的时候，必然要覆盖领导和客户的诉求。

2.2 交付质量的几个维度

交付时效

按时交付是任何一个项目第一诉求，但是项目延期也是很多项目制作过程中广泛遇到的困难。

计划赶不上变化，遇到各种突发情况，跳票也是每个开发人员一定会经历的噩梦。

这里放上这个logo，我什么都没说，但懂得自然懂

完成品质

这个品质主要讲的就是bug率，故障率，稳定性这些指标。通常这在实施过程中是可以由开发人员自行掌控的。

但即使一些成熟成功的团队，也会出现各种各样的BUG。

这里放上这个logo，我什么都没说，但懂得自然懂

信息同步

我们的交付除了产品本身以外，信息的同步也是高质量交付的重要环节。这个信息包含了前期的诉求沟通以及后期的交付说明。

有的团队交付本身的产品没有什么问题，但是在说明文档，教学等环节做得不够好，也会让使用者有所困扰。

这里的配图是 艾尔登法环中的留言系统，一些语焉不详或者充满恶意的信息也会让玩家在游玩过程中哭笑不得。

灵活拓展

产品是有自己的使用周期和迭代需求的，大部分产品也不是以第一次交付作为终点的。持续迭代，灵活拓展在产品的使用过程中也是必不可少的环节，这个时候，代码架构的设计，各种接口和逻辑的拓展性安排就至关重要。

这里放上经典游戏“上古卷轴”，他的mod扩展性给游戏提供了丰富的玩法

这里放上经典游戏“上古卷轴”，他的mod扩展性给游戏提供了丰富的玩法

2.3 回顾交付质量的方法

• 相关人员交流
• 问卷调查
• 数据埋点统计

我们可以按照主观感受和客观评价两个维度去回顾交付质量, 其中交流和问卷调查都是比较主观的，而数据埋点就是属于比较客观的。

针对数据埋点统计，制作一款好用的数据看板也是很有意义的

3 实践路径

知道了我们要做到什么样程度才能算是一个高质量交付，我们接下来探讨如何对这个目标进行实践，这个部分也有我们自己在实际开发过程中遇到的困局和解法案例。

3.1 关于进度和时效

进度问题是任何一个项目管理都会遇到的难题，单独出来说也是一个很大的课题，但我这里主要从 规划，执行，调整三个方向分享我们实际操作过程中对进度管理的一点经验：

规划阶段

合理估算，预留缓冲 聚焦核心，会做减法

很多项目最终遇到进度问题，都和规划不合理有较大的关系。

盲目乐观和功能贪多也是最普遍遇到的问题。在这个阶段，做好buffer和优先级划定尤为重要。

执行阶段

紧密追踪，风险预警 全民动员，只争朝夕

这个阶段除了科学的手段，和主观态度的关系也很大。团队在全力以赴和摸鱼划水，自然在结果产出中会有很大差别，

充分调动大家的积极性和投入程度是执行阶段时刻需要关注的。

但是积极产出不代表盲目加班和死命内卷，仍然要劳逸结合，以输出效率作为第一评价要素。

而执行过程中对于进度同步，风险问题，一定要鼓励大家提早暴露。

不要害怕发现问题，比知道问题更可怕的是连问题在哪里都不知道。

调整过程

“永远不变的是变化本身，

不出意外的话就一定会出现意外”

积极沟通，分清主次 心态谨慎，留有备案

制作过程中遇到各种变化，无论是需求调整，还是人员，资源 ，前置条件的意外都是有可能出现各种问题的。

任何意外发生，首先还是要和受付方达成沟通，去的理解，并重新划分优先级。

第二在安排的时候始终有Plan B，比如人员方面可以让通过互相穿插工作来形成人力备份等。

这个地方也可以参考我们制定OKR的思想，定一个一定能做到的目标，然后再定一个需要够一够才能打到的目标，

“求法其上，得法其中”，我们再往下一个更高目标努力的过程中，至少能先完成保底的目标，最终的结果也会坐落在下限和上限之间。如果一开始就以努力才能达到的目标作为自己的必须目标，一旦有了风吹草动，就没有腾挪空间。

3.2 关于产品的质量

我们把产品的质量拆分成这样几个维度：设计，编码，测试，体验

设计质量

• 技术设计文档 作为技术研发，我很希望大家做好技术设计文档，虽然书写这样的文档费时费力，但是可以让你更好地在编码之前把各种问题想清楚。也可以把你的想法更好地传递着给其他同事和需求方。
• 方案评审 我前几天听了组内的一个分享，关于技术评审的，里面有一句话我印象和深刻： 方案评审是帮助被评审人更好地完善自己的设计 我们任何一个人的能力和认知都是由缺陷的，所以我们需要其他人帮助我们来补完自己的短板。

编码质量

编码质量我们主要从代码规范和代码检查两个角度去保证

•  代码规范 这个基本上每个腾讯的程序员都在日常工作中需要遵守和遵循的。 我们也可以借助一些工具帮助我们做到。 比如 我们在写JS的时候，就可以使用eslint的插件， 在提交之后也可以加上codecc来进行检查。
•  Code Review 代码检查的价值不只在于项目本身，更大的价值在于帮助程序员成长，从人的角度提高代码能力 解决”渔“的问题而不是”鱼“的问题。 有时候团队会因为项目进度问题，没有积极或者严格地进行code review，这个也是可以理解的, 但我们可以用一些更灵活的方式找到适合自己的review方法。

比如下图的几种方式就是在时间安排上递进的，可以根据自己项目的实际情况选择。

测试质量

在技术研发这里，测试主要依靠自动化测试和开发者主观测试两种

• 自动化测试 我们需要在项目开发的前期就规划好各种自动化测试，来保证整个项目的一些基础能力被验证
• 开发者测试 开发者的主观测试仍然是很必要的，除了我们基础的单点测试，测试用例覆盖，我们的体验测试也是非常的重要。 开发者需要由足够的责任心去把控测试的效果.

体验质量

体验的感受是一个很主观的问题，这个需要开发者有很强烈的自驱性去带入自己是使用者，思考这个事情的价值。

你只有认同了这个改进的价值点，才能做出更好的体验。

在我们的开发过程中，有一个下载速度的案例，就是我们在我们体验实际的使用场景，感觉到这个下载速度以及公司wifi的限速是一个非常困扰使用的瓶颈。最终下了很大的功夫，协同了很多部门人力，最终达到了一个比较理想的解决方案。

3.3 关于信息的同步

关于信息同步，我们也可以套用经典的“事前” “事中” "事后“ 的方法论，分别从各个阶段来理解一个好的产品交付需要做到信息的同步。

我们在实施过程中，我们深圳团队的产品同学表现出了很强的专业沟通能力，这个部分的成效业主要是产品同学的成果。

这里的记录更多是给技术同学一个学习的榜样。

前期调研

我们产品部门的同事，在启动这个项目之前，针对需求做了数百小时的调研任务，一次次出差和驻场，深入了解项目组真正的痛点和流程，这个信息的获取和同步，也是项目能成功的关键点。

过程同步

中期过程中，我们大家通过例会，周报，阶段性showcase等方式，要确保和项目组保持信息的对等和同步。

这个同步内容既包含进度，完成情况，也包含风险和变动。

同时一些需求方面的调整，也会在这个阶段充分交换意见。

交付输出

在最终的交付中，我们提供了完备的使用说明，示例场景，介绍视频等内容，确保使用者能够开箱即用，迅速上手。

我们技术人员自己在体验别人产品的时候，对于文档，教学这块通常也是比较敏感的。那么自己在交付的时候也必须要好这一块。

各个阶段的信息同步形态和文档：

3.4 关于功能的拓展

面对需求的变动，功能的拓展，很多开发人员都会天然抗拒和抵触，这个也是很正常的

但我也都知道，一个好的产品是需要不断打磨完善的，所以一些拓展和变化也是必然会发生的。

我觉得在这个点上我们可以按照以下方法和原则：

遵从需求，但不盲从设计

用户或者策划的一些设计，我们要从底层逻辑去思考它的根本目的和诉求是什么，

我们能不能用更便捷有效的方式帮他们解决问题，在这个环节上，我们是有变通的空间的。

自我拷问，内部完善能力

我很喜欢在自己开发的时候给自己一个定位：“甲方程序员”

与其被别人批判，不如自己先批判自己，自己给自己找茬挑刺。

如果自己下手太轻，还可以让小组小团队一起来。我们目前组里的很多产品，都是这样让同事相互帮着找问题，提建议，缺失可以很大程度提高交付出去的结果。

换位思考，提前发现问题

作为开发者，很多时候的视角和使用者是不同的，

但是很多时候，我们还是需要把自己带入别人的视角，从用户的角度去思考, 去发掘问题

这样我们面对拓展和需求，也就有更提前的准备。

4 价值收效

在秉承高质量交付的态度去开发整个产品，也为我们最终的产品交付打下了良好的基础。

除了Bug少，不奔溃等常规成果以外，我们在落地的项目组也取得了一些额外的价值收益。

4.1 产品落地

由于在交付的前期就做了比较充足的准备，在最终验收的环节进行的非常的快。

而这个产品在做好交付质量的基础上，我们又切实解决了一些用户痛点之后，整个产品在项目组的使用和推广也进行的非常顺利。很快就把既定的用户人员基本覆盖，而一些其他相关的人员也跃跃欲试，希望我们能提供支持他们工种的版本。

4.2 口碑传播

我们的产品在A项目落地之后，有隔壁的B项目组看到之后，也很感兴趣地让A项目做了详细的介绍，

在后续的调研中，我们充分准备的wiki内容也让B项目组很快了解到我们产品的价值和专业性，

之后的合作也就是顺利成章的结果。

4.3 后续合作

除了之前交付的作品之后，项目组后续的一些小功能开发，也会第一时间想到我们。

虽然也不是特别大的工程，但是也让我们作为开发受宠若惊。

尤其是A项目组也是公司头部的项目，团队自身也有着非常多优秀的开发人员，

得到这些专业人士的信任对我们来说缺失是很大的鼓励。

5 总结

--

高质量交付是一个长期持续在项目开发中的课题，文中说的一些方法论大部分都是在我们团队摸索和实践过的，也取得了一定的正面的效果。但我们也认识到自己有很多方面还有提高空间，在后续的工作中还需要持续总结和提高。

原创声明，本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

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