《人人都是产品经理》读后笔记20130305

最近在看《人人都是产品经理》这本书，这本书给我的感觉就是比较通俗易懂,由浅及深的阐述方式易于理解，善于运用故事来说明观点，适合初学者。为了整理一下自己思路，特意把自己看过且觉得是重点的部分记录了下来... ....

全书的结构，如图示：

第一章：写给~1到3岁的产品经理

主要介绍为什么要做产品经理，现在我们到底是不是产品经理，我们真的想做，怎么入行以及作者入行三年的简要介绍。（可直接跳过）

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

重点一：用户研究

用户研究的方法，如下图所示：

横向，用户的说和做。

怎么说表现了目标和观点，怎么做反映了行为，用户怎么说和怎么做经常是不一致的。 纵向，定性与定量

定性研究可以找出原因，偏向于了解；而定量研究可以发现现象，偏向于证实， 说和做、定性和定量，合理的打牌组合使用，才能发挥最大的作用。

重点二：需求采集

1.需求采集过程：明确目标、选择采集方法、制定采集计划、执行采集、资料整理，然后进入下一步的需求分析阶段。

2.需求采集方法：

2.1常用的需求采集的方法，如图示：

2.1.1 定性的说：用户访谈------->【用户访谈的常见问题与对策】

第一：“说”和“做”不一致的问题。【对策：尽量在用户可以和产品交互的场合下进行，让用户在“说”的同时也“做”】。

第二：样本少，以偏概全的问题。【对策：选择样本，尽量做到随机；尽量识别出各种可能引起的偏差因素；以增量的方式进行访谈】。

第三：用户过于强势，把我们往沟里带。【对策：牢记访谈的目的】。

第四：我们过于强势，把用户往沟里带。【对策：牢记访谈的目的】。

2.1.2 定量的说：调查问卷------->【调查问卷的常见问题与对策】

第一：样本的偏差，即样本与想了解的目标用户群体出现偏差。【对策：样本选择尽可能覆盖目标群体中各种类型的用户；可以把目标群体的特征也定义成一系列问题，放入问卷中】。 第二：样本过少的问题。【对策：只是得有100份的问卷】。

第三：问卷内容的细节问题。【对策：进行小范围的试答，根据反馈修改后，再大面积投放】。

2.1.3 定性的做：可用性测试------->【可用性测试的常见问题】

第一：如果可用性测试做得太晚(往往在产品将要上线的时候)，这时发现问题也于事无补了。 第二：总觉得可用性测试很专业，所以干脆不做。

第三：明确是测试产品，而不是测试用户。

第四：测试过程中，组织者该做的和不该做的。

2.1.4 定量的做：数据研究------->【数据的常见问题】

第一：过于学术，沉迷于“科学研究”。

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

第三：平时不烧香，临时抱佛脚。

2.2 需求采集其他方法：现场调研、AB测试、日记研究、卡片分类法、自己提需求。

2.3 二手需求采集工具：单项需求卡片 ，模板如下图:

重点三：需求分析：

1.用户需求和产品需求的区别：

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

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

2.需求分析的概念和过程:

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

3.2.2 需求分析过程：“首先：树叶——树枝——树干，其次：树干——树枝——树叶”，即需求分析师一个“分—总—分”的过程。

需求分析过程如下图：

步骤1：把用户需求转化为产品需求；

步骤2：确定需求的基本属性；

步骤3：分析需求的商业价值；

步骤4：初评需求的实现难度；

步骤5：计算需求的性价比；

3.满足需求的三种方式：

3.3.1 改变现状

3.3.2 降低理想

3.3.3 转移需求

4.需求分析总结：伟大的需求分析师，可以无视用想要的东西，去探究他内心正在的渴望，在给出更好的解决方案，用户正在需要的东西，这就是我们存在的价值。

重点四：需求筛选

1：需求筛选的过程：把需求打个包----->利用商业需求文档，在产品会议上提出需求并认可需求。

名称解释：BRD、MRD、PRD

BRD：Business Requirement Document ：商业需求文档

MRD: Market Requirement Document ：市场需求文档

PRD: Product Requirement Document ：产品需求文档

BRD包含的内容如下：

项目背景、商业价值、功能需求描述、非功能需求描述、资源评估、风险和对策。

2：需求筛选原则：情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子。

3：需求的生命周期，如下图：

第二篇：《人件》读后感

人在软件工程中的定位

