人人都是产品经理——iamsujie

时间：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个小时的版本，希望以后有机会与同学们分享。

2008年开始，我们在卖e网打进，Web based Software。

用户买到的是什么？花几千块买了两串数字——一个叫帐号，一个叫密码。中小企业付钱的老板晕了，销售渠道晕了，最后我们终于也晕了。到头来大家发现，做企业级产品不能像个人网络应用这么玩，太时尚了，我们还是要回归传统，搞点实在的东西。

于是有了下图，无中生有的搞出一些实体化的东西，这就是包装，事后证明靠谱。这期间做的事情很多都不是典型互联网/软件的产品设计工作了，我发起和参与了整个过程，简单说说。

2008年4季度，活跃度提前达到早先的目标，老板提出了更高的要求，于是我的产品小组接到任务，只有一句话——提高产品用户的活跃度！于是围绕“活跃度”，兵分两路做了如下事情：

治标的运营活动：奔着数字指标，直接对“1个月登录4天以上为活跃”下药，将用户按登录频率切分群体，启动“小福星”运营项目，尝试将“1个月登录1~3次”的用户往4次转化。运营2周后，发现效果不理想，继续分析数据，发现减少“1个月登录4~8次”用户的流失率，提升空间也不大，于是这条线索暂停。

但这个过程产生了一些有价值的副产品：一方面，发现很多用户通过线上运营无效，因为他们根本就不是“真正用过产品的用户”，所以联合销售部门、服务部门一起做了用户监控系统，可以检测虚假用户、对问题用户报警。另一方面，进一步对活跃度的KPI提出自己的观点，认为“活跃用户与付费用户之间，应该添加使用用户的概念”，并且定量的证明了老板给出的新KPI数字在当时的状况下是没法达到的，后来这个数字也就不了了之了，插一句，对于如何把“老板你不靠谱”这个想法向上传达，虽然需要技巧，但是在我看来，最重要的还是要有个通情达理的好老板。

=================== 太长了，加个分割线吧 ===================

治本的用户研究：先分析了用户几个月的登录日志，寻找阻碍活跃度进一步提升的问题；通过电话访谈，实地访谈，了解引起问题的原因，分析总结后归为从主到次的4类。

原因1：经销商失责或造假，用户没用过产品。

解决方案：继续分析数据提供支撑，营销/产品/服务共同制定明年的渠道政策。渠道建设，考虑混合模式，即“经销（传统软件很多再用）+代理”。参与策划三大计划：营销辅助计划，阿里统一品牌，帮助经销商造势；服务培训计划，提升经销商服务能力；销售培训计划，提升经销商销售能力。

原因2：产品太虚，记不住帐号、网址用不起来。

解决方案：发起“鸡毛信”项目，产品实体化，也就是做了产品包装，下面还有详述。

原因3：产品没人用，用的人不对。

解决方案：发起“天使计划”，做了服务外包的试验，我们找人来帮用户使用软件，直接把通过软件获得的潜在生意机会输出给用户。

原因4：网站流量低，产品没有用。

解决方案：思考ing（这块除了产品转型做推广，暂时还没找到突破）

其他动作不展开，其中原因2的最终产物就是图中的光盘及其包装，整个过程有很多是设计一个网页、一个功能模块学不到的东西，稍微展开说说。

先明确目的：主要解决“用户记不住帐号、产品网址”的问题，顺带着有辅助销售、辅助产品初始化的作用。

说服老板，申请预算和资源：把问题和解决方案做成ppt，说服老板。把需要做的东西分解为“光盘内容、盘面、光盘包装”，便于后续多人协作，最初我们也考虑过做“会员卡”之类的东西，被否了。申请预算，表现形式会影响预算，特别是包装的形式，我们最终还是选择了一个相当省的方案。

联系供应商：联系包装供应商、看已有样品，依照想展现给用户的内容，选择光盘包装的大小、版式、材质。联系光盘供应商，选择光盘的形状（大盘、小盘、名片盘，各有优劣与特色）。

