《人人都是产品经理》之谈需求-谈项目-谈团队-谈战略-谈修养

前言

• 苏杰用他的产品经历讲述的生动的描绘出做产品的一生，以第一人称的方式表达了自己的想法和经验。
• 那么，究竟什么是产品br> 产品就是用来解决某个问题的东西。

谈需求

• 用户是需求之源
  

• 常用的需求采集方法
  

• BRD怎么写，都包含哪些内容/strong>
  项目背景：我们在哪里什么要做这个项目，解决什么问题，可以列出一些数据说明项目的必要性。
  商业价值：我们去哪里关键的重点！大老板们最感兴趣的，做了这个项目以后有什么价值，一定要说在点子上。一般我们还会预测一下相关数字的变化，提出这个项目的商业目标。
  功能需求描述：我们怎么去过做哪些事情来达到目标，把打好包的需求描述一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系。当然我们也经常会搞点技巧性的东西，比如故意加入一些让老板砍的需求，希望老板砍完之后心有愧疚不好意思再砍我们真正想做的东西，这有点类似谈判技巧里的玩意，大家可以试试，但不要在这上面太花心思了。
  非功能需求描述：提一下重要的非功能需求，如果有的话。
  资源评估：第二个重点！大老板们要看成本，他们在了解达成项目的目标需要多大的花费以后，才能做出决策。
  风险和对策：有的项目会有一些潜在风险，这个时候不妨抛给老板们看一下，并且给出自己的对策，说不定你觉得是很大的麻烦，在老板那里一句话就可以搞定。而且由于信息的不对称，我们无法了解某些功能是否会与公司将来的战略冲突，这时候提出来也是让老板们把一下关。
  从BRD中的“商业价值”、“资源评估”两个重点中大家可能也发现了，其实本质上大老板们也是在追求那个词——性价比。大家都希望花费最少的资源获得最大的商业价值。

• 管理好每个需求的去留
  在这个过程中，需求会越来越多，永远做不完，就像工作永远做不完一样。而我们要做的事情是，在资源限制下找到最有价值的需求，然后把它做好。那么，新的问题产生了，我们得找个办法把越来越多的需求管理起来。
  一个需求的生老病死
  

谈项目

做产品 VS 做项目
我们从三个方面来比较“做产品”和“做项目”。

• 第一，从生命周期的角度来看。
  做产品的生命周期相对较长，关注的是整个产品从规划到制造，再到最终维护和消亡的整个过程。而项目有特定的目标，所以生命周期较短，通常在项目开始以前就有明确的起始和结束时间，通过验收则表示项目生命周期就算完成了。
  我们要开始做一个产品的时候，没法明确这款产品何时“结束”，一般会随着时间的推移、市场的变化、公司战略调整等因素，渐渐走向“生命周期完结”。所以，会有一个已经“结项”的项目，但不可能有一个已经“完成”的产品（只有不断完善中的产品，除非它被新产品替代）。
• 第二，从具体要做的事情来看。
  做产品的过程，会有更多的探索，随着各种内外部信息的变化，产品负责人需要不断地修正自己的判断，给出适宜的创新；而项目在开始时就已经有明确的目标，更注重计划与控制，项目的过程很像是执行一个任务。当然，也有很多事情无论是做产品还是做项目都必不可少的，比如与团队成员的协调沟通，对未来一段时间做出计划等。
• 第三，从产出物的角度来看。
  产品是可以批量生产，或者提供给大量用户的，所以相对通用，通常考虑用有限的资源去满足更多的、能有更多回 的需求；而项目只进行一次，意味着每次都是定制的、个性化的，通常为了满足特定的需求，产出物也比较个性化。这就意味着，项目要满足那个特定的需求；当然我们会看到有的项目产出物经过改造，成为更通用的产品，或者有的产品也可经历“个性化定制”（即做项目）。

产品经理 VS 项目经理

我们接下来很自然就会想到产品经理和项目经理，他们有何异同br> 一个是Product Manager，一个是Project Manager，工作都需要跨团队，工作范围也有重叠，简称还都是PM，工作中我们自己都经常搞不清在说哪一个。

