The Blog Logo
Innovating
Published on

笔记-产品经理

极客时间课程笔记

验证码是好设计吗？

Completely Automated Public Turing test to tell Computers and Humans Apart,用来区分人类和电脑的全自动图灵测试

  1. 不要将责任推卸给用户
    1. 输入验证码操作对用户来说其实是并无价值的
  2. 方案选择的平衡
    1. 在 让系统引入复杂的策略判断 or 验证码
  3. 验证码的进化
    1. 智能判定，提供各种行为特征，训练算法去分辨机器和人。

设计工具

手+笔+拍照

原型设计：Axure/Keynote/OmniGraffle/Sketch/**墨刀**/POP 等

思维导图：MindManager/MindNode/XMind

UML图： UML 中的很多语法非常适合产品经理做概念模型、流程、状态设计等StarUML/Visio/LucidChart/ProcessOn

关于交互可以看看UI movement

AI时代产品经理

唯一能持久的竞争优势是胜过竞争对手的学习能力--盖亚斯

需要需要学习算法？ 人工智能的能力大都隐藏在我们能感知到的功能之下，我们很难从场景出发，理解内部机制，获得认知。

怎么学算法？通过视频课，李宏毅等等

要不要写代码？简单一些可以，没有工程能力不需要给自己添堵

明确目标，产品经理需要明白算法背后的原理，机制和边界，这样才能和工程师站到同一个话语空间，推进具体的产品工作。

产品经理

  1. 要能够深入理解小粒度的算法，并将其产品化；
  2. 重视工程，不要追求纯粹的算法输出
  3. 利用设计，最大化算法和工程的产出
  4. 数据的规划
  5. 机器算法带来的思维模式转变

案例-文本之美-TheGuardian

以一篇文章为起点，去串连起所有的上下文和背景信息。（沉浸式，获得更多的相关文章）

需求变更

唯一不变的，就是变化本身 ---斯宾塞·约翰逊

需求不会变更，变更的是实现。

挖掘需求背后的需求

比如，做公司内部的订单系统，用户提出希望为订单添加根据最近修改时间排序的支持，你不应该直接

去实现，而应该问为什么。可能用户会说，因为每天的订单量太大，审核不完，为了防止订单过期，所以要从最久远的一份开始审核。很多产品经理到这里就结束了，但这还不够，你应该继续就这个问题问下去，比如可以问为什么订单会过期，或为什么一定要审核。

这是我经历过的一个真实案例，随着不断深入挖掘，后来发现有大量的审核工作是可以自动完成的，最终我们做了一个自动审核的功能，彻底解决了这个问题

给需求分析留出时间

换一个更冷静的状态去重新审视自己的需求分析，”需求发酵“

需求评审

说明白自己的目标。实现方式可变更。经验性，完备性，通用性等等等等

拥抱变化 阿里巴巴价值观之一

尽量引入需求评审来金可能避免需求变更。

需求评审中，评审的页面，功能，需要具体，数据，架构可以使假的，但是尽量要保真。

变更时机选择：不是所有变更都是越早越好，需要平衡收益和成本。首先方案应该完整。工程师接手前，需求变更较好，工程师接收后，变更就会产生实际的开发成本。稍微大一点的功能，最好在发现变更后就立即和开发沟通，判断合适的变更时机。

让团队能消化需求变更，不要怕责任，问题和错误。变化是永恒的，你不可能规划好路线一帆风顺，你总要随时准备好用最快的速度追击或躲闪，这才是求胜的不二法门。

案例-Hopper的“人工智能”

Hopper的设计非常的场景化，设计几乎都是顺着场景长出来的。这样的提示以一种非常自然的方式，把信息描述给用户听。，而不是一个很生硬的机器去提示用户，并让用户从复杂的信息表格或者图表里去获取到信息。

Hopper永远在场景里面去理解你当前的位置，理解你当前的关注点，然后适时地去把它的一些功能嵌入在你实际的使用中，让用户觉得非常不突兀，也很吻合

**场景是需求的灵魂，我们需要让产品和功能贴着需求与场景长出来。**Hopper所有的交互过程正是这样，每一处都是与场景相吻合，在用户想做决定的时候，恰好的出现。

在我们向技术去索要人情味之前，我们可能更多地需要向产品、向用户的场景去要一些人情味

评论：

