存档

文章标签 ‘培训记录’

产品设计体会(7019)《课程设计》培训记录

2009年2月16日

公司在“冬天”启动了内训项目,意在经济危机的时候练内功。21314号两天,参加了《品牌课程设计》的培训,正好可以把工作与理想结合起来了,不错。

“课程设计”是这次培训的内容;“产品设计”是我的工作;“问题分析与解决”是我所在团队将要开发的课程。

我的感觉,“课程设计”正好是“产品设计”的一个实例,产出的产品就是一门课,而“问题分析与解决”正好又是“产品设计”的泛化,“产品设计”的过程其实就是在分析和解决某个问题。嗯,我真能扯。重点是:我对“产品设计”最熟悉,所以会很自然的把方法论往它的“实例”或者“泛化”上套用的,这种举一反三就是所谓“手里头拿着锤子,看什么都是钉子”。另外,越抽象的事情,前面设计的过程越重,越具体的事情,后面执行的过程越重。

先上个图,集中体现了这两天培训的产出课程:《化蝶之道:问题分析与解决》。

 

下面是一些记录:

 Ø  以受众为中心(同理UCD),同样的信息对不同的人会产生不同的认知,要有empathy(同理心)

 Ø  课程最重要的是结构,多级结构,节点是你的观点,低级结构可用证明观点的案例

 n  金字塔原理:结构化思维、分类

 n  从各个方面重复要点

 n  不要自己造轮子!把精力放在本地化的二次开发上,做任何事情都是这样

 n  PAJES强化故事神经:

 u  个人经验:personal experience

 u  类比:analogy

 u  专家判断:judgment of expert

 u  产业经验:examples from industry

 u  外部数据支撑:startling statistics

 Ø  内到外三圈:目的、方法(为目的服务)、案例(练方法)、案例展开(对比、设问,让人看反差),道理不要自己说出来,启发式的让受众自己体会到,“孩子亲生的比领养的好”。

 n  要点的细分,到第三层以后,找出最关键点一两点即可,适合轻量级的培训

 Ø  商务文档的引用,记得左下角需要注明资料来源:一方面是知识产权意识,一方面是给自己找支撑

 Ø  课程package

 n  原理图(mindmanager

 n  课程讲义(ppt,在备注里写明要点,形成讲师手册)

 n  学员讲义(纸面材料,留白)

其他的一些记录:

 Ø  MOTmoment of truth

 n  我们与客户在多点、多层面上全面接触,并不只是销售

 n  我们的认知与客户的认知不同,客户的认知才算数

 n  方法:explore(客户需求)-offer(提供建议)-action-comfirm

 Ø  虚的东西是因为不熟悉而无法量化,在apple,连“优雅”都是可以量化的

 Ø  供应商选择的风险:“一直选一家的垄断风险”与“换一家的不确定性风险”。

 Ø  有思想没行动:空想;没思想有行动:盲动

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

产品设计体会(7017)《流程管理》培训记录

2009年1月27日

2008年秋参加的,全称是《市场驱动的产品开发流程管理》,记录一下,先归纳一下整体的内容,然后再说几个专题。

Ø  大思想:

n  管理是一门科学(法治,规章制度,合适中公司)也是一门艺术(通俗的人治(从外向内的推动),领袖魅力,适合小公司;高雅的德治(由内向外),企业文化,适合大公司)。

n  路况(软硬件环境)与开车水平(个人能力)要求成反比,流程的目的就是改善路况。

n  公司战略–>产品战略–>产品路标规划–>计划。

n  公司战略推动:流程、组织、IT为骨架,并由激励机制保证。只有流程而没有与之配套的战略、组织、IT、激励等,就好比没有爱情的婚姻不能长久……

n  凡事的三个凡是:必计划、必评审、必文档化

Ø  最多传统行业的一次培训,都是中年人,-,-bbb,传统行业的流程明显细化了很多,比如奇瑞汽车的项目过程中有两三百个评审点,此外采购、物流等实体工业特有的元素也让他们的产品开发过程复杂了不少,当然也有相似之处,比如:

n  制造业的样品,类似我们的Demo

n  小批量试产,类似部分用户内测。

Ø  项目与生小孩:

n  生小孩容易养小孩难,不但培养成功很难,而且弄死他也很难,而且越往后越难,毕竟人是有感情的……

n  所以要少生优生,不幸多生就要排定优先级,不能 “会哭的孩子有奶吃”,而要“劫富济贫”(把资源投入到回报最大的小孩身上)。

n  小孩小的时候容易教容易影响,所以高层要尽早参与项目决策。

n  情感因素会与业务需求矛盾,越高层遇到的这种矛盾越多,所以好老板都不是“好人”。

Ø  项目管理与流程管理:项目管理是独特工作,风险大,效率低;流程管理(有点向运作型管理,类似的项目做多了就会出流程,据说华为员工去世的处理都有流程……)的是例行工作,风险小,效率高。

Ø  产品开发流程的最简模型(普适的),各阶段的关键词:

n  概念:启动,目标管理(SMART),业务需求,DCP1(商业评审点,Decision Check Point)。

n  方案:立项,外围组(一些非关键成员,执行层面)加入,规格、计划,DCP2

n  开发。

n  验证:测试,DCP3

n  发布:项目团队解散,成立LMTLife-Circle Management,老人带新人做这个来锻炼比较合适)。

n  生命周期维护:DCP4

n  前面两个阶段需要高手做,进入第三个阶段,高手应该去做新项目,引出“管道管理”。

继续,一点和组织有关的内容,组织是对流程的支撑。

