ROY·产品经理知识体系（持续更新中）

• 协作团队​管理

  1. 梳理清楚公司或产品线内部的组织架构
  2. 熟悉不同团队的职能与工作流程
  3. 了解不同团队的人力资源配置
  4. 建立良好的沟通交流机制

  • ​设计团队

    • 了解设计知识

      • ​设计知识

        1. Google的Material Design https://material.io
        2. Oracle的Alta UI http://www.oracle.com/webfolder/ux/middleware/alta/start-design.html
        3. 阿里的淘乡甜 http://www.25xt.com/appdesign/14961.html
        4. 设计达人网 http://www.shejidaren.com/
        5. 星巴克外送平台 http://www.ui.cn/detail/379868.html
        6. 阿里UEDS设计团队 ​http://www.aliued.cn/
        7. 微信公众号【 UI头条】
        8. 《原来Banner设计还有这么多套路》https://mp.weixin.qq.com/s/dXG3CipC_HFDAIE2iiwqLA
        9. http://styleguides.io/examples.html 设计模式范例（需要翻墙）

      • ​设计作品

        1. 追波网 dribbble.com
        2. 追波网免费psd下载 http://www.fribbble.com/
        3. 追波网动效gif下载 http://guifff.com/
        4. 追波网分类 http://www.designtickle.com/
        5. 站酷网 http://www.zcool.com.cn/
        6. tool网站 http://toolofna.com/#!/home
        7. 应酷设计 http://blog.enqoo.com
        8. 视觉中国 https://www.vcg.com/

        • ​动效设计

          1. http://bouncejs.com
          2. https://minimamente.com
          3. http://tobiasahlin.com/
          4. https://daneden.github.io/animate.css/
          5. http://ianlunn.github.io/Hover/
          6. http://animejs.com/
          7. 数字效果 http://github.hubspot.com/odometer/docs/welcome/
          8. 等待加载https://projects.lukehaas.me/css-loaders/

      • ​设计规范

        如何从0到1建立设计规范

        https://mp.weixin.qq.com/s/hAZMWV3pYbV9862_Vv47Zw

    • ​角色

      • ​交互设计师

      • 平面设计师

      • ​UE/UI设计师

  • ​研发团队

    • ​开发团队（参考《软件工程师知识体系》）

      http://www.woshipm.com/pmd/1301115.html 《程序员：我心目中的优秀产品经理》

    • ​测试团队

    • ​运维团队

    • ​与研发团队的协作之道

  • ​运营团队

• ​产品（商业模式）定位

  1、精简的商业模式通常包含以下

  
  

  1. 合作伙伴（投资方）
  2. 核心业务行为
  3. 核心资源
  4. 价值命题
  5. 目标用户
  6. 端渠道（web\app\wechat&wap)
  7. 支出结构
  8. 收入结构

  例如：Uber的商业模式画布

  

  2、产品定位描述包含

  
  

  1. 产品品类定位
  2. SWOT分析
  3. 优势——资源
  4. 劣势——资源
  5. 机遇——痛点
  6. 威胁——竞品与市场
  7. 产品亮点与差异化
  8. 基于SWOT分析
  9. 独特的资源
  10. 可能产生壁垒
  11. 目标人群
  12. 用户特征标签
  13. 种子用户
  14. 用户构成
  15. 视觉锤（Logo、视觉关键词）
  16. 文字钉（Slogan、产品名称）

  • 行业与市场调研

    • ​市场规模

    • 行业上下游（产业链）

      • ​构成角色

      • ​各类角色的盈利方式

      • ​行业前三名的公司（国内外各三个）

    • ​行业最新最前沿资讯的来源

      • ​数据及行业报告

        • 艾瑞网 http://www.iresearch.cn/

        • ​城市数据派 http://www.udparty.com/

        • ​IT桔子 https://www.itjuzi.com/

        • ​百度指数 https://index.baidu.com/

        • ​199IT http://www.199it.com/

        • ​易观数据 http://www.analysys.cn/

        • ​百度数据研究中心 http://data.baidu.com/ 

        • ​前瞻网 https://www.qianzhan.com/

        • ​中国报告大厅 http://www.chinabgao.com/stat/

        • ​中商情报网 http://www.askci.com/data/

        • ​阿里研究院 http://www.aliresearch.com/

        • ​梅花网 https://www.meihua.info/

      • ​新媒体平台

        • ​微信公众号

        • ​知乎

        • ​Quora

    • 咨询行业资深人士

  • ​用户调研

    • ​从竞品用户群体入手

    • ​定位目标用户群体

      • ​用户画像

        http://www.woshipm.com/pmd/107919.html（[干货]如何构建用户画像）

        https://www.zhihu.com/question/19853605（MS实例）

        http://www.chinaz.com/manage/2016/0115/496489.shtml（浅谈“用户画像”方法）

      • ​用户场景

    • ​提出假想痛点、采集痛点

    • ​实践三板斧

      http://www.chinaz.com/manage/2016/0115/496489.shtml

      （如何做一次完美的用户调研?）

      • ​用户访谈

      • ​调查问卷

      • ​实地考察

  • ​竞品调研

  • ​商业模式画布

    • 客户细分（Customer Segments）

    • 价值主张（Value Propositions）

    • 渠道通路（Channels）

    • 客户关系（Customer Relationships）

    • 收入来源（Revenue Streams）

    • 核心资源（Key Resources）

    • 关键业务（Key Activities）

    • 重要合作（Key Partnerships）

    • 成本结构（Cost Structure）