——读人件有感

刘胜男 11计科一班 110507140120

初学软件工程导论这门学科，听老师说过《人月神话》和《人件》这两本书，它们被誉为软件图书中“两朵最鲜艳的奇葩”。于是我迫不及待的借了《人件》一睹它的风采。这两本书关注了软件开发过程中两个不同的方面，《人月神话》注重于“软件开发”本身，而《人件》则是强调了软件开发中的“人”。我选择了《人件》这本书来写读后感。

看完《人件》这本书，发现全书中基本没有涉及到任何软件技术，但作者精辟的探讨了专业软件团队管理这一非常专业的话题。怎么把团队做好，这是一个大问题。只有做好团队，才能做好软件。《人件》提到，软件工程本质上其工作的主要问题，与其说是技术问题，不如说是社会学问题。记得有位老师也曾提过三分技术，七分管理，我想道理应该是一样的。《人件》告诉我不是因为技术更重要，而是因为它更容易做。的确如此，人际关系是很复杂的，大家都希望尽快做完项目，一味的去追求代码的速度，而没有人愿意去管岌岌可危的人际关系，因为人们的天性就是用对自己有利的方式去解决问题，与人沟通这种能力恰恰是整日埋头编码的程序员所缺乏的。

而对于编程这件事，从大一到大三，也编过不少程序了，但在考试的压力下我总认为一个程序越少出错越好。而《人件》告诉我对大多数脑力劳动者来说，偶尔犯一个错误是自然的，也是工作的一个健康组成部分。尽管整个团队的技术平均水平也许会因为采取的任何

限制错误的措施而得到适度改善，但是团队社会学却会受到严重损害。所以当人们犯错时，作为项目经理应该鼓励他们。

《人件》内提到大多数程序员都是热爱自己的工作的，这一点我不太清楚，因为不太了解计算机从业人员是否都热爱编码这一过程。假设这条是正确的，那么“管理就是赶驴”这句话就有待商榷了，开发与生产不同，一个进行脑力劳动的人要进行思考，他有自己主动的因素抽象化并忽略掉。

提到关于人选的问题，不得不提的就是面试的问题。面试是选拔人才的方式，但是面试时似乎有条不成文的规定：可以问候选人以前干过的工作，但是不能要求看看其工作产品。但是检查其工作产品往往是非常有好处的，可以更直观的了解候选人。而新录取的员工往往被要求做能力倾向测试，这种测试大部分是关于左脑的，即不进行创造性活动。《人件》提供给我一个数据：一个有40年工龄的人，只有5年的工作时间，却有35年的管理时间。这就说明能力倾向测试只能为我们提供短期工作得很好的人，所以不应该只通过该测试来决定是否雇佣这个人来作为团队的成员。

大概从马列主义传进中国开始，理论指导实践的思想在人们脑海里已根深蒂固。伴随理论的指导实践是一套方法论，大方法论是关于所有种类的需要集中思考的工作应该如何进行的总系统理论。而这种大方法论并不适合在软工中使用。这让我想到了老师上课强调的文档的建立，而我们在强调文档的重要性的同时也要清楚的认识到建立文档不等于解决问题，有时候动手解决比建立长篇累牍的文档更为重

要。综上所述，方法论并不适合于软工，如果一定要规定一个标准，那么可以制定一个非标准的标准（即规定员工不能做什么）。

《人件》中提到了“黑衣团队”的一个案例。作为一个胶冻团队的特例，黑衣团队有种接近疯狂的行为，他们培养一种毁坏者的形象，在程序上制造各种失败，作为团队他们成功了，并且他们快乐的工作着，他们有着共同的目标促使他们成为一个成功的团队。

我觉得，建立一个有健康氛围的团队我们可以从以下几个方面着手：1、质量崇拜；2、提供许多令人满意的完形；3、建立精英意识；

4、保持和保护成功的团队；5、提供战略但不是战术指导。

以上就是我读《人件》的初步感想，我相信以后花时间再精读一遍会有更深的领悟。《人件》让我懂得“伟大的经理懂得人本质上是不可管理的，软件成功的本质是使每个人朝着同一个方向努力，然后使他们热情高涨，并且任何事物都不能阻止他们前进。”同时也让我重新对软工有了更深一层的见解，让我认识到了自己思维的误区。我认为《人件》带给我的是建立成功团队的非常重要的思想，对我以后的工作颇具指导意义。