Ø  最简项目组织结构(PDT):督导组(PAC)、Leader、核心组、外围组。根据产品性质,结合公司组织结构决定核心组成员,有能力、有权力的人要加入核心组。督导组是核心组所涉及部门的一把手,这样才能给核心组成员授权。

Ø  职能型组织/项目型组织/矩阵型组织:

n  职能型组织适合计划经济,有利于同类资源共享,互相学习提高,但各部门目标不一致(个人目标、部门目标、公司目标容易不一致),只对“上面”负责(唯一的客户),没有人对客户负责。

u  小段子:修高速公路最难的是拆迁问题(个人最优与集体最优的矛盾,没办法的,必然是在什么山头唱什么歌)。

u  团队同学们认为,这比较适合运作型的公司,人真的可以当作可替换的“资源”。

n  项目型组织正好相反,会资源浪费。项目发展下去就是事业部–>分公司。

n  矩阵型组织,一条是产品线、业务线,为了对客户负责;一条是资源线、行政线,为了资源共享。缺点:考核困难,要建立对事负责的文化。

n  权责利匹配,谁负责谁决定,谁执行流程谁制定流程,让着急有用的人着急。

n  职能(角色)与职位(人)的关系,一个人可以承担多个角色,一个角色也可以多人承担。

Ø  项目经理与部门经理兼任带来的问题:

n  管事,短期,有成就感,“猎人”,对打仗负责;

n  管人,长期,有权力,“农民”,对练兵负责,贡献技术与人;

n  部门经理如兼任项目经理会用权力来寻求成就感,从而放弃农民的责任去做猎人,短视。

n  推论:职能型组织变革,相当于剥离部门经理的成就感,所以会遇到有权力的人的阻力。

n  考核应该项目经理提供建议,部门经理决定。

Ø  公司变革必然要有人流血牺牲,所以变是找死,但不变是等死。如果要变,一把手必须亲自做,各层次执行流程的人亲自制定流程,有痛苦才会珍惜(对于请来的咨询公司而言,答案早已经有了,但就是要有一个过程让这个公司里的相关人员自己把答案说出来才有用)。并且向流程制定小组中派“政委”来掌控这个过程。

最后一部分,说一些评审的话题,再罗列一下我记的一些有意思的句子。

Ø  商业评审与技术评审:

n  参加评审的人都要承担相应的责任。

n  商业评审(决定做不做)与技术评审(决定怎么做)两者必须分开,否则陷入细节,技术人员受打击,领导变昏君。

n  商业评审的一大目的就是砍项目(决定继续、终止、重新定向),类似与我们的产品例会,BRD评审以及开发完成以后的“演示会”。

u  商业评审是分阶段分发资源的时间点,通过的项目发放到下一个商业评审点之前的资源。

u  小段子:决定玩21点(启动项目),每一张(设立评审点)看(评审动作)一次,再决定是放弃还是继续。

n  合理设置商业评审点,并且两点之间要“将在外君命有所不受”。

n  想要评审不走形式,就必须把评审会变成形式。

u  事情做在前,提前发邮件材料,电话确认(邮件收到,附件能打开,图能显示……),约面谈(分别串供)。

n  技术评审类似我们的UC评审、设计评审、TC评审。

n  技术评审的三个决定:GoGo with risk(有风险的继续)、Redirect(必须要解决某问题后再继续)。

n  反例:技术评审三部曲——抓壮丁(随便找的有空的人来参加)、科普会(来的人根本不了解情况)、批斗会(争论……)。

Ø  零散的句子:

n  “取其精华,去其糟粕”,但是多数情况我们无法分辨精华与糟粕(上海地铁1号线与2号线的例子),所以不如“先僵化、后优化、再固化”。

n  土匪与游击队的区别在于将来他们有没有成功,失败了就叫土匪,成功了就叫游击队。

n  个人能力关键部门:研发(基底)、销售(体会乙方)、采购(体会甲方)、售服(练心态)。

n  研发人员要有成本意识,不要盲目创新。

n  当需要某种技术时的思路:一买(用现成的)二包(外包)三开发(自己做)。本质上还是基于成本的考虑,中国的国情下,说不定自己做更便宜……

n  著名先烈Motorola:技术开发强,产品开发弱。发明了很多,后来都是别人商业化的好。

n  产品开发是一个投资行为;产品开发是一个端到端(起:从客户中来;止:到客户中去)的流程;产品开发不只是研发部门的事情。

n  产品与样品:样品是做出来就行(很像实验室的行为),产品需要考虑经济效益。

n  协调是非增值的工作。

n  大会(应该是指人数多少吧)决定小事,小会决定大事。

n  小段子:硅谷的ICIndian软件强,Chinese硬件强。

n  流程结构的轻重,只能通过试错来找到平衡点。

n  新人做老产品(新人不挑活,老产品不容易出事),老人做新产品(老人需要激情)。

n  太贱的东西不适合直销。

n  信息充分的情况下,随着项目进行风险应该越来越小,否则项目必然有问题。

n  激情来自于变化,看来价值观中拥抱变化和激情其实是一条。

VN:F [1.2.0_562]
Rating: 4.0/5 (1 vote cast)

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

2009年1月27日

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

问题的定义:

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

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

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

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

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

问题的分类:

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

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

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

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

Ø  SMART原则:SpecificMeasurableAchievableRelevantTrackable

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

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

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

Ø  分析问题:

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

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

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

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

Ø  制定对策:

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

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

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

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

Ø  实时监控

Ø  持续改进

有趣的零散记录:

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

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

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

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

VN:F [1.2.0_562]
Rating: 5.0/5 (1 vote cast)

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

2009年1月27日

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.  以人为本:软件项目的主要成本是人力。

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