• ​产品知识学习渠道

  实时更新，宁缺毋滥

  • ​https://cdc.tencent.com/

    腾讯产品设计部门

  • ​http://www.woshipm.com

    大杂烩

  • ​https://www.pmcaff.com/

    问答式产品经理社区

  • ​http://www.aliued.cn/

    阿里UED设计团队，里面的【友情链接】有许多大厂产品设计网站的链接

  • ​https://www.processon.com/diagrams/new#temp-system

    processon图表中产品经理方面的常用图表及知识梳理

  • ​http://dh.woshipm.com/（工具网站导航大全）

    产品和运营工具、网站大全

• ​产品设计

  • ​业务流程调研与设计

    • 业务场景

      基于应用场景的设计——场景设计四部曲

      • 场景列举
      • 机会点挖掘
      • 设计策略
      • 衡量标准

      1、场景列举

      首先，明确场景的定义，或者说场景的构成，分别是：Who # When # Where # Do # Env。

      然后，通过【UML-活动图】或【UML-用例图】逐一提取其中的场景来进行场景列举。

      推荐一个用于描述非线性场景的工具Twine http://twinery.org/ 算了，不太好用。

      
      

      http://www.woshipm.com/pd/405766.html 《场景设计：应用场景设计四步曲中的方法挖掘机会点》

      http://blog.cathy-moore.com/ 一个对场景颇有研究的设计师的博客

      http://blog.cathy-moore.com/scenario-based-training-headquarters/how-to-write-scenarios-with-twine/what-is-twine/ 《Introduction to Twine, a scenario design tool》

    • ​用户行为

      • ​设计用户行为时需遵循的原则：尼尔森十大可用性原则

        https://www.zcool.com.cn/article/ZNTY4MDA0.html 《浅析在工作中尼尔森十大可用性原则的运用（启发式评估）》PS：给设计师挑刺、找理由的时候特别有用

        
        

        https://www.nngroup.com/ 尼尔森诺曼的体验设计公司官网

        • 状态可见原则

        • 环境贴切原则

        • 撤销重做原则

        • 一致性原则

        • 防错原则

        • 易取原则

        • 灵活高效原则

        • 易扫原则

        • 容错原则

        • 人性化帮助原则

      • ​流程描述工具：UML建模

        • ​时序图

        • 活动图

    • ​Stakeholder Resource（利益相关资源） 行为

  • ​架构设计

    • ​两种架构设计的策略

      • 按照功能模块设计

        如果产品的目标用户比较单一，且该类用户的需求也很统一，不涉及到用户权限、组权限、功能权限及数据权限的情况，并且，各个功能模块之间没有太多的业务交互逻辑，可以尝试按照功能模块对产品进行架构的划分。

        简而言之，如果可以分分钟就构思出主要的功能模块，那就可以用这种策略进行架构设计。

        
        

        步骤如下：

        1. 定义产品包含的端类型
        2. 定义产品涉及的用户角色
        3. 一个特定的端+一个特定的用户角色 = 一个特定的产品领域（Product Domain)
        4. 选取一个产品领域(Product Domain)之后

        

      • ​按照业务逻辑设计

        此种类型的产品的目标用户往往会涉及到多个角色，比如：企业内的业务部门、客服部门、前台部门等，还会涉及到公司内部职能的划分。针对此类复杂的产品，通常可以利用泳道图或时序图对产品的主业务逻辑进行梳理，大的业务流程梳理过之后，再逐步拆解各个模块的业务流程与逻辑。通常，这里涉及到的难点会是不同业务模块之间交互逻辑的设计。

        简而言之，如果不能分分钟构思出主要的功能模块，那就要用这种策略。比如后台系统、ToB产品等等。

        
        

        我没做过这类产品。。所以编不下去了。

    • ​端分类

      • ​WEB

      • ​APP

      • ​Wechat & WAP

      • ​微信小程序

      • 后台管理端（Server/Admin Center/Dashboard）

    • ​架构描述工具

      《功能结构图、信息结构图、结构图，你还傻傻分不清吗？》

      http://www.woshipm.com/pmd/838667.html

      http://www.woshipm.com/pmd/844937.html

      • ​功能结构图

      • ​信息结构图

    • ​经典产品架构案例解析

      • ​WEB

      • ​APP

        • ​小红书

          http://coffee.pmcaff.com/article/55746

      • ​WAP

      • ​Backend

  • ​常见功能模块

    • ​引导页面

      《产品设计中「引导页」的相关思考》

      https://mp.weixin.qq.com/s/nYCTwKssib0NX0vFA6fOkg

    • ​登录与注册

    • ​搜索与筛选

      http://www.woshipm.com/pd/1454945.html

      • ​搜索

        • ​历史搜索

        • ​热门搜索与推荐搜索

        • ​预加载（猜你喜欢）

        • 自动填充

        • ​模糊匹配（智能纠错、拼音与同义词匹配）

        • ​分类搜索

      • ​筛选

        • ​合理分类

        • ​具有预测性

        • ​避免晦涩的文案

        • ​突出优先级

        • ​筛选组件

          • ​开关（toggle button）

          • ​标签

          • ​滑块

          • ​卡片

          • ​步进器（Stepper）

        • ​筛选条件之间的联动关系

          • ​包含

          • ​递进

          • ​并列

          • ​互斥

    • ​内容展示列表

    • ​导航

    • ​信息表单

    • ​提示信息

    • ​RBAC（Role-Based Access Control）基于角色的访问控制

      后台设计的基石：用户权限管理（RBAC）及工作流（workflow）模型

      
      

      http://www.woshipm.com/pd/959125.html

  • 基于端的非功能设计

    

    • ​WEB

      • 非功能设计

        • ​表单

          • ​防止输入框的遮挡

          • ​智能预填写

          • ​键盘匹配

          • ​实时校验

    • ​APP

      • ​功能设计

      • ​交互设计

    • ​Wechat&WAP

      • ​功能设计

      • ​交互设计

    • ​后台管理端（Server/Admin Center）

• ​产品运营

  http://www.woshipm.com/topic/project

  • ​不同产品阶段的产品运营

    • ​上线前期

      • 基础建设

        • ​VI设计

          VI设计主要包括标志设计、标志字体、辅助图形、口号使用规范、二维码使用规范等一系列有关产品的对外形象设计图。这些VI的主要功能是辅助产品推广、增强品牌形象以及在第三方合作时使用的，这也是展示一个产品形象的必备条件。

        • ​产品介绍

          • ​产品概述

          • ​功能与特点

          • ​用户人群定位

          • ​投顾资源

        • ​媒体矩阵

          • ​自营媒体（内容分发平台）

            • ​第一梯队

              • ​今日头条

              • ​大鱼号

              • ​网易自媒体

              • ​微信公众号

            • ​第二梯队

              • ​企鹅号

              • ​百家号

              • ​搜狐自媒体

            • ​第三梯队

              • ​知乎

              • ​微博

              • ​一点资讯

              • ​简书

          • ​PR媒体

            • ​科技媒体

              科技媒体又分平台与专业媒体，平台性的科技媒体主要包括猎云网、创业邦、虎嗅等等（请自行问度娘所谓的10大科技新媒体），专业性的科技媒体就要按行业分咯，比如教育行业的有茄葩、芥末堆、多知网等，O2O行业的有亿欧网、品途网等。上这些媒体通常比较难，就像古代的青楼女子，人家是卖艺不卖身，不是给人家钱就能上的，人家也要挑人的。

            • ​自媒体

              包括三种类型，首先是自家公众号；其次是真正的某个人或者某个团队做的原创公众号，但是这类号很多为了保持原创，一般都不会发水稿；最能发布的就是各地方性的创业孵化器、创业空间搞的自媒体，他们通常热衷报道创业团队的。

            • ​大众媒体（新闻门户）

              大众媒体是包括腾讯、新浪、搜狐、网易等大大小小的新闻网站，如果你的产品是面向大众消费者的，在这些媒体上发稿特别有效，只要告诉用户“你看，腾讯新浪搜狐网易上都有我们的报道呢！”，用户就不会觉得你是骗子。这类媒体很多都是通过转载科技媒体上的文章来报道你的文章。

              
              

              分众传媒

              
              

            • ​传统媒体

        • 双微社群运营

        • ​品牌建设

          • ​百科类

          • ​问答类

          • ​垂直社区

    • ​上线初期

      • ​引导注册

        http://coffee.pmcaff.com/article/1483041212571776/pmcaff?utm_source=forum

    • 用户迅速增长期

    • ​用户增长停滞期

      • ​精细化运营

        http://www.woshipm.com/operate/758636.html

        精细化运营的基础：建立用户画像和用户分群

    • ​用户增长平稳期

• 产品数据

  • 数据采集体系

    • ​数据埋点与采集

      http://www.woshipm.com/operate/300099.html（数据分析第一步 | 做好数据埋点）

      
      

      http://www.woshipm.com/operate/1987879.html（细分十一步，助你构建完整的数据运营体系

      ）

      • ​工具

        • ​吐个槽·反馈平台

          https://tucao.qq.com/

        • 数据观 

          ​https://shujuguan.cn/

        • ​七麦数据

        • ​诸葛IO

        • ​神策数据

        • ​GA

        • ​集奥聚合 http://www.geotmt.com/

        • ​友盟+ http://www.umeng.com/

      • ​常用数据指标

        • ​产品数据

          • ​PV & UV

          • ​DAU & MAU

          • 停留时长即​平均访问时长

          • ​转化率

          • 跳失率（bounce rate）即只访问一个页面

          • 退出率（landing page的退出率）

        • 用户数据

          • ​ARPU

          • ​渠道分析

          • ​用户构成（用户自然属性）

    • ​用户标签体系建立

      1. 标签系统的结构
      2. 数据加工层（数据加工层收集、清洗和提取数据，通过遍布产品的数据埋点采集数据，并对其进行清洗、去重、去异常等处理）
      3. 数据业务层（维护标签体系的核心部分，集中管理原始数据及标签系统，并接受业务方的标签需求，创建所需的标签实例并执行）
      4. 数据应用层（赋予产品和运营人员标签的工具能力，聚合业务数据，构建具体的数据应用场景）
      5. 三层之间的关系如图所示
      6. 标签分类一
      7. 维度一：属性
      8. 事实标签（定性或定量描述用户）
      9. 自然属性
      10. 产品属性
      11. 消费属性
      12. 资源属性
      13. 模型标签（基于用户属性及用户行为抽象和聚类而成，用以总结概括，并添加相应的指数表示程度）
      14. 兴趣、偏好（兴趣程度）
      15. 需求（需求程度、购买概率）
      16. 预测标签（基于用户的属性、行为、位置、特征等，挖掘用户的潜在需求，针对这些潜在需求配合营销策略、规则进行打标，实现营销适时、适机、适景的触达用户）
      17. 维度二：动态&静态
      18. 静态标签（长期甚至永远不会改变）
      19. 动态标签（存在有效期，需要定期更新，比如用户的活跃情况、购买力等）
      20. 标签分类二
      21. 
      22. 原始数据
      23. 事实标签（购买次数、类型，退换占比，活跃次数，购买金额，购买间隔，用户价值，行为次数等）
      24. 模型标签（性别、流失、购买、工作、忠诚、风险等预测，行为、兴趣偏好等）
      25. 策略标签（待激活、待挽回、待维护、待发展等）
      26. 

  • ​数据分析

    产品经理必知的三个数据分析框架

    https://www.jianshu.com/p/ee8f18e4dd06

    
    

    【万字干货】以虎嗅网4W+文章的文本挖掘为例，展现数据分析的一整套流程

    http://coffee.pmcaff.com/article/12629

    
    

    • ​数学建模

    • ​分析策略

      • ​逻辑分层

      • ​漏斗分析

      • ​用户行为路径

