3

如何建立/管理一个产品的文档(知识)体系?

 2 years ago
source link: https://www.pmcaff.com/discuss/3015020252067904?newwindow=1
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

如何建立/管理一个产品的文档(知识)体系?

新进一个公司接手了一个较大的项目(一个APP原型就有200多个界面,还有3个端口),原来的一批老员工交接得很简单很仓促,好几个人已经离职了。花了很长时间来了解原来产品的情况,自己重新做了流程图,自己重新汇总了一下所有的原型,总算初步了解了产品。工作了一段时间后,发现一些令人头疼的情况:交代下我们的协作方式:我们团队使用的是蓝湖作为共享产品原型和说明的工具,因为每个版本需求很多,时间又很短(1个月1... 查看全部
匿名用户   一周前   2740 阅读
  • 大厂 高级产品经理

    #产品经理挑战赛# day1

    从描述来看楼主的问题主要是在于版本需求以及产品功能清单之间应该怎么进行连接

    首先需要明确两个前提:

    • 整体的产品功能清单需要维护
    • 版本需求写出来要明确交付版本

    以下附上我自己写的一个产品文档目录来说明我理解的产品体系是如何做的

    • 大事记:讲的是项目中发生的history,例如用户数破千万,营收过亿,又或者是版本重大功能更新
    • 产品规划:规划里写明产品的发展方向,现在的功能清单,历史版本做了什么,下个版本要做什么
    • 数据字典:名词解释以及产品埋点
    • 竞品分析:顾名思义,关注竞品的动态
    • 版本明细:每个版本完成的功能点以及为什么要做,原始需求有哪些
    • 共创用户/性能说明:就是一些与项目相关的内容

    image.png

  • 某不知名小公司 产品经理助理

    #产品经理挑战赛# DAY 1

    最近从0到1做的产品很多,也被好多研发说了这个问题:

    -为什么每次写需求都不好好写个新迭代和做个汇总阿?

    -每次要找你的需求里找个功能,都得找老半天哎?

    于是,为了防止被同事们白眼以及降低查询效率,最近做了一些优化的工作:

    1、首先了解下你自己产品中最经常迭代的功能/业务/有哪些?先把最近需要解决的大功能先补充完整。

    这一步是让你明白自己工作的重点在哪,毕竟不是所有东西都要一下子一步到位,若团队里只有你一个产品,这工作量基本不可能完成了,所以要一点点去整理

    2、每个迭代里有迭代的功能,但管理需求的工具不只是有迭代,你还可以去需求分类里找:

    导出表格,整理成功能表,然后进行汇总归纳整合。

    (如果你有对关键词进行分类最好。。没有的话,祝你好运)

    3、合理设计团队资源库,文档库、知识库?

    -这个部分就是需要产品经理好好进行整合了,很考验产品对知识分类及归档的能力

    我这边就做的比较简单了:(当然目前也是最近才开始一点点磨,可能还得验证是否有效)

    (1)线上版本内容:最新需求文档

    (2)历史迭代版本:每个版本迭代增加的需求

    如:V8.23-8.30、V8.16-8.22

    每个版本需求内容都可以加进去。

    4、不过目前遇到的问题比较多的还是把经常会提问,经常需要查询的功能点,做成文档放置在知识库里。

  • 这种情况最简单的方法,就是 把需求文档和原型全都拆开,不进行你们最后的那一步,将所有版本原型整合在一起合并上传。

    需要做的工作:

    1、拆分原型模块
    将200多页面的原型,按照业务、功能、界面,进行拆分成多个独立的原型

    2、拆分需求文档
    根据拆分的原型,对照需求文档,拆成对应的小文档

    3、建立对应目录
    记录原型结构,每一部分拆分后的名称或编码,以及对应的文档名称或编码

    4、后期维护,版本迭代
    仅在需要维护的那个版本原型或需求文档上进行更新
    可以本地生成多个版本文件,也可以在线文档仅留存最新部分

    这样子,不论产品变成什么样子,你只需要找到所有的最新版本,能“组装起来”就可以。

    ~~~~~~~~~~

    我这里所谓组装原型用的是摹客,一个项目文件可以对应上传多个原型文件,完全不影响查看。
    所有负责这个产品人员可以在线协作,建立好项目后,每个人都可以独立管理自己的原型,上传到对应项目或者项目集中进行管理,省去一个负责组装上传的人力。

    图片.png

    或者建立项目集,将每一个拆分后的原型独立按照一个项目进行上传,在该项目里面,累积上传不同版本的原型,版本如上图,项目集如下图。

    图片.png

    同时还可以对 文档、原型、设计稿,统一进行管理。

    图片.png

    设计稿上还可以直接进行交互链接,进行高保真演示

    图片.png

    我想这样子全都处理完,基本应该就不会出现你说的那个问题了吧

  • 国潮500强偶尔逛逛社区 半产品半项目半商务

    最强大是建立在你不慌不忙的过程中梳理对产品的理解和拆分,还有就是硬核的花心思。

    抛开工具不说,其实步骤很简单,无非就是以下几步:

    • 梳理流程,页面流程。
    • 功能/用例要严格进行归类。
    • 最后就是每个功能点的需求说明。
    • 当然啦,如果能知道业务背景当前最好,最起码知道这个需求是怎么一路填坑过来的。

    最后说说工具:

    • 协同的原型工具是个快速整合和迭代的起点。比较建议某刀的企业版。
    • 先把交互框架做好,然后就是按功能模块分工。
    • 然后把需求规范约定好,所有的需求描述都写在原型旁边的备注中。

    软件工具只是一个辅助,核心是大家的文字描述尽量一致,让大家减少相互沟通的成本。

  • 大蜂保险 产品经理

    建立规范:包括文档命名规范,文档规范 ,说明规范,做到统一 

    建立版本:根据功能模块,以及更新迭代,建立版本,形成说明文档(文档需要有规范)

    建立索引:如果可以的话,可以让运维建立自己内部的文档库,然后根据需求给每个文档建立索引,能快速查找到所需文档;

  • 学生

    蓝湖本身支持版本管理和多人协作,此外建议在需求文档里标明蓝湖版本(最好是带直接能打开的特定版本链接)。需求文档这块需要有统一的命名和维护规范。建议文档名做模块区分,文档内做版本迭代摘要说明。

  • 信业 PM

    维护一份基线文档,定期更新最新产品文档;同时增加一份版本明细清单,写清楚每个版本更新的功能点。

  • 成都华西公用医疗信息服务有限公司 产品负责人

    这个问题不简单喔,关注一下

  • 广州某IT PM

    我也遇到了同样的问题,但是不知道有什么好的解决方案,听被人说可以按每次项目单独做一份需求,然后整合到wiki的方式


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK