产品经理业务流程图的绘制流程分享

近来一段时间,忙于整理业务流程图,期间,关于流程图的绘制方法和工具也与内部团队和外部做了心得交流,恰好,个人生活也牵涉在买房,婚礼,户口迁移等流程中。不知不觉,伴随着实践与反思,个人所得的系统知识趋于完整,今儿天气极好,坐在飘窗一隅,听着间或几声鸟鸣歌唱,偶尔瞥一眼窗外的遍地绿荫,真真觉得是个写点什么的日子。所以就整理成文,如果恰好对你有所帮助,那是真真好的。

真实整理的流程牵涉到公司未公布的计划,不好公开,所以在本文中会借助一个简单的案例替代(这个案例呢,也就是计划写本文前30分分钟才想到的,如有考虑不周,请各位见谅),但是仅传达概念和方法,倒也足够了。恩,甄環体告一段落,咱们开始吧。

224A61255-0

图1 用即时贴与白板做的简单流程图

本文会包含几块内容:

  1. 什么是流程图?流程图和其他图表(如线框图,概念图,架构图,用例图)有什么不同?
  2. 为什么需要流程图?
  3. 流程图的分类?
  4. 如何绘制流程图?
  5. 流程图绘制工具

视篇幅情况,会在行文时略加划分为系列,敬请关注并多多交流。

第一部分:什么是流程图?

1. 定义

了解一个事情,我习惯从它的定义开始。至于为什么,可以参见我之前的博客文章:点击查看

我们因为厌恶十年教育,厌恶背各种定理和定义,所以我发现生活中和工作中很多人都很讨厌给一个事情下定义以及去参考定义。所以你会发现很多人在一起争吵得不可开交,仔细去听,原来是鸡同鸭讲,根本不在一个频道上。对于一个事情的描述,没有一个共同的语言,没有所谓的术语。有定义很好办,你们共同引用一个定义,发现定义有问题,OK,去补充这个定义,并扩展到更多的人群。当然,任何事情过犹不及,我们相互提醒吧。

那什么是流程图呢?说文解字是一种了解定义的好方法。流程图=流程+图,如下图:

224AC227-1

图2 流程图的定义

流程:Flow,是指特定主体为了满足特定需求而进行的有特定逻辑关系的一系列操作过程,流程是自然而然就存在的。但是它可以不规范,可以不固定,可以充满问题。所以就会造成看似没有流程。前不久,团队每个人对接一个业务团队去调研流程,反馈给我的流程有一些缺失。询问时,负责人反馈给我的答复是:这一块业务他们没有流程。其实严格意义上讲,业务已经开展,不可能没有流程,只是说没有固定的流程或者你调研的对象也讲不清楚。

图:Chart 或者 Diagram, 是将基本固化有一定规律的流程进行显性化和书面化,从而有利于传播与沉淀、流程重组参考。

从定义可以看出,只要有事情和任务,流程就会有,但是并不是所有的流程都适合用流程图的方式去表现,适合用流程图去表现的流程是一定程度固定的有规律可循的,流程中的关键环节不会朝令夕改的。

2. 流程图与其他图表的对比

工作中我们还用到或听到很多其他类型的图表,比如交互设计师们经常说的线框图(Wireframes),信息架构图或站点地图(Site Map),,开发工程师们经常说的用例图(Use Case)或E-R图。这些不同的图表要表达的内容有何种差异呢?简单做个对比,如图:

224A632b-2

图3 流程图VS其他常用图表

如果要串到某一个项目来说,可以理解成:

用例图(Use Case):表现了一个角色在系统里要完成的活动是什么,比如用户这个角色与ATM取款机的交互过程中,用户需要完成的活动有存钱,取钱,查询等。而存钱这个活动再可以进一步细分为插卡,输入密码,输入金额,ATM吐钞,用户收款,退卡等活动。用例图可以不考虑用户动作的前后次序,而仅仅提取一些关键的动宾短语,映射出系统应该满足的功能点。常用用例图的人是产品经理和开发工程师。

流程图则表示用户每一个活动的前后次序,比如用户必须要先插入银行卡,才能够输入密码,且流程图必须直接表现出各种异常判断,比如当密码错误时,出现什么提示,密码输入错误超过多少次时,出现什么提示和动作。常用流程图的人是产品经理,设计师,或者任何需要讲述业务如何运作的人。

信息架构图,站点地图(Site Map):表现为了做一个这样的系统,功能与内容的展现层次是什么,比如用户一进去后,欢迎页面的导航如何设计,是否直接出现取款,存款,查询,或者还有别的导航?常用信息架构图的是设计师。但是常用组织架构图的是HR。

线框图(Wireframe):将具体每个界面的内容布局和权重表达出来,且标注出一些交互细节的设计,比如当密码错误后,如何提示下一步动作。常用线框图的人是设计师。

实体关系图(E-R图):则是数据库架构的工作,表示一个业务系统或场景中的实体时间的关系,比如储户与银行卡的关系是归属1对多,通过开卡事件产生关联。一般来讲,用矩形来表示实体,椭圆标识这个实体的属性,比如储户这个实体的属性有:姓,名,手机号码,住址等。而银行卡的属性有:开户行,开户名称,银行卡号等。

以上的这些图表各自都有领域的专家,我这里就不班门弄斧了。

那么流程图要体现出他的差异定义,要素是什么?总结出了流程图的6大要素,希望大家能够记住,这6个要素可以在以后的文章里不断回顾,你也可以拿来判断你所看到的流程图是否专业。

224AA4V-3

图4 流程图6大要素

  • 参与者:谁在这个流程中?可以是系统,可以是个打印机,更多的指什么角色——一般是有某种工种的人。比如客服同时有小A和小B两人,但是若他们的工作性质完全一样,那么在流程图里只需要写一个客服角色就可以了。
  • 活动:做了什么事,比如点餐,结帐等活动。
  • 次序:这些事情发生的前后顺序如何,哪个任务是其他任务的前置条件?比如客人不结帐,就不会产生送他优惠卡的活动。
  • 输入:每项活动开始取决于什么样的输入物或数据,比如做饭的师傅开始做菜时,需要拿到具体的点菜单。
  • 输出:每项活动结束后,会输入什么样的文档或数据传递给下一方,比如师傅做好菜后,如何让负责传菜的人知道菜已经做好?
  • 标准化:采用一套标准化的符号用以传递你的流程图,从而使受众更快明白。

关于流程图的标准化,并不是强制的,事实上,我们见过很多种类的流程图,只要能够传递明白任务和次序其实已经归类于流程图了。如下面的图:

224A64b9-4

224A64230-5

但是若在一个公司的环境下,你的流程图的受众又非常多的话,采取标准化的符号会带来很多交流上的好处,总之你懂的。

第二部分:流程图的分类?

常见的流程图有业务流程图(Transaction Flow), 页面流程图(Page Flow)。

在工作中,作为UED,你可能会发现PD经常谈的是业务流程,而作为交互设计师,我们更多产出的是页面流程图。页面流程图和业务流程图到底有什么关系呢? 先有谁,其次再有谁呢?

先讲个故事:假设你的梦想是开个中高档的全国连锁餐馆,那么首先你想到的应该不是如何去选址,而是将为何要开连锁餐馆这件事情,以及你的定位,核心竞争力想清楚。是快餐,还是点餐,是连锁还是加盟?定位于社区还是繁华商圈?是川菜还是江浙海鲜?是面向中老年还是年轻人?是家庭主题还是动漫主题?竞争对手是谁?需要什么样的投资?可能的风险是什么?这些都想清楚了,问题都有答案了,所谓战略层要清晰了吧。然后假设你现在分析来分析去,与主要投资方决定了一个方向:面向年轻人的时尚动漫茶餐厅,连锁,但是先在杭州开始第一家,选址定位于年轻人约会,扫街的地域,比如风景区,著名商圈,电影院旁……那么,接下来呢?

接下来就是想办法让这些实现吧?那么需要做什么事情呢?选址?拉投资?搞装修?选餐饮菜单?雇佣员工?每一步怎么去做,时间点是什么?等等的任务拆解以及计划,就需要到战术层了。

这些事情的执行,总是需要请人的吧?先是核心团队分工去部署各项建设任务,当餐厅开设起来后,就需要组织稳定的运营团队,如服务、卫生、厨房、采购、人事等等,厨房里面还得分工,白案,热菜,冷菜等等吧?每个部门需要设置管理层以及汇报关系吧?所以你的组织结构就诞生了。

那具体每种角色是如何顺畅合作完成日常稳定的以及突发的各项任务呢?比如,当顾客上门时,谁去引导客人入座,谁去点菜,怎么将点菜的讯息迅速传递到厨房,并分发到酒水间、冷菜间、热菜间?并保证客人尽快能够吃到所点的菜?你必须要考虑各种人员的协作流程,优化效率,所以业务流程就出现了。

人肉运营了一段时间,没有借助任何点餐系统,你发现也还可以。客人点菜时,服务员手抄写下客人的要求,因为有复印纸,所以服务员能够将副本送入厨房,同时写下餐桌号码。厨房规模较小,负责分配任务的员工看下菜单,分别往冷菜处的黑板上写下需要他们处理的,以及跑到热菜区的黑板上写下待处理的菜品,以及去酒水间报下品名即可。可是随着经营的扩大,以上的人肉方式出现了很多问题,首先,手抄效率太低,顾客频繁换菜,响应来不及,手抄出错,导致经常报错菜。厨房很混乱,不得不多招了几个人专门跑堂。而一旦顾客要加菜,撤菜就更麻烦了,需要找出他们当时点的菜,再进行人工的批注和修改,同时要修改厨房后端的各个黑板……

所以你们想要开发一套智能系统,取代很多人肉工作,你们请了系统开发团队,他们经过评估,判断从点菜开始,一直到传菜都可以用系统解决。手持终端,能够快速传递顾客点菜需求到打印机,打印系统能够根据顾客点菜的类型进行自动的分单打印,所以热菜间看到自己的热菜菜单,冷菜间看到自己的冷菜菜单,而酒水间看到酒店菜单。当他们准备完毕后,送出,传菜员可以根据菜名与打印出来的单据进行传菜并根据顾客的点菜小票进行核对。这套系统同时必须配备结算系统,将最终确认掉的菜单及消费价格传递到结算前台,收银员能够快速进行操作。

这套系统最终是需要展现出来的,那么手持终端的界面如何设计?服务员能够用更少的点击完成一个菜的点餐吗?结算中心的界面如何设计?

通过以上的故事,是不是更明白从战略、战术、业务流程图到页面流程图的关系了?总结下:

  • 先是有一个业务需求和业务目标,也即我们的愿景是什么?(战略)
  • 然后就诞生了我们需要分解出什么样的任务,如何执行战术?(战术)
  • 然后就诞生了需要架构什么部门,岗位去分工协作?(组织架构)
  • 然后就诞生了不同的部门在协作完成某件任务时的业务流程?(业务流程)
  • 业务流程基本稳定后,往往会考虑优化效率,所以会诞生出系统来支持流程,减少人肉环节,促进数据采集(系统愿景)
  • 为了设计这个系统,PD需要思考什么功能能够取代某个环节的人肉工作(功能需求,系统流程)
  • 不管是怎么样的功能最终都会以界面的方式呈现,设计师们会关注用户在系统里的任务流,行为路径,让用户完成任务更加高效愉悦。(页面流程)