• ​产品管理

  • ​需求管理

    • ​需求采集

      • ​需求方提供

      • ​需求挖掘

    • ​需求分析

      • ​筛选

        • ​技术可行性

        • ​场景可行性

        • ​成本评估

        • ​商业价值评估

        • ​风险评估

      • ​匹配（分类）

        • ​需求所指向的目标（作用）分类

          • ​基础需求

          • ​核心需求

          • ​利于拉新/活跃度

          • ​优化用户体验

          • ​提升运营效率

          • ​商业需求

          • ​产品进化新模式

        • ​需求的功能分类

          • ​功能需求

            功能需求指明了产品必须做的事情，即产品为了满足它存在的根本理由而必须执行一些动作。同时，功能需求是产品为了支持工作而必须做的事情。它们的表述应该尽可能独立于实现需求的技术。比如，登录功能、购物车功能、收藏功能、支付功能等。

            在编写功能需求时，要为需求加上理由，说明需求为什么存在。

            在大多数情况下，这是需求的关键部分。

          • ​非功能需求

            侧重用户体验的表达

            
            

            1.观感需求

            观感需求描述了对产品外观期望的精神实质、情绪或风格。比如：产品应该显得保守、产品应该吸引人、产品应该表现出权威性、产品应该吸引年纪较大的人、产品应该显示出艺术水准、产品应该看起来显得很昂贵，等。 要注意，观感需求描述了外观的意图，不是界面的设计。

            2.易用性和人性化需求

            易用性和人性化需求使产品符合用户的能力和期望。易用性需求包括：用户的接受率或采用率；因为引入该产品而导致的生产效率的提高或错误率的降低；在产品使用的国家被不说该国语言的人使用；个性化和国际化，让用户改成本地拼写方式及其他选项；对残障人士的可用性；被没有计算机使用经验的人使用；在黑暗的时候可以使用（夜间模式）。

            礼貌是易用性中一个常常被忽略的方面。在过去的网站，通常是要求创建账户，填写所有个人信息，然后输入密码。在这之后，用户得到一条消息：“密码应该是8个字母或数字，包括一个大写字母和一个数字，请重新输入密码。”同时，前面为了创建账户而输入的所有个人信息都被清除，要求用户再来一次。我们不能容忍这样的行为，这对用户的这种行为表明缺少礼貌需求。

            此案例的非功能性需求应该这样写：

            • 描述：产品应该避免要求用户重复已输入的数据
            • 理由：为了建立用户对产品的信心

            易用性需求源自两个方面，一方面是用户期望产品达到的易用性水平，另一方面是预期用户具有怎样的经验。自然，用户的特征不同导致他们的期望不同。作为产品经理，我们必须发现这些特征，并确定怎样的易用性水平将给用户带来舒适有用的体验。

            3.执行需求

            如果产品需要在给定的时间，或以特定的精确度来执行某些任务，或者产品需要有一定容量，就要写下执行需求。 比如：产品应该支持2000个并发用户、产品支持最多好友数量是5000个等。

            执行需求主要来自于操作环境。每种环境都有自己的情况和条件。人、机器、设备、环境条件等都会对产品有要求。产品响应这些情况的方式（它应该多快、多健壮、多大、多频繁），就是相应的执行需求。

            4.操作和环境需求

            操作需求规定了如果要在产品的环境中正确操作，产品必须做的事。在某些情况下，操作环境创造了一些特殊的情况，会影响产品构建的方式。比如：产品应该能在不同的照明条件下使用；产品应该节省电池用电等。

            为了发现操作需求，要查看产品边界并考虑每一个相邻的系统和利益相关者。如果需要，要与每个利益相关者或系统的代表进行访谈，发现与该产品相关的工作方式所导致的需求。

            5.可维护性和支持需求

            可维护性和支持需求描述的是预期的改变，以及完成改变允许的时间，也包括对产品的支持的规定。在需求阶段，通常不知道产品在它的生命周期里所需的确切维护工作量，而且也不会总是知道它所需的维护类型。然而，产品在构建时总可以在一定程度上预见维护的类型。 比如：产品应该能够移植到Android和iOS上。

            要让研发知道，希望在将来某个时候，产品能移植到另一个平台上，让产品有适应新设备的能力。

            6.安全需求

            安全需求涉及到三个方面：

            • 可得性。可得性是可以访问数据，产品保存数据的方式让用户能得到数据，同时能理解数据。在安全方面，可得性需求规定了产品必须做什么，来确保数据只能由授权的用户访问。在编写这类需求时，要在规定允许的访问，即谁有授权，在哪些情况下授权是有效的，每个授权的用户可以访问哪些数据和功能。
            • 私密性。私密性表示产品尊重用户的隐私，产品必须满足一些需求来确保用户数据的私密性。例如：产品的数据不支持打印、产品的数据做加密处理等。
            • 完整性。完整性是指产品所保存的数据与相邻系统发送给产品的数据完全保持一致。必须考虑防止数据冲突的需求，如果发生了最坏的情况，就要及时恢复丢失的数据。比如：我们的产品如果投入运行，将保存用户组织机构的重要数据，完整性需求就是要保护些数据。

            7.文化需求

            文化需求规定了一些特殊因素，它们可能导致产品不被接受，原因是习惯、宗教、语言、禁忌、偏见，或几乎是人类行为的任何方面。如果试图把产品卖到另一个国家，特别是文化和语言与我们自己的有很大不同的国家，就带来了对文化需求的不同要求。比如：产品不应该显示与主流宗教有关的宗教符号和文字；产品不应该使用可能激怒任何人的术语和图标；产品提供的语言选择顺序应该符合所在的地区等。

            8.法律需求

            我们并不想摊上法律诉讼，我们必须注意到那些适用于自己产品的法律，为产品写下符合这些法律的需求。即使我们的产品是在组织机构内部使用，也要注意到有一些适用于工作场所的法律可能会有关系。

            公司里要是有法律顾问就太好了，可以随时请教他。我们可以考虑如下问题：

            • 考虑用户的法律需求和权利。例如，是否有一些对残障人士的法律是适用的？
            • 相邻系统对保存的数据是否拥有隐私权？是否需要留下交易的证据？是否不能暴露产品拥有的关于某些系统的信息？
            • 是否存在与该产品相关的法律？例如，数据保护、隐私法律、担保、消费者保护、消费者信用、知情权等法律是否适用？

            • ​性能

            • ​可拓展性与可维护性需求

            • ​观感（视觉）需求

            • ​易用性与人性化

            • ​操作和环境需求

            • ​安全需求

            • ​文化需求

            • ​法务需求

        • ​优先级与产品阶段

          • ​初期

            • ​基础功能 >> 利于拉新/活跃度

          • ​爆发期

            • ​核心需求 >> 利于拉新/活跃度 >> 优化用户体验

          • ​平台期

            • ​优化用户体验 >> 商业需求 >> 新功能探索 >> 提升运营效率

  • ​敏捷管理

    参考书籍《敏捷革命》

    • ​敏捷涉众

      • ​产品团队

      • ​协同团队Leader

    • 敏捷流程

      • 1、挑选一位产品负责人

        • 产品负责人必须清楚产品前景，即【做什么】。

      • 2、挑选一个团队

        • 通常3-9人较为合适，团队中的每个人都是真正做事的人。

      • 3、挑选一位Scrum主管

        • 对Scrum过程负责

        • 组织各种Scrum会议

        • 草拟待办事项清单

        • 帮助团队消除一切障碍

      • 4、拟定待办事项清单并确定优先顺序

        • 借助斐波那契数列来拟定事项的重要性（1、3、5、8、13）（“犬点”）的概念

        • 一定要有一线做事的人员来决定

        • 待办事项清单是一直在演变的

        • 一定要不断寻找可以带来80%价值的20%功能

      • 5、改进和评估待办事项清单

        • 使得每个事项都有可以衡量的完成标准

        • 最好可以得出能够给用户试用的成果

      • 6、冲刺规划会议

        • 通过事项的“点数”判断团队冲刺的速度

        • 冲刺过程中，没人可以改变冲刺内容

        • 一般是一至两周

      • 7、工作透明化

        • 通过一块白板展示项目：待办事项、在办事项、完成事项

        • 燃尽图

      • 8、每日立会

        • 每天固定时间，每次不超过15分钟

        • 【1】你昨天做了什么去帮助团队完成冲刺？

        • 【2】今天你打算做什么来帮助团队完成冲刺？

        • 【3】什么因素阻碍了团队的前进之路？

      • 9、冲刺评估或冲刺展示

        • 任何人都可以参见

        • 只展示符合“完成定义”的事项

      • 10、冲刺回顾

    • ​敏捷会议

    • ​敏捷工具

  • ​原型管理

    • ​原型制作（Axure）

      • ​原型上的交互说明

        http://www.woshipm.com/rp/1528320.html

    • ​团队协作

  • ​产品迭代

    • ​发布

      • ​多部门协同发布

      • ​要点

        • ​时机选择

        • ​促进用户认知

        • ​引导市场传播

        • ​冷启动

        • ​完善整体服务

    • ​运营数据反馈

    • ​需求采集与分析

    • 产品设计

    • ​开发

    • ​测试

  • ​产品文档管理

    • ​文档脚手架

      • ​商业需求文档（MRD）

      • ​功能结构图（ProcessOn维护）

      • 信息结构图（ProcessOn维护）

      • ​需求说明书（PRD）

        • ​需求管理

          • ​需求文档

            1、需求管理文档应当由以下几个文档构成

            • 功能结构图
            • 信息结构图
            • 需求文档
            • 需求背景及价值
            • 需求细节
            • 应用场景上下文
            • 用户行为流程（顺序、分支、循环结构）
            • 状态变化（对应行为流程）
            • 数据流
            • 异常场景
            • 是否涉及其他相关联的功能或模块

            2、需求在需求管理文档中的流动（workflow）

            
            

            首先，需求应该体现在功能结构图中。因为功能结构图是展示一个产品所有功能最全面最直观的方式，是指导产品需求的最高纲领。

            然后，信息结构图总是与功能结构图相对应的，一旦功能结构图发生改变，信息结构图就必然发生改变，通过具体的信息描述，如字段名称、字段格式、字段约束等，使需求进一步具象。

            最后，将需求写入需求文档，用详尽的文字、形象的贴图等，使需求得到最准确的描述，撰写需求文档时应该恪守以下原则

            • 多角度、多状态地描述应用场景
            • 充分考虑每一个功能涉众，包括不同角色的用户、不同的内部团队成员、不同的需求评审方
            • 使用更丰富的表述手段，包括但不限于文字、思维导图、表格、贴图、手绘图、视频等
            • 使用统一规范的专业术语

            3、原型在需求管理中的作用

            在需求验证或评审阶段，可以从原型的master分支上建立一个新的分支来制作原型辅助验证或评审。

            当需求评审通过后，将新需求纳入“待开发”池中后就可以进一步完善优化原型了。

          • ​需求管理工具

            • ​石墨文档

            • ​Zhimap

      • ​数据库设计说明书（研发团队提供）

      • ​线框图

      • 原型（Axure维护）

      • ​UI设计稿（设计团队提供）

• ​思维能力

  • ​MECE原则

    “相互独立，完全穷尽”原则

    
    

    MECE，是Mutually Exclusive Collectively Exhaustive 缩写，中文意思是“相互独立，完全穷尽”。 也就是对于一个重大的议题，能够做到不重叠、不遗漏的分类，而且能够借此有效把握问题的核心，并成为有效解决问题的方法。

    它是麦肯锡的第一个女咨询顾问巴巴拉·明托（Barbara Minto）在金字塔原理（The Minto Pyramid Principle）中提出的一个很重要的原则。

    所谓的不遗漏、不重叠指在将某个整体（不论是客观存在的还是概念性的整体）划分为不同的部分时，必须保证划分后的各部分符合以下要求：

    （1）各部分之间相互独立 （Mutually Exclusive）

    （2）所有部分完全穷尽 （Collectively Exhaustive）

    MECE（相互独立、完全穷尽）是麦肯锡思维过程的一条基本准则。 “相互独立”意味着问题的细分是在同一维度上并有明确区分、不可重叠的，“完全穷尽” 则意味着全面、周密。

    

    http://blog.sina.com.cn/s/blog_53cd78770102v3m4.html 《分享两篇文章，把金字塔原理和MECE原则解释的很清楚 》