存档

‘产品设计:7000 学习与成长’ 分类的存档

产品设计体会(7026)知识管理与思维导图

2009年8月6日

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

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

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

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

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

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

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

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

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

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

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

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

VN:F [1.2.0_562]
Rating: 4.2/5 (6 votes cast)

产品设计体会(7025)只有方法没有答案

2009年7月7日

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

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

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

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

demo用什么软件?

……

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

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

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

上学的问:要读研还是找工作?

找工作的问:应该去大公司还是小公司?

……

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

那么,为什么大家都喜欢问这样的问题呢?

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

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

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

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

VN:F [1.2.0_562]
Rating: 4.5/5 (4 votes cast)

产品设计体会(7024)有关交互设计,读过的6本书

2009年6月24日

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

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

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

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

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

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

产品的三个模型:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VN:F [1.2.0_562]
Rating: 4.9/5 (7 votes cast)

产品设计体会(7023)产品经理(PD) @ alisoft做什么

2009年6月13日

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

 1.  阿里软件,管理软件事业部各产品PD代表(做完后,开始整理课程大纲);

 2.  阿里软件各产品PD代表(做完后,尽快发布课程的beta版,可用于阿里软件内训);

 3.  阿里集团各子公司PD代表(完善,仍然用于内训);

 4.  业界产品经理代表(这部分,聊天对象还在积累中);

采用深度访谈的原因很简单:无明确问题,先开放式聊天,每个人12小时,围绕几条线索“一个需求从采集到实现;一个项目从立项到结束;以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 based2周到1个月(不算产品1.0这种大项目);旺旺,34个月。

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

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

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

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

团队相关

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

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

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

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

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

VN:F [1.2.0_562]
Rating: 4.4/5 (8 votes cast)

产品设计体会(7022)TTT实战演练记录

2009年4月30日

200941617两天参加了倪砥老师的TTT实战演练,比起之前参加过的简化版TTT培训,这个课理论不多,更多的是倪老师的实战演示和我们的实战训练,老师的演示讲了职业竞争力执行力课程的节选,内容本身也让人很有收获。自己的30分钟实战讲了《人人都是产品经理》的一小段,并且有录像,有点评,很挑战。下面记录一些课程内容:

开始提到了课程材料准备:

Ø 公开内容按照时间线出3份:大纲(mindmap),ppt,手册

Ø 不公开给学员的东西,针对每张ppt准备对应的“主题、素材、手段”。

常用工具:研讨法、个案法、影像法、角色法(角色演练)、游戏法

课程常见操作路径

Ø 引言:打危机,为观点造势

Ø 个案法:推出相关案例(或先抛观点)

Ø 研讨法:与主题相关的提问

n 经验:15min是自由讨论的时长极限,手法:明确的“现在开始”+研讨音乐+结束提醒

n 收问题:封闭的(讲师点评),开放的(学员陈述+讲师点评)

n 听学员提问的手法:聆听、反馈、确认、感谢、小结

Ø 观点总结

讲课实例:职业竞争力,节选。

Ø 引子:管理与领导的区别

n 管理 –> 行为 –> 权力,偏技术,伟大的领导者可以没有管理才能

n 领导 –> 思维 –> 魅力,偏艺术,优秀的管理者不能没有领导才能

Ø 抛利益:企业为什么需要这门课?管理者为什么?员工为什么?过渡到本次讲的是“管理者版本”

Ø 什么是职业化

n 感性:快乐的做必须做的事,快乐还是痛苦自己可以选择,必须做和喜欢做的事更多时候是被迫

n 真正的保障:就业保障降低竞争力,职业保障提升竞争力

n 职业化金字塔:职业能力,职业结果,职业品牌

课程小结:

Ø 用问题做一级大纲,比如某某是什么,为什么,怎么做

Ø 用问题做每张ppt之间的连接和转换

讲课实例:执行力,节选,蜂王原理(蜂王指有领导能力的管理者)

工具名称

优点

缺点

适用范围

属性

1.高压式

快速简单

员工被动,创造性差

能力相差大,突发事件多的团队

硬朗

2.权威式

凝聚力强,万众一心

盲从,决策风险高

提高士气和热情的最佳策略

硬朗

3.组织式

归属感强,容易留人

钢性机制难以推进,执行力差

拉拢人心,平衡作用

柔和

4.民主式

观点多元,减少借口,增强责任感

效率低下

能力相差小,对决策期限要求不高

柔和

5.前导式

令员工更自信,更投入

难以驾驭

“三好”员工

柔和

6.教练式

激励员工,提高能力

对自身要求高

所有新人

硬朗

Ø 按能力和意愿的高低,对员工做二维划分,矩阵中四象限的策略选择:主打+辅助+平衡。

n 高能力高意愿,好员工:5+4+2

n 高能力低意愿,老油条:2+4+3

n 低能力低意愿,“垃圾”:1+2+6

n 低能力高意愿,菜鸟新人:6+1+3

Ø 小结:先意愿,后能力;先控制,后治疗。个人感觉管理策略没这么绝对,完全因人而异。

讲课实例:执行力,节选,组织管理的终极目标

Ø 人治(被治,由外而内) –> 法治(硬法律+软伦理+执行者以身作则) –> 人治(我更愿意称作:德治,是自治,由内而外)

Ø 如何对待“抱怨”

n 抱怨就是需要:分为合理的与不合理的,不合理的沟通,合理的再分为可满足的与不可满足的,可满足的满足他,不可满足的沟通。

n 赫兹堡的双因素理论

u 激励因素:能带来满意,满足感,偏精神,主观

u 维持因素:能消除不满意,不能带来激励,满意度,偏物质,客观

u 满意度吸引人,满足感留住人

u 对孩子的教育亦如是,不能只看满意度,还要看满足感

u 中低层管理者往往只能决定满足感因素(精神薪水),无法决定满意度因素

u 精神薪水:满足“马斯洛需求层次”的上三层,满足“激励因素”

n 所有人都奖励,是没有激励作用的

Ø 企业文化的通用逻辑结构(第一次听到,可能真是“你觉得虚的东西只是因为你不了解它”),盖房子。

n 地基是企业命脉:把谁放在第一位(客户、员工、股东,无所谓对错,取决于价值观)

n 房顶是目标,是以地基为原因而得到的结果

n 墙面的几条是支撑

n HP的例子:“员工第一”为地基,“超越”是房顶,“创新、团队、诚信”是墙面

其他零散的句子:

Ø 广告提升知名度,公关提升美誉度

Ø 内训传播的关键点:公司的立场、员工的角度,缺一不可

Ø 苏格拉底法:通过提问让对方说出我想说的

Ø 要说服就不要对立

Ø 说服演讲:总结现象,指出问题,解决问题,展示效果,鼓励行动

n 误区:只有信息传递而没有说服

Ø 学习三境界:读书 –> 读事 –> 读人

VN:F [1.2.0_562]
Rating: 3.0/5 (5 votes cast)