• 产品经理——靠想。产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润。
• 项目经理——靠做。项目经理是把事情做正确，把事情做得完美，在时间、成本和资源约束的条件下完成目标。

用我自己的话总结，就是：一个内部驱动，一个外部驱动。

评估“工作量”并推算出“工期”。
常用的方法是“三点估算法”，即评估出最乐观的工作量、最悲观的工作量、最可能的工作量，然后按下面的公式估算出工作量：
“工作量 =（最乐观+最悲观+最可能）/3”
或“工作量 =（最乐观+最悲观+最可能×4）/6”

这里的工作量粒度也会比初评的时候细，至少精确到“1人天”，短期项目甚至是“1人小时”，按照经验，我们的“1人天”通常等价于5～6“人小时”，而并不是按照一天工作8 小时计算，因为每个人都很难保证持续高效，并且不被其他事情打断。
而对于项目经理来说，需要在更大的粒度上把开发计划、测试计划、发布计划等合并成为项目计划，并确定项目的几个里程碑，也是监控点，通常是需求完成、编码完成、发布上线，在项目进行中，一定不要忘了这最初的约定！
做项目的本质就是在保证品质的前提下，在时间要求、人财物花费、项目范围三点上做平衡。

产品需求文档，PRD
一份实际的PRD模板目录与结构示意图

产品Demo
也经常被说成是产品原型、演示版。

• 用例里最多只能放Demo的截图，所以如果要表现更多交互和视觉的细节，Demo是必须独立存在的。现在应该有一些可以嵌入富媒体内容的文档方式，可以直接把Demo嵌入用例，不过我们没有尝试过，周围也尚未看到有人用。
• Demo最好是由用户体验部门的同学主导，当然你在的团队可能并没有这样一个叫User Experience，简称UE的部门，那么做这个事情的人也许叫用户体验师、交互设计师、视觉设计师，甚至是比较过时的称呼——美工。

Demo也会经历从低保真到高保真，从抽象到具体，从全局到细节的渐变过程。

产品不同，用到的Demo工具会不同（铅笔加A4纸、Visio、PPT、PhotoShop、Word、Axure、Dreamweaver）

日常需求发布流程

• SVN，对权限的控制比较精细，有几次保密项目用得挺顺；
• VSS，只在和微软合作的项目中用过，感觉更复杂一点。

流程是一种手段

• 长视者把目的当手段，短视者把手段当目的。
• 当年的“英雄”把自己的个人经验转变成显性知识表达出来，而对于经常做的事情，就可以用流程这种形式固化、传承，后人在做这些事的时候起码不会太无助。在这点上，规范、模板的作用也类似，这就是团队的核心竞争力。

敏捷也是一种手段
特点

• 有计划，更要“拥抱变化”；
• 迭代周期内尽量不加任务；
• 集中工作，小步快跑；
• 持续细化需求，强调测试；
• 不断发布，尽早交付。

敏捷沟通

• 从沟通扩大至整个敏捷方法，任何团队都在探索一个介于“无过程”和“过度过程”之间的折衷方案，使之给团队带来最大的收益。

“项目的坎坷一生” 详图

游走于商业与技术之间

产品团队简图

• 用户研究员（User Researcher），一看就知道，是做用户研究工作的，他要利用各种方法进行用户研究，给产品决策提供建议。
• 交互设计师（Interaction Designer），他要负责人机交互界面、用户操作流程的设计，典型的工作有导航设计、信息设计等，必须要了解很多商业的内容，理解功能的商业价值。
  举个例子，比如在商业目标是“注册用户数”的前提下，去设计注册流程是一页搞定还是分几个“下一步”，出错提示如何处理，等等。
• 视觉设计师（Visual Designer），在很多小作坊被简称为“美工”，他与交互设计师的界限也挺模糊的，他们主要做视觉设计，即用户第一眼看到的效果，比如页面结构、配色方案、字体字 、按钮的形状、颜色、大小、质感，等等。
• 前端工程师（Web Developer），互联 行业特有的一个偏技术的职位，要运用前端技术进行Web页面的开发，实现产品体验的良好传达。我们在 页上看到的各种很炫的效果，通常都是他们的杰作。