具体设计：盘内内容的设计；盘面设计；包装的每页上都放哪些内容。这些都是基于产品目的、对用户的了解、以及各种限制下的选择，太细节的思路，毕竟有些敏感，不再详述，可以举个小例子：我们在光盘里设计了一个很土的“安装软件”过程，可是对于BS模式的互联网软件有什么要安装的呢？其实我们的安装过程就是在用户的桌面添加了一个到产品登录页面的快捷方式，事实证明很有用。

整个过程中，学到了很多传统产品的设计思路，很有收获。

我一直觉得敏捷是理想与现实妥协的结果，是一种很好的实践，理论网上随便一搜就有很多，这次就说说我身边的团队，真实的实践，通过“沟通”的角度来讲，不妨起个名字叫做“敏捷沟通”。

我们的每个项目，项目经理都会建立一个临时的IM群（旺旺）、一个临时的邮件列表，把项目干系人全部加入。邮件列表通常是通过第一封项目相关的邮件，把大家的email整理齐，在邮件最后说明“本项目干系人以此封邮件为准，大家的项目邮件可以直接回复全部并修改邮件名称和正文”。IM用于实时沟通，比如发了项目邮件要大家赶紧收、文档有重要更新、测试环境构建了暂时没法访问等等，都可以群里吼。旺旺有群公告，我们会贴上项目各种文档、资料的wiki地址，以及一些测试环境的host绑定等等公共信息。

经典的每日站立晨会我们团队是坚持的，对于典型周期为2～4周到项目，控制粒度到“天”还是很必要的，项目状态看板视情况而定，经常搞，举例如下。

第一张图，是用白板做的项目看板，这类项目典型长度是两个星期，看板可以和项目日报、晨会整合应用，板上横轴为进度百分比，纵轴为项目成员。每个项目成员负责的功能点，用一张张便签表示，在项目开始的时候这些便签都贴在0%的下方，随着项目的进行，这些便签就逐渐被拿到右边的方格里。每天晨会的时候，大家都围在白板前，集中调整便签的位置。便签的红黄绿不同颜色可以加以利用，比如代表不同类型的任务，白板最右边留出一块可以写其他必要的信息，非常随意。用了这种看板，对于如此短周期的项目，邮件日报通常可以省略。这个看板的最大好处是随时可视，项目成员、老板路过都会看两眼，而每个人要自己贴条，也是一种督促和帮助，试想大家都按进度在走，你老是滞后，自己也有压力，另一方面，如果真遇到困难，大家也能及时发现并提供帮助。这里也蕴含着自我管理的思想，让每个项目成员都对项目进度负起责来。

第二张图，是“魔方计划”（项目代号）的项目墙，和白板比起来，这个项目相对长期，2个月左右，毕竟这样一个KT板也要200多块钱，上面主要有整个项目的时间轴、各个团队的重要里程碑、产品设计过程的一些可视化文档等等。究其目的，也是让所有项目干系人随时可以了解到项目的各方面信息，在每个项目里，类似的看板应该包含哪些内容，大家可以边实践边改进。最终能做到根据项目特点的不同，在启动的时候自然使出最合适的项目管理方法，从而画出最适合的看板，就是最高境界了，而这种最高境界的习得，我现在的感觉是没法学，没法文档化，只能靠悟，比较郁闷。

顺便提一点，我们喜欢尽量给一些项目起个有意义的代号，说实话这样还真能增加临时团队的凝聚力，比如“还魂丹”（激活不活跃用户的项目）、“魔方计划”（将多个产品的零散模块整合成一个新产品）、“画皮”（产品界面改版）、“画心”（产品交互改版，PM光光同学在这个项目Kick Off的时候，一直放着张靓颖的《画心》做背景音乐，感觉真的很不错），而一些特别的项目，还会把团队临时集中在一个会议室做，叫封闭开发。

最后小结一下，从沟通扩大至整个敏捷方法，任何团队的探索，都在试图给出一个介于“无过程”和“过度过程”之间的折衷方案，使这个轻重适中的过程给团队带来最大的收益。