关于需求管理文档和产品经理的脚手架思维

3 评论 17314 浏览 97 收藏 8 分钟

今天和大家分享的文章主题是:关于需求管理文档和产品经理的脚手架思维。顾名思义文章分为两个部分:第一部分分享一个重要的需求管理文档模板;第二个部分介绍一种在工作和学习过程中一种很重要的思维方式:脚手架思维。

一、关于项目管理过程中一个重要的文档

好用的工具和规范的文档让我们所有的需求、计划、目标以及问题都可视化的罗列,有序的处理和解决。

之前的两篇文章《产品设计规范与关乎“秩序和混乱”的人生算法 》&《基于Axure的移动端APP产品设计规范 》主要分享了关于Axure 的工具使用规范。今天分享的是项目需求管理过程中一个重要的文档:需求管理文档

1.需求管理文档

需求管理文档的目的是明确项目进行过程中各个阶段的任务安排和研发周期,能让产品研发过程中的每个角色明确自己的任务以及时间安排,同时方便产品经理把控项目整体的宏观进度。如下图是两种适合不同研发流程的需求管理文档。

  • 第一种模板比较适合大公司的产品研发流程:需求设计→需求评审→UI设计/技术开发→产品测试→测试验收→产品上线,每一个环节都有明确的负责人和执行者以及任务的计划时间。
  • 第二种模板比较灵活,产品研发流程中,需要哪个模块增加哪个模块,不需要的可以折叠或者删除。

所谓模板&工具最大的意义是提高我们的工作效率,以上提供的两种需求管理文档模板,大家可以根据自己日常工作中的实际需求去修改调整成适合自己的,适合的才是最好的。

二、产品经理的脚手架思维

之前的公司产品团队比较大,产品研发遵循典型的瀑布型研发流程。很多时候在业务逻辑产品化的过程中,产品存在的问题都会在评审会上被其它产品经理和相关部门同事纠正,到真正开发的时候,基本不会出现太大的问题。但后来去了创业公司,一个人来设计产品,没有标准的评审会去审视你的设计和逻辑,很多问题往往都是在已经开发的过程中暴露的,程序猿无奈,自己也很无奈。

业务逻辑产品化的核心部分是:形成业务逻辑的闭环。 在业务逻辑复杂的产品设计过程中,个人的思考往往很难穷尽所有的逻辑闭环。

原因是当我们思考业务逻辑的时候,思维往往是发散的(想到什么就先确定是什么,然后在拼接成闭环),这样思考方式难免会存在遗漏的地方。

所以我们需要一套思考的规范,用规范来弥补大脑本身的缺陷,尽可能的帮助我们穷尽所有的业务逻辑形成闭环,这样的“思考规范”可以称之为“思维的脚手架”。

1.穷尽业务逻辑闭环的思维脚手架:

1)拆分功能模块—实现模块功能闭环:

将一个大的业务需求拆分成若干个明确的功能模块,保证每个功能模块形成最小的模块功能闭环。当然一些功能模块独立闭环,有的需要多个功能模块共同形成逻辑闭环。

2)串联闭合的功能模块——高内聚,低耦合,可拓展:

将每个功能模块串联起来,保证每个功能模块足够的独立,各功能模块之间耦合度尽可能的低,不会因为一个功能模块的修改,牵一发而动全身;其次还要保证各个功能模块的可拓展性。

3)查验-MECE(相互独立,完全穷尽):

根据MECE分析法,对每个功能模块进行查验,穷尽模块功能闭环后,串联起来再查验整体的业务逻辑闭环;然后再进行产品可视化设计。

2.产品可视化设计的查验脚手架:

以上基本是思维导图和产品流程图的设计阶段,业务逻辑闭环后,开始进行产品原型的设计以及PRD文档的输出。

这个时候,我们同样需要一套查验机制去弥补我们思维的局限性,这套机制或者模板足够的穷尽和高阶帮助我们修正没有考虑到的设计和交互。如下图:

三、脚手架思维总结

综上所述,脚手架思维是一种思维方式:这种思维方式让我们在思考和解决问题的时候能主动的去寻找并运用有效的脚手架(包括但不限于某种工具、模板、套路、原则、道理、方法论&思维方式),从而提高解决问题的效率,甚至达到事半功倍的效果。

脚手架思维带给我们的启示是:当我们遇到问题的时候,不要仅仅局限于处理自己问题的本身,要想到如果大多数人都会遇到这样的问题,有没有一套工具、模板、套路、原则、道理、方法论&思维方式等能够解决这样的问题,寻找解决问题的脚手架,实现同类问题的批量化处理。

 

作者:Allen,个人公众号:思维改变生活。初级产品经理一枚,喜欢研究高阶的产品学习方法论,从而改变职业成长的加速度变量。

本文由 @Allen 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自pexels,基于CCO协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 你这名字

    来自浙江 回复
  2. 一个问题的核心和外延 😐

    来自浙江 回复