当然,除了业务流程,系统流程,页面流程,还有数据流程被人关注。

我们平时工作中,还会经常听人谈到泳道图、任务流程图等等概念,究竟是神马关系呢?

224AA535-6

图5 流程图的分类

本文着重于上述流程中的“业务流程图”——并会分享如何绘制泳道图——也即是PD们最多使用,技术们最多参考,UED们最多看到的流程图。

本来在第四部分会对泳道图的图示以及绘制方法、原则做更详细的说明,但是看目前的篇幅情况,预计会放到下篇,所以先在这里简单说明下吧。

在工作中,我们经常能够看到两种业务流程图,从表现形式来看,一种很好区分,俗称为“泳道图”的它,在样子上也确实像个泳道,可以有横向的泳道,也会有纵向的泳道。泳道图在某些文档里会被称为“以活动为单位的流程图”,浮在泳道中的都是一个个活动。

224A64159-7

另外一种类型是以部门和岗位为单位的流程图,下图中的圆形就代表一个个部门或岗位。矩形代表活动。这种流程图关注事情如何完成的逻辑,但是在体现各个部门的责任上比较弱。如果是某个岗位的人来看,很难像泳道图那样一眼就能看到自己部门的职责和任务。所以现在用得比较少。

224AC439-8

再回过头来说泳道图,泳道图有几个关键点:两大维度,活动流转,流程要素。我们会在以后详解。

224A640J-9

第三部分:为什么需要业务流程图?

流程图可以提供一种简单扼要的“缩略俯瞰图”,帮助观众快速了解业务如何运转。它包含了几个关键词:谁,什么时候,在什么条件下,做了什么事情,输入什么,输出什么,输出给谁……

与系统流程不同,业务流程更关注于业务本身如何运作,讲的是业务故事,包含的是业务规则。而系统流程则是满足业务流程,实现部分流程或全部流程的信息化和系统化。

所以业务流程是所有环节的前置条件——软件需求分析,信息系统建设也会先进行业务流程的梳理。

下面表现了业务流程图是如何在三个主要场景中发挥作用的:

1. 员工培训

224A64516-10

图6 流程图的应用场景之一:培训

在此场景中:流程图能够提供一种快速了解业务如何运作的视图,通过业务流程图,新员工能够快速明白业务的最终目标是什么,中有哪些角色在参与以及他们的职责,以及彼此之间的联接。

除了培训新员工,在员工轮岗、调职场景中,员工也需要业务流程图参考,明白新的工作内容如何开展,以及自己所处的位置,自己的上游是谁,下游是谁,自己需要交付的工作内容是什么。

2. 流程优化与重组

224A62N4-11

图7 流程图的应用场景之二:流程优化

业务流程重组(Business Process Reengineering)的存在可以明确反驳:存在即合理。事实上,存在的业务流程并未是合理的,有可能是参与的多个角色习惯了某种做法,有可能是变革尚未影响到末端的操作,也有可能缺乏对于运行中的业务流程问题的洞察以及强有力的变革推动——因为要推动业务流程变革,不是某个部门的事情,而是需要流程中各个部门的通力配合。

更多时候,业务流程优化是自上而下的,但是老板们未必对实际运作的业务流程那么心知肚明,业务流程图能够很好去表现这个“运作模型”。通过看业务流程图,找关键节点的人访问,能够直接切入:为什么要这么做,为什么不这么做?从而探索出更深层次的问题,而不是问:你们现在怎么做?

通过调研,分析业务流程图,引入更多角色,能够分析出目前业务流程的问题:缺失,重复,风险,效率等等。从而制定相应的优化方案。

3. 信息化的基础  

224ABN8-12

图8 流程图的应用场景之三:信息化基础

正如上文所述的餐馆梦想的案例,信息系统的一项任务就是解放员工的手脚,取代一些重复的人力劳动工作。系统上了之后,不是说业务流程不需要而是经过了一些调整,其中某个参与者变成了系统,或手持设备,或打印机而已。

那么在做系统的功能设计和系统流程设计时,是不是必须先要了解目前业务是如何运作的呢?从而更好分析分析,更好说明系统在什么环节取代了什么类型的人肉工作?

所以我们看到的PRD往往也会先以业务流程图开始说明,而叙述一个系统建设的好处时,也可以用以前的业务流程与系统上了之后的业务流程进行对比。根据分析,将愿景中的新的业务流程图背后需要系统的功能点撰写清楚。

第四部分:如何绘制业务流程图?

首先绘制业务流程图本身有没有流程?一定是有的。在软件工程学里听说一句话叫:万物皆对象。那么在流程学里,万事皆流程。吃饭难道没流程吗?就吃饭的动作而言,就有流程:拿筷子——夹菜——入口——咀嚼——吞咽。

有不少同学在这一部份很快想会问一个问题:Heidi,请介绍画流程图的工具吧?

我个人是工具派,从不否认人工欲善其事,必先利其器的道理。好的工具本身就是一名好的老师,除了技能,也能够教会我们一些理论与理念,这些理念也是“器”中很重要的一部分。其次才是具体的工具应用技能。所以我并不建议直接跳转到工具应用。对于初学者而言,笔与纸永远是最好的入门工具,因为你无需和任何一个陌生的软件较劲。

那么,绘制业务流程图有没有可遵循的流程呢?我建议可以从下面4步着手。

1. 调研

如何快速了解业务运作真相?有没有调研的技巧放送?

2. 梳理与呈现

  • 能否快速将调研得到的文字和问题,快速转化为业务流程图?
  • 业务流程图的标准图示是什么?
  • 怎么评价一个业务流程图的好与坏?

3. 评审与确认——能否真正让业务流程图反映现实中的业务?

4. 归档维护——流程不断变更,业务流程图如何快速响应?

这些将会在下篇《业务流程图的绘制流程分享(二)》详解。

第五部分:绘制工具?

如果不搞工具研讨会的话,这部分比较简单。

Windows

线下工具大家常用的就是下面三个:

小的流程图用用PPT就够了,完了就导出图片或截图。交互设计师们因为常用axure绘制线框图,所以也不必为了流程图去学习新的工具,完全可以用axure的flow控件完成简单的业务流程图的制作。而PD们则常用微软的visio。

224A610D-13

此外,特别推荐一个软件:SmartDraw

我最近的流程图都是用SmartDraw绘制的,你可以下载一个免费版本体验下。这个工具不仅仅是为了流程图而设计的,几乎上包罗万象:线框图,流程图,E-R图,UML ,韦恩图,甚至甘特图,脑图……没有像很多人推荐就是因为他太庞大了,尤其是里面的模版。大家体验下:

224AAW0-14

Mac电脑

自然要推荐omniGraffle., 绘制出来的任何图表不知为何总会觉得很美……

当然,这个软件是可以去www.macx.cn下载免费版的……

但是不管windows还是mac,除了线下的工具,还有更多线上的选择:

不过貌似我们对线上工具普遍来说都不太放心,是对服务器,网速,还有对GFW不放心吧。

1.  https://cacoo.com/

224A64R6-15

这个是界面做得最好看的一个工具。我用它来绘制过概念图(Concept map)。如下图即是用以上的工具画的。

224AC4V-16

2. http://creately.com/

224A61356-17

3.www.lucidchart.com

224AAb8-18

本文装载自:http://weibo.com/heidixie

相关阅读

产品经理业务流程图的绘制流程分享

如何绘制业务流程图

谈谈页面流程图(附案例)

传统产品经理混进互联网的感受

回忆刚加入腾讯电商的时候,一切都让初上手的笔者心里很忐忑,这里木有传统项目的大计划,木有非常清晰的传统标准需求规格说明书,各种木有,大家都是短打上阵,迅速奔跑。同时项目小而密集,一周两次发布,需求如雨而来,与已往所做过的动辄一两年,再短也得三个月以上的项目相比,实在有点灵巧得超出预期,一度颠覆了笔者对项目这一概念的认知。所幸遇到了不错的导师,还有很给力的兄弟们。在半年的摸索和试探里,兄弟们被笔者几经折腾,依然一如既往的支持,感谢导师和团队的兄弟们。如今半年过去,各种苦涩的纠结,甜美的回味,写下来与各位分享,恳请各位高手拍砖指点。

  行文之前,先做个概要的铺垫,按时间顺序,将要展开的内容要点如下:

多看多问,小步演进;明确方向,聚焦重点;

梳理流程,培养习惯;鼓励沟通,增进效率;

明晰责任,接口清晰;适度计划,有序敏捷;

理念宣导,水到渠成;开放合作,共同成长。

这些内容都是从初加入团队至今的体会,也是一路走过来历程,自然不只是以上的泛泛概要,且看一一展开。

多看多问,小步演进

11322I3E-0

每一个有理想的青年,在被委以重任的时候,都希望自己立马能运筹帷幄,气死诸葛赛过子房,三把火一烧,令旗所至莫不如臂使指。事实上理想很丰满,现实很骨感,三把火下来,要么是烧得一锅焦黑,要么是烧得一锅夹生。

  多亏导师一再叮嘱,要求多看多问,因此笔者就静悄悄的把自己的火把给灭了,静下心来好好观察。这时候问了自己三个问题:

1、 电商整体的开发模式是什么样的;

2、 团队目前面对的问题是什么;

3、 项目经理在这个团队的位置在哪里;

要把这三个问题回答完是一篇很长的文章,在此不多说什么,这里表达的意思在于,当PM们初到一个新团队时,是以一个中医望闻问切的方式来介入,还是以目前流行的暴力强拆的方式来介入。特别是传统IT项目经理出身的同学,必须正视互联网在项目管理方面的特殊性,需要柔性融入,小步推进,在保持团队产出的情况下,进一步提升团队效率。

  笔者在初入团队的时候,自然是用的望闻问切:

– 望,望团队气氛,所处环境,工作方式;

– 闻,有人可能会问,团队有可以被闻到的东西吧,告诉你有的,那就是团队成员身上散发出来的情绪的味道,人家一般不说也不写在脸,但用心是可以闻到的;

– 问,上面提的三个是问自己的,除此外还要问团队,比如问团队自身觉得哪里感觉不舒服,哪里感觉很麻烦,总归以探知当前痛点为目标;

– 切,表象看过,就得深入的来了解,切就是扎实的去切入一些实际工作,从实践中来验证,来发现各种好的要保留的亮点,以及各种要调整的痛点。

  下面笔者来分享下初期笔者们搞的水果会的故事,这也是个关于望闻问切的故事。

小技巧分享之水果会:刚到组内的时候,初看一轮,很不习惯,发现居然没有例会,是为望。继续深入发现新来的同学,不仅是笔者本人,在初期都散发着惆怅的味道,因为距离感消除起来有点难,是为闻。一轮访谈下来,同志们普遍反应例会还是需要开的,只是没人有空来组织,是为问。初入的头两周,没有例行的固定时间来集中进行各种交流与反馈,让日常的各项工作很难整体集中统筹起来,此为切。把脉完毕,开始对症下药,团队例会必须开,团队建设也必须开搞,但是,是分开做?还是合起来做?笔者的答案是合起来,既是团队例会,又是常规团队建设。怎么做呢?首先与开发Leader沟通,争取了些经费,在每期例会上买上一些水果,例会名为水果会,先谈正事,后吃水果敞开交流,例会的气氛活跃了很多,而且正事团建两相宜。