国内的售票app以卖你东西为主，是售票员的角色，人家是以为你服务为主，是出行小秘书的角色，这个还是在于创始人对这个app授予的是卖票，还是卖好票。其实我们现在应该反过来思考的是既然这个app既然这么受欢迎，为什么哪儿去，某程这些为什么不借鉴它

文化不一样 市场不一样 竞争方式不一样，这是个好问题，想清楚这个问题恐怕就想清楚了为什么国外的很多产品在国内水土不服

产品抄袭

世界有两种产品，一种没人用，另一种被人抄

https://readhub.cn/很多交互细节设计都是经过取舍的，信息流里面哪里点击展开，哪里点击跳转，这些都是具备整体性的，我们需要牺牲一部分页面访问量换取体验和信息密度的一致；后来看到有网站抄这个交互，影响了他们本身的信息密度一致性，还牺牲了流量，很可惜。

每个线上的版本永远都是中间态，是我们沿着产品规划往下走的一个节点，是我们过去的思考结果。

竞争对手即便能抄走，也无法理解你背后的发展规划和逻辑。你当前的思考应该领先于产品，你清楚当前的问题在哪里，接下来应该如何调整。

管理好自己的节奏，和情绪。

借鉴灵感

在借鉴和抄袭的一线之间，我们一定要把握好度。不要不顾职业操守像素级抄袭，也不要因噎废食，闭门造车。多思考自己的问题，带着问题去透过别人的方案看背后的逻辑，把别人方案背后的方法变成自己的，而不是直接照抄。最后，要记得在条件允许的情况下，对给你带来灵感和帮助的人心存感激，表达敬意。

一念一世界

案例-LabRdr设计实验

新闻阅读应用

  1. 场景设计产品
    1. 使用这款应用的时候，LabRdr会提出问题：通勤时间，通勤时间长度，然后在通勤时候推送给你，并且会离线下载，因为路上手机可能没有信息
  2. 用户收集数据的透明化处理
    1. 将LabRdr将逻辑和规则开放给用户，让用户有控制感和安全感
  3. 每一次与用户互动都是一次交易
    1. 比如很多APP都会请求推送。只要一打开APP就会弹窗请求。
    2. 而应让用户了解到，推送是可以带来直接在价值的。需要说清楚推送的原因。达到用户预期交易才会顺利进行。

产品规划

为什么，做什么，怎么做，什么时候做

好的产品规划应该从更宏观的视角和判断入手，尽量避免过分关注具体的项目和特性列表

"No battle plan ever survives contact with the enemy.

在产品规划中要加入项目发布计划时，可以尽量写得模糊化，不要把项目内容和发布时间写得太精确。当你面前有艰巨而冗长的任务队列等待实施时，你的创造力将会被严重的抑制。

从研究怎么做转向该做什么。关注动机和目标会让我们考虑的更加周全。

规划时要谨慎，尽可能地想周全想清楚；可一旦落定，就应该坚决、激进，不要完美主义，接受80 分，边做边迭代，快速调整，这样才是优秀的节奏和状态

案例-Mimo与LearnPython

针对IT教育的应用

学习者自我驱动。利用社区的方式增加用户的黏性。交流，讨论，问答。好友，任务挑战。

影响力

何况异形体，信任为股肱。

  1. 建立信任是一个长期的过程
  2. 如何试错

做砸就会扣分，但是一直不做事也会减分。最后整个团队没人敢于尝试。做的时候沟通清楚，哪一环可能出现问题，出现什么问题，大家都清楚并且达成一致。这样对信任度的影响相对小一点。

  1. 重视承诺，不要找借口

更重要的信任是来自于主动承诺。

承诺没做到：第一不要找借口，第二要要提前反馈，第三要有耐心在未来逐渐找补回来。

  1. 不要在不重视承诺交互的环境中工作。

如何和开发打交道

横看成岭侧成峰，远近高低各不同

产品经理脑子里偏向”为什么“，工程师脑子偏向”怎么做“，交集在”做什么“上面。

在团队内部，随着人越来越多，就会有角色的分化，进而有了流程。

加强沟通，互通有无，On the same page.

合作共赢

  1. 全流程参与（尽早和工程师沟通）
  2. 多听工程师的意见
  3. 不要强迫工程师做评估
  4. 主动承担责任
  5. 同仇敌忾

产品文档

没有内容的形式和没有形式的内容，都是不能存在的；即使存在的话，那么，前者有如奇形怪状的空洞的器皿，后者则是虽然大家都看得见、但却不认为是实体的空中楼阁。

