人人都是产品经理——iamsujie

翻出来一份同事写的培训记录，应该是去年的需求管理方面的课程，该人长相彪悍，被大家一致认为家里是开夜总会的，他倒也欣然接受，于是有了同样文风彪悍的短文一篇，当作介绍产品经理（PD）日常工作的文章看吧，正式开始：

• HI ALL：听了董老师的课，看了苏老师的笔记，收获良多，收益非浅，对自己的工作有极大的指导意义。

• 鄙人一直以来都认为PD的工作就是和找小姐的过程一样，都是要解决两个问题：一个是X谁的问题，另一个怎么X的问题；

• X谁的问题，在公司一般不由PD费心选择，上面的老板自然早就运筹帷幄且成竹在胸，就象是老板把哥几个带到了一个夜总会说到：“哥几个今天晚上就在这里消费，大家好好干，整高兴！”那我们也绝对不会跑出去换个其他的夜总会玩，你说是不是？这个步骤我们的专业术语叫做“立项”；

• 接下来，我们会叫来几十个MM 来看看，看看哪些个MM长得好看，笑得甜美，声音好听，性格温柔，再叫她们做几个仰卧起坐给哥几个看看，这个步骤我们的专业术语叫做“调研”；

• 调研的结果是，我们把符合我们标准的MM留下来了，赶走了那些长得不好看的MM，叫她们回去反省、学习、进步，等进步好了再出来接客。我们要‘有所为，有所不为’，自己的体力有限，也不能全部都留下来，这个过程，我们就叫做“规划”；

• 规划结束，老板给每个兄弟都分一个MM，让哥几个练习演讲口才和忽悠技术，分配的原则就要看各位擅长应付哪种类型的MM了，这个过程我们的专业术语叫做“模块划分”；这个过程结束，好戏就要开场了；

• 好戏开场，哥几个一人抱一个MM，海阔天空，天马行空，前世今生。。。一边胡吹乱砍，一边拉MM的手，一边还碰MM的长发，各人心怀鬼胎，想着后面的好事，这个过程，我们的专业叫做“设计”；海阔天空，胡吹乱砍，我们叫“头脑风暴”，为在MM面前博得好感，哥几个相互吹捧，我们叫做“团队协作”；

• 要想换地方娱乐的，需要和MM达成一致，在离开大厅跳双人舞之前，出于礼貌和安全，哥们还是应该给我们大家打个招呼是不是？这个过程我们就叫做“评审”；如果其中有个兄弟说：“小心点哦！最近扫黄，风声紧。。。 ，”那明显就是“评审”没通过哈；

• 如果评审通过，当然就是该干什么干什么了，XXXXXXXXX.（此处省去108字），这个过程我们叫“开发”；

• 有鉴于哥们的体力有限，这次开发，你一般不太可能展现完72招108势，您的大部分技术还没展示出来，不过你不要着急，也不用感觉委屈，你有本事就有的是机会给你，对于本次展示剩下的部分，我们会安排您过一段时间再进行展示，这个过程我们就叫做“迭代”；

• 开发结束出来，老板问大家：“哥几个今天玩得HAPPY不？”你肯定要说“HAPPY！HAPPY！”但是如果有MM说：“XXX那个家伙让我感觉不爽！有X、Y、Z这个几个地方不到位”那你就惨了，测试给你报了BUG。再如果老板对你说：“你娃不适合玩这个”你就更惨了，这个我们就叫“考核”；

• 本次培训，老师对以上整个过程的实际操作方法给我们做了理论性指导，我们的苏老师也做了总结和归纳，结合自己平时工作中的实际操作，感觉很好，很 HAPPY！以后工作也好，泡MM也好，大家有了理论知识做基础，完全有理由相信自己可以做到游刃有余，百发百中。

最后，我们再对比着看一篇比较悲观的文章——《PD就是出来卖的》，希望同学们能对PD的工作有更深刻的认识……

前段时间把交互设计之父Alan Cooper大爷（此牛也是VB之父）的《About Face 3.0》中译版《软件观念革命：交互设计精髓》翻完了，发现自己对交互设计的“术”兴趣不浓，所以还是留给更专业的交互设计师去研究吧，自己只记了如下一点点笔记：

知识体系的4P，这个总结的很通用，可以映射到很多事情上，赞：

 Ø  Process，过程，整个设计的过程。我的理解，比如一些常用的流程。

 Ø  Pattern，模式，一些解决问题的方法论。比如用户研究。

 Ø  Principles，原则，一些习惯用法的规则。比如“不要让用户思考”。

 Ø  Practices，实践，把上述3个理论具体化，找到所在产品、团队的较优实践，每次都会不一样。此外还有与产品有关的周边团队的影响，不要让非核心的失误坏了大事。

产品的三个模型：

 Ø  现实模型，描述产品是怎样运作的。

 Ø  心理模型，表达用户是怎样理解的。

 Ø  表现模型，即设计者模型，是设计者如何将现实呈现给用户，应该尽量接近用户的心理模型，但是相应的工作量也会增加。

