2015-9-1
好巧恰好是9月第一天，标题的书看到现在，对产品经理与各部门之间的关系大致清楚了，今天看到二百多页的时候，看到了可行性分析，应该是做具体工作时候要涉及的，在产品的创作过程中比较靠前的，基础的工序（PAGE232开始）。
可行性分析，书中说的比较幽默，分三步走，一是我们在哪儿，二是我们去哪儿，第三是我们怎么去（这个也是很通用的事物分析方法吧）。
第一步的具体工作：分析行业如何-市场扫描（pest方法）；竞争对手如何-竞品分析（appeals、搜索，行业报告，咨询公司）；自己情况如何-自我分析（swot分析）三部分。
第二步的具体工作：典型问题，细分市场是什么、目标用户是谁、要解决他们什么问题、满足他们什么需求。
第三步：分析的典型问题：用什么产品满足需求，产品的核心竞争力是什么。
产品规划明天补上。

第二章：一个需求的奋斗史

第二章：一个需求的奋斗史

单项需求卡片
单项需求卡片的理念就是：产品的需求工作不只是需求分析人员的事，而是涉及
产品的每个干系人的义务，至少得参与“采集”的过程

尽可能多地采集
需求采集，并不是产品设计之前的工作，而是一个贯穿始终的过程；它并不是产
品人员的事情，而是所有人的责任；它没有特定的方法，不管白猫黑猫，抓到老鼠就
是好猫；它并不怕发现什么荒谬的需求，而是怕遗漏合理的需求……这才是需求采集
的大生产运动。
最后再简单分享几个有特点的需求采集方法，希望大家能灵活应用，尽可能多地
采集。
现场调查。说简单一点就是打入“敌人”内部，和客户一起工作一段时间，深度
了解需求。它是一种典型的定性分析，持续时间长，从几小时到几个月，既能听到用
户怎么说，也能看到用户怎么做，不过受众面极其狭窄，一次只有一个，要特别小心
被“非典型”用户带到沟里去。
AB 测试。基于大用户量比较合适，比如有一个按钮不知道是放页面的左边好，还
是右边好，而我们有 10 万用户，那就先随机挑选少量的用户发布这个按钮，1000 人放
左边，另外 1000 人放右边，然后过一段时间分析结果，再决定剩下的 98%用户该怎么
办。很明显，这也是让用户直接参与了设计，这样低成本的方法让很多传统行业的同
学羡慕不已。
日记研究。互联网新兴的个人应用比较适合，某个新产品出来以后，很多业内的
朋友都会去尝试，然后写一些使用体会，但作为产品设计者在看这些日记的时候，要
明白日记的作者往往是同行，而不是主流用户。
卡片分类法。我们把产品的各种需求写在便利贴上，让用户一起讨论并完成分类。
这能让你深入了解用户是怎么给产品划分模块的，用户认为这个网站应该是什么结构。
因为产品设计人员的思维和用户的思维通常不一样，这也就导致了如果是产品设计师
来单方面决定网站结构的话，很可能导致用户理解的困难，所以卡片分类法能让最终
的产品更加符合用户的心理模型。
自己提需求。这是最简单的方法。每一个靠谱的产品都会有一群粉丝用户，不用
你去找他们采集需求，他们也会给我们惊喜，主动提出很多需求，作为产品的主人，
我们好意思还没有用户了解产品么？产品要用才能感觉出好坏，特别是自己做的产品。
产品做多了，我们随便看看别人做的产品，总能一下子挑出很多问题，提出很多需求，
反过来看自己的产品越看越完美，这一定有问题，所以必须用自己的产品，最好是发
动认识的人都来用。
需求采集的各种新方法层出不穷。和学习任何领域的知识一样，建议大家在了解
知识框架后，坚持“需求驱动学习”。

百度贴吧粉丝节这个夏天火热开启，这是一场属于粉丝的嘉年华，一次感恩粉丝的空前盛宴。
群星云集工体，爱豆亲自为粉丝团颁奖，前所未有，你准备好了吗
现在报名，即有机会参与线下颁奖盛典，详情请戳查看详情

用户需求 VS.产品需求
用户需求：用户自以为的需求，并且经常表达为用户的解决方案。
产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。
需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需
求的过程。
听到过一个说法，说需求分析与常见的技术分析最大不同是思路的本质差异，技
术分析是“树干——树枝——树叶”的任务分解过程，技术人员很适应并乐于用这种
方式思考，可以把大问题分解成小问题，发现难点逐一攻克。不少需求人员都是做技
术出身的，所以开始往往会用这种思路做需求，听到客户提出的功能点，直接想怎么
做系统设计了，这导致有时候需求分析甚至已经越俎代庖到“详细设计”的职责了。
大多数人在生活中也习惯于用这样的思路来对付问题，而真实情况是，需求分析是“首
先：树叶——树枝——树干，其次：树干——树枝——树叶”的分析过程，所以说完
整的需求分析是一个“分-总-分”的过程。一方面不能漏掉提炼用户需求的这个过程，
目的是透过现象看本质，另一方面也不能停在本质上，试想如果做到“树干”就结束，
后端的执行人员可能还是不知道要做什么东西，所以我们还要继续把树干再重新分解
成树枝、树叶。