BRD Business Requirement Document，商业需求文档。 MRD Marketing Requirement Document 市场需求文档。

PRD Product Requirement Document，产品需求文档，写具体的功能逻辑和细节。可以把网上各种模板都研究一下，根据不同的产品或项目类别选择合适框架。比如重操作的TO C产品需要交互流程描述和线框图。而To B的产品注重的是概念模型和业务流程。

UC 用例文档。用例的模板比较简单。最核心的部分是流程。

FSD Function Specipcations Document功能详细说明，交代具体的数据字典，概念模型结构，业务接口规范

产品原型，交互稿，需要出不同保真程度的产品原型。不要炫技，也不要偷懒。 Mike Cohn在《团队之美》采访中说过”一个应用中所有的代码不一定要处于同样的质量水平“，克服完美主义倾向。

其他各种因需创建的文档比如需求文档，需求进度文档，需求评审报告，验收测试文档等等。有任何需要文档来规范思考，引导书面沟通，存档留底的场景都可以建立相应的文档机制。

要有明确的目的，保证沟通效率的前提下，文档不是坏东西，但是不要形式化，紧固流程和创造力。

产品图例

世间无限丹青手，一片伤心画不成。

  1. 概念模型图

抽象与建模的能力。”业务架构师“

概念模型图通常是用 UML 中的类图或传统的 E-R 图的结构来绘制，突出概念和关系，去询问自己每个概念实体和另外一个概念实体之间可能有的关系。理解和重现业务架构模型，把业务背后的逻辑关系抽丝剥茧整理清楚。

  1. 流程图，泳道图，时序图

流程图有一些图形规范：开始结束时圆角矩形，数据操作是矩形，判断是菱形等，基本就用到矩形和菱形。

泳道图：在传统的流程图上加入角色。

时序图需要好好学习一下。读图成本低，逻辑丰富。

  1. 状态图

image-20220807231010067.png

  1. 用例图

写好文档的方法

  1. 明确受众目的和形式

站在对方角度上，结合他们的思考维度，才能知道语言表达的逻辑和形式。

你希望他获得什么信息，做出什么决定，后续有什么动作。

  1. 知其所以然，然后知其然。

很多人只在文档中较低做什么，不交代为什么。

  1. 良好的阅读体验--金字塔原理，逻辑及格式
  2. 先写厚，再写薄

写文档需要不断地重读，裁剪，重构，修改和挑中。查缺补漏，是否表述不明确。不要急于求成，写好的东西放下一段时间（发酵），然后二次加工。

产品分析

自小秦楼望巧，吴机回锦，歌舞为谁

需求分析

谁的？ 什么问题？ 用什么方法？

谁的？： 利益相关者，用户

TO B和TO C的决策不同，采购系统的人可能并不使用这个系统，更多在意是否安全，是否稳定，价格等

能帮助我们完成进步的，恰恰是人类的天性本身。

重视解决的问题，而不是解决的方案。

收藏，不同形态产品的收藏功能背后要解决的问题是不同的。浏览器的收藏可能是为了重复访问。阅读工具是为了日后检索，所以需要准备标签和检索。

服务设计工具https://servicedesigntools.org/

知到蓬莱难再访，问何方法得长生。

解决方案

第一印象

需求评审

一句话： 需求评审应当是凯旋的钟声，而不是冲锋的号角

会前沟通，预习。 明确受众，目的。

小公司可能没有具体流程，在设计开发的过程中，还会不断沟通，明确需求，可能需求分析的过程直到产品上线的一刻才最终成型。这样的工作方式对于小团队可能是合适的，因为足够灵活，没有流程成本，但是也需要需求评审的过程。

项目管理

将者，智、信、仁、勇、严也。 孙武《孙子兵法》

项目管理中我们要能识别关键路径，清楚任务依赖，并且建立尽可能多的观察点，在问题发生前预警、问题发生时快速做出调整。这要求我们在脑子里或纸面上有一张完整的甘特图，即使出现问题，也能弄清楚可能的影响范围和应对措施。

  1. 人比事重要。士气
  2. 交付大于计划。不能过分拘泥于计划，因为过程中的一些意外自乱阵脚
  3. 正确看待项目管理工具
  4. 稳住才能赢
  5. 团结一心。影响力。

（I want to touch people with my art. I want them to say: he feels deeply, he feels tenderly.