用户访谈和用户观察的注意点：

 Ø  在交互发生的地方进行访谈：能观察到用户使用产品的情景很重要，但很多时候我们是出于成本的考虑，并没有到实地去访谈。

 Ø  避免一组固定的问题：固定的问题会让被访者产生被审问的感觉，我们应该准备好问题清单，但清单只是一个引导作用，并不用照着读。

 Ø  首先关注目标，任务其次：比用户行为更重要的是行为背后的原因，多问问为什么。

 Ø  避免让用户成为设计师：听用户说，但不要照着做，用户的解决方案通常短浅、片面。

 Ø  避免讨论技术：特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式。

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

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

这本书我是去浙图借的，当时居然发现《About Face 2.0》，当然也是中译版，也在，就一并借来翻翻，一直没看过这本类似行业圣经的书，也着实遗憾，发现2.0到3.0，由于写作的时间从2003变成了2007，所以加了一些最新的东西，比如很多图片更新了，用于举例的软件版本也升级了，全书也从40+万字变成了50+万字，不过整体依然大同小异。

作为一个准产品经理，我一直说，在公司里被迫的要做一些交互设计的事情，而交互设计又是那么的专业和有深度，所以也意味着被迫的犯很多交互设计的错误，于是只好通过看一些书、文章来尽量少错一点，这两、三年来看过的书还有：

《交互设计之路》，Cooper大爷again，个人感觉这看起来比About Face轻松一些，入门可以用这个；

《GUI设计禁忌》，更加的实用，“术”一些，可能更适合一线的交互设计师，不过这块的知识发展太快，对于一本2005年就翻译完成的书，看的时候要多加小心；

《可用性工程》，一般般了，比较的理论化，像教材，有些通用原则值得仔细品味；

《一目了然》、《点石成金》（即著名的《Don’t make me think》），这两本是小书，看起来轻松愉快，半天搞定，而且也比较新，推荐翻翻。

发现全是英文书的中译版，所以对于实力型选手，建议读原版，可以领先国内思想2、3年，自己早年读书没有做笔记的习惯，现在感觉挺可惜的。

当然如果你对读书很感兴趣的话，也可以看我的《产品经理值得读的12本书》。

这是一次中篇的尝试，先放出1.0版，总觉得干巴巴，希望能收集到多多的意见和建议，一定会改写出2.0版，周末团队去武夷山Outing了，回来再看，：）

将近4000字，有必要给个摘要，本文已用于某机构内部发行的刊物，有媒体对本文感兴趣也可联系我：

本文分析了互联网、软件的产品经理与传统行业的产品经理有什么异同。

文章从“产品经理”一词的来源说起，之后转到互联网、软件行业巨头的“产品经理”招聘广告，从中发现了这个职位的内涵变化。那么，新兴行业的产品经理在概念 上究竟有什么发展？为什么会有这些发展？结果导致产品经理的职责、技能要求有哪些不同？文章的后半部分，分析并提出了造成差异的5大因素：

第一， 市场阶段不同，成熟市场与新兴市场。

第二， 产品形态不同，实物与虚拟物品。

第三， 生命周期不同，几年与几个月。

第四， 盈利模式不同，卖产品赚钱与多元盈利。

第五， 用户心态不同，花钱买与免费用。

注：本文把互联网、软件的产品经理放在一起讲，是因为现在的互联网产品越来越复杂，越来越像软件，而软件产品也越来越多的基于网页浏览器，越来越像互联网，相信不久的将来，这两个概念再也无需区分。

========================= 正文开始 ==========================

产品经理的概念最初是由美国的宝洁公司于1927年提出（另有说1931年，差不多就是二十世纪二三十年代）。当时宝洁推出一种佳美牌（camay）香皂，但销售业绩较差。一名叫麦古利的年轻人在一次会议上提出：如果公司的销售经理把精力同时集中于camay香皂和lvory（宝洁的一种老牌香皂）的话，那么camay的 潜力就永远得不到充分发掘。幸运的麦古利赢得了宝洁高层的支持，之后，每一个宝洁品牌都当做一个单独的事业在经营，有其专门的产品人员、销售人员支持，与 其它品牌同时竞争。同时，他的成功表现使宝洁认识到产品管理的巨大作用，之后，宝洁便以“产品管理体系”重组公司体系。这种管理形式为宝洁赢得了巨大的成 功，也导致后来大部分消费性商品业者纷纷沿用和抄袭。

阅读全文…

时间：20090617，周三，19~21点。

地点：西溪路525号浙大科技园B座206（大学生创业园），UU咖啡馆

内容：我的创业之路系列第四期，题目“人人都是产品经理”，昨晚临时被抓，准备仓促，打算分享一下阿里产品经理内训课程的“留头留尾掐中段，公开试讲版”

