读书笔记-《人人都是产品经理V1.1》

这是一篇读书笔记，读《人人都是产品经理V1.1》的笔记，有点像在学校上课的时候记的笔记，把苏杰老师讲的重点内容记下来，各种颜色。

============================================================================================================

第1章 写给-1到3岁的产品经理——前言

一个成长中的产品经理，期待和同学们一起，用好产品改变世界。

1. 为什么要做产品经理？

    好产品和坏产品都能改变世界，这里的产品泛指传统行业和互联网行业的产品，包括牙刷、门、电梯按钮、指路牌等。

    坏产品的例子：山上的路牌，一眼看上去容易让人走错；做成Z字形的盲道和盲道途中有电线杆；某网站的雷人提示框。

    好产品的例子：可回收和不可回收的垃圾桶；麦当劳洗手间的门和标识；马桶。

我最近遇到的坏产品，举个例子，我用途牛和同程APP分别买了一个一日游，途牛的APP上当日游玩结束后我不能发表点评，一定要隔夜之后，当天让我很窝火，其背后可能是用程序强行控制，而不是导游可以人工设置行程已结束吧（个人猜测，也有可能是导游懒……）。同程的APP在返程的大巴上就已经开始短信提醒可以点评了，猜测是导游人工提交行程已结束，允许用户进入评价阶段吧。虽然是个很小的事，但是影响心情……虽然并不会让我从此不用途牛了，毕竟，价格至上。 我最近遇到的好产品，举个例子，手机壳，前段时间淘宝上买了一个手机壳，翻盖的，收到的时候发现壳内侧还设置了卡袋，放交通卡、门禁卡的利器，尤其是去园区门口拿快递的时候，原来要分别拿手机和门禁卡，现在只要把门禁卡放手机壳里就行了，确实方便~

2. 我们是不是产品经理？

产品就是用来解决某个问题的东西。所以说，产品这个东西，可以是有形的实物，也可以是无形的服务，多种多样。而解决问题其实就意味着满足人们的需求，这样才能产生价值。本书里，产品是什么， 产品就是要同时解决用户的问题和公司的问题，一个都不能少！

书中列了BAT三家给公司的产品经理招聘信息，如下：

阿里巴巴产品经理招聘信息	百度产品经理招聘信息	腾讯产品经理招聘信息
工作职责：负责公司XX产品规划； 根据公司战略，负责产品发展的长期规划，保证业务指标； 深入了解XX方面的业务，挖掘用户的多种需求，不断推出有竞争力的产品； 根据产品效果及业务发展状态，不断改进产品； 组织资源实施产品，对其效益负责。	工作职责：对市场发展趋势有敏锐的洞察力和创新意识及良好的分析、研判能力，能够深刻把握用户需求； 制定所负责产品线的发展蓝图和实施路线图； 完成需求分析，发起产品研发项目，善于利用设计工具完成产品UC设计和Demo制作； 负责或配合其他部门制定产品运营计划，持续改善产品。	工作职责：负责XX某产品的策划、运营、管理； 负责用户研究，把握用户需求，实现用户需求； 负责公司产品推广、运营等情况跟踪，收集用户信息并根据市场情况提出产品开发和改进方面的建议，提出运营思路。
职位要求：熟悉互联网或软件产品整体实现过程，包括从需求分析到产品发布； 对工作充满热情，富有创造精神，能承受较大的工作压力； 3年以上软件开发或项目管理相关经验者优先； 有网站产品运营和发展相关经验者优先。	职位要求：本科以上学历； 熟悉XX业务者优先； 对项目管理的完整流程和环节有比较准确的认识，有实际经验者优先； 优秀的理解分析能力、沟通合作能力； 执行力强，善于组织协调并推动项目进展； 较强的自我情绪调节能力和自我激励能力； 具备严谨的工作态度、强烈的责任心和团队精神。	职位要求：本科以上学历，5年以上互联网产品设计经验； 熟悉互联网领域产品开发，管理和运营流程； 能通过数据分析等系统性方法深刻理解用户需求并予以满足； 良好的沟通能力和团队合作精神，出色的组织能力； 有良好的学习能力和人格魅力、能承受压力。

从以上三家公司对产品经理的招聘信息可以看出，互联网、软件行业中的产品经理与旧有的产品经理的概念不太一样。它更多的侧重产品本身 “从无到有”，“从有到优”的过程，更多地涉及了“ 产品规划、数据分析、用户研究、需求分析、功能设计、项目管理、敏捷方法”等内容，而不是如传统的产品经理那样，去做已经有了的产品之后需要做的诸如管理产品、推广和营销产品的事情。

产品经理概念的进化：

a.行业形态不同：成熟行业VS.新兴行业。

b.产品形态与成本结构不同：实物VS.虚拟物品； 传统行业有采购、仓储、物流等分工，产品研发出来以后还有大量的制造成本，互联网、软件产品更加集中在产品研发的过程。