“阴险狡诈”的运营师

• 如果说规划师是产品的父母，把产品生出来；设计师是产品的老师，把产品教育好；那么运营师就算是产品的老板吧，他们要把产品卖出去，让产品从“叫好”到“叫座”，让更多的人愿意使用产品。

产品与运营的战与和

• 客观地看，不论是高层、运营，还是产品团队做的事情，都是在平衡短期与长期利益。有时候产品与运营共同承担商业指标会好一些，但运营的同学总会显得急一些，他们希望尽快看到效果，而产品的同学则热衷于练内功，好在大家的根本目的是一致的，只是这个度需要双方共同寻找平衡点。

商业团队，冲锋陷阵

有这样两种工程师

• 一类是技术痴迷者，常见于工作不久的新人，或者少数工作很久且一直醉心于技术的牛人。
• 另一类是实用主义者，常见于工作过一段时间的老人，或者只是把技术当作工具的工程师。

如何与工程师合作

• 第一，综合大家的需求，大家最看重的居然是一个很大的话题：“流程”，但仔细想想就一点都不奇怪了，一群超级理性的人很明白“没有规矩，不成方圆”的道理，他们喜欢被规则管理而不是被人管理
• 第二大的问题就是“沟通”，这是团队合作必不可少的一个环节。站在PD的立场上，我们会把自己作为产品的中心，这个角色注定要和各种各样的人交流，客户、老板，以及开发、运营、测试、客服、合作等部门的同事。
• 第三点是PD要不断提高自我修养，大家希望PD给出的文档在质量上更进一步，准确、全面、简洁，即时更新、保持最新。

支撑团队简图


谈战略

触及产品的灵魂
我觉得做产品经理、PD，或者说产品设计师都有三个境界：

• 第一层，产品帮助我们。这时候，我们的思想还不是很成熟，做什么产品，只能被动接受地安排，且可以在做的过程中迅速提高自己各方面的能力。
• 第二层，产品与我们互相帮助，共同提高，我们仍然离不开产品，不同于第一层的是，这时候产品也离不开我们了。
• 第三层，我们帮助产品。我们开始占据主导地位，能够帮助产品开拓局面，如果觉得高层的方向不对，有能力和意愿去寻找，甚至创造自己信仰的产品。

以价值观为根基

• 产品的灵魂，或者说企业的灵魂是什么，探到最深处，是由价值观（Value）决定的，而企业的价值观就是：企业决策者对企业性质、目标、经营方式的取向做出的选择，是员工所接受的共同观念，是长期积淀的产物。

阿里巴巴的价值观


仰望战略会议
俗话说“高层定向，中层分解，基层执行”，务虚的战略会议是经验丰富的人在掌握了极多信息的基础上做出的预测与判断，并不只是海阔天空的闲谈。只有这样的“找出问题、发现机会”的过程才真正体现出人的价值，从某种程度上讲，这才是最最不可替代的事情，或者说没办法自动化之后交给机器做的事情。

• 如何准备战略回顾会议上的演示，总体来说我觉得围绕大纲的13个问题可以分为四部分。
  第一部分：
  1.上次会议讨论的重点问题是什么br> 2.关于这些问题我们达成了哪些一致意见br> 3.上次会议中哪些问题由于缺乏信息考证，具有不确定性因素等原因而未能解决br> 4.上次会议哪些执行计划通过了于这些执行计划我们有哪些主要设想br> 上面四条都是回顾上次会议中的信息，把大家带入状态，这些细化的问题可以让我们在做演示准备时不会漏掉任何重要的内容。
  第二部分：
  5.自上次讨论会议后外部发生了哪些主要变化br> 6.自上次讨论会议后采取了哪些重要行动及这些执行对战略和财政产生的影响br> 7.上次会议后我们搜集了一些参考信息，根据这些信息考虑是否要对当初设想的执行计划作些调整。
  继续回顾，但是重点变成了上次会议结束到本次会议开始这段时间内的问题。
  第三部分：
  8.我们今天讨论的重点是什么br> 9.你们提议的执行计划是什么初的设想和决定的理由br> 10.我们怎样实践这些设想和确定减少潜在的不确定因素。
  11.今天要讨论和做出的决定是什么br> 面对这么多回顾的信息，今天要做的事情则是重中之重，每个问题都需要很多的工作来支撑。
  第四部分：
  12.从上一轮的战略回顾中我们学到什么样在下一轮中学到更多br> 13.怎样改进战略回顾会议和会议进行方式br> 持续改善，考虑如何将“战略回顾”这件事情做得更好。