项目管理是件很灵活的事,望闻问切能让笔者们一开始就是以团队的需求来作为切入点,进而打开符合团队长期利益的持续改进之门。同时各种以人为本的小技巧或许能收到奇效,大家尽可以挥洒创意,做到更好。

明确方向,聚焦重点

113K210a-0

  在开始这部分的时候,先提几个很实际的问题在前面:

– 团队天天很忙,但各方仍然说没支持到,怎么办?

– 需求从很多方向来,可做可不做,怎么办?

– 各种零散咨询,支持要求满天飞,怎么办?

这些问题现实中在老团队里很普遍,作为一个运作了很多年的团队,我们团队其实挺苦逼,除了电商主平台外,其它各项业务都有支持,你来我往好不热闹,但是团队成员只有那么多,颇有疲于奔命的架势。

在经过第一轮的望闻问切后,可以发现以团队目前的人力情况,只能对现有的主平台进行全力支持,否则确实是力有不逮。因此团队内部已经高度一致的希望把支持的业务进行聚焦,重回到主平台的支持和基础技术框架本身的持续改进上来,只是一直没有想好来怎么进行切割聚焦。

这对团队而言是一件迫在眉睫的事情,得不到好的处理,就会把团队拖到一个个泥塘里,在这个泥塘里,各个上游无法得到充分满足,自己苦于奔命,下游测试与运维也一样深陷其中。这个时候,需要帮助团队一起来进行团队方向的确定,然后找各级老板沟通,重新定位团队的位置与目标,进行适当的业务切割。

  有人问,你说聚焦就聚焦啊,太水了,木得干货,那咱就上干货,团队在打算聚焦时,进行了以下考虑:

1、目前支撑的业务中,是否都与公司及部门战略相合?

2、公司及部门战略显示不适宜由笔者们支撑的业务,是否可以整体逐步移交出去?

3、公司及部门战略显示应由笔者们支撑的业务,是否可以把高度定制化部分移交出去?

4、这些移交是否会对公司及部门的长期利益造成损害?

前三点,是团队在进行业务筛选时的一些要点,而最后一点是团队决定是否移交的终极原则。如果违背第4条,奉劝大家就不要提移交了,这必须是团队份内的事。因为有产品经理们和技术Leader的长期积累,聚焦方案出来得比较快,同时非常幸运的是,团队的聚焦尝试得到了各位领导的大力支持,最终某些业务被全移交,某些业务定制化部分被移交,很顺畅的实现了再次聚焦。

如果一个团队已经处于疲于奔命状态,那么一定需要审视下自己的业务,关注下团队是否还是聚焦在自己的主业务上,精力是有限的,毕竟团队里的兄弟都不是叶问。

  梳理流程,培养习惯

113K23411-1

  团队初步融入了,业务也聚焦了,问题仍然有,比如:

– 需求仍然飞舞,开发排期依然困惑无比,怎么办?

– 开发兄弟做了很多工作,但外界仍然一再的问,你们到底在做什么,怎么办?

– 产品经理每每要想知道进度就只能找到对应开发兄弟时常催问,怎么办?

– 测试天天反馈说,这转测的也太随机了,忽而来一个,忽而又来一个,没有个计划也没个通知,怎么办?

– 运维说你们的发布太乱了,太随意了,怎么办?

– 其他各兄弟部门说,想要跟你们合作,需求到底要肿么提,提了你们会不会做,怎么办?

其实这一堆的问题,都是涉及到流程的问题,具体而言,就是需求找谁提,需求达到什么标准可以排期,测试什么时候介入,信息在哪里公布等等。

  工欲善其事,必先利其器,工具是非常重要的,有的人用微软的Project,有人用Excel,也有人只用白板。电商一直用的是公司自研的研发管理平台,老实说这个平台工具并不算是较完美的工具,但是结合现实灵活运用好,也能给团队带来较大的帮助。因此结合研发管理平台,解决以上的问题团队用了以下的办法:

1、 所有需求都必须提到研发管理平台,需求都必须经过产品组的产品经理接入,解决需求来源的问题;

2、 所有需求都必须产品经理与对应开发评审过后才能流转到需求就绪,产品组必须在组内对需求评级,这样有效解决了排期难的问题,排期目标变得明确;

3、 排期权收归项目经理与开发Leader手上,把控入口,让开发及后续执行流程得到保障,也有效避免了所谓的黑活;

4、 排期与评审时,开发、测试、产品三方共同参与,解决了测试直到转测才知情的问题,也有效促进了各环节的积极沟通与协作;

5、 向外界约定,所有进度与需求信息从研发管理平台获取,借助研发管理平台实现信息透明。

事实上所出的措施并不多,但产生的效果是很显著的,目前团队的常规排期会,每周只需不到半小时的时间,测试与开发协作也顺畅了很多,需求流程清晰,各方也不会再困惑于怎么提交需求。由于所有的信息都在研发管理平台上流转了起来,信息高度的被集中,同时具备了可信度,且随时可探查。任何人想知道团队在做什么都变得很简单,打开团队的研发管理平台,都在那里,最大限度的利用工具做到信息的公开透明。

流程并不需要很复杂,流程在这里的作用是让事情有章可循,让工作顺畅有序,好的流程不带来麻烦,只带来有序、效率和透明的工作信息。不是因为规范而需要流程,是因为效率,秩序和沟通而需要流程。

小技巧分享:应用研发管理平台在实践中最痛苦的莫过于,让每一条信息的状态与实际情况进行同步。刚开始的时候,大多数人都是不习惯去系统里同步状态的,笔者团队也有这样的苦恼。为了改善这种情况,启用了个无伤大雅的惩罚措施,每周例会审查时,如果有人没有及时更新,那么就必须捐十块钱到团队的水果基金。开发leader和团队成员一视同仁,在此感谢兄弟们,在笔者屡次找兄弟们要水果基金时,兄弟的积极配合,欣慰的是,现在收基金越来越难了,因为这代表着同步状态已经成了一种习惯,再次感谢兄弟们的配合。

象征性小捐献也好,类似小红花小蔫花也罢,真实目标是在流程执行过程中促进习惯的养成,最终产生新的习惯来主动驱动流程,使之融入团队的血液之中。互联网人都是主动,积极,有独立思想的人,催工的鞭子并不适宜挥舞在这里。在这里好的团队是不用催的,好的团队是兄弟们都会主动的习惯性把所有好的,或不好的消息传递过来,然后大家伙一起去解决,或一起去欢呼。

  鼓励沟通,增进效率

113K231C-2

  笔者也是个老程序员,仍然清晰的记得以下几个比较鲜明的场景:

– Boss问,为什么做成这样子,答曰产品让干的,Boss批曰,猪脑啊让干啥干啥;

– 做了个牛逼的产品正等表扬,这天Boss发了嘉奖邮件,木有自己名字,悲愤不已,心头升起小小的幽怨,不满积攒中;

– 又见兄弟慨叹怀才不遇,Boss有眼无珠,悄悄然裸辞远去,心生悲凉。

稍年长后回顾,真的是Boss无眼么,真的是产品不靠谱么,非也非也,只是自己放弃了表达的权力,被动,被动,一再被动,从而真的就把自己藏到墙角里去,于司于已,两不落好。

每个闷骚的程序员心里都住着一个哲学家,笔者最愿用装满饺子的茶壶来比喻开发的兄弟们。他们都很有才,但是他们都很沉默。无论多么不合理的需求,他们都习惯性的轻微抵抗后,就开始埋头专心的想着去怎么实现。无论做出的产品多么牛逼,在庆祝邮件里即便没有列上他们的名字,他们也只会默默的在心里感慨下苦逼而已。很多人说,这跟效率有关系吗?笔者要说,大有关系,非常有关系!

笔者至今工作也不算太长,以经验论,相比较而言一个乐于表达自己心情,时常保持心情愉悦的开发兄弟,是最有战斗力的开发兄弟,也是最不可能默默的跳槽让你郁闷到哭的开发兄弟;一个乐于分享的开发兄弟,是能最快成长,也最能帮助提高整个团队战斗力的开发兄弟;一个能在需求涌来时,敢于且擅于表达正确意见的开发兄弟,就像一尊门神,是个能保证团队的产出永远是高质量的开发兄弟。

  团队半年里在这方面的做法是:

– 开设双周分享,每期让开发兄弟们上去分享自己的心得与体会;

– 在需求评审时,要求至少要问到为什么、有没有其它更好方案等;

– 鼓励兄弟们互相间的沟通,鼓励兄弟们从RTX里走出来,面对面的交流;

– 鼓励兄弟们就自己的工作、团队的各方面提出优化建议;

– 例会上,虽然研发管理平台已经有足够的信息,仍然要求兄弟们进行自由表达。

每个开发兄弟都是一座富矿,PM们要让兄弟们不只是会茶壶口微微冒热气,PM们还要让兄弟们勇于把茶壶盖打开,亮出自己一肚子的热腾腾细细煮好的饺子,之后就静待神奇的收获吧。以笔者团队的双周分享为例,每一期的内容和分享时的妙语连珠都时常让人赞叹不已。现在,团队的目标是,下半年,争取让部分开发兄弟走上整个电商的大讲堂。

沟通是个很系统的工程,我们没有办法可以一下子提高所有人的沟通能力,但是我们可以去鼓励沟通行为的本身,从而提高沟通的意愿与能力。

  明晰责任,接口清晰

113K231C-21

责任是一件很有趣事情,一旦分摊到很多人身上,大家就会习惯性的将其从自己身上寄托到其他人身上,这与高尚与否无关,就像笔者老家常说的,一龙治水粮满仓,二龙治水河底干。

  在笔者的团队,起初相关矛盾会出现在两个地方:

– 需求状态不透明,不能快速哪些需求可以进行排期,哪些需求其实已经发布完;

– 外部向团队提需求时,可能是找TL,可能是找几个产品经理中的某一个,也有可能直接是找开发兄弟或项目经理;

这其实导致了一些混乱,第一点解决比较简单的,需求都可以进行充分拆解,落实到人,一来责任清晰了,二来工作量评估也可以更为准确。再辅以前述的水果会基金捐献制度,需求状态的流转更及时可信。目前流程定下来后,经过一段时间以来的实施,大家已经形成了每天去查看状态并流转的好习惯,水果基金的捐款收取难度是越来越高了。

  第二点就会比较麻烦些,需要团队内外双向的互动来推动,最后定了几条基本的准则:

– 所有需求,都必须由产品组进行对接评估,通过后再与开发侧、测试侧共同评审;

– 开发人员,开发Leader和项目经理在接到外部需求时,需引入相应产品经理介入跟进;

– 产品组按目前业务方向,对人员进行分工,明确相关责任与接口方向,在各方来提需求时,可以方便的找到对应的产品接口人。

曾经需求来时,开发组就像草船借箭中的草人,每每被劈头盖脸的需求直接轰击,膝盖都不知道中了多少箭。几板斧下来,首先是进行产品组,开发组的责任划分,然后进一步定位好产品接口人,一下子天空清净,蝗虫箭雨再也没有了,需求开始像涓涓流水从产品组缓缓而来。在此感谢产品组兄弟们在前线的辛苦工作与支持。

