导语
作为一个中台的开发,我们会经常思考交付产品的过程,如何让我们自己交付的产品维持在一个比较高的品质。我们组在最近一段时间的项目实践中有了一些积累和心得,在这里做一个记录和回顾,希望能给到其他团队一些帮助和启发。
那么一个产品有那么多人员参加,谁来承担这个高质量交付呢?
一个大格局的答案当然是:“所有人”, 在项目中的每个人都应该对最终的交付品质负责,
但人人负责等于人人不负责,我们还是要去明确这个具体的分工。
虽然传统的团队即使技术研发只要做好自己的部分,也有其他成员保证交付质量,但是我们的团队也有自己的一些问题.
通常一个产品交付都要满足 用户 领导 自己 三个维度,大部分情况也是按照这样的顺序优先级以降,
但我们在实施过程中需要反过来,首先要做到要拔高自己的自我审视标准,
需要做到自己满意的时候,必然要覆盖领导和客户的诉求。
按时交付是任何一个项目第一诉求,但是项目延期也是很多项目制作过程中广泛遇到的困难。
计划赶不上变化,遇到各种突发情况,跳票也是每个开发人员一定会经历的噩梦。
这里放上这个logo,我什么都没说,但懂得自然懂
完成品质
这个品质主要讲的就是bug率,故障率,稳定性这些指标。通常这在实施过程中是可以由开发人员自行掌控的。
但即使一些成熟成功的团队,也会出现各种各样的BUG。
这里放上这个logo,我什么都没说,但懂得自然懂
我们的交付除了产品本身以外,信息的同步也是高质量交付的重要环节。这个信息包含了前期的诉求沟通以及后期的交付说明。
有的团队交付本身的产品没有什么问题,但是在说明文档,教学等环节做得不够好,也会让使用者有所困扰。
这里的配图是 艾尔登法环中的留言系统,一些语焉不详或者充满恶意的信息也会让玩家在游玩过程中哭笑不得。
产品是有自己的使用周期和迭代需求的,大部分产品也不是以第一次交付作为终点的。持续迭代,灵活拓展在产品的使用过程中也是必不可少的环节,这个时候,代码架构的设计,各种接口和逻辑的拓展性安排就至关重要。
这里放上经典游戏“上古卷轴”,他的mod扩展性给游戏提供了丰富的玩法
这里放上经典游戏“上古卷轴”,他的mod扩展性给游戏提供了丰富的玩法
我们可以按照主观感受和客观评价两个维度去回顾交付质量, 其中交流和问卷调查都是比较主观的,而数据埋点就是属于比较客观的。
针对数据埋点统计,制作一款好用的数据看板也是很有意义的
知道了我们要做到什么样程度才能算是一个高质量交付,我们接下来探讨如何对这个目标进行实践,这个部分也有我们自己在实际开发过程中遇到的困局和解法案例。
进度问题是任何一个项目管理都会遇到的难题,单独出来说也是一个很大的课题,但我这里主要从 规划,执行,调整三个方向分享我们实际操作过程中对进度管理的一点经验:
合理估算,预留缓冲 聚焦核心,会做减法
很多项目最终遇到进度问题,都和规划不合理有较大的关系。
盲目乐观和功能贪多也是最普遍遇到的问题。在这个阶段,做好buffer和优先级划定尤为重要。
紧密追踪,风险预警 全民动员,只争朝夕
这个阶段除了科学的手段,和主观态度的关系也很大。团队在全力以赴和摸鱼划水,自然在结果产出中会有很大差别,
充分调动大家的积极性和投入程度是执行阶段时刻需要关注的。
但是积极产出不代表盲目加班和死命内卷,仍然要劳逸结合,以输出效率作为第一评价要素。
而执行过程中对于进度同步,风险问题,一定要鼓励大家提早暴露。
不要害怕发现问题,比知道问题更可怕的是连问题在哪里都不知道。
“永远不变的是变化本身,
不出意外的话就一定会出现意外”
积极沟通,分清主次 心态谨慎,留有备案
制作过程中遇到各种变化,无论是需求调整,还是人员,资源 ,前置条件的意外都是有可能出现各种问题的。
任何意外发生,首先还是要和受付方达成沟通,去的理解,并重新划分优先级。
第二在安排的时候始终有Plan B,比如人员方面可以让通过互相穿插工作来形成人力备份等。
这个地方也可以参考我们制定OKR的思想,定一个一定能做到的目标,然后再定一个需要够一够才能打到的目标,
“求法其上,得法其中”,我们再往下一个更高目标努力的过程中,至少能先完成保底的目标,最终的结果也会坐落在下限和上限之间。如果一开始就以努力才能达到的目标作为自己的必须目标,一旦有了风吹草动,就没有腾挪空间。
我们把产品的质量拆分成这样几个维度:设计,编码,测试,体验
编码质量我们主要从代码规范和代码检查两个角度去保证
比如下图的几种方式就是在时间安排上递进的,可以根据自己项目的实际情况选择。
在技术研发这里,测试主要依靠自动化测试和开发者主观测试两种
体验的感受是一个很主观的问题,这个需要开发者有很强烈的自驱性去带入自己是使用者,思考这个事情的价值。
你只有认同了这个改进的价值点,才能做出更好的体验。
在我们的开发过程中,有一个下载速度的案例,就是我们在我们体验实际的使用场景,感觉到这个下载速度以及公司wifi的限速是一个非常困扰使用的瓶颈。最终下了很大的功夫,协同了很多部门人力,最终达到了一个比较理想的解决方案。
关于信息同步,我们也可以套用经典的“事前” “事中” "事后“ 的方法论,分别从各个阶段来理解一个好的产品交付需要做到信息的同步。
我们在实施过程中,我们深圳团队的产品同学表现出了很强的专业沟通能力,这个部分的成效业主要是产品同学的成果。
这里的记录更多是给技术同学一个学习的榜样。
我们产品部门的同事,在启动这个项目之前,针对需求做了数百小时的调研任务,一次次出差和驻场,深入了解项目组真正的痛点和流程,这个信息的获取和同步,也是项目能成功的关键点。
中期过程中,我们大家通过例会,周报,阶段性showcase等方式,要确保和项目组保持信息的对等和同步。
这个同步内容既包含进度,完成情况,也包含风险和变动。
同时一些需求方面的调整,也会在这个阶段充分交换意见。
在最终的交付中,我们提供了完备的使用说明,示例场景,介绍视频等内容,确保使用者能够开箱即用,迅速上手。
我们技术人员自己在体验别人产品的时候,对于文档,教学这块通常也是比较敏感的。那么自己在交付的时候也必须要好这一块。
各个阶段的信息同步形态和文档:
面对需求的变动,功能的拓展,很多开发人员都会天然抗拒和抵触,这个也是很正常的
但我也都知道,一个好的产品是需要不断打磨完善的,所以一些拓展和变化也是必然会发生的。
我觉得在这个点上我们可以按照以下方法和原则:
用户或者策划的一些设计,我们要从底层逻辑去思考它的根本目的和诉求是什么,
我们能不能用更便捷有效的方式帮他们解决问题,在这个环节上,我们是有变通的空间的。
我很喜欢在自己开发的时候给自己一个定位:“甲方程序员”
与其被别人批判,不如自己先批判自己,自己给自己找茬挑刺。
如果自己下手太轻,还可以让小组小团队一起来。我们目前组里的很多产品,都是这样让同事相互帮着找问题,提建议,缺失可以很大程度提高交付出去的结果。
作为开发者,很多时候的视角和使用者是不同的,
但是很多时候,我们还是需要把自己带入别人的视角,从用户的角度去思考, 去发掘问题
这样我们面对拓展和需求,也就有更提前的准备。
在秉承高质量交付的态度去开发整个产品,也为我们最终的产品交付打下了良好的基础。
除了Bug少,不奔溃等常规成果以外,我们在落地的项目组也取得了一些额外的价值收益。
由于在交付的前期就做了比较充足的准备,在最终验收的环节进行的非常的快。
而这个产品在做好交付质量的基础上,我们又切实解决了一些用户痛点之后,整个产品在项目组的使用和推广也进行的非常顺利。很快就把既定的用户人员基本覆盖,而一些其他相关的人员也跃跃欲试,希望我们能提供支持他们工种的版本。
我们的产品在A项目落地之后,有隔壁的B项目组看到之后,也很感兴趣地让A项目做了详细的介绍,
在后续的调研中,我们充分准备的wiki内容也让B项目组很快了解到我们产品的价值和专业性,
之后的合作也就是顺利成章的结果。
除了之前交付的作品之后,项目组后续的一些小功能开发,也会第一时间想到我们。
虽然也不是特别大的工程,但是也让我们作为开发受宠若惊。
尤其是A项目组也是公司头部的项目,团队自身也有着非常多优秀的开发人员,
得到这些专业人士的信任对我们来说缺失是很大的鼓励。
--
高质量交付是一个长期持续在项目开发中的课题,文中说的一些方法论大部分都是在我们团队摸索和实践过的,也取得了一定的正面的效果。但我们也认识到自己有很多方面还有提高空间,在后续的工作中还需要持续总结和提高。
原创声明,本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。