c.生命周期不同：几年VS.几个月； 互联网、软件的项目过程本身更接近“艺术”而不是“技术”。

d.赢利模式不同：单一卖产品赚钱VS.多元赢利。

e.用户心态不同：花钱买VS.免费用； 花钱买的东西即使有不足，也会凑合着用，而免费的东西，稍有不足就换一个产品用，所以互联网、软件产品更重视用户体验。

  由于分派给产品经理的责任越来越多，有的公司开始质疑——对产品经理一个人来说，这样的负担是不是已经难以负荷。结果造成现在出现缩减产品经理的责任，让他更为专业化的趋势。至于要求产品经理专注的方向，则因公司或行业类别而不同……

  有时高科技企业会采取类似的做法，让产品经理专心处理产品在工程和技术方面的问题，而把大部分营销决定交给另外的职能单位来负责。在这种情况下，产品经理可能会变成产品技术/应用方面的专家，他最主要的工作就是支援、协助销售人员，至于了解市场和从市场了解产品利益等工作，则另有他人代劳。像这样把营销功能和产品开发活动分开来处理的做法也有风险：产品经理将失去和顾客间的联系，而且会因为对产品太过熟悉，以致丧失判断上的客观性。

  不管是企业想用怎样的专业取向，以便产品经理更容易地管理他的工作，很重要的一点是，请记住这个职位当初是为何而设—— 想要更了解产品与他面临的竞争情况，最终目的是要满足顾客的要求 。

管理的能力，其实就是“在 资源不足 的情况下把事情做成”的能力， 资源不足包括信息不足、时间不足、人员不足、资金不足。

3. 产品经理需要什么样的人？

官方说法	需要全面负责产品的整体实现过程
私下交流	因为产品经理这个职位比较新，所以具体要做哪些事情没有开发人员、测试人员明确，于是，干多干少全凭自己决定
事实真相	具体的职责不清楚，就意味着事情多起来没个谱，任何与产品有关的事情都可以是你的，总是闲不下来
官方说法	需要能承受压力、自我调节、自我激励，综合素质要求高
私下交流	看到这条就怕了吧，产品经理做的很多事情都是更看重质量而不是数量，所以很难用工作量和工作时间来衡量绩效，经常好几天没什么产出也正常。这时候你可千万别崩溃了
事实真相	可是，产品的任何方面、团队里其他人做的任何事情如果出了问题，产品经理都很可能要背黑锅
官方说法	对市场发展趋势有敏锐的洞察力，辅助决策公司战略方向
私下交流	你真的可以决定公司产品长什么样
事实真相	产品当然是老板生的，你也就是给它化个妆
官方说法	需要很强的沟通能力，出色的团队合作精神
私下交流	有很多机会展示你的想法，如果有兴趣的话，可以利用工作机会认识公司里的几乎每一个人
事实真相	你总是某个产品的信息交换中心，也是各方共同挤压的对象，哪边都不得罪真是一门艺术
官方说法	关注业界动态，对互联网产品兴趣浓厚
私下交流	因为你要了解行业的最新资讯，做竞争对手分析，所以需要不断去各种网站注册、试用，老板无法判断你是否在冲浪或瞎逛，全凭自觉
事实真相	这样时间久了是很痛苦的，整天被那么多垃圾产品恶心，自己做的产品看太多了更觉得恶心

做产品的大前提是要喜欢做产品 ，要搞清楚你是喜欢做产品经理还是喜欢做用户？ 比如抢车位游戏，用户是想怎样停车才能利益最大化，产品经理是想怎么设计让玩的人更多？

最在乎的是应聘者 有没有激情，是否够机灵、好学，逻辑思维是否清晰，沟通表达是否顺畅等。

常见问题：

1.谈谈我们生活中经常使用的一个产品，它解决了什么问题，要是你来改进，打算怎么做？

2.看电视/书/电影吗？举个例子分析一下它的目标用户。

3.说说你是怎么准备这次面试的。

研究几十家公司的产品经理招聘广告，把研究结果做成一份漂亮的调研报告，而后去应聘产品经理。

怎么做？---->做不做，做多少？

☆☆☆找到产品的灵魂。

爱生活，有理想，会思考，能沟通。

写给自己的话：

咋整，我觉得自己是个没理想，也不爱生活的人，勉强算是会思考，能沟通。……

要开始爱生活吗？从做饭写读书笔记写游记开始，已经连续带了9周的午饭了，即将迎来第10周；这是第3篇读书笔记，继续吧……

也许哪天就爱生活了，理想这种东西是什么呢？用好产品改变世界吗？也许吧……

会思考，我好像很懒……要积极主动思考……

能沟通，貌似问题不大。

我的背景：

做了一年多时间的开发，两年不到……

后来三年到现在跟着项目算什么呢？感觉像项目助理，也写写需求，写写制度，写写方法，做做方案，管管测试，支持投产，画画PPT，更多的时间投入在测试管控上，因为不停的进入各种测试……这三年感觉更往产品经理靠边，也就是靠边，成长的就是思考的能力，考虑问题的方向和角度得到了补全……但是还是不够。