在兄弟们被各种外来的嘈杂折腾得烦不胜烦的时候,我们应去倾听各种报怨,鼓励说出真实的心声,从而想办法通过厘清责任,重新界定各自的权力与义务,来让事情重新顺畅清爽起来。

  适度计划,有序敏捷

  初到团队的时候,每每有人问笔者:

– 可不可以快些,更快一些,咱们不是要敏捷么?

– 为什么要去做计划,难道咱们不要更快的响应么?

– 团队没有时间可浪费,难道咱们不能拍完脑袋就立即实现,看看效果么?

等等诸如此类,似乎快就是敏捷,敏捷就是快;似乎因为会变化就完全不需要规划;似乎一切就是极快的响应,极快的去试,而不需要方向性的指导与评估。那么团队有没有可能做到,既不失于规划,又不失于快速?

先回到笔者团队的现实,初入团队内的时候,团队内的计划性是比较弱的,强调的是按周排期快速响应各种业务需求。在接手时候,排期已经成了较大的问题,让所有人头痛不已,同时较远期的规划也变得艰难,在日复一日的埋头苦干中,没有空去看方向。因此决定还是进行适度的计划,来让团队在可预期的一段时间内,对即将开始的工作有个大致的预期,同时仍然开启周常规迭代,来对零散紧急的需求进行响应。整个计划链与常规紧急响应调整后现状如下:

1-120626113J54Z

上图中,计划外需求有几个分支,如紧急且复杂的需求,将按照优先级依据一进一出的原则进入当月的月度计划,在项目型迭代中进行开发;不紧急且复杂的需求,则放入下月月度计划。

在这种长短迭代结合的协作之下,笔者团队可以较有效的使产品保有一定的规划性,同时又能对日常紧急需求进行及时响应。有适度计划带来的秩序和节奏,又不失敏捷的交付与响应。

很难说这种方式是敏捷还是传统的RUP,这更像是参考两者后量体裁衣的实践,没有包治百病的最优方法论,是为没有银弹。笔者在此抛个砖,希望所有团队都能给自己裁出一身合体的好衣裳。

  理念宣导,水到渠成

113K24A7-4

  “我手执钢鞭将你打!……”阿Q兄当年有个梦想就是拿着钢鞭当领导。咱能学他么?好歹也是受过高等教育的,再说了,咱就一普通PM,手上也还真就没有钢鞭!是不是没了钢鞭事情就没法推了呢,美帝和我党用历史经验告诉大家,宣传工作才是一个组织的传家宝。回到地面,当大家在一个团队内推行一些措施时,真的感觉不是容易的事情,以下几个问题是通常会被挑战到的:

– 团队运转得好好的,为什么要按这些措施做?

– 这样做会有什么好处与弊端?

– 软性抗拒,应付性的处理下,等不催了就悄悄的停掉。

当然,还会有其它的一些问题,暂列几个典型的做个样例,在推行的过程中,发起人推得辛苦,执行的伙计们也接受得辛苦。个人经验,在一项措施要被推行前,事先的宣导是很重要的,即要在推行前,在团队内进行一系列的导向性宣传,且必须真的以团队长远利益为出发点。

宣导的目的是在事前清理掉可能的误会区,这会有效的防止在执行中误会频生,引出各种牵强的解释,甚至引发冲突;同时团队也有机会在事前做好充分的思想准备,消解可能遇到的阻力,引发愿意尝试的动力。如果确实是一项好的措施,也确实对团队有益,那么在事先充分的宣导后,必然可以水到渠成,事半功倍。

  分享下笔者团队推行双周分享的事吧,团队曾经是有过双周分享的,但由于忙等种种原因,没有持续下来。现如今重新开张,如何来调动大家的积极性呢?我们专注于去发掘分享对大家的益处,一定要是实实在在的好处,这些好处大致如下;

– 双周分享可以给到大家舞台,让大家尝试去展示自己所长;

– 双周分享可以让大家吸收其他人的经验成果,开阔眼界;

– 分享前的准备,可以有效的总结自己的经验,促进自己成长;

– 分享能力是个人综合能力很重要的一环,并且有助于在司内长期发展。

等等诸如此类,实实在在绝无虚假的益处。宣导的一定是可信的,真实不虚的,为团队成员着想的,这样团队成员才会愿意相信,愿意投入精力来做这件事情。目前团队的双周分享是很不错,每期同志们都会积极准备,而且讲起来也是各具风采。

  开放合作,共同成长

113K21348-5

这个话题比较大,开放合作是大势所趋,就像QQ网购在前些天接入了支付宝,腾讯也在去年开始了倡导整个大平台的开放。双赢的组织和个人,会得到更多正向的支撑与反馈,从而让团队能在更健康的氛围中持续壮大。

这个部分说不上什么经验之谈,更多的是一份寄语,腾讯电商,乃至整个腾讯,大方面需要各个Group的合作,小方面要各产品组、开发组、测试组、运维组、运营组之间的精诚合作,大家才能一起水涨船高。落实到个人,对开发而言需要去尝试理解产品经理们KPI的压力,对产品经理而言要尝试去体谅开发和测试这些后端兄弟的琐碎与不易,团队之间互相理解,互相扶持,大家一起和电商共同成长。

在笔者团队,团队也会有一些尝试,比如开发团队的大讲堂,并不局限于开发技术分享的本身,总是会邀请产品经理、运营、测试来分享他们的工作与体会,从而促进各方的理解与合作。

笔者前述的部分业务高度订制部分移交各业务部门自己处理,在这件事上,其实也是从合作的角度出发,各自做自己最擅长的事,笔者团队提供底层技术平台,业务方按自己的意愿更快速的响应定制,各展所长,在合作中双赢。

同时,团队也在致力于运营平台的建设,最大限度的将相关的运营合作能力开放出来,让运营可以对程序的结果进行个例的自主优化,该平台的上线,很多运营的同学给予了极其热烈的欢迎,这是团队与运营的合作双赢。

还有团队的鼓励沟通,明确职责与接口,这些都是为了让个人和团队更为开放,能够更地好去分工合作,形成集体的战斗力。

开放与合作,团队会一直进行下去,团队的未来,一定是更开放的,也是更懂合作的。

  最后的结语

零散的写了很多,从传统到互联网项目,乍一接触会感觉反差比较大,但骨子里,大家都是希望团队稳定、效率高,执行有序、质量高,信息透明、互信高。私心里深深以为,这之间距离确实有,但并不会比想象中的更远。有很多东西都是相通的,比如都应该是以人为本,以计划为工具,以流程建立团队风俗,以绩效为目标。执行层面粒度与倾向性或有不同,大的脉络仍然是一脉相承。

最后列些个人感受到差异,给大家参考下。计划是重要的,但并不是唯一重要的,比如团队必须随时响应更高优先级的突发需求;项目不一定是要规划得大而全整体交付的,大的项目其实是可以拆小来做的,比如保持快速小步的迭代,持续交付;流程不一定是要卡得死死的,其实可以抓大放小,保持团队的自主性,比如在团队成熟后,可以尝试把部分排期权下放;优先级并不是一成不变的,其实每过一段时间优先级可能就转换了,因此需要时常进行更新调整;再比如团队是必须珍惜爱护好的,因为互联网是由无数小型项目串起来的大事业,你将与你的团队在N多的小项目里一起同行到永远。

项目管理,其实没有成法可照搬照抄,不同的团队,不同大环境,都会有自己不同的实践选择,操作上无优劣之分,只有是否最适合自己团队的考量。在此抛砖一块,期望得到更多的回应,互相交流促进。

产品经理到底要不要懂技术

前言:我不是做产品的,只是对产品设计颇有兴趣,所以个人并不代表产品经理的立场;我是技术出身,但不热衷技术,所以也不能代表研发工程师的立场。我所说的可能会比较中立,也可能带有极强的个人偏见,不过我也只是个无知无畏的学生,所以十分乐意接受大家的指正。

掐架可以很艺术
  PM(产品经理)VS RD(研发工程师)

常听业内人士说起,产品经理(PM) 和 研发工程师(RD) 之间是很喜欢互相掐架的(知乎上的讨论),对个人而言感同身受,因为自己内心的技术小人和产品小人也是常常互相掐架的,感觉更像是一种是思维模式上的互掐。当然这并不代表这两种思维模式是相互对立的,好的产品显然不是掐出来的。PM 和 RD 之间需要的是一种建立在尊重和理解上的有效沟通。不过铺砖垒石的朴实研发工程师们还是比较倾向于被动的,所以我的建议是,产品经理主动去了解技术。

  为何 PM 要懂技术?

不得不说,技术人员是很傲娇的。PM 虽然并不是凌驾于 RD 之上的角色,但遵照着 PM 的设计来进行实现多多少少会让 RD 生出低人一等的感觉(不乏 PM 本身也是这么认为的),这可能是让骄傲的技术流不爽的地方。所以 RD 不待见 PM 可以说是自然而然,如果 PM 还不懂技术,那么 RD 就更加可以在自己的长处上放心大胆地鄙视 PM 了。这倒也不是 RD 的小人得志,几年的技术经验会让他们觉得这更像是一种自我保护,保护自己引以为豪的知识领域不被非专业人员指手画脚。所以如果 PM 懂技术的话,是会在一定程度上赢得 RD 的尊重的。这么说似乎有点绕,说白了就是,如果我是 RD,我会更尊重懂技术的 PM。

  与被“指点”的设计师不同的是研发很难被“指点”

懂技术解决的不仅仅是心理层面的问题,事实上,这会让 PM 和 RD 之间更容易交流。我们常常觉得 RD 出于对技术的自负而难以沟通,如果 RD 开始甩术语、甩原理,那么多耗费一些时间和耐心也还是能够理解的,有时候,更可怕的就是 PM 会觉得自己和 RD 的对话完全发生在两个次元里。其实 RD 们在这样交流的时候,并不是在企图彰显技术的 NB,这似乎更多的是一种习惯,是技术流长期和技术流交流所养成的习惯。所以,PM 懂技术,可以更好地去理解和适应这种习惯,至少也可以让自己不被 RD 们忽悠了,PM 如果被 RD 绕得云里雾里,无法反驳、无力判断,那也是一件很可怕的事情,如下面这个来自 xkcd 的漫画。

  另外懂些技术可以把 PM 从高屋建瓴拉到脚踏实地。很多时候 RD 会消极配合 PM,很有可能是 PM 的设计在技术可行性上出现了问题或制造了麻烦。于是在 RD 看来,PM 就是天马行空不负责任的 YY,却把落实的各种不靠谱问题都抛给了他们。就好像建筑师不可能对土木工程毫无了解,PM 有时候也需要在技术层面上了解一砖一瓦是如何落实的,才能让设计变得踏实。

  PM 也许可以不懂技术?

行文至此,也该中庸一下,其实 PM 懂技术,也未必是必须的,比如我个人内心的技术小人就会把这三种情况排除在外。

  1. 这位 PM 有着非常成功的产品经验

技术流虽然骄傲,但也有着崇尚权威的谦卑。如果你有着非常辉煌的历史,即使你对技术一窍不通,但凭借着“PM 将再一次带领大家走向产品成功”的信念也足以令 RD 们信服。不过能够做到这种程度的 PM,不懂技术的应该是凤毛麟角吧。

 2. 这位 PM 有着非常敏锐的产品直觉

