这几天有位产品咨询我:同一个功能随着版本更新,如何追踪它的迭代内容,用于后续回顾、参考和复盘?
我针对他的问题,根据个人经验和方法,简单进行了回答。
想起我刚做产品时,其实也被这个问题困扰了很久,后来随着项目积累、工作总结,问题也就随之解决了。
最近我重新梳理了回答内容,功能维护要想做的好,主要涉及 3 个方面:需求池管理、需求文档、版本日志。
希望能帮到同样被问题困扰的你。
需求池管理
在项目的版本迭代中,主要有这 3 种类型:新功能版本、优化修复版本、混合版本。
涉及新功能的版本,我一般会通过文档驱动迭代。
而一些体验优化、 BUG 修复的版本,则会在需求池中,抽取多个小需求打包成一个版本,并提交到类似 Jira、禅道等团队协作工具中,进行版本快速迭代。
假设既有新功能,又有优化修复的内容,那么就把这两种方式进行混合,去驱动版本迭代。
如果按这个产品工作流程,去管理系统版本的话,一旦遇到了上述产品童鞋的类似问题,就可以通过查看指定文档,或在需求池中,复查平台、版本号、功能模块等维度,去追溯指定功能的更新内容了。
需求文档
作为资深的产品老油条,文档撰写 500+ 起,版本迭代更是数不胜数。
一打开几年前自己写的东西,也会忍不住吐槽,这人文档写的真 TM 水。
回顾这 6 年的产品生涯,我在撰写需求文档中踩过 3 大坑,总结一下避免后人继续摸黑踩坑。
它们分别是:文档命名问题、文档更新问题、文档划分问题。
文档命名问题
我记得一开始的需求文档命名,都比较随意,一般是日期 + 系统 + 版本。
随着文档数量增多,很多几年前的旧功能文档,已经记不清放在哪个文件夹了。
临时去找的时候,真是耗时又费劲。
为了解决这个问题,我后续花了几天时间,把用到的几百个文档,都统一按这个格式去命名:日期 + 系统 + 版本 + 更新内容。
例如:20241108-XX 后台 V1.6(积分任务、积分商城)。
这样做的好处是,通过类似 Listary 等效率工具搜索文件,几秒内即可定位对应功能的相关文档。
以后再也不怕文档找不到啦~
文档更新问题
我刚做产品那会,很快就遇到了文档相关的版本迭代问题。
我意识到,每个版本都应该独立创建一个文档,进行单独的管理维护。
但因为当时经验不足,总是为了图省事,把 2-5 个版本内容,都写在同一个文档中。
甚至还试过把同一个功能,迭代时间较近的新旧更新内容,也写在了一起。
这样做的坏处是,当我进行版本回顾、数据分析时,完全无法对比新旧版本的功能差异。
现在看来,其实当时的我,是犯了文档过于耦合的问题。
正确的做法,应该是拆分解耦,以提高文档的独立性、复用性。
文档划分问题
文档划分问题指的是,把用户端和后台的更新内容,都写在一个文档中。
这样做的缺点是,由于文档内容过多,一方面容易撰写耗时过长,另一方面会让开发理解成本过高。
从而导致版本迭代效率太低,无法灵活应变紧急排期。
我的经验是,一个文档最多涉及单平台的一个大功能和若干小需求。
当版本的颗粒度控制好后,版本迭代就能随时进行排列组合了。
并且由于文档划分清晰,后续查找某个功能相关文档,也更加方便快捷了。
版本日志
初级产品经常接触的工作之一,一定是版本日志撰写了。
一个清晰详细的版本日志,不仅能方便业务方确认需求落地情况,还能让研发团队明确当前版本的更新内容。
最重要的是,一旦进行版本迭代和项目重构,亦或团队面临重组时,那么一个对项目不太熟悉的产品经理,去迭代某个相关功能,就能按图索骥去搜索功能名称,找到对应的版本日志内容,以作方案设计参考。
记得我刚做产品那会,写版本日志就遇到了几个大坑。
我试过把版本日志写在需求文档的某一页,然后随着文档的更新叠加,继续在新文档中记录版本更新内容。
这样查找、协作麻烦不说,不同新旧文档的日志内容还不一致,简直难搞。
我还试过一阵用 Excel 去写,效果也不大理想。
随着手上项目增加到十几个,这些办法都不管用了。
为了方便管理,我用了类似飞书的协同文档,给每个系统都专门开了一个版本日志页,这下整个人都舒适了。
后来随着 AI 兴起,像这种简单枯燥的工作,我也试着让团队产品,去用 AI 自动化撰写日志了。
总结
功能更新太频繁,如何才能科学管理迭代逻辑?
我的经验是,可以从需求池管理、需求文档、版本日志这三个方面去努力。
需求池管理:建立可溯源的需求池和版本,以此驱动项目迭代;
需求文档:撰写需求文档时,注意避免文档命名、文档更新、文档划分等问题;
版本日志:团队详细记录版本更新内容,便于留存备份和随时参考。
看完觉得写得好的,不防打赏一元,以支持蓝海情报网揭秘更多好的项目。