你好,我是小树。这是我为你写的第 106 封信。每期都会同步更新在微信公众号一颗小树。
我曾经在高质量的需求交付聊过我推崇的需求交付方法论,但仅仅有方法还不能很好落地,每一套方法论都应该有配套的工具,来帮助我们尽可能减少重复工作,高效达成目标。
我目前的主要工作就是一名钉钉多维表的研发,自然而然地萌生了用它来实践需求研发工作流的想法。
首先,简单介绍一下我日常的工作流:
- 由产品经理产出需求文档
- 由设计师产出设计稿
- 由我(前端)和服务端同学配合完成功能开发
- 由产品经理和设计师完成验收,修复验收问题
- 由测试同学完成功能测试
- 跟随团队的发布周期,择期上线
为了保证需求理解到位和技术方案完备,我会在多维表格中新建一篇名为 RFC(征求意见)的说明文档,用来承载开发前的需求评估、需求拆解和测试用例等环节。文档本身是一种非常灵活的表现形式,所有和需求相关的过程和内容,都可以在这篇文档中承载,以方便协作方查看和批注。
在明确方案之后,我会将实际要做的事情进一步细化为任务,方便跟进进度,能够做到心中有数。
借助看板视图,可以更直观的关注任务的关键信息和进展。
借助开发进展仪表盘,可以实现自定义数据指标的可视化展示,直观地关注到需求的进度全貌。
开发完成之后,为了保障产品/设计验收时的功能质量,我会按照 RFC 中梳理的测试用例先进行一轮自测,预先完成明显问题的修复。
自测和问题修复之后,就进入到了产品和设计验收环节。
和 RFC 文档类似,我会通过验收文档,来补充验收时必要的信息说明。
为了方便填写验收过程中发现的问题,可以借助表单来完成数据的收集。
所有验收问题和测试中发现的问题处理完成之后,功能就可以准备上线了。 如果涉及多方协作或是发布过程较为复杂,可以再通过发布 Checklist 梳理依赖项,确保发布过程有条不紊地进行。
以上就是我用钉钉多维表实现的整个研发工作流。
多维表格能够非常方便地帮我实现个性化的小型业务系统。在这个场景中,所有的功能设计都是完全贴合我的需要,并且能够很方便地进行调整。
同时,一个需求完整的过程信息都沉淀在了同一个多维表中,如果需要回溯数据会很方便,对于公司和自己的团队中也是一份宝贵的历史数据资产。
若有对多维表格感兴趣,或是需要提供多维表解决方案的朋友,可以在公众号后台找到我的微信联系方式,欢迎交流讨论。
谢谢你的关注,我们下期再见。👋🏻
往期推荐
你也可以在这里找到我:即刻、Twitter、微信公众号一颗小树。
如果你觉得这篇文章对你有用,欢迎分享给更多好友。