如位 PM 有着非常敏锐的产品直觉,尤其对新技术可能带来的产品革新有着灵敏的感知的话也是被排除在外的。好的 sense 是能令其他人都跟着拍手叫好的,RD 再顽固,也是能够嗅到方向的,所以也会愿意跟着你的直觉走。不过,sense 这种东西,有时候跟天赋一样可遇而不可求。

3. 这位 PM 有着很强大的逻辑思维能力。

技术流都是逻辑控,如果你的设计出现了逻辑上漏洞或者问题,将会让 RD 们无比鄙夷,如果已经令 RD 们做了很多无用功,那更可能招致怨念。正是因为 RD 们对逻辑的执着与看重,PM 的逻辑思维能力就更加成为了一个巨大的考验。另外学习技术其实可以锻炼人的逻辑能力。当然,懂技术到逻辑强大,这不是充要条件。

  小结

说了这么多,倒也不是要标榜懂技术的种种好处,其实技术有时候反而会给设计思维带来限制。例如,PM 看产品可能首先考虑的是产品定位,而 RD 看产品首先想到的是功能。个人以前就很喜欢拿功能攒产品,做出来的东西基本不能称之为产品。这也许就是前面所说的思维模式上的差别。PM 的思维模式其实是很宝贵的,所以学习技术,还需慎重。

总而言之,PM 应该是懂些技术的,或许不需要懂到技术的细枝末节,但至少要有常识,再次也要对技术表现出尊重和热情。只有这样才有可能成为一个优秀的产品经理。

周鸿祎在i黑马大赛的演讲:谈颠覆性创新

其实参加黑马已经不是一次两次了,但是每次见到这么多创业者我还是心情特别激动,我平常是不拽什么词的,后来我想了一句话送给大家,就是不管黑马白马,敢于创业就是好马,不管黑马白马,勇于创新才是好马,这是我今天送给大家的一个感想。

我们拟定的题目是谈谈搜索,这是一个爱恨交加的话题,但是我们又希望能够扣紧今天的主题,是创新与挑战,我就拿这个搜索的例子来讲一讲什么是创新,如何面对挑战。我就是一个成天给人家挑战的典型,所以我可以现身说法。

周鸿祎:颠覆式创新最大的考验,在于是否有
  什么是颠覆式创新?

我其实讲了很多微创新,有很多人对我的微创新特别不满意,就老觉得我在误导年轻人,老是说我们都梦想要改变世界,你天天让我们关注产品细节,关注用户体验,关注很多鸡毛蒜皮的小事,不让我们谈平台,不让我们谈战略,甚至谈概念,谈什么O2O,SNS都要被你嘲笑。你天天教育我们中国的年轻创业者将往何处去,后来我想了想就不谈微创新了,我就谈两个更大胆的词汇,就是颠覆式创新,也叫破坏式创新。

其实过去我不敢谈这两个词,你们都知道,这两个词在中国很是反动的词汇,一个叫颠覆,一个叫破坏,都听说有颠覆政府,有反革命破坏,把这两个字跟创新连在一起,很多人都会觉得有点大逆不道。包括也有很多人认为周鸿祎天生就是一个破坏狂,天生就是一个搅局者,他老是能想办法让别的企业挣不着钱或者是少挣钱。我想可以解释一下,其实这些都是误解。其实在美国商学院经典的讲颠覆式创新的那本教材里面讲得非常清楚,一个创新的企业他起来一定不能够按照在市场里已经成功的企业的游戏规则去做,因为他缺乏资源,缺乏资金和人才,他一定要反其道而行之。所以所谓的颠覆式创新就是要想办法去破坏已有企业的这种游戏规则,去破坏它的商业模式。但是这里面无论你怎么样的颠覆和破坏,一定有一个参照标准,就是你确实是给消费者,给用户创造了价值,创造了利益。这样颠覆的创新才能变成产业前进的动力,甚至西方的管理学家都认为这才是推动商业文明进步的一种动力。

除了这个大的概念之后,很多人就说什么叫颠覆式创新?是不是你在家里蒙上被子想三天,想一个损招,发明一个可口可乐的秘方或者发明一个别人都做不了的专利?其实错了,我们太多的人把创新错误的跟发明划了一个等号。发明一个新的东西坦率来说确实很了不起,也很难。但是对于我们绝大多数普通人出身的创业者来讲,可能对你来说发明不代表创新,你也很难去发明一个别人从来没有想出过的东西。还有创新,很多时候意味着对一个已有的产品换一种新的方式去运作。这里面就有三种颠覆的方式,第一种被称为发明,但是比较少见,这样的案例也很少,所以它是通过技术上做出一种你可以做,而别人不能做的技术来进行更新换代,来进行颠覆。但是更常见的,颠覆式创新是两个,一个是从用户产品体验和用户体验上去改变,用一句最俗的话来说,就是让过去很难用的东西变得很简单,很复杂的东西变得很容易用。你去翻一翻两本经典教材,听起来特别宏大的颠覆式创新,里面的定义就是两句话,第一个就是我说的体验创新,就是让过去很复杂的东西变得很简单,这个也有颠覆的机会。还有是很重要的创新就是商业模式的创新,用一句大俗话来讲,就是让很贵的东西变得便宜,甚至让花钱的东西变得免费。恭喜你,你做这样的事情也是颠覆创新。所以你看颠覆式创新很多的案例,大概都是在用户体验和商业模式的运作上来产生出跟巨头不一样的做法。

  如何挑战巨头?

我在进场之前,其实几位同学已经在问我,说作为一个创业者,在中国永远面临着就是生死和巨头,在面临巨头竞争的时候怎么办?其实当你采用颠覆式打法,特别是在用户体验和商业模式上你决定颠覆的时候,最大的考验是在于你自己有没有这个勇于自宫的决心,因为他们有太多的既得利益。但是创业者本来什么都没有,所以敢不敢从用户出发,为了用户我就损失掉,为了用户,我一定要把体验做得比他们多到极致。包括在商业模式上,我本来也没有挣多少钱,我就不挣这个钱。但是对于巨头来说,让他们自宫真的是一件比你还痛苦的事情。所以有的时候决定胜败,能不能去做颠覆式的创新,是在于你敢不敢自己首先从心态上来讲,从立场上来讲,你真正的从用户出发,你真正的敢于自我颠覆。

颠覆式创新坦率来说是一个听起来好吓唬人的概念,但是实际上也就是从微创新开始,当你做一件事的时候,你就琢磨琢磨你的对手他们有什么不敢干的,他们有什么包袱,他们有什么钱不敢放弃,他们有什么商业模式舍不得丢掉。这些地方都有可能是你进行颠覆的机会,你只要敢于脱下鞋,把自己当成光脚的,你敢于做得彻底,那么你开始的这种颠覆式创新,实际上对手的很多优势资源可能就会变成他的包袱,你就会让对手陷入到一种两难的境界。

我想拿搜索作为一个例子,我决定做搜索这个事也给我引来了很多的麻烦,大家也看到了,最近我成了众矢之的,有很多谣言扑面而来。我做搜索也有很多的原因,就不一一细讲了,我只是从颠覆式创新的角度来讲,其实我看到了创新的机会。因为在美国和中国一样,搜索市场已经不是一个新兴市场,是一个经过了10几年的成熟市场,而且市场的领先者基本上占有70%甚至是80%的垄断性份额。用户已经形成了认知,也养成了习惯,甚至可以很不客气的说,搜索技术在最近10年来,在传统的基于PC互联网的搜索技术上没有本质性的技术变革,哪一家跳出来说我的搜索是第几代,这都是糊弄人的说法。当然在手机上,可能有语音,有地图,有手机很多传感技术的介入,搜索可能会产生更多的产品上的这种创新,今天我有不在这里班门弄斧了。

  现在的搜索行业,最大机会是搜索行业的领导者并不重视用户体验

我其实觉得,如果说中国的搜索行业也像美国的谷歌一样在用户体验上做得无懈可击,确实把用户利益和社会责任感也能放在他考虑的范畴之内,我觉得即使360有中国最大的网址站的流量,即使360有中国最大的浏览器的份额,我觉得我也不会考虑做搜索。因为还是那句话,你没有颠覆的机会,你完全模仿,完全照着市场领先者去做,你是永远没有这个机会的。但是我要讲,在这样一个大家认为不可能的市场里,为什么我能看到搜索的未来有颠覆的机会?特别简单,因为可能在座的很多创业者当你需要查资料的时候,你肯定希望找到的是一个知识引擎,而不是一个广告引擎。我也很喜欢谷歌这家公司,但是当你使用它的搜索的时候,很多时候访问结果出不来,可能你也不知道发生了什么。所以在中国的搜索用户,其实没有选择,你只能去用那家搜索引擎。所以我也经常讲,作为一个自由市场竞争的原教旨主义者,我觉得企业不用来自己标榜自己有多好,我相信即使几家坏企业,他们只要展开公平的市场竞争,他们为了争先讨好和取悦消费者,消费者最后就能得到最好的结果。如果没有选择了,一个道德上标榜自己再怎么样的企业,我觉得他也没有动力去改善搜索的体验。所以你看到今天的搜索在某一些关键词的时候大家都学会了,第一屏都是广告,自动忽略。你可以忽略,各位,你的父母,很多小白用户他们都不懂。

比如说再举一个搜索的乱象,在用户体验上跟极端的例子,如果你做一本媒体,你一定会把文章和广告区分开来。今天搜索引擎已经变成一个公器,不是某家的后花园,他已经在80%垄断的市场占有率下,已经是中国最大的媒体,甚至是媒体之王。但是搜索结果和广告是混在一起的,甚至是有意的混在一起,让小白用户不加区分的去点击。所以最近我我说看到了机会,某企业说他们要向我学习狼性,我就问他们有没有搞错?他们缺的是狼性,他们缺的是人性。每一个商人都要挣钱,但是你一旦完全从企业自己的利益出发,而不考虑用户的利益,因为用户没有选择,你的广告放得再多,用户有再多的抱怨,甚至媒体有再多的批评,无所谓,因为用户没有选择。所以我就看到了,在用户体验上,我认为有了颠覆的机会。如果我做一个搜索引擎,跟大哥、二哥都差不多,也是塞满了乱七八糟的广告,我觉得这个事根本没有意义,我一点机会都没有。刚才讲了,如果在体验上让我们感觉我的搜索更干净,广告更少,如果有广告,我也一定要把这个广告用不同的颜色标出来和搜索结果区分,不至于让小白用户去误解,我觉得在体验上就产生了一个颠覆。虽然搜索的技术可能都差不多,但是这种颠覆就会让巨头面临一个很尴尬的局面。你跟不跟?你不跟,我相信总有一些用户不甘心上当,有很多用户可能觉得无所谓,但是我相信有很多用户不愿意上当,他们希望能够搜索到更多的,中立、客观的搜索结果,而不是经过操纵的搜索结果,我就能得到用户。如果用户跟进,那恭喜,这就是我说的,央视批评了6天没有改变的问题,我做了一个搜索,我至少就驱动了这些巨头去做一些改变。至少如果搜索行业骗得更干净了,我觉得好歹我们能满足一点小小的成就感。

  欲想成功,必先自宫

