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