初评需求的实现难度
绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不做
首先简化为人力成本，即工作量
其次，我们把工作量再简化为开发量

需求打包注意点：、
第一，“需求打包”最好打包类似的功能点
第二，需求依赖，功能互相之间有依赖关系
第三，需求的粒度大小问题

项目的坎坷一生
我 们 从 三 个 方 面 来 比 较 “ 做 产 品 ” 和 “ 做 项 目 ”
第 一 从 生 命 周 期 的 角 度 来 看
做 产 品 的 生 命 周 期 相 对 较 长 ， 关 注 的 是 整 个 产 品 从 规 划 到 制 造 ， 再 到 最 终 维 护 和
消 亡 的 整 个 过 程 。 而 项 目 有 特 定 的 目 标 ， 所 以 生 命 周 期 较 短 ， 通 常 在 项 目 开 始 以 前 就
有 明 确 的 起 始 和 结 束 时 间 ， 通 过 验 收 则 表 示 项 目 生 命 周 期 就 算 完 成 了 。
我 们 要 开 始 做 一 个 产 品 的 时 候 ， 没 法 明 确 这 款 产 品 何 时 “ 结 束 ” ， 一 般 会 随 着 时
间 的 推 移 、 市 场 的 变 化 、 公 司 战 略 调 整 等 因 素 ， 渐 渐 走 向 “ 生 命 周 期 完 结 " 所 以 ，
会 有 一 个 已 经 “ 结 项 " 的 项 目 ， 但 不 可 能 有 一 个 已 经 “ 完 成 ， ， 的 产 品 〈 只 有 不 断 完 善
中 的 产 品 ， 除 非 它 被 新 产 品 替 代 ） 。
第 二 ， 从 具 体 要 做 的 事 情 来 看
做 产 品 的 过 程 ， 会 有 更 名 的 探 索 ， 随 着 各 种 内 外 部 信 息 的 变 化 ， 产 品 负 责 人 需
要 不 断 地 修 正 自 己 的 判 断 ， 给 出 适 宜 的 创 新 ； 而 项 目 在 开 始 时 就 已 经 有 明 确 的 目 标 ，
更 注 重 计 划 与 控 制 ， 项 目 的 过 程 很 像 是 执 行 一 个 任 务 。 当 然 ， 也 有 很 多 事 情 无 论 是
做 产 品 还 是 做 项 目 都 必 不 可 少 的 ， 比 如 与 团 队 成 员 的 协 调 沟 通 ， 对 未 来 一 段 时 间 做
出 计 划 等 。
第 三 ， 从 产 出 物 的 角 度 来 看 。
产 品 是 可 以 批 量 生 产 ， 或 者 提 供 给 大 量 用 户 的 ， 所 以 相 对 通 用 ， 通 常 考 虑 用 有 限
的 资 源 去 满 足 更 名 的 、 能 有 更 多 回 报 的 需 求 ； 而 项 目 只 进 行 一 次 ， 意 味 着 每 次 都 是 定
制 的 、 个 性 化 的 ， 通 常 为 了 满 足 特 定 的 需 求 ， 产 出 物 也 比 较 个 性 化 。 这 就 意 味 着 ， 项
目 要 满 足 那 个 特 定 的 需 求 ； 当 然 我 们 会 看 到 有 的 项 目 产 出 物 经 过 改 造 ， 成 为 更 通 用 的
产 品 ， 或 者 有 的 产 品 也 可 经 历 “ 个 性 化 定 制 ” （ 即 做 项 目 ） 。
“ 做 产 品 ， 和 “ 做 项 目 " 也 是 分 不 开 的 ， “ 亻 故 产 品 ” 的 过 程 ， 正 是 通 过 做 一 个 又
一 个 项 目 实 现 的 ， 但 并 不 是 项 目 的 简 单 累 加 。 在 产 品 渐 渐 满 足 目 标 用 户 群 体 的 通 用 需
求 后 ， 继 续 做 下 去 的 话 ， 会 使 产 品 成 为 项 目 的 集 合 体 ， 臃 肿 不 堪 ． 因 此 我 们 就 需 要 细
分 市 场 ， 这 时 候 产 品 可 能 升 级 为 “ 产 品 线 ” ， 按 不 同 的 细 分 市 场 ， 推 出 不 同 的 产 品 ，
表 现 形 式 上 叫 版 本 、 模 块 、 增 值 服 务 ， 什 么 都 行 ， 本 质 上 是 通 过 合 理 地 安 排 项 目 来 实
现 产 品 的 规 划 。