凡事最重要的是搞清楚目的，确定目的之后再决定用什么策略用什么方法去达到，目的可以认为是用户需求吧。挖掘用户最终想要实现的目标是什么，然后提出可行的方案，推进落实。

第2章 一个需求的奋斗史——需求

1.需求的来源？

对产品经理来说，更重要的是“ 发现一个问题，然后设法将其转化为一个任务来解决 ”。

用户是需求之源，以用户为中心，体会真正的用户，不要试图满足所有的用户。

理解用户，是产品经理最重要的素质之一。

需求的本质就是问题，问题的本质就是理想与现实的差距。

不同的用户有重要程度之分，我们必须、也只能有所偏重。 “相比您的需求，我们可能更重视您的用户的需求”

以用户为中心的思想，以老板为中心的行动。

对于已经充分占据市场的产品来说，用户数不可能有爆发式的增长，只能考虑从已有的客户上深挖客户价值，即核心用户，优先满足核心用户的需求。

对于没什么用户的产品来说，当务之急是把池子做大，需要先做一些大众功能，优先满足一般用户的需求。

描述用户，建立用户角色，创建Persona。

用户研究是前提

第一轮：听用户定性地说，确定产品方向，做什么？

第二轮：听用户定量地说，确定需求优先级，先做什么？

第三轮：看用户定性地做，要先做的那几个需求，应该怎么做，一边设计一边做可用性测试。

第四轮：看用户定量地做，根据产品的用户使用情况做数据分析，不断改进产品。

X “经组织研究决定，用户需要一个XX功能” ，坚决杜绝！

2.需求如何采集？

到底采用哪种用户研发方法，往往取决于资源，比如人员数量与能力，老板给你多少时间、经费。如果资源非常少，我们甚至可能简化出很不正规的方法，比如只是查一些二手资料然后和同事们一起讨论，猜测一下用户是怎么想、怎么做的，而有了资源以后，我们可能会叫几个用户过来访谈，请咨询公司协助出报告，或者出差做用户调研等。每个人所处的团队条件不一样，也只能在实践中慢慢总结出适合自己的方法。

明确目标、选择采集方法、制定采集计划、执行采集、资料整理、需求分析阶段

※用户访谈

a.用户说的和做的不一致的问题；

b.样本少，以偏概全的问题；

c.用户过于强势，把我们往沟里带；

d.我们过于强势，把用户往沟里带。

避免一组固定的问题：准备好问题清单，但清单只起一个引导作用，并不用照着读。

首先关注目标，任务其次：多问问用户为什么这么做。

避免让用户成为设计师：听用户说，但不要照着做。

避免讨论技术。

鼓励讲故事：故事是最好的帮助设计师理解用户的方法。

避免诱导性的问题：典型的诱导问题是“如果有xx功能，你会使用吗？”一般来说用户会给出毫无意义的肯定答复。

※调查问卷

a.样本的偏差，即样本与想了解的目标用户群体出现偏差。 把目标群体的特征也定义成一系列问题，放入问卷中。

b.样本过少的问题。

c.问卷内容的细节问题。 不要问“你喜欢某个产品吗？”，正确的问法是“你是否喜欢某个产品？”

用户访谈和调查问卷的区别与联系？

用户访谈的提纲通常是开放式的问题，适用于我们心里还比较疑惑的时候去寻找产品的方向，适合于对较少的访谈对象进行深入的交流；而调查问卷通常封闭式问题比较多，适合大用户量的信息收集，但不够深入，一般只能获得某些明确问题的答案。我们经常通过前者的开放式问题，为后者收集具体的封闭式问题。

用户的特点：沉默与骑墙的总是大多数。

※可用性测试， 指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题。

a.如果可用性测试做得太晚，这时发现问题也于事无补了。 任何时候都可以做，初期可拿竞争对手的产品给用户做；拿着手绘的产品，加上纸笔给用户做；拿着Demo给用户做；拿真实的产品给用户做。

b.总觉得可用性测试很专业，所以干脆不做。

c.明确是测试产品，而不是测试用户。

d.测试过程中，组织者该做的和不该做的。 “发声思维” ，即在使用产品的同时说出自己的思考过程，比如为了完成某个任务，用户想先做什么，后做什么，为什么要做某个动作等。 做测试的过程千万不要有任何的引导与暗示，而只是观察和记录。

一切的错都是产品和我们的错，用户绝对没有错。如果真觉得用户错了，那也是你找错人了，不是这个人错了。

改版： （要把“暴力革命”变成温柔和谐的“和平演变”）

a.先从部分次级页面改起

b.新旧版本并存一段时间，允许用户自由选择

c.小面积试验，选择一小批测试用户放出新版本，监测效果，做用户调研

d.傍上一个用户已经习惯的风格

※数据分析

