产品设计体会(7016)《问题解决》培训记录

2008年秋,参加了一个名为《有效的问题解决技巧》的培训,感觉是参加过的最务虚的一个培训了,之前是觉得产品设计的工作就是在解决各种问题(需求),很多时候碰到问题都依靠“灵光乍现”、“随机应变”来解决,很不靠谱,所以希望能得到一些梳理,课程完了以后还是小有收获的,小结一下。

问题的定义:

Ø  目标与现实的差异(客观描述),加入了主观因素以后就是:期望与体验的差异,所以因人而异了,更复杂了。

iamsujie补:往往现实比你期望的差,但也比你认为的好。)

Ø  解决问题就是消除差异,所以不一定要改变体验,还可以降低期望,但这种方案会降低满意度。

Ø  另一个思路就是通过期望挖掘出用户的多种Need(注意与Want,想要的,区别,Need是真正需要的),用更强烈的Need来代替当前这个,从而转化问题于无形(例如,高层写字楼电梯旁边装镜子的案例)。

Ø  自己加一条,还要关注几点:谁的问题,哪里发生,持续多久,频率怎样……

问题的分类:

Ø  发生型,已经发生了的,先补救使影响最小化,再找原因预防;

Ø  设定型,给自己定的目标,主动改进;

Ø  将来型,潜伏期的发生型问题,善于解决这类问题是真正的高手,但会让事情过于平淡,企业里的现状,往往善于解决发生型问题的“救火队员”会得到更多的欣赏

判断问题解决优劣,需要订一个目标:

Ø  SMART原则:SpecificMeasurableAchievableRelevantTrackable

Ø  目标应该是一个体系,并且细化到合理的程度。

结构化的问题解决,这块是我最想了解的内容:

Ø  发现问题:注意趋势,从Data出发,特别注意独特性、思维要有创造性。

Ø  分析问题:

n  问题不一定能解决,碰到这种问题,专业的态度是积极反馈,寻求帮助,也是对自己的保护。

n  问题不一定都要解决,分析其概率、影响、急迫性后,砍掉部分。

n  列举问题点(问题发生的原因,可以一层层的细化下去),问题影响=发生概率*后果大小。

n  要解决的问题也不是每个问题点都要处理,应该挑出“成本小、影响大”的。

Ø  制定对策:

n  四种策略:规避(绕过去不承担,不让问题发生,较保守)、缓解(承担部分)、接受(承担全部,分积极与消极)、转移(找别人承担),策略的选择要与公司战略一致。

n  标准问题模型:定义问题极其发生的概率,定义后果及其发生的概率,找出问题的驱动因素(问题点)并预防,找出后果的驱动因素并缓解,最后计算后果导致的损失。(问题与后果在不同层面上可以互相转化)

n  确定策略后制定具体方案,考虑方案的经济因素,有时候宁愿让一个问题发生

n  针对问题点找对策,如果发现困难,很可能是问题点不够具体,需再细分。

Ø  实时监控

Ø  持续改进

有趣的零散记录:

Ø  企业现状,最大的问题是3CCustomerCompetitorChange

Ø  说客户给我们带来的是钱太俗,应该说“给我们提供持续的发展机会”。

Ø  Brainstorm不够系统,所以必须有Data等信息基础,并且前置一个鱼骨图(因果分析图,第一层的7M1S:人员、时间、机器、环境、材料、能源、方法、测量,有几个不知道是啥词……)。

Ø  人的行为是需求驱动的,想改变人的行为,可以寻找更强的需求展现给对方,而无需证明他原来的行为是错的。

产品设计体会(7015)《项目化管理》培训记录

2008年夏,又培训了,《项目化管理》,每周上4天班上2天课还是有点累的,不过培训的收获也不小,整理一下。

整体感觉Eric老师还是很不错的,授课技巧很好,在项目管理方面也确实资深(十几年前在李嘉诚一个净利润1k多亿的项目中,就已经是一个子项目的高级PM),课程讲了较多“道”的东西,较少“术”的内容,需要听者有很深厚的功力才能收获更多,自己感觉有不少内容是听得懵懵懂懂,要点记录如下:

1.  课程网站:www.21pm.com,右上角有Eric课程精彩点。

2.  PMBOK的九大知识体系,应按照life circle理解,而不是9个模块分别理解。

3.  ABCDE经典游戏:

a)  A+有企业所有权,ACEO有经营权;

b)  A要做正确的事:明确目标、提供资源、核查;

c)  B要正确的做事:上令下达、多快好省、帮A找到目标;

d)  CDE倡导提问文化。

4.  存在即有理!(不是存在即合理)

5.  项目型管理vs运作型管理

a)  项目:跳跃式发展,有始有终(毛泽东,打江山易,但在价值链上更重要);

