iamsujie的产品设计：人人都是产品经理

剧透一点，第6章《产品经理的自我修养》–> 产品经理主义 –> 解决问题的通用思路。这段是全书总结的一部分。

我们看到，产品经理的思维方法和做事方式是有很明显的特点的，因为我们的工作抽象了说就是在解决问题。而很多时候，靠“灵光乍现”、“随机应变”来解决问题，让人心里很不踏实，那么，可以提取出其中更具一般性的内容来指导我们做任何事情么？我觉得是可以的，最近我就试着把这个思路总结成了一句话：

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

简单分析一下，这句话又可以细分为如下几个部分。

做某件事情“为了什么”是大前提，对应本书的第5章战略。

这个问题问到最深处，必然要到价值观和理想的层面，知道自己需要什么的人在任何时刻都是充满力量的。

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

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

要弄清楚“什么问题”，就要从问题的定义入手，想清楚“现在在哪儿”、“想要去哪儿”，然后明确目标与现实的差距，这个差距就是问题所在。对于“什么人”，我们还可以想得更广一些，泛化到这个问题发生的条件，所以除了“谁”以外，还可以考虑“哪里发生”，“持续多久”，“频率怎样”等等。而“做什么事”就要分析问题和制定对策了，我们要综合考虑拥有的各种资源，给出一个可行的解决方案。这里要明确两点：一是问题不一定能解决，有的时候资源有限，只能把问题放在一边；二是问题不一定都要解决，如果解决问题花费的成本超过任其发生造成的损失，那宁愿顺其自然。

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

我们可以引申一下，“何时，谁来做”也能提醒我们考虑一些事前的要点。“何时”提醒我们思考，这件事为什么是现在做？时机是否合适？大家都知道“早一步是先驱，早两步就成先烈了”。“谁来做”提醒我们思考，这件事为什么是我们做？我们的核心竞争力在哪里？

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

吃透这句话以后，设计一款互联网产品只是解决一个具体的问题，同样的，如何做一桌年夜饭是一个具体的问题；如何设计一套政治制度是一个具体的问题；如何让公司的会议室、投影仪资源得到充分利用是一个具体的问题；如何买一辆家人都满意的车也是一个具体的问题……我觉得，越抽象的事情，前面“想”的过程就越重，越具体的事情，后面“做”的过程越重，所以，如果我们想清楚了上面的那句话，真正到了开始做事的时候，其实已经搞定问题的大半了。

我们来看几个例子吧。

计划一次旅行，用思维导图。

我们要回答的具体问题是：为什么旅行，寻找刺激还是放松？不同的目的导致不同的目的地。怎么旅行，做汽车、火车还是飞机，住酒店、农家还是帐篷？不同的目的地有不同的方案。什么时候和谁去？确认有几天时间，多少人……简单思考一下，我们就可以画出下图，帮助我们做准备。

计划一次旅行的思维导图

开一个网店要做哪些事，用流程图。

我们要解决的具体问题是：卖什么？如何定价？货从哪里来？在哪里卖？卖给谁？谁来卖？成交后怎么发货？……于是，简单的流程图就出来了。

开一个网店要做的事

举办一场婚礼，用甘特图。

仅仅说晚宴的部分，我们要考虑的具体问题是：短短的三个小时，一共有十来项任务，不同的角色，如新郎新娘、工作人员、来宾各自的任务是什么，每项任务的开始时间与结束时间，需要准备的道具，注意事项等……项目管理里的甘特图正好派上用场，图中表示的是当天17点到20点的180分钟，划分为18块，精确到每10分钟的任务，这个晚宴已经是相当精简的了。

婚礼晚宴的甘特图

……

生活中任何事情都这样想会不会太理性，反而没意思了？我认同，所以对待重要的问题，我们可以用上面的思路，但是大多数情况下，还是感性一些，轻松一些。

我有个比喻：世界对每个人来说本是一片黑暗，你对世界认识的发展，就好比在一片黑暗的空间中，在不同的地方点亮一盏盏知识的小灯，然后看到一些情况并且猜测着还看不清的情况，当灯亮的越来越多，就可以不断修正对这个世界的认识，每个人都会经历这种“认识中的世界越来越复杂”的过程，期间可说快乐，也可说痛苦。

但少数人会突破一个拐点，开始“发现世界越来越简单明了”，我粗浅的认识，突破拐点的一种表现就是有一些关键的灯被点亮了，渐渐发现黑暗中的世界原本是一个整体，有着他根本的道理，很多事情底层的规则都是相同的，从而我们会觉得做起事来反而越来越轻松。一旦到了这个阶段，当事人就会忍不住的去拼命点亮更多的小灯，这其实是很痛苦的，因为你发现了方向与终点，但同时也知道必然走不到那里，也许，真正强悍的人会把这个过程视为一种快乐。

插播：爱因斯坦晚年试图用一个方程式来解释整个世界，但是也失败了……

世界本来就是一个整体，人类为了便于理解将其人为的切割，但蛛丝马迹让我总是很想再把每一块拼起来……推荐一本书：《系统化思维导论》。

随着世界渐渐被点亮，我才可以更合理的勾画自己的知识地图，在明确了自己在哪里，想去哪里，已经知道哪些路……的情况下，考虑怎么去的问题，一点一点的连出一条线。