根据不同的目的，数据来源多种多样，常见的有用户使用产品的日志、客户管理系统里的信息、网页访问情况的统计信息等。

a.过于学术，沉迷于“科学研究”， 科学研究通常只注重“性价比”的性，只要结果好，方向新，往往不在乎投入；但实际生产环境中更注重综合的性价比。

b.虽然数据不会主动骗人，但我们经常无意或有意地误读数据。

c.平时不烧香，临时抱佛脚。 经常在做决策的时候才想起数据分析，但忽然发现手头没有数据可分析。应该在产品设计的时候就把数据分析的需求加进去，比如记录每个按钮的点击次数、统计每个用户的登录频率等。

数据分析是如何转化为商业价值的？

在对产品足够熟悉的基础上，先做出方向性的假设，再提取相应的数据并分析，得到一些现象，最好是之前没发现的现象，然后尝试解释，接下来做用户调研修正解释，最终指导产品发展方向。

单项需求卡片的理念： 产品的需求工作不只是需求分析人员的事，而是涉及产品的每个干系人的义务，至少得参与“采集”的过程。重点是描述用户场景，谁在什么时间、地点产生了何种需求。

其他需求采集方法：

a.现场调查

b.AB测试， 比如有一个按钮不知放左还是右，随机挑选1000用户放左，1000用户放右，根据数据分析结果进行最终决策。

c.日记研究， 使用体会，主要是业内人士会对各种产品写下各种使用体会，意见偏专业性。

d.卡片分类法，把各种需求写在便利贴上，让用户一起讨论并完成分类。

e.自己提需求

“需求驱动学习”

3.需求如何取舍？需求分析、需求筛选

用户需求VS产品需求

用户需求： 用户自以为的需求，并且经常表达为用户的解决方案。

产品需求： 经过我们的分析，找到真实需求，并且表达为产品的解决方案。

需求分析： 从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。

技术分析是“树干——树枝——树叶”的任务分解过程，

而需求分析是“首先：树叶——树枝——树干，其次：树干——树枝——树叶”的分析过程

满足需求的三种方式：

a.改变现状

b.降低理想

c.转移需求

需求转化： 把用户需求转化为产品需求

确定需求的基本属性： 编号、提交人、提交时间、模块、名称、描述、提出者、提出时间、缺陷ID

确定需求种类： 分类：新增、优化、体验提升、缺陷修复、内部需求等；层次：基础、扩展、增值

也可以从 雪中送炭 和 锦上添花 两个角度来理解需求

分析需求的商业价值： 重要性（可细分为满足后“一般”到“非常高兴”；未实现“略感遗憾”到“非常懊恼”）、紧急度、持续时间

确定实现难度： 工作量（人力成本）-->开发量，技术经理初次评估，然后再乘以一个系数（结合实际开发人员与技术经理自己的差距）得出开发量，一般以"人天"作为单位

绝对不能因为某个需求的实现难度很小就马上去做，也不能因为另一个需求的实现难度大就不做。

性价比： 商业价值/开发量

终极目标： 多快好省，即范围大、时间短、品质高、资源省。

任何时候都要保证项目品质，最后能变的只能是量—— 项目范围 。

注意：

a."需求打包"最好打包类似的功能点。

b.需求依赖，功能互相之间有依赖关系，同时还要考虑功能与人力资源之间的依赖关系。

c.需求的粒度大小问题，需求列表里出现的任意一行，工作量最好不要超过“5人天”。

商业需求文档（Business Requirement Document）：

项目背景（我们在哪里？为什么要做这个项目，解决什么问题）， ☆ 商业价值（我们去哪里？做了这个项目以后有什么价值，商业目标），功能需求描述，非功能需求描述， ☆ 资源评估，风险和对策

情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子。 当发现一个功能可有可无的时候，甚至只要是没有强烈的理由要做的时候，要明确的选择：不做！

尽可能多的采集，然后尽可能多的放弃。

4.需求如何管理？

阶段：需求采集、需求分析、需求筛选

列：需求状态（待讨论、拒绝、暂缓、需求中、开发中、已完成等）、负责PD、开发工程师、项目名称、发布时间、备注……

对新人来说，好的产品对我们的帮助会远远大于我们对产品的帮助，论好的公司、好的产品、好的老板的重要性。

写给自己的话：

刚好前段时间就经历了需求转化的过程，临下班前领导突然召我过去说要重新做一个绩效考核信息收集的表，然后噼里啪啦说了一堆，这就可以认为是用户的需求了，同时他还提出了他的解决方案。

然后顺着他的说我提了几个问题，表达了下现状，表示为什么要这样做？然后领导又开始噼里啪啦说了一堆……

经历了三次这样的轮回，终于变成了“产品需求”。

每次轮回得出的结论都不一样呀，事实证明最后的结果才是真的用户需求和解决方案，而不是一开始他以为的需求和方案。

这样想每个问题、每次会议的讨论，其实都是在发掘我们自己的需求，搞清楚我们自己到底想干什么，要怎么做才能实现我们的目标。