b)  项目老板最高境界:无为而治(德治?);

c)  运作:常规,周而复始(邓小平,守江山难);

d)  运作老板最高境界:大道无术;

e)  中国的传统:生产制造大国,擅长做运作型管理。(iamsujie补:这和农耕文明肯定有关系,而项目型管理明显有西方的狩猎、游牧文明的影子)

6.  项目三重限制:T(时间)、R(资源)、Q(质量、数量)

a)  多快好省:数量多、时间短、质量高、资源少

7.  项目要让两个人满意:BossCustomer,但两者的目标往往是矛盾的!所以要Balance,达到win-win项目要“物有所值”而不是“物超所值”!

8.  项目的大小级别:

a)  Portfolio(组合项目)>Program(大型项目)>Project(单一项目)>MD(交付件,通常15人以内、6个月以下);

b)  MD往下再分就是WBS(任务、工作包、活动)。

9.  项目的三边六拍:边行动边计划边修改;拍脑袋、肩膀、胸脯、桌子、屁股、大腿。

10.  WBS相关:

a)  六把刀:

i.  先管理(追求:快、省)再产品(追求:多、好):形成模板;

ii.  动名结构:动词模板偏管理,任务级;多年积累形成固定的名词模板,偏产品,工作包级;

 iii.  最底层作业:action,用工作量衡量(!=工期);

iv.  暂不考虑资源限制;

 v.  头脑风暴:不批评、不排斥、不评论;

vi.  不排序:工作分解开始要“滴水不漏”,重完整性,不考虑流程。

b)  WBS做完,就:心中有树!叶子做完项目就完成,树枝都是模板!

c)  有经验的项目可以自顶而下,无经验可以自下而上。

11.  三点估算法:工作量,(最乐观+最悲观+最可能)/3,对比(1+4+1)除6的方法。

12.  项目预算(资源、时间等)中,B应该找A要一个备份资源,但尽量不要动用。

13.  action plan–>工作量–>关键路径–>工期–>Baseline

a)  因事择人:把高手调入关键路径;

b) 工作串行多(不愿分解)消耗T,并行多(不善分解)消耗R

14.  收买人心:团队为各自的任务买单,承诺最可能时间,任务分配矩阵的表格最后要老板签字!

15.  以人为本:软件项目的主要成本是人力。

产品设计体会(7014)《需求工程》培训记录

2008年夏,参加了2天的名为《产品经理需求工程实务》的培训,和去年的《产品需求管理》培训内容大约有60%的重合吧,但经过一年,还是听出了大于40%的新东西。

有关需求:

Ø 需要(Need,客观上需要,解决方案)、欲望(Want,主观上想要,内心深处的目的)、需求(Demand);用户经常跟你提他以为的Need,但我们要挖掘出Want,再转化为真正的Need可实现的Demand。

Ø 需求收集听的技巧:“聚焦于人们的期望而不是问题”,期望–>基本功能,问题–>增值功能。我的理解应该是:基本功能一定要听用户的,增值功能往往是设计师主导的。

项目管理范畴:

Ø OBSOrganization Breakdown Structure)产出物:项目管理的方法、体系;WBSWork)产出物:进度计划;PBSProduct)产出物:产品模块;FBSFunction)产出物:用例。

Ø 项目计划,传统:功能–>工作量–>人力–>工期;SCRUM:迭代周期(一周~一月)–>人力–>功能范围。一正一反,很有意思。

Ø 项目每日站立例会,每个人只能说3句话:昨天做了什么?今天要做什么?碰到什么问题,如何解决,需要什么帮助?

Ø 功能点工作量估计:宏观–>专家法;微观–>执行者自评(最悲观 + 4*最可能 + 最乐观)/6

综合方面的:

Ø 模仿 + 改良–>创新,随着时间的推进,“有可能遇到,但不要奢望”突破式的创新。

Ø 领导的四个层次(比较扯蛋的):“亲力亲为”,“活着(松下幸之助)”,“活过(邓小平)”,“没活过也行(耶稣)”。

Ø 企业成功四个模式:拥有资源(国企),生意模式(ali),拥有核心技术(Intel),管理/营销强(P&GNike)。

Ø 要找到自己产品的“最”,人们只能记住“第一”、“最”。

Ø 自己的想法:IT公司要做的事情都是类似的,都有那么几块,但是每种职位做什么事情在各个公司都有所不同,并不用在意,只要每件事情都有人做就行了。这其实就是产品的用户体系里“权限”和“角色”的关系,所有公司都有那些权限,但是各自有独特的“角色定义”,在阿里PD的角色对应经典定义就是:部分“产品经理”的权限 + 部分“开发/系分/架构”的权限 + 部分“项目经理”的权限。