我们经常学到很多知识，但也经常不知道在当前场景下应用哪一条知识！所以你知道多少知识并不重要，重要的是在各种应用场景下，能提取出多少。而提取知识的能力，可以通过知识管理来提升。我们的大脑好比一个图书馆，每个人都在不停的往里面加书，可是，很多人都是把书买来以后就随手放在一个书架上，等到想找到时候，无从下手，而这种挫败感会严重阻碍知识的继续增长。知识管理就是帮助你尽可能的梳理已有的知识，以便要用到时候可以轻松索引，对一个公司是这样，对个人也是这样，越是优美的架构越是能支撑庞大的系统。

有了这样系统化的思维习惯之后，再做事的时候也愿意用一种清晰的方式展现思路。知识管理是内力的修炼，思维导图（mindmap）是内力向外驱动的招式，实践表明，简单实用。

前段时间看了一本小册子《思维导图——大脑使用说明书》，还不错，只有60页，其实比网上一篇稍长点的文章长不了多少，不到一个小时就翻完了。而画图的软件，我用的比较多的是mindmanager，也试过xmind、freemind、visio，网上一些在线的工具，其实都差不多，关键是理念与思路，这些有了，拿纸笔画也非常好。

思维导图可以用作头脑风暴时的工具：在需求采集的最后，一堆PD就会窝在一起头脑风暴（俗称yy），只重数量不重质量的想出尽可能多的需求点，不要反驳，不要讨论可行性，尽管乱想，最后再统一的略作整理，就得到了一张思维导图。

思维导图也可以用作记读书笔记，如“读《餐巾纸的背面》，图解商业问题”；还可以用作整理做事的思路，如“网络推广实战的执行思路”……

如果你还没画过这样的图，可以先从轻松有趣的事情开始，比如计划一次旅行。

这个话题我想的比较乱，所以写出来也很乱，见谅了。

终于发出这篇了，因为总是被一些问题困扰，比如很多同学都会问的：

产品团队用什么组织结构最好？

我要写PRD，你们的文档模板能给我传一个用么？

最优的项目流程是什么样子的？

画demo用什么软件？

……

我觉得，文档、流程、工具软件、组织结构等等都是支撑，背后的核心还是产品，要满足哪个市场哪些人，要做什么、怎么做，想清楚了，支撑的东西自然而然会浮出水面。 当然，浮出水面的过程中，团队里有个“经验足且熟悉产品”的人是必要的，大多数团队碰到的问题就是只有“经验不足但熟悉产品”的人，于是到处去问“经验足而不熟悉产品”的人，这样是得不到满意答案的，而且后者也很郁闷，不是不想帮忙，而是只有思路、方法却不知道答案、解决方案，真的不敢乱说……

我们都在类似的窘境中前进，每做过一个产品之后，总会发出类似“要是现在让我重新做一遍就好了”，而我相信，就算真的重新做一遍了，做过之后还是会继续发出这个感叹！这真是难以避免的悲剧？

每每至此，总让我想到另外一些类似的问题：

上学的问：要读研还是找工作？

找工作的问：应该去大公司还是小公司？

……

多年的教育让我们误以为所有问题都是有标准答案的，可实际上很多问题连参考答案都没有。这是因为，考试题往往都是对现实情况的简化，只有这样才说得清楚，才便于将答案与“分数”这个KPI映射，很多背景条件都不用我们去考虑，而真实的问题往往是背景复杂的，比如“最优的项目流程是什么样子的？”这个问题，我们先得想清楚公司的目标，基于此目标，需要去打什么市场、什么用户，从而要做什么产品，然后考虑做这样的产品需要做什么事情，哪些人具备做这些事情的技能，再决定组建什么样的团队，匹配以什么组织结构，之后，根据产品、团队等等的特点，确定什么样子的流程比较合适。这些，会让这个问题根本没法通过msn的几句话，或者一个电话聊清楚，而是至少需要3个月的实地工作才能给出一个还算靠谱的结论（这是我自己的体会，做一个产品，往往都是连续做3个月以后才开始有感觉的）。

那么，为什么大家都喜欢问这样的问题呢？

最好的情况，是我多虑了，提问者知道上述我说的这些，只是问方法论的话，总难免长篇大论，于是可以通过问解决方案，从而推出背后的道理。嗯，这确实是一种办法，但一定要注意，管中窥豹，只见一斑。每一个靠谱的解决方案都是做过很多事情以后，提炼出来的，你直接拿过去，很容易误读，只能看到是什么，不知道背后的很多为什么，这样的话，只要情况稍有不同，就会用得走火入魔，而武器越厉害，伤害也越大。

更多的情况，可能是下述两种。

一是技术上，舍本逐末了，我认为去问外人，只能在方法论上得到一些建议，但是不要奢望一个外人给出的解决方案靠谱。

二是心态上，太急躁，工作中确实碰到问题了，希望能迅速解决，但在这点上我很悲观，没有速成，只有慢~慢~~熬~~~

前段时间把交互设计之父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本书》。

今年在参与阿里软件的内训师计划，负责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个小时的版本，希望以后有机会与同学们分享。