恩，现在是不是开始用产品思维来面向生活呢……每天前进一小步，偶尔退后一大步……功亏一篑。

某个周末在上海图书馆听了杜鸿飞先生的讲座，讲早期产品的低成本营销策略，归根结底，核心还是在于确定产品的核心功能是什么，目标用户是哪些，然后才是怎么向这些目标用户推广我们的产品。

现在是用户为王的时代哈。

我们现在的项目就完全没有考虑数据分析的需求，当然也有是企业内部系统的原因，但是个人觉得类似登录分析、菜单、按钮使用情况分析等还是很有必要的，有一些废了很大力气做的功能，可能完全没有人需要；有些蜻蜓点水般的功能，可能使用量很大。当然，也不是说完全没有人用的功能是不需要的，只是那个场景还没有发生……这些，都需要数据告诉我们答案。

同样，不仅仅是好的产品，好的项目对我们的帮助也会远远大于我们对项目的帮助，对我们这些普通人来说，兢兢业业的努力工作，对项目的帮助也许更多的是来自于我们的态度，而不是出众的能力，类似于减少了一些生产bug，让一些问题提前暴露了，并不会有决定性或突破性的变化。换了AorB，会有区别，但是这些区别不会产生特别大的，具有决定性的意义。

第3章 项目的坎坷一生——项目

1.产品和项目的异同？

产品VS项目

产品就是用来解决某个问题的东西。所以说，产品这个东西，可以是有形的实物，也可以是无形的服务，多种多样。而解决问题其实就意味着满足人们的需求，这样才能产生价值。本书里，产品是什么，产品就是要同时解决用户的问题和公司的问题，一个都不能少！

项目：只会进行一次，包含多项互相关联的任务，并且有绩效、时间、成本和范围限制的一项工作。

产品是一个解决问题的东西，而项目是一个过程。

维度	做产品	做项目
生命周期	相对较长，整个产品从规划到制造，再到最终维护和消亡。不可能有一个已经“完成”的产品	有特定的目标，生命周期较短，通过验收则表示项目生命周期就算完成了，会有一个已经“结项”的项目
具体要做的事情	随着各种内外部信息的变化，产品负责人需要不断地修正自己的判断，给出适宜的创新	在开始时就有明确的目标，更注重计划与控制
产出物	可批量生产，或提供给大量用户的，所以相对通用，通常考虑用有限的资源去满足更多的、能有更多回报的需求	只进行一次，每次都是定制的、个性化的，通常为了满足特定的需求，产出物也比较个性化

做产品的过程正是通过做一个又一个项目实现的，但并不是项目的简单累加。

产品经理VS项目经理

产品经理靠想，产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润。 关注的是做正确的事，关注的是产品生命周期，关注的是产品能否赚钱，能否持续地赚钱。

项目经理靠做，项目经理是把事情做正确，把事情做得完美，在时间、成本和资源约束的条件下完成目标。 项目能够按照目标完成则项目就是成功的，即使项目的产品不能真正盈利，那往往也是产品规划出现了失误。

项目经理关注的是项目能否按照既定的目标顺利完成。产品究竟应该规划哪些功能点，那是产品经理的事情，是项目范围的输入。

2.项目怎么启动？

※团队组建

※计划确定， 工作量=（最乐观+最悲观+最可能）/3 或 工作量=（最乐观+最悲观+最可能*4）/6

※启动， 誓师大会（项目背景，项目意义、目的与目标，需求、功能点概述，项目组织架构，项目计划，沟通计划）

做项目的本质就是在保证品质的前提下，在时间要求、人财物花费、项目范围三点上做平衡。

3.项目中PD要写的需求相关的文档？

※BRD：Business Requirements Document，商业需求文档。

其内容涉及市场分析、销售策略、赢利预测等，通常是给大老板们演示的PPT，比较短小精炼，没有产品细节，有点像创业者给投资人看的商业计划，主要是为了获得认可，争取资源。

※MRD：Market Requirements Document，市场需求文档。

包括可通过哪些功能来实现商业目的，功能、非功能需求分哪几块，功能的优先级等。

※PRD：Product Requirements Document，产品需求文档。

第一部分 总体说明

修订历史、项目概述、功能范围、用户范围、词汇表、非功能需求、其他说明

类图、用例图、状态图

第二部分 UC

※FSD：Functional Specifications Document，功能详细说明（用例，经常包含在PRD中）

UC概述：用例ID、用例名称、业务描述、行为者、前置条件、后置条件、其他说明

UC主体：界面描述、业务规则、流程描述

时序图、活动图、协作图、其他

※Demo

※概要设计与详细设计

a.不以写的东西是需求还是设计区分职责，而以“业务”或“技术”区分。 比如在业务上需要对“公司名称”的长度做何限制由PD确定，而“公司名称”的数据在数据库里如何存储，由工程师决定。