就像当年我去做免费杀毒,其实今天所有的杀毒厂商都跟进了,他们唯一的错误,就是在我做免费杀毒的时候,他们太爱惜这点到手的收入了。所以当时我就经常送一本葵花宝典给同行,葵花宝典第一页写着:欲想成功,必先自宫。当时最后一页还写着,如果他很犹豫就翻到最后一页,叫做即使自宫,也未必成功。在我刚开始做杀毒的时候,不瞒大家说,我的董事会,我的投资人也闹翻了天,我们都恨不得互相拍桌子,摔杯子。他们说:“周鸿祎,我们投了你们这么多钱,你原来答应我们做社区搜索也没有做起来,好不容易做一个免费杀流氓软件弄了点用户,你卖卡巴斯基一年也有一两个亿的收入,我们弄一两年就上市了,就套现了。你还搞了一个免费的,而且还是终身免费,你还没有把别人杀了,你不是把自己傻了吗?”

我们当时不是动了金山、瑞星的奶酪,是砸了自己的饭碗。如果你连自己都不敢颠覆的话,你如果说有别的方向,能够挣着把钱挣了,如果没有这样的决心,谈何去颠覆?

今天的搜索也是一样,搜索里面最臭名昭著的商业模式就是所谓的竞价排名,你的网站流量大,本来搜你的名字应该可以搜到,你绝对应该在最前面。各位站长,但是对不起,你流量大了,有人花了钱搜索的时候就可以排在最前面,这就叫竞价排名,最后你不得不花钱。更恶劣的是这种劣币驱逐良币的方式,导致谁花钱,谁就能够排在最前面。举一个例子,虚假医疗广告,这个行业的大部分收入原来都是自己挣的,因为他们的广告主要是刷在男厕所里面,刷在电线杆子上面,现在这些地方被清理了之后,他们终于找到了可以集中投放的地方。所以他们这个行业贡献了收入,占到搜索行业收入的30%以上,我不想去批评这个行业,我也不懂,我只是想说一个最纯朴的个人感觉。跟大家讲,我在北京看病也要托关系,否则医院里面人满为患,因为你看不到好的大夫,因为医疗资源是匮乏的。所以医院每天人满为患,人山人海,病人都看不及,他们还要花500块钱一个点击到搜索引擎买访问者吗?所以在搜索引擎前面花几百块钱去买一个点击的那些医疗机构大概是什么样的角色你也知道。

我就在想,如果我也要挣这个钱,其实我跟搜索引擎的大哥没有本质差别,那谈什么颠覆?你跟他就是一丘之貉。所以商业模式的颠覆,就是敢于放弃巨头不敢放弃的钱,不挣这个医疗行业的钱,不挣竞价排名的钱,这就形成了商业模式的颠覆,这种颠覆也会让巨头觉得很两难,你不跟可能会丢掉用户,你跟会丢掉收入,反正不管怎么做,都会很难。其实我不是要跟谁故意为难,我觉得商业里面竞争,每家公司都会想办法让自己给客户提供与众不同的服务。作为每一个创业者,想办法去颠覆巨头,甚至有人有一天想要颠覆我,我觉得这是天经地义,就是从用户体验和商业模式这两个角度出发,这也是我觉得很多创业者能真正把它身体力行做到的。

  别人如果要打“封闭牌”,你就应该打“开放牌”

其实无线搜索才代表了搜索的未来。今天的主题谈谈创新和挑战,我就拿搜索来做一个例子。我决定做搜索,我觉得没有彻底干翻什么,我也没有这个想法。但是我觉得,当你进入一个哪怕被人认为是已成定局的红海市场,可能你没有发明搜索的算法、没有发明一个什么更先进的技术。但是从用户的角度去看问题,从产业的角度去看问题,从商业模式的角度去看问题,你可能就能看到颠覆的机会,所以真正颠覆的机会也无处不在。

我也有一个梦想,我希望不要像当年央视批评某搜索引擎说的那句广告语,什么搜索一下你就上当。同时对于产业来说我认为搜索引擎应该回归搜索的本质,其实这也是一个颠覆的机会。为什么呢?因为搜索引擎过去讲的概念是你有权利索引大家的网站,大家都把最好的内容通过搜索引擎来搜索,搜索引擎理所当然的要把流量带入各个网站。所以搜索引擎要让大家快速的找到东西,然后快速的离开。但是今天中国的搜索老大已经公开的说,我们希望用户来了就不要走,他们不仅做搜索引擎,他们也用自己的流量养垂直的内容再把垂直的内容封闭起来,再来继续稳固对于流量的垄断。所以就像互动百科那位兄弟来说,你很不幸,你做了跟搜索引擎同样的垂直的内容,你就得不到流量,今天优酷可能比我更容易感觉到这句话子意思。

当搜索引擎把各种垂直的内容都通过流量垄断起来,就未必很好生存。这使得即便有很好内容的网站也要为流量去付费,那我们就要搞一个开放的策略,要跟各种垂直的网站合作,给他们带流量。如果搜索引擎过度商业化,就是对用户体验和产品环境最大的破坏,这就是我们后来进入者最大的机会。

做颠覆听起来很爽,但等到你真正做了一个颠覆者,准备动哪个巨头的奶酪的时候,你同时还要有准备,大公司会用各种方法来对你进行绞杀。今天巨头不理你,是因为你还没有撼动他们,如果真正找到颠覆的规则,触动他们利益的时候,今天所有在我身上的故事可能也会落到你的身上。

颠覆时要有一颗细腻的心去关注用户的利益和体验,但竞争中也要有一颗粗糙的心,脸皮要厚,对对手的打击要做到熟视无睹。

颠覆者要坚信一点,无论你动谁的奶酪,你所能依赖的就是一件事,比巨头对用户更好。如果你跟巨头一样,凭什么去挑战别人?这是垄断者的专利。敢于有把自己当成光脚的精神,才有资格去做一个颠覆的创新者。

来源:i黑马

产品经理要懂多少技术才能赢得程序猿的尊敬?

产品经理是个辛苦的工作,除了要最热爱产品,练功坐禅研究用户体验外,还要和一大堆人打交道——写代码的,做设计的,搞运营的,做市场的。前两类人算是艺术家,自然会带点艺术家特有的奇葩气质,第一类人又是和产品经理打交道的人里面最聪明的,一个不小心,没准就被程序猿们划入“白痴”族群,作为茶余饭后鄙视的对象。

那么,产品经理要懂多少技术,才能游刃有余的和程序猿们打交道呢?

  在 Gevin 看来,成功的产品经理必须是被程序猿尊敬的。虽然程序猿的水平和素质也良莠不齐,但要做一个成功的产品经理,必须假设面对的是一帮最优秀的程序猿,这样才不至于被当作白痴来骂。因此程序猿应该是这样一帮人,他们是聪明的,坚毅的,勇于克服困难的;中间也不乏文艺类的,或懂艺术,或注重体验,或关心人文。产品经理也不必为了能和各种程序猿沟通,使自己面面俱到,但至少对自己要有一个明确的定位,并把自己的定位展现在程序猿面前。

Gevin 会把产品经理分为两类:

●A:改变世界的海贼

●B:自给自足的农夫

  A 类是那些真正热爱互联网的人,有自己的梦想,希望在互联网的海洋里冒险驰骋,不断创新,不断探索前行,看中的是这份冒险精神,享受的是冒险成功后的喜悦,他们也许会失败,但虽败犹荣,他们一旦成功,则会带来革命性的东西,甚至改变世界。B 类只是在互联网上求生存的人,他们并不热爱互联网,如果有更好的生存平台,他们可以放弃互联网;他们会踏实的基于数据做些分析,把一些实际可靠的元素融入产品,只要赚钱就行,创新和探索这些不靠谱的东西,尽量不碰。

产品经理在开始做事之前,需要明确自己是 A 类还是 B 类,与程序猿沟通时,通过语言或者行动表明自己的定位。如果你是 A 类,优秀的程序猿会成为你强大的助手,如果你是 B 类,好的程序猿也会帮你衣钵满载。但如果你有 A 类的心,却做 B 类的事,不被骂白痴才怪;如果你按 B 类的要求与程序猿沟通,却心怀 A 类的雄心,高傲的程序猿会认为你在玩弄他。

A 类的产品经理,对技术的要求高,能力覆盖范围广,程序猿对 B 类产品经理的要求,只是 A 类的一个子集。下面提到的产品经理,如无特别说明,是指 A 类。

程序猿也知道产品经理是要与多种职责的人打交道的,要有较强的综合能力,不会在技术领域拿自己的强项和产品经理过不去,但他们同时认为一个优秀的产品经理要具备一些能力,能力不足的产品经理不会被程序猿尊敬。这些能力包括:

●对技术的理解

●美学的修养

●强大的学习能力

●无限热情

对技术的理解

产品经理不懂技术当然不行,但产品经理也没必要掌握技术细节。产品的技术实现是由程序猿完成的,产品经理只要做到理解程序猿,尽量和程序猿做“无损沟通”即可。

非技术出身的产品经理是比较辛苦的,因为你要在技术上下不少功夫。技术不简单,种类多,各有特色,发展日新月异,是产品经理和程序猿要时刻关注的主题。即便是对技术做整体的宏观的把握,也不是一个不懂技术的人一时半会就能融会贯通的。非技术出身的产品经理首先要迈过技术上的一道坎,让不懂技术的人看来,你是一个技术领域的内行。技术出身的产品经理,对技术的理解自然不是问题,但在和程序猿沟通时,会不自觉疏忽的是,容易过分纠结于细节,尤其是曾经在技术领域有不菲造诣的产品经理。产品经理不是对产品做技术实现的人,技术更新那么快,技术细节本身甚至技术实现的理念,会迅速更新迭代,产品经理和程序猿死磕技术细节得不偿失。

上文提到的“无损沟通”,是指产品经理和程序猿在沟通中彼此完全理解,不存在疏漏和误解。这是不可能的,但这必须是二者沟通的目标。

产品经理和程序猿沟通时,两个方面尤其重要:

●A:对需求的沟通

●B:对技术实现的沟通

对需求的沟通主要应用于产品经理向程序猿阐述需求的场景中。程序猿实现产品功能,是基于对需求的理解;在功能实现过程中和实现完成后,需求的变化又可能带来产品实现上的灾难。如果程序猿不能准确理解产品经理对需求的描述,很可能实现的功能与产品经理的想法大相径庭,浪费大家的时间;如果产品经理想法不够明确,导致需求变来变去,无疑是对程序猿的恶意攻击。需求上任意一个小小的变化,在代码实现中的都有可能产生巨大麻烦,甚至会动摇代码的整体架构。从程序猿的角度来说,虽然程序猿在技术实现时以构建稳定的系统为目标,尽量灵活应对需求的变化,让系统易于扩展和维护,但这也是要基于程序猿们对需求的理解,以及对潜在的需求变化的预测。如果在沟通过程中做不到让程序猿准确把握需求,那就不用考虑产品实现的满意度了。

对技术实现的沟通主要应用于程序猿向产品经理沟通的场景中。如果产品经理对技术理解不够,程序猿很难向产品经理讲明白自己的工作现状,当产品经理想要改变需求或者希望为产品添加新的特性时,也无法准确理解程序猿对此产生的各种反应。

只有依靠足够技术基础,产品经理才能理解程序猿对工作和任务的描述,把握技术实现的难度,制定更加合适的计划。至于多少技术才算“足够”,需要产品经理和程序猿慢慢中磨合了。

最后,请相信程序猿,请在技术上放手!

美学修养

