产品设计体会(7021)TTT培训记录

TTT(Training The Trainer)培训,意为培训者培训。好为人师的人对这样的培训自然不会放过,所以前段时间去参加一个简化版的,3小时左右,同时也融入了一些《课程设计》培训里和“讲”有关的话题,记录如下。

Ø 培训师:鱼what+how,一个都不能少。

Ø 编(课程设计)导(教学技巧)演(现场授课)的技能三角,愈发的想了解影视作品的创作过程了。

Ø 课程开发ADDIE,其实和软件开发很像:需求分析,Analysis;教案设计,Design;教材开发,Develop;培训实施,Implementation;培训评估,Evaluation

Ø 有关ppt:文不如数,数不如表,表不如图,图文并茂,循环。

Ø 培训展示技巧——如何演:声音、身体语言、视听帮助。

Ø 开场白五步:

n 引子:抓用户,可故事、笑话、案例、多媒体,最好和主题有关

n 主题:直截了当告诉大家这次的分享是什么

n 学员收获:抛出利益点

n 自我介绍:说明自己有资格站在讲台上

n 共识:一些规则、原则

Ø Story tellingcase telling),推荐阅读“编剧”的教材(曲折的“弧”,UCD

n 内容

n 表达

Ø 有关讲

n 感染力,共鸣:舞台感(练习:角色感)、同理心(心态:真诚,和大家一起成长)

n 引导力,facilitator(促动者)

n 学习力

Ø 现场互动:最动听的声音是学员的名字;找学员帮忙:高手、课托、提问者;对付提问:群众法、反问法、延后法。

Ø 点评的要点:要理性,要有建设性。推及日常的沟通,也应该遵循这样的原则。

Ø 最后,失败了又怎样,so whatso TaMa what

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

公司在“冬天”启动了内训项目,意在经济危机的时候练内功。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,连“优雅”都是可以量化的

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

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

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

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  激情来自于变化,看来价值观中拥抱变化和激情其实是一条。