b.细枝末节的设计经常重复，PD应该和开发工程师一起协商，渐渐沉淀出产品规范。 比如通过几次协商，我们确定了以后产品中出现的各种字段的各种限制规范，下次再写UC的时候，只要引用规范即可，省去重复劳动。

※评审：需求评审、设计评审、测试评审

4.项目包括哪些阶段？

※开发阶段 ，设计、设计评审、编码、单元测试

※测试阶段 ，测试案例编写、评审、冒烟测试（绿灯）、功能评审、测试

※发布 ，发布评审、预发布、发布、线上验证

项目小结

5.项目怎么管理？

※文档，建立文档规范

模板的作用： 让经常看同类文档的人提高效率；让写文档的新人可以尽快上手；让写作者不会漏考虑某些内容.

版本管理

※流程

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

※敏捷

有计划，更要“拥抱变化”，不断地修正计划

迭代周期内尽量不加任务

集中工作，小步快跑

持续细化需求，强调测试

不断发布，尽早交付

无论最终发现了什么，我们必须理解并完全相信：每个人在其当时所处情况下，在其能力范围中，做了最大的努力。

PS. 看到这里才知道，“请赐予我力量，去接受我所不能改变的；请赐予我勇气，去改变我所能改变的；并赐予我智慧去分辨两者的不同”这句话，是写在“安东尼达斯的银币“上的。。。

写给自己的话：

我一直在做的都是项目，第一个项目是个研讨性的，因为各种原因历时半年就退场了，上个月刚看到当时的甲方一个专家发的一个帖子，后来还是采用了当时研讨的技术，略感欣慰，虽然和我p关系么有。第二个项目是项目外包，老老实实的做开发，需求变化也不是很离谱，没有超出控制范围，当然对项目经理来说是超了，个人感觉还ok。第三个项目就是现在这个已经跟了三年了……各种变化，T永远是大大大大领导给定的，每次大的迭代都要延期一次已表达当时计划是不够科学的，在大框架下不停的改变项目计划以赶上整体进度。小到测试计划就不用说了，改的和第一次已经看不出是同一个东西了。大到整个项目，小到一个模块一个功能点，都需要不停的修正测试计划，匹配开发进度，投产进度……

说到模板和流程这个东西，刚开始进项目组的时候领导叫我梳理，回想一下当时其实是心不甘情不愿的，觉得整这玩意没用。这三年到现在，还在不停的整各种模板，流程已经基本稳定了，但是，确实，有，梳理了，从来没有推下去过的流程……也有，从来没有推下去过的模板……这部分其实就属于不是频发的，只是当时为了特定的某个事，万万没想到以后就没有了。同样流产的还有方案，这个流程倒也是固定的，先写个方案吧，然后把流程定一下呗，模板梳理一下~...

每一个期次的迭代，都会有模板上的调整，说不上来是不是进步，也许下一个迭代，还会继续调整，当然，也有成功的模板一直沿用至今（few）。流程上小的优化还是存在，这都是进步！！！

感慨一下，最稳定的就是PPT模板了，哈哈哈哈，唯一的一次微调还是因为甲方领导换了的原因。

版本管理这个事，在我们的文档上，因为领导的强力及明智的要求，很早就用svn管理起来了，所以一直没有出过问题，偶尔出的问题，还是因为有时候目录调整，找不着了……这个文档树一直没有好好维护，找不着了或者找错了实在是囧……但是，但是，开发方那边的版本管理从开始吐槽到现在已经吐了三年了！！！无语凝噎。

沟通的问题，因为我们是外包方，甲方是内网，邮件用的相对少，一开始用的rtx，后来换成了espace，还是rtx好用啊。。。

人和人之间的信任……各种难以言明的……不能言喻的……

第4章 我的产品，我的团队——团队

所有和产品有关的事都是产品经理的事

五种用户群体：

a.创新者：新鲜感强，消费能力强，但是忠诚度不高，需要新鲜的东西不断刺激。

b.早期追随者：观念比较新，但是需求目的性很强，需要迅速能够解决其问题的产品。和创新者最大的区别在于，早期追随者不是为了尝试新技术而使用某产品，而是为了解决某些需求才使用。

c.早期主流用户：是产品大规模产生商业价值的用户群，典型的实用主义者，觉得正在使用的老产品也能解决问题，就不会更换，但心中还是对新产品存在期待。

d.晚期主流用户：早期主流产品对新产品有尝试的愿望，而晚期主流用户对新产品心存抵触。直到老产品已经渐渐地出现明显的劣势，才会很不情愿的使用新产品。

e.落伍者：最后一批用户。

一个公司的成功与否，所有的影响因素似乎都可以归结到商业、产品、技术三个方面。

产品设计的五个层次：

a.战略层，明确商业目标和用户需求，找准方向，重点是解决两者之间的冲突，找到平衡点。

b.范围层，明确“做多少”，对于软件类产品，是确定功能范围；对于网站类产品，则是确定内容范围。

