人人都是产品经理——iamsujie

2009年4月16、17两天参加了倪砥老师的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 误区：只有信息传递而没有说服

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

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

Ø 培训师：鱼what+渔how，一个都不能少。

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

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

Ø 有关ppt：文不如数，数不如表，表不如图，图文并茂，循环。

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

Ø 开场白五步：

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

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

n 学员收获：抛出利益点

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

n 共识：一些规则、原则

Ø Story telling（case telling），推荐阅读“编剧”的教材（曲折的“弧”，UCD）

n 内容

n 表达

Ø 有关讲

n 感染力，共鸣：舞台感（练习：角色感）、同理心（心态：真诚，和大家一起成长）

n 引导力，facilitator（促动者）

n 学习力

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

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

Ø 最后，失败了又怎样，so what到so TaMa what。

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

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

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

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

 

下面是一些记录：

 Ø  以受众为中心（同理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  学员讲义（纸面材料，留白）

其他的一些记录：

 Ø  MOT：moment of truth

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

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

 n  方法：explore（客户需求）-offer（提供建议）-action-comfirm

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

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

 Ø  有思想没行动：空想；没思想有行动：盲动

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  发布：项目团队解散，成立LMT（Life-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  技术评审的三个决定：Go、Go with risk（有风险的继续）、Redirect（必须要解决某问题后再继续）。

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

Ø  零散的句子：

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

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

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

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

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

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

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

n  产品与样品：样品是做出来就行（很像实验室的行为），产品需要考虑经济效益。

n  协调是非增值的工作。

n  大会（应该是指人数多少吧）决定小事，小会决定大事。

n  小段子：硅谷的IC，Indian软件强，Chinese硬件强。

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

n  新人做老产品（新人不挑活，老产品不容易出事），老人做新产品（老人需要激情）。

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

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

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

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

问题的定义：

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

（iamsujie补：往往现实比你期望的差，但也比你认为的好。）

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

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

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

问题的分类：

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

Ø  设定型，给自己定的目标，主动改进；

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

判断问题解决优劣，需要订一个目标：

Ø  SMART原则：Specific、Measurable、Achievable、Relevant、Trackable。

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

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

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

Ø  分析问题：

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

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

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

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

Ø  制定对策：

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

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

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

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

Ø  实时监控

Ø  持续改进

有趣的零散记录：

Ø  企业现状，最大的问题是3C：Customer、Competitor、Change。

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

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

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