为什么程序猿可能会关注这一点?虽然程序猿不会像设计师那样与产品经理讨论产品的设计和交互等问题,但也会关注下用户体验的,而且优秀的程序猿也是艺术家,没准还是个真实的画家,要想赢得程序猿的尊敬,美学修养低于程序猿说不过去吧?

学习能力

产品经理和程序猿,是互联网上最需要频繁接受并掌握新知识的人。新知识新概念接受的慢,谁放心把产品交给这样的产品经理?何况产品经理要与聪明的程序猿们交流沟通,学习能力差的产品经理在沟通过程中会遇到各种困难,各种无法理解,在工作过程中也无法应该程序猿的尊敬。

无限热情

这是产品经理最重要的素质,也是程序猿最需要从产品经理身上获取的元素。产品经理是最热爱自己产品的人,如果产品经理不能把自己的热情传递出去,程序猿也不会实心实意做产品的实现,实现一个没有激情的产品经理的想法,实在不是一件很 cool 的事情!

小结

产品经理若要和程序猿默契配合,最重要的是要赢得程序猿们的尊敬。产品经理并不是懂的技术越细越好,而是要在宏观上对技术有总体上的把握,在微观上懂得放手,相信程序猿,并锻炼好自己其他几项能力。

  做一个站在科技和人文交叉口上的产品经理吧!带着自己的梦想和激情去改变世界,会有一帮优秀的程序猿帮你的!

来源:UXDC

为什么百度的产品经理大多不懂技术?

我们知道很多的产品经理是从程序猿直接升上去的,但是为什么百度的很多产品经理都不太懂技术,而腾讯的产品经理大多都懂技术,特别是百度作为一个技术驱动的公司,这其中有什么内在秘密呢,下面我们来看一下几位牛人的观点。

Ricky的观点:

首先作为产品经理,在此之前应该叫品牌经理,关注更多的应该是品牌产品的运作推广,在有技术驱动之后开始逐渐偏向于产品的定位管理和一定的运营推广,实际上产品经理是个中间角色,可以说没有专业技能的限制,任何人都可以成为一名产品经理,不限于设计、市场、运营、技术等等来源,这是产品经理的一大特点,也就是所谓的人人都是产品经理,所以必然有一个结果就是,如果你有一技之长,如设计、技术等,也一定会给你的产品经理生涯有一定的加分,当然产品经理在过程中增加对各个领域的深入了解,说明你是一个善于学习的人,这一定是优势而非劣势,当然这并非强求,不代表不懂这些就不能是个NB的产品经理,网吧的网管李兴平都能打造满足用户需求的NB产品,什么奇迹又不会发生呢?没准今天的丐帮帮主就是明天NB的产品经理了。

其次,百度的一大特色,很少有固定称之为产品经理的岗位,而大部分指的都是产品市场经历,尤其连部门都叫产品市场部,所以在这里的PM整体也就更偏向于产品市场定位,而非产品开发管理。百度貌似也和GOOGLE一样重视工程师文化,技术大牛不胜枚举,不缺乏所谓的产品开发管理者,所以外招的产品经理就更偏向于市场层面,而实际上百度的产品线列下来,有哪些实际是跟市场有必然关联的呢?我想不到。

所以百度和腾讯的产品经理差别文化就出现了,腾讯的产品经理更注重产品本身和技术层面,注重用户体验,而市场位置略低,使得腾讯的产品线UED基本都很流畅,包括专门的CDC部门做支撑,让用户有切实感受,而反之百度的PM由于对技术驱动的认知不够充分,所以很多产品就会偏离轨迹,包括百度下载、影音、游戏、文库、知道等等现有和已经挂掉的系列产品,都没有找到基准的用户需求点,贴吧和知道做的很好,但个人觉得和市场其实没多大关系,完全是原有用户需求的再转化。 一些事

李丹华的观点:

产品经理可以对技术不专精,但还是略要懂一点,但这个不是产品入门的前置条件,相反是入门后逐渐学会的:

1、产品本质上是用户需求的集合。不同职业的人都可以成为产品经理,因为用户本身就是多样化的。产品经理对产品,对用户群,对公司KPI负责,这意味着他需要做的是糅合3者的需求并且找到交集。这里面在意的是对需求的判定,数据的把握,进度的控制以及用户体验本身。这里面需要的更多是个人的数据分析,沟通和控制能力,对技术要求不高。

2、技术和产品应该是两种思维。技术会在现有的资源和技能下对一个东西进行判定。这种判定基于技术式的思考办法,而产品的思维要跨越现有技术,这样才不会被技术限制想象力。另一方面也能抑制因追求技术产生的超前产品。

3、产品是策划+运营+市场。知道某项需求在技术上难实现不难,但产品要做的是尽可能需求解决方案,这也就是后天不断地了解粗浅技术的原因。没杀过猪,但总知道这玩意叫猪腿吧……同时,产品不是拍脑袋的产物,生出后怎么让它长大,怎样调动资源让它被接受,这些都是产品需要做的。而这些范畴其实偏市场偏营销,核心技能对技术要求反而不高。

成远的观点:

这个本来不是一个问题,但也许在中国大家对产品和产品经理的概念的理解存在差异,所以有了这个问题。产品最终是要盈利的,无论直接的还是间接的,就跟人最终是要参与社会的价值交换,要生存,要工作一样的道理。这和互联网产品先期不考虑盈利,先创造用户价值的做事原则并不矛盾。

具体到百度这一家公司,产品高层几乎都不是(互联网)技术背景,除了上面说的大原因,肯定也有因为恰好是历史的偶然出现的那个人成就了百度的某些产品的原因。比如MP3、知道、贴吧、百科、文库等等的成功,其中一些用边江的话说是“神来之笔”,还有一些可能是顺势而为,百度做很难不成功的。也就是说有时候是需求和市场的崛起帮了产品经理,但总有那么少数个人能出现在恰好的时机,影响整个系统。那基本上,能成为后一种情况的人,也就是不受系统束缚,能够改变系统的,经常会显现为”不走寻常路“的样子。他们来自于非正统IT行业的概率就高很多。看看俞军、孙云锋、边江的简历,看看他们在百度前做过的事,都特别有趣,你就知道为什么百度会出现这种情况,而且为什么那些产品后来很长时间保持成功了。

再有,大家有时候把互联网技术理解狭隘了,IT说的信息技术,其实包含很多学科的知识,难道只有会写代码才叫懂技术?算法很好,或者精通情报学、分类学等等,就不算懂技术吗?我一直觉得技术是对一个复杂系统的透析能力,而高级的系统,其实在很多领域里长相都差不多的(最终会有大一统的模型),透析能力强的人,对很多领域都能很快培养出一种觉解──快速看透内部结构和运行机制。

姚旭的观点:我瞎扯一些我了解的。百度的产品人员PM的Title实际是Product & Marketing,而不是Product Manager。PM是以产品人员的角色参与到项目当中,而不是以项目管理人员的角色,同样工程师也会以技术人员的身份加入其中。而百度的PM培养体系之前有一个理念(我不知道现在是否还在延续),那就是要求新入行的产品人员PM不能是技术出身(以前几乎没有计算机专业的PM)。

可能有几个目的:

1 一个是防止技术限制想象力,在提出想法之前就被自己认为无法技术实现而否定掉;

2 另一个目的是,产品人员直接面向满足用户需求,用用户数据来衡量产品,防止单纯为了应用新技术而开发超前产品。PM从用户的角度来衡量技术实现的目标和效果,不参与具体的实现过程。而具体技术实现的部分,都是由工程师来完成。所以,百度的PM 产品人员真的是“大多数”不懂技术,而是专精于分析用户和市场。这是百度传统PM的一大风格。当然,这样的风格是否需要改进或者如何改进那是另一个更大的问题了。

所以产品经理不仅仅是简单的制作出产品,还要与销售,营销,公司的整体规划联系起来。

文章来源:知乎

离职周年祭 – 如果再让我做一回产品经理

说起来不止一年了。2011.04.18,我记得很清楚,我离职了。经过了一小段时间的迷茫,开始了独立开发者之路。 之所以写这段文字,是因为昨晚发现前公司的社交游戏,卖给了KamaGames LTD,并正式在App Store上线。

两年之前

当时我是”产品经理“,负责cocos2d客户端,服务器,游戏交互设计,数值转换脚本,项目管理等一堆事情。团队成员都是行业新人,没有成熟的产品研发流程。3个月我们完成了第一版,之后又调整了5个月。我离职后半个月左右,产品上线,一度冲到美国免费榜第2名。

如果再让我做一回产品经理

  • 不给外行老板打工,除非自己是合伙人
  • 玩法、题材、货币化模式上,至少要有一个有创新
  • 不做中国市场,至少不优先做
  • 杜绝团队内部吵架
  • 团队优于产品,即使对于创业公司也是这样
  • 招多面手进团队
  • 做超前设计的产品,而不能仅放眼当前
  • 三天纸上原型
  • 核心玩法先行,货币化设计次之,UI交互再次之,最后考虑制作和实现
  • 找个靠谱的策划,充分放权给他
  • 找个写代码比我好的工程师,这样就不用事事自己做
  • 提前制订产品推广计划,Press Resource列入产品计划中
  • 不加班,伤团队
  • 保证会议15分钟,站着开
  • 定里程碑,不作超过三天的计划
  • 禁止使用邮件长篇大论,当面沟通
  • 招3个人,做5个人的事情,发4个人的薪水
  • 尽快获得收入,保证财务健康
  • 除了输出价值,还在输出价值观,否则是帮别人培养团队

曾经的”小说“

曾经离职后在Cocoachina上写”小说“,现在看来挺可笑的。解决不了任何问题,反而使自己陷入麻烦之中。

不在其位,不谋其政。维护老板的权威,即使他是错的。还有即使老板的及其女人的私生活影响整个团队,离职就好了。这种事情不需要为团队出头,出头也没有用。

本文作者:王轲

LinkedIn产品经验分享: 移动优先,至繁归简

美国职业社交网站LinkedIn产品主管迪普·尼沙尔(Deep Nishar)近日接受了科技博客BusinessInsider的专访,跟大家分享一下迪普·尼沙尔工作中做产品的一些经验。

对于美国职业社交网站LinkedIn来说,2012年是具有里程碑意义的一年。相比Groupon、Zynga和Facebook等新近上市的明星科技公司低迷的股价,LinkedIn的股票走势却形成鲜明对比,受到投资者热烈追捧。LinkedIn现在的注册用户已突破1.87亿,月独立访问用户达1.09亿,目前股价达到了109.7美元,成绩斐然。

该公司业绩提升如此显著的一个重要原因,就是LinkedIn产品用户体验的提高。这正是迪普·尼沙尔这一年主要在做的事情。与许多产品在功能的添加堆叠中迷失不同的是,在过去的一年里,迪普·尼沙尔在LinkedIn的工作是围绕产品简化展开的。迪普·尼沙尔正秉承着“至繁归于至简”的理念,带领LinkedIn的团队走精品路线。

目前,在整个互联网业界都存在着向移动互联网迁移的现象,LinkedIn也不例外。LinkedIn不仅在2011年年底发布了iPhone应用,2012年3月份发布了iPad应用,还发布了Windows Phone 7应用,黑莓10应用也在开发中。LinkedIn的iPhone应用和和iPad应用都表现突出,备受用户的赞扬。即使是Android或者Windows8平板电脑平台,LinkedIn亦会继续跟进。