c.结构层，考虑产品的各个部分互相之间是什么关系，对于软件类产品，主要工作有交互设计，对于网站类产品，主要工作有信息架构。常见的产出物有软件的业务逻辑图、网站的站点地图等。

d.框架层，对于软件类产品来说主要的工作是界面设计，对于网站类产品则是导航设计，两者都有的是信息设计。

e.表现层，包含了视觉设计和内容的优化。设计师和艺术家的区别就在于要满足的对象不同，一个是“你！你！你！”，另一个时候“我！我！我”。

从整体看是抽象到具体的过程，是从概念到实现的过程，又有一点从商业到产品到技术的感觉。

写作的五轮：搭建框架，填充文字，理顺逻辑，调整风格，后期制作。

《设计心理学》->《情感化设计》

本能水平设计，行为水平设计，反思水平设计

一些基础原则：反馈、容错、简化

※游走于商业与技术之间的产品团队

产品团队——心思缜密的规划师

产品经理及其带领的产品规划师、产品设计师和需求分析师

有大局观，逻辑严密，理智而冷静

从概念设计到信息架构

概念图描述的是整个产品的内外关系，形式并不重要，重要是表达出以下两点：产品与外界的关系、产品内部的关系

概念设计是为内部而做的，为了团队的沟通，便于大家对产品达成共识。

信息架构为外部而做的，为了设计出更合理的方式，把信息传递给用户。

“做什么”->“怎么做"

PD习惯从内向外，从本质出发；而用户习惯于从外向内，从表面看起。

用户体验团队——激情四射的设计师

规划师更多的是“结构化思维“，保证产品有用，能满足用户的某些需求，让产品”从无到有“；而设计师更多的是”形象化表达“，保证产品好用，能让产品用起来舒服，让产品”从有到优“。

每一个细节设计都是有理有据，包括每块区域的位置、长宽，每行文字的字体、字号，每张图片的颜色等，都不只是为了好看，而一定是与商业目标相符合的。 （需要进一步查阅相关资料）

文案问题：

低级阶段：错别字，病句，错误标点。

中级阶段：用词不统一，不准确。

高级阶段：语言风格不统一，产品气质不统一。

写给自己的话：

文案问题应该是一个用心就可以解决的事情，但是要保持时刻警惕也是个体力活，项目组里有的人从来不在乎，有的人一直保持警惕，想起有一天看厕所日报，一个人在同一天里提了五个问题，不到一百个字的问题描述里有四个错别字，也是蛮不容易的。时刻警惕……

产品里的文案越少越好，用户都是凭着自己的感觉去使用产品，通常不会去看帮助、不会去看说明书，甚至不会看页面上一句话的提示。

运营团队——阴险狡诈的运营师

产品做出来之后，不能直接向用户介绍功能，而是有一个把“功能转换为卖点”的过程，先要告诉用户产品“有什么用”，用户才有兴趣了解“怎么用”，之后要关注产品的市场反应，推动产品改进。

※商业团队

包装、定价、促销、销售（直销、分销）、渠道（代理、经销）

※技术团队

开发团队

测试团队

运维团队

※支撑团队，法务等

第5章 别让灵魂跟不上脚步——战略

价值观是社会成员用来评价行为、事物，以及从各种可能的目标中选择自己合意目标的准则。价值观通过人们的行为取向及对事物的评价、态度反映出来，是世界观的核心，是驱使人们行为的内部动力。它支配和调节一切社会行为，涉及社会生活的各个领域。

价值观是指一个人对周围客观事物（包括人、事、物）的意义、重要性的总评价和总看法。像这种对诸事物的看法和评价在心目中的主次、轻重的排列次序，就是价值观体系。价值观和价值观体系是决定人的行为的心理基础。

企业的价值观就是企业决策者对企业性质、目标、经营方式的取向做出的选择，是员工所接受的共同观念，是长期积淀的产物。

写给自己的话：

价值观这个问题，很难说清楚自己的价值观，但是对于自己接手的事情，应该认真努力的完成，不能保证时刻投入100%的精力（会有情绪问题），但是没有情绪问题的时候都应该投入100%的精力，情绪高昂的时候可以投入120%的精力，情绪低迷的时候可以低至60%，情绪问题是一个问题……这一年来已经有很大的改进了，继续控制自己的情绪，可以往高了调，但是不能在的低的时候敷衍……爱生活，爱生活，爱生活；

“虚”是由于你对某领域不熟悉而产生的感觉，只要用心去体会，就能发现任何事情都是有一套方法的。

使命（Mission）是指我们为什么而存在，要做什么事情，而愿景（Vision）是说我们希望成为什么。

可行性分析三部曲：我们在哪儿；我们去哪儿；我们怎么去？

PEST 分析的细分因素：

政治法律环境（Political Factors） ：国际关系、政治干预、方针政策、政治局势、国体与政体

经济人口环境（Economic Factors） ：宏观经济政策、经济基础结构、国家经济形势、经济发展水平、城市化程度、储蓄与信贷、消费结构、收入水平、人口变化