KPI

• KPI，即Key Performance Indicators，关键业绩指标，它是在分解企业战略目标的基础上，分析并建立各子目标与主要业务的联系之后提出的。可见，KPI是企业目标的具体表现，所以不一定只是常见的营收、利润、用户数，也可以是客户投诉率、员工满意度、 会贡献等。
• 企业战略往往很难让每一个员工都充分理解并为之奋斗，自上而下的分解并设定每个基本战斗单位的KPI，是一种很好的简化方案。

谈修养

四大修养，分别是：爱生活、有理想、会思考、能沟通。这四节，谈到了四个方面，它们也有递进的关系：

• 爱生活让我们充满动力；
• 有理想让我们目标明确；
• 会思考让我们方法得当；
• 能沟通让我们团结前进。

爱生活
爱生活，才会爱产品。
我们发现自己产品的用户们也很热爱生活，要不我怎么老说“人人都是产品经理”呢，这个世界就是因为有了这么多有爱的人而变得越来越可爱。

有理想
有明确理想的人，会过得很开心，也会很让别人敬佩和羡慕。一个人活着的终极目的是获得内心的安宁，我的理解是：做事可以follow your heart，感觉这辈子过得不后悔。只要为理想努力过、付出过，在通往理想的路上不停地走，最终是否走到已经不重要。所以，我觉得有理想的人，本质上还是为了自己。

个人品牌建设

就业保障会降低一个人的竞争力，职业保障可以提高竞争力，假设有一天，公司突然不需要你了，这时候你不用去找工作，而是有一堆公司马上排着队请你去，这才是真正的保障。

个人名片设计实例
正面：


任何事情，需要同时有能力和意愿才能做好。“活到老学到老”，需要激情与理想做支撑，思维方法做指导，才能不断前进，产品经理这个岗位涉猎的知识领域太多，只有保持不断学习的习惯才能胜任。

能沟通
我的沟通理念

• 理论上严格意义的“充分沟通”是不存在的！
• 沟通不是为了说服，而是为了更好地认识世界。

职场中的点对点沟通




四种一对一沟通方式比较

• IM：成本最低，适合不紧急不重要的沟通。
• 电话：成本适中，适合紧急不重要的沟通。
• 面谈：成本最高，适合紧急且重要的沟通。
• E-mail：成本适中，适合重要不紧急的沟通。

职场中的群体沟通

• 群体沟通正好对应前面说的单点沟通方式，它也有四种方式：IM群，电话会议或视频会议，会议，群发邮件，从“紧急、重要、成本”三个维度上看与点对点沟通类似。

---

我觉得产品经理应该是通才，本行功夫自不必说，要能出彩，更重要的是外家的功夫，所谓“功夫总是在诗外”。

---

有14个模板，它们的名称及在书中出现的位置如下：
1、第2章提到的
① 人物角色（Persona）实例：2.1.2
②用户访谈实例：2.2.1
③ 调查问卷实例：2.2.2
④ 单项需求卡片模板：2.2.5
⑤ 商业需求文档（BRD）模板：2.4.1
⑥简易需求管理模板：2.3&2.5 2
第3章提到的
① 项目组织结构模板：3.2
② 产品需求文档（PRD）模板：3.3.1
③用例（UC）文档模板：3.3.1
④ 项目日 周 模板：3.4
⑤ 项目发布通知模板：3.4 3、
第5章提到的
①产品路标规划实例：5.3.1
② 会议记录模板：5.3.2
③ 其他书中未出现的
④ 个人日 周 模板
（已上传资源）

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！