移动端是一个不断变化的循环。迪普·尼沙尔的想法是,随着新操作系统的出现,LinkedIn的产品仍能保持应用在这些操作系统的通用性。LinkedIn非常专注于现有应用,保证在各类厂商对其操作系统进行升级时,这些应用仍然能够使用。不盲目地用大部分的精力快速地更新产品,而是要保证在每个平台上用户都能得到产品的完美体验。迪普·尼沙尔表示,LinkedIn作为一家企业,始终专注于让用户为LinkedIn产品集体欢呼。

LinkedIn在移动端成效显著,截至上个季度末,LinkedIn 25%的周活跃用户来自移动端,在大约一年时间内增长了一倍。在流量增长方面,LinkedIn在移动互联网和应用两个方面都表现突出,而后者显然正占据主导地位。虽然在iPad等设备上,人们也在使用移动端网页浏览器登录LinkedIn。

LinkedIn主页的设计和改进也体现迪普·尼沙尔“至繁归简”的产品理念。

LinkedIn主页的简化工作从2011年开始,而其思路和数据来源受到了iPhone版应用的支持。在制作LinkedIn的iPhone版应用的时候,迪普·尼沙尔给LinkedIn移动团队下的命令是,以完全不同于桌面端的方式设计出LinkedIn的移动端。他的团队提出了一个比预期还要简单的移动端版本,专注于认为用户在活动过程中想要做的重要事情。基于这一思路,团队不仅获得了更积极的用户反馈,还获得了大量宝贵数据,让团队对用户如何使用LinkedIn应用有了深入了解。并抱着这种思路对网站进行了重新设计。

新主页改版以来,通过对用户在LinkedIn新主页上的社交活动(如分享、评论等)进行调查,迪普·尼沙尔的团队发现这些活动的数据都创下新高,是推出新版LinkedIn第一个月时的两倍。网站的页面浏览量增长了40%。这些数据均表明新版设计取得了成功。

至于LinkedIn未来的发展展望,迪普·尼沙尔显然更着重在眼前的工作,他表示LinkedIn今年最重要的事情是每天不断简化服务并不断成长,显然“至繁归于至简”的理念会一直伴随着他。人们认为简化会削弱服务的功能性,但迪普·尼沙尔却认为简化本身就是面向用户群的更具针对性的功能。LinkedIn会对整个网站继续进行简化,今年LinkedIn主要专注于主页和个人页面的简化,接下来会逐渐对其他一些产品进行简化。

另一方面,LinkedIn会继续进行海外扩张,发布不同语言的版本,拓展更多的渠道,以延续移动端的成功之路。

来源:雷锋网

Web产品的一些技术知识

不懂技术的产品经理不是一位好设计!前两天发布了一个原创WordPress主题,有位PM朋友下载研究了一下,并问了一些问题,结合他的提问我决定写一篇Web产品的相关技术知识。

今天我要讲的内容基本上都是技术原理的一些知识,主要是罗列出来并做一些简单的介绍,更深入的研究推荐Google一下,看看相关的百科介绍,作为产品经理如果能够知道这些知识,那么基本上算是马步扎稳了。

1、B/S结构

首先要讲到是Web产品的结构,Web产品是属于B/S结构(Browser/Server,浏览器/服务器),这种结构我们只需要考虑到服务器的负载而不用担心用户设备的性能,因为很多事浏览器已经帮我们解决了,当然这种结构模式拥有一个无比头疼的问题,那就是跨浏览器的兼容,当然这是前端工程师的事了(嘿嘿),不过,作为产品经理,必须要知道哦,例如有些功能特效在IE6浏览器里,那就…

2、技术框架(PHP框架)

技术框架太偏向于技术层面的知识了,不过对于产品经理来说,如果能够掌握相关原理,那么在以后的产品规划中,能够帮助我们做很多资源整合和资源复用的工作,减少技术资源成本,当然这些更多是技术负责人考虑的问题了,但是如果我们PM也懂原理知识的话,在沟通上就方便多了。

3、模板引擎

模板引擎最典型的案例就是CMS系统的架构,通过模板引擎让我们实现了前端界面和系统架构分离,无论任何一方的升级改良都不会影响到另一方。WordPress主题就是模板文件,由模板文件定义前端界面的展现风格,模板标签调用数据,实现数据内容的显示。

通常最基本的模板引擎文件分为:首页、列表页、内容页。由于每一页的头部和尾部是一样的,所以这三页又拆分成:头部、中间内容、尾部。三页共用头尾部,只是中间内容不一样。如果你了解Axure软件的话,应该能够明白,这和Axure软件中的Masters是一样的原理。

TangStyle主题的结构如下:
首页组成部分:
header.php 头部
index.php 中间左侧(列表)
sidebar.php 中间右侧(Widgetable侧栏区)
footer.php 尾部

分类列表页组成部分:
header.php 头部
category.php 中间左侧(内容列表)
sidebar-category.php 中间右侧(Widgetable侧栏区)
footer.php 尾部

内容页组成部分:
header.php 头部
single.php 中间左侧上(内容)
comments.php 中间左侧下(评论)
sidebar-single.php 中间右侧(Widgetable侧栏区)
footer.php 尾部

由于我每一页都重新定义了一次Widgetable侧栏区,为的是分开管理首页、列表页和内容页的侧栏,当然他们也可以和首页共用一个侧栏。

以上就是我写的TangStyle主题的模板文件,由WordPress模板引擎索引并显示。(当然这只是简单的描述,模板文件里还有其他的一些文件,这里就不多介绍了。)

4、插件扩展

一般情况下,技术框架都会有一套内在的API接口,用于实现一些相对独立的技术功能,例如计划任务。这个技术知识没有统一的理解,也会根据不同的产品需求有不一样的结构规划,主要应用在平台级产品中,例如WordPress就有一套系统插件的机制,如果有兴趣可以看看官方的相关介绍,这里我就不多介绍了。

5、CMS

我个人觉得,每一位产品经理都应该非常了解CMS系统的架构,因为这是一套最基本且可扩展性很强的平台级产品架构。推荐PM们在自己的电脑里配置一个PHP环境,多多下载体验一些Web产品,多了解各种类型的产品结构,这对我们以后规划产品时非常有帮助的。这篇文章里讲到的所有知识在CMS系统里都有体现。

6、开源程序

开源的英文是Open Source,意思是开放源码,也就是说开源程序是一个开放源代码的程序,技术框架就是一种开源的项目,很多热心的个人或组织将自己积累的技术框架开源出来,提供给大家使用。

之所以我提到开源程序,是因为上一条我推荐大家多多使用开源的Web产品,了解更多的产品结构,所以这里我介绍几个比较知名的开源Web产品,当然都是PHP语言开发的。

Discuz(被腾讯收购)、PHPWind(被阿里巴巴收购)、PHPCms(被盛大收购)、ThinkSNS(功能类似新浪微博,但是开发出来比新浪微博早)、WordPress(应用最多的Blog系统,国内各大公司的UED团队博客都是使用的这套系统)、EmpireCMSDedeCMS(国内知名的CMS系统)

就介绍这几个了,国内外开源的程序挺多的,基本上B2B、B2C、C2C、BBS、SNS、O2O等等模式的开源程序都有。

7、Rewrite

Rewrite在IIS和Apache中的手法是不一样的,但是实现的结果是一样,当然这个我们就不需要深入了解了,我们首先需要知道,Rewrite是一种服务器的重写脉冲技术,它使得服务器可以支持 URL 重写,是一种很流行的服务器技术。

这是偏向于服务器技术的知识了,之所以拿出来介绍,是因为很多程序都运用了这项技术,在SEO方面最常见的称呼是:伪静态

真静态就是程序生成真实存在的html静态文件,而伪静态就是利用Rewrite技术实现静态需求。像我的博客文章:http://tangjie.me/blog/64.html 实际服务器上并没有真实存在blog这个文件夹,也没有64.html这个静态文件,他是由Rewrite技术实现的URL重写功能,重新定义了URL的请求。http://tangjie.me/tangstyle 在服务器上也是没有tangstyle这个文件夹的。

伪静态的好处就是重写了URL,方便搜索引擎索引,也方便用户记忆,因为URL简化了。

8、API(应用程序编程接口)

随着移动互联网和开放平台的发展,产品的多方面拓展需求增强,因此产品规划中对API的需求也会更加重要,因此API的相关知识对于PM也是相当重要的。
这里推荐一篇我之前写的文章:产品规划中的后端规划,后端规划中的API规划

来源:唐杰博客

PM培训的答疑课小结

原文出自独占神话

这期PM培训的最后一次课安排的是答疑,回答了一些同学们普遍关心的问题。对学员们和讲师的讨论,我做了些小结如下:

一. 项目失控怎么办?

产生这种情况说明项目管理已经存在大的问题了。要做到的是提前预知,避免这种情况的出现。
万一出现了,首先要深入了解原因。多问自己问题,是人的原因吗?因为开发是新人?负面情绪引发懈怠?还是沟通不畅? 再看如何解决。两个方向,项目内搞定或者项目外搞定。项目内可以搞定吗?回答这个问题的关键是找关键路径。看从非关键路径是否可以抽调资源到关键路径上。这是要注意关键路径的变化。如果没法解决,项目外解决。项目外也就是看项目管理三角形,在资源、时间、范围上找解决方法。

二. PM如何建立威信?

其实PM需要建立的不是威信,而是信任。这里提到一个非常有趣的概念,Johari Windows。乔哈里之窗能够用来展现、提高个人与组织的自我意识,也可以用来改变整个组织的动态信息沟通系统。
乔哈里之窗把人的内心世界比作一个四格的窗口:
The Open Arena:开放区,自己和他人都知道的领域。
The Hidden Facade:隐藏区,自己知道别人不知道的领域。
The Blind Spot:盲区,别人知道但自己不知道的领域。
The Closed Area:封闭区,双方都不了解的领域。
真正有效的沟通,只能在公开区内进行。因为在此区域内,双方交流的主题是共知的,沟通效果是会令双方满意的。实际沟通中,很多情况下信息不对等,处于封闭区,导致沟通无效。要使得沟通更有效,需要增强信息的真实度、透明度,进而扩大开放区。扩大开放区的方式可以经由自我坦诚,或经由反馈。

三. 遇到能力强但固执的项目成员怎么办?

1. 识别出其固执的原因。
2. 和其身边的朋友多沟通,对其个性和行事风格等更多了解。
3. 使其承担责任,成为某个课题的owner,自我价值实现。
4. 多搞团建,和团队融合。
5. 不能被团队认可,请出项目组。

四. 跨团队的资源如何协调?

1. 要清楚的认识到,我们不是去要资源,而是要取得一致目标。是我们大家一起要把这个事情做出来。讲讲清楚要做什么,得到认可,把事情变成大家的事情,而不是变成对立。
2. 要有结果,要及时反馈。

五. PM要对技术方案负责吗?

PM对技术方案影响越少越好,要认清PM的职责,是带领团队在竞争中取胜。要识别出可以对技术方案或业务拍板的关键人物,他们去负责。
这里又涉及到PM正确的心态应该是怎样的,一是善假于力,融会贯通。对人,要知人善任,了解团队,了解成员的长处短处。对事,项目管理各个环节都要融汇进去。二是正向关注,助人自助。对人,给人机会,也要慎重淘汰。对事,接受挑战,积极正向。