社会文化环境（Social Factors） ：风俗习惯、审美观念、宗教信仰、价值观念、语言文字、教育水平

技术环境（Technological Factors） ：自然地理因素、科学技术发展

SWOT，优势、劣势、机会、威胁

计划、路标、里程碑

多个项目并行的情况，可以看一些项目组合管理、管道管理的资料

不要试图在一个会议中解决很多问题。

大会决定小事，小会决定大事。

要想让会议不流于形式，就要把会议本身变成形式。

所有人提供意见，少数人讨论，一个人拍板。

高层定向，中层分解，基层执行。

制定目标时要遵循的 SMART 原则，S代表具体（Specific），M代表可度量（Measurable），A代表可实现（Attainable），R代表现实性（Realistic），T代表有时限（Time bound）

远视者把目的当手段，近视者把手段当目的。

多个目标间的权衡，多目标总会产生矛盾。

像商用软件这种专业产品明显是做给专业用户使用的，他们使用频繁，追求的是效率，所以更倾向于让人适应产品；反正，设计给新手用的产品必须是产品适应用户。

第6章 产品经理的自我修养——修养

爱生活让我们充满动力；

有理想让我们目标明确；

会思考让我们方法得当；

能沟通让我们团结前进。

每个人身边都有很多整天皱着眉头不开心的人，他们说不想上学、工作无聊、社会不公、朋友不好……而这样的抱怨对任何事情都没有帮助。所以我们不妨时刻微笑，像孩子一样好奇地观察这个世界。一个人只有拥有了积极、乐观、向上的人生态度，内心才会有爱，才会去积极发现生活中的美，才会有好奇心和创造力，才会愿意研究生活中的产品，才会爱上做产品这样一件改变世界的事情。

一个人与一家公司一样，最重要的，做事应该是 内驱 而不是外驱的。内驱的人是鲜活的，外驱的人更像是一个物化的工具，只会接受任务，成为别人实现理想的工具。

世界对每个人来说本是一片黑暗，你对世界认识的发展，就好比在一片黑暗的空间中，去不同的地方点亮一盏盏知识的小灯，然后看到一些情况并且猜测着还看不清的情况。当亮的灯越来越多，就可以不断修正对这个世界的认识。但少数人会突破一个拐点，开始“发现世界越来越简单”，突破拐点的一种表现就是有一些关键的灯被点亮了，渐渐发现黑暗中的世界原本是一个整体，有着根本的道理，很多事情底层的规则都是相同的，从而我们会觉得做起事来反而越来越轻松。一旦到了这个阶段，我们就会忍不住地去拼命点亮更多的小灯，试图看到这个世界的全貌，这其实是很痛苦的，因为你发现了方向与终点，但同时也知道必然走不到那里，也知道任何人都走不到那里，也许，真正强悍的人会把这个过程视为一种快乐。

PD第一卖—— 老板：需求、项目多得是，凭什么给你资源？

PD第二卖—— 其他PD：大家都很有想法，凭什么听你的？

PD第三卖—— 开发与测试：这样做很麻烦，值得吗？

PD第四卖—— 合作公司：凭什么帮你，给个双赢的理由？

PD第五卖—— 市场与销售：让我们High起来的产品，才有动力！

PD第六卖—— 服务、财务、法务：我们一直在擦屁股啊！

PD第七卖 ——客户：我要爽，搞清楚，钱都是我付的！

理论上严格意义的“充分沟通”是不存在的！换句话说，没有无失真的信息传输过程。

沟通不是为了说服，而是为了更好地认识世界。

我们的目的是尽快找出对方感兴趣的、熟悉的、擅长的、自己也懂一点的话题，从而成功破冰，尽快进入需求采集阶段。所以，要在去之前做一些功课，了解对方的行业、公司、老板。

解决问题的通用思路：

为了什么？做什么事，解决什么人的什么问题？何时做？谁来做？效果如何？

做某件事情“为了什么”是大前提，即战略。

后面的问题分别对应做事的前、中、后。

“做什么事，解决什么人的什么问题？”是事前需要考虑的，其中“什么问题”和“什么人”对应用户需求和目标用户，“做什么事”则是从用户需求转化而来的产品需求。

“何时做、谁来做”是事中关注的重点，对应项目和团队，着重讲的是计划、控制与执行。

“效果如何”是事后需要讨论的，总结、反馈一类的观点都是对这个问题的回答，想清楚了才能持续改进，不断提高。

不是每个人都能以产品经理为业，产品经理是一类人，他的做事思路与方法可以解决很多实际的生活问题。只要你能够发现问题并描述清楚，转化为一个需求，进而转化为一个任务，争取到支持，发动起一批人，将这个任务完成，并持续不断以主人翁的心态去跟踪、维护这个产物，那么，你就是产品经理。至少，你已经是自己的产品经理，这才是“人人都是产品经理”的真谛。