欢迎对，产品经理这个职业感兴趣的人 or 热爱生活的人 or 有理想的人 or 希望成为上述几种人的人，来进行惨无人道的围观。

已知到场嘉宾：陈博及其“热血三国”产品团队；沈剑师兄及其产品团队；淘宝、网易、yupoo等公司的好友~~~

今年在参与阿里软件的内训师计划，负责PD（Product Designer，也可算是产品经理的半成品吧）入门培训课程的开发，所以一直在找各种机会和同行聊相关的话题，这也是作为课程需求采集工作的一部分，这块我自己分了4期：

 1.  阿里软件，管理软件事业部各产品PD代表（做完后，开始整理课程大纲）；

 2.  阿里软件各产品PD代表（做完后，尽快发布课程的beta版，可用于阿里软件内训）；

 3.  阿里集团各子公司PD代表（完善，仍然用于内训）；

 4.  业界产品经理代表（这部分，聊天对象还在积累中）；

采用深度访谈的原因很简单：无明确问题，先开放式聊天，每个人1到2小时，围绕几条线索“一个需求从采集到实现；一个项目从立项到结束；以PD为中心的组织与流程；零散话题”，大家来谈各自的产品是怎么做的。

相对而言，等到有明确的事情需要验证的时候，问卷就比较合适了，到时候可能会利用自己的网站做数据的收集，提前和同学们说一声也希望大家能帮帮我，：）

4月底，开始了第一期的访谈，参与者是管理软件事业部3大产品“钱掌柜、外贸版、e网打进”的PD代表；5月上旬，进行了第二期访谈，参与者是“阿里旺旺、alisoft.com”的两位PD代表，根据聊天的内容，上个图，是我根据PD @ alisoft做什么、怎么做整理出的，这只是最高层的一张图（点击看大图），也是内训主干的框架，里面的各个部分还有细化的图，后续准备仔细写出来。

最后放出一些可以公开的聊天内容：

需求相关

 Ø  产品早期多为老板驱动，PD驱动，特别是市场不成熟的时候，我将之不成熟的比作“主动进攻”；后期会逐步转变为用户驱动、销售驱动、服务驱动，更像“被动防守”。

 Ø  管理需求，特别是日常的小需求，包括收集、状态跟踪，两个团队用excel，两个团队用mantis+excel，一个团队用QC，都ok。用mantis的团队说，mantis适合收集，跟踪，方便记录存档与反馈，但管理还是由各个产品的PD自己做，多用excel。大家都会按需要开产品会，召集产品相关方共同确定接下来一段时间做哪些需求。

 Ø  需求的优先级谁定，安全的做法是谁获益谁负责（俗称老板拍脑袋），但PD是专家，应提供专家意见给老板，当然高层授权的专家负责制也许更好。

 Ø  部分团队的需求文档直接在wiki上写作，管理。

 Ø  部分团队需求评审与UC评审分开，需求评审偏商业，UC评审偏技术。

项目相关

 Ø  典型项目周期：web based，2周到1个月（不算产品1.0这种大项目）；旺旺，3、4个月。

 Ø  项目沟通方式各有不同，主要是4个方面：周期分“日”、“周”为单位；形式可以是会议、邮件；发起者不同；参与者不同。但目的相同，都是为了项目成功，所以可以按需选用最合适的方法。

 Ø  一般5开发工作日以下的小需求不参加产品会争夺资源，采用搭车的方式做。

 Ø  一个团队的产品文档实践很高级，拥有整个产品的UC，直接在网页上编写，采用SVN做版本管理，和代码类似，项目启动开UC分支，完成后要合并UC。另4个团队仍然是项目文档的模式，产品文档只在产品1.0的时候出现一次。

 Ø  一个团队的敏捷实践很值得推广，用白板做看板，把晨会、日报整合，已经写了一篇相关分析。

团队相关

 Ø  PD团队人员构成，偏商业+偏技术背景各半比较合理，有团队大部分技术出身，深感对偏互联网的产品“感觉”上不到位，比如对用户体验有心无力。新人过多也是大问题，这也是高速成长团队必然存在的问题，老中青的结构还是必要的，个人感觉1年内的同学不要超过一半，且需要有3年以上的同学，这样才稳定。

 Ø  PD不要侵占交互设计师的工作，不要侵占系统分析师的工作，现状是存在很多侵占现象的，这也许和很多历史原因有关，有同学感到不停的在被迫做不专业的事情，犯各种错误……

 Ø  讨论了阿里巴巴B2B区分PD和RA（Requirement Analyzer，需求分析师）的做法，PD尽量往前走，偏市场/用户，产品规划；RA往后走，偏实现，写UC，做系统设计。

 Ø  开始出现专职DM（开发经理）的角色，配合项目经理管理开发过程，比如协调人员、制定开发计划，自己并不是项目的开发人员，而且可以同时担任多个项目的TM。

最后提一下这门内训课程，已经开发出5、6个小时的版本，希望以后有机会与同学们分享。