IPD《hw能，你也能》摘抄
名词解释
- PDT - production development team - 产品开发团队
- TDT - Technology development team - 技术开发团队
- TMT - Technology management team - 技术管理团队
- carter -- 项目任务书
- CD DCP -- charter development DCP -- 产品概念评审点
- KO -- kick off -- 项目启动
- CR -- Commercial Release -- 可商业化生产
- EOL -- End of life -- 产品退市
- CD -- Concept definition -- 产品概念评审
- KO -- Kick off -- 项目规划评审
- TL -- Tooling launch -- 开发设计评审
- ES -- -- 工程验证评审
- DR -- Design release -- 设计验证评审
- CR -- Commercial release -- 生产验证评审
- MP -- Mass production -- 量产发布评审
- WS -- Working sample
- EVT -- Engineer Verification Test
- DVT -- Design Verification Test
- PVT -- Production Verification Test
- checklist -- 评审要素表
- BAT -- Baidu, Alibaba, Tencent
- BB -- building block -- 组件
- BG -- business group -- 业务群
- BLM -- Business leadership model -- 业务领先模型
- BMT -- Business management team -- 业务管理团队
- BP -- business planning -- 业务计划
- CB -- capability baseline -- 能力基线
- CBB -- common building block -- 通用构建模块
- CDP -- charter development process -- 项目人任务书开发流程
- CDT -- charter development team -- 项目任务书开发团队
- CRM -- customer relationship management -- 客户关系管理
- CP -- check point -- 检查点
- C-PMT -- corporate protfolio management team -- 公司组合管理团队
- C-RMT -- corporate requirement management team -- 公司需求管理团队
- C-TMT -- corporate technology management team -- 公司技术管理团队
- DCP -- decision check point - 投资决策点
- DRR -- deployment readiness review -- 推行准备评审点
- E2E -- end to end -- 端到端
- EOL -- end of life -- 生命周期结束
- ESP -- early support plan -- 早期客户支持计划
- GA -- general available -- 通用可获得性
- IFS -- integrated financial system -- 集成财务系统
- IPD -- integrated product development -- 集成产品开发
- IPMT -- integrated protfolio management team -- 高层决策团队
- IRB -- investment review board -- 投资评审委员会
- ISC -- integrated supply chain -- 集成供应链
- ISOP -- integrated strategy & operation process -- 集成战略运营流
- ITMT -- integrated technology management team -- 集成技术管理团队
- ITR -- issue to resolution -- 从问题到解决
- JIT -- just in time -- 准时制
- LMT -- life-cycle mnanagement team -- 生命周期管理团队
- LPDT -- leader if PDT -- 产品开发团队经理
- LTC -- lead to cash -- 从销售线索到回款
- MM -- market management -- 市场管理
- MOT -- moment of truth -- 关键时刻
- MP -- marketing planning -- 市场规划
- ODM -- original design manufacture -- 原始设计制造商
- OEM -- original equipment manufacture -- 原始设备制造商
- O/S -- offerings requirement -- 产品包需求
- PACE -- production and cycle-time excellent -- 产品以及周期优化
- PBC -- personal business comitment -- 个人绩效承诺
- PDT -- production development team -- 产品开发团队
- PLM -- production life-cycle management -- 产品生命周期管理
- PL-IPMT -- production line integrated protfolio management team -- 产品线集成组合管理团队
- PL-LMT -- production line life-cycle management team -- 产品线生命周期管理团队
- PL-PMT -- production line protfolio management team -- 产品线组合管理团队
- PL-RAT -- production line requirement analysis team -- 产品需求分析团队
- PL-RMT -- production line requirement management team -- 产品需求管理团队
- PL-TMT -- production line technology management team -- 产品线技术管理团队
- PMBOK -- project management body of knowleage -- 项目管理知识体系
- PMI -- Project management institute -- 美国项目管理协会
- PMOP -- program management operation process -- 变革项目管理运作流程
- PMT -- protfolio management team -- 组合管理流程
- production roadmap -- 产品路标（也叫产品线路图）是产品、 服务或解决方案的发展方向和中长期规划， 对内用于指导项目任务书（ charter） 开发和牵引技术规划， 对外用于与客户互动以获取需求和支撑销售。 是SP和BP的重要内容。
- PROPS -- the project for project steering -- 指导项目运作的项目
- PRR -- pilot readiness review -- 试点准备度评审点
- PRT -- production research team -- 产品预研团队
- PSST -- production and solutions staff team -- 产品和解决方案体系
- PTIM -- product & technology innovation management -- 产品技术创新管理
- QMS -- quality management system -- 质量管理体系
- RAT -- requirement analysis team -- 需求分析团队
- RDPM -- R&D project management -- 研发项目管理
- RM -- requirement management -- 需求管理
- RMT -- requirement management team -- 需求管理团队
- RP -- roadmap planning -- 产品路标规划
- SDCP -- selection DCP -- 决策选择评审点
- SDT -- solution development team -- 解决方案开发团队
- SE -- system engineer -- 系统工程师
- SP -- strategy planning -- 战略规划
- SPDT -- super production development team -- 超级产品开发团队
- S-PMT -- solution protfolio management team -- 解决方案组合管理团队
- systemn requirement -- 系统需求
- TDCP -- temporary decision check point -- 临时决策评审
- TDT -- technology development team -- 技术开发团队
- TMG -- technology management group -- 技术管理组
- TMS -- technology management system -- 技术管理系统
- TMT -- technology management team -- 技术管理团队
- TPD -- technology & platform development -- 技术开发
- TPM -- transformation progress metrics -- 变革进展评估
- TPP -- technology & platform planning -- 技术和平台规划
- TR -- technology revirew -- 技术评审
- TRT -- technology research team -- 技术研究团队
- WWPMM -- world wide project management methods -- 全球项目管理办法
- X-TMG -- 跨产品线 TMG
- POP -- 项目助理
- CMO -- 项目配置管理
- QA -- 项目质量保证
- UCD -- user center design -- 以用户为中心
- SP -- 战略规划 -- 制定未来3～ 5年的战略规划
- BP -- 战略展开 -- 制订下一年度业务计划和预算
- 战略执行和监控 -- 战略执行与监控， 持续进行， 通过定期（ 季度或月度） 对SP和BP进行审视和更新。
- 战略评估 -- 战略评估是对战略执行情况进行评估和总结， 包括组织和团队绩效、 个人绩效、 项目绩效、 管理体系评估等。
- 技术
广义上， 所有达成目标的实现方式都是技术， 比如： 管理也是一门技术。 但在IPD体 系和本书中采用的都是狭义的定义， 特指和产品密切相关的实现方式。
这本书的技术主要指一下几个方面：
系统设计技术， 可分不同层次， 比如： 产品/解决方案系统设计技术、 子系统 设计技术
各领域专业技术， 比如： 外观、 机械、 结构、 工艺、 硬件、 软件等
流程 / 原则
- IPD 的七大核心思想
1. 研发是投资行为：“君子爱财，取之有道” ， 公司也应如此。 对公司而言， “道” 就是合法满足客户需求， 在此基础上实现商业目标， 所以， 业务经营有两条主线： 实现公司商业目标和满足客户需求， 两者缺一不可。
2. 基于需求的研发：满足客户需求是企业生存的基础， 无论公司战略、 市场规划、 产品和技术规划、 各功能部门的规划， 还是产品和技术的研发， 以及公司其他运营活动， 都必须围绕客户需求进行。 客户需求是多方面的， 需要通过管理层、 营销部门、 产品管理部门、研发部门、 售后部门、 质量部门等“神经末梢” 进行系统收集， 并传递到公司的各个体系和部门。
3. 平台开放化：为了提高产品、 服务、 解决方案的开发效率， 需要通过需求管理、 产品和技术规划提前识别公共技术和关键技术， 单独立项开发， 这样才能在产品开发过程中调取这些资源， 从而在快速响应客户需求、 提高质量、 降低成本上同时取得领先优势。 为了做到这一点， 抽取现有产品共同使用的模块和技术形成平台只是最基础的工作，更为重要的是要探索和研究目标客户未来的共同需求， 在此基础上形成产品和技术平台， 对产品研发提供有力支撑。
4. 跨部门协作：创新和研发是全公司的行为， 接力棒式的产品开发流程难以保证产品质量。 在IPD体系中， 无论是需求管理、 产品和技术规划、 项目任务书开发、 产品和技术研发、 产品上市， 还是上市后的生命周期管理， 都广泛采用跨部门团队， 汇集各个领域的专业智慧， 形成合力， 共同满足客户需求， 为产品的商业成功负责。 为此， 各个职能部门应“退到幕后” ， 为这些跨部门团队提供资源和支撑。 同时， 公司的企业文化、 绩效管理和激励机制也要支撑跨部门团队的运作
5. 结构化流程：把复杂的产品创新过程进行解构是管理的基础。 IPD体系中的各种流程被划分为若干个阶段， 在每个阶段设置了评审点， 按角色归集流程中的活动， 以便与组织结构相互匹配。 评审点分为决策评审点和技术评审点， 在MM流程和IPD流程中， 通过决策评审实现高层决策团队（ 投资方） 和规划团队、 研发团队（ 承诺方） 等的互动， 资源分批受控投入， 既满足项目进展需要， 又避免投资失控。 通过流程中的技术评审，实现专家和项目团队的充分互动， 各领域专家充分利用其专业经验为研发团队提供指导， 确保产品最终满足客户需求。
6. 业务能力均衡：业务发展和内部能力建设是一对相互支撑的矛盾， 业务发展可以促进能力提升， 但独立进行能力构建也是必需的， “磨刀不误砍柴工” 。 所以， 快速响应市场需求的同时不能忽略内部能力构建， 两者都很重要。 无论产品多有竞争力， 终有生命周期结束之时， 但企业通过各种方式构建的能力可以使其源源不断地推出新产品。 在企业发展的不同阶段， 可以有策略、 有选择地把重心放在业务发展或内部能力的构建上
7. 灵活发展，与时俱进：任何管理模式都必须结合企业实际情况，IPD不是一套固化的思想、 流程、 子流程、 组织架构、 激励机制， 更不是各种纷繁复杂的工具、 模板、 表单和考核指标。 IPD是灵活发展的， 必须在不断吸取业界最佳实践和解决业务问题的过程中与时俱进， 因此华为目前运行的IPD与1999—2003年在IBM咨询顾问的指导下引入的IPD已经有非常大的不同 - IPD 七大组成部分 管理优化变革，绩效与激励，矩阵组织，RDPM， RM， IPD，MM
- MM 方法论的六个步骤 理解市场，细分市场，组合分析，指定业务计划，融合和优化业务计划，管理和评估业务计划
- IPD 研发的六个步骤 概念，计划，开发，验证，发布，生命周期
- RM 以客户未中心的五个过程 需求探索和收集，需求分析，需求分配，需求实现，需求验证
- 5 个决策评审点
1. 项目任务书（ charter） DCP， 简称charter DCP。
2. 概念（ concept） DCP， 简称CDCP。
3. 计划（ plan） DCP， 简称PDCP。
4. 可获得性（ available） DCP， 简称ADCP。
5. 生命周期终止（ life end） DCP， 简称LDCP。 - MM 方法论
1. 孙子“上下同欲者胜”
2. MM 方法论的 6 个步骤：理解市场，细分市场，组合分析，指定业务计划，融合和优化业务计划，管理和评估业务计划
3. MM 更多用圆圈表达，他不是串行的，而是循环迭代的， 也就是在规划过程中随时可能修订前期的结论。
4. ISOP 以 MM 为基础，统一管理企业的战略规划和各种运营活动及其管理体系的流程框架。
5. ISOP 的四个阶段：战略规划（SP）,战略展开（BP）， 战略执行和监控，战略评估
6. ISOP 中通过战略执行中的监控和定期评估活动， 确保组织、 团队和项目工作既能实现公司的短期目标，也能实现中长期目标。 - 业务计划书的主要类型
公司业务计划书 -- C-BP -- corporation BP
产品线业务计划书 -- PL-BP -- product line BP
产品包业务计划书 -- O/SBP -- offering / solution BP
细分市场业务计划书 -- SM-BP -- segment market BP
功能部门业务计划书 -- FD-BP -- function department BP - 需要进行长期规划的产品
1. 不确定性业务
2. 产品和技术研发周期长的业务
3. 投资越大的业务
4. 如果要取得长期竞争优势， 必须进行长期规划， 在此基础上进行基于产品和技术平台的开发， 取得质量、 成本和时间进度在高层次上的平衡。 - 企业在产品开发过程中的典型问题
1. 没有把研发作为项目进行管理
2. 开发流程结构化不足或者过度结构化
3. 研发部门唱独角戏
4. 决策层介入不当
5. 部门经历或者专家介入不当
6. 在产品开发过程中进行技术公关
7. 创新过程缺乏一致的方法论 - IPD 流程核心
概念和计划阶段是IPD流程的核心，国内企业在这两个阶段的投入严重不足， 研发中的大多数非组织问题都可以通过加大概念和计划阶段的投入来解决， 也就是先做周密策划， 再开展具体开发工作。
1. 概念阶段投入不足， 导致在没有明确客户需求之前就开始设计方案， 并很快启动系统设计和概要设计工作。
2. 计划阶段投入不足， 导致在没有明确系统设计和规格之前就启动具体开发工作， 最终结果就是在开发过程中不断被需求和设计变更打断
3. 到了验证和发布阶段， 产品和技术问题纷纷暴露出来， 不断进行修改， 甚至导致产品在没有经过严格测试验证的情况下发给客户， 客户现场成了实验室。
4. 研发以外的其他角色， 如市场、 销售、 采购、 制造等角色在概念和计划阶段基本没有参与， 他们的需求没有纳入总体方案加以整体考虑。
5. 前期没有深入分析需求、 技术难点和模块重复利用等问题， 导致在产品开发过程中解决技术难题， 由此也加长了研发周期 - 决策评审必须做出明确的结论， 且只有三个结论：
1. 继续（ Go） ： 同意， 可以继续开展项目， 承诺提供下一阶段资源。
2. 终止项目（ No Go） ： 不同意， 项目终止， 释放资源。
3. 重新定向（ Redirect） ： 重新定向， 要求项目组根据高层评审意见对业务计划进行调整优化， 重新进行决策评审 - 产品层面的技术评审点设置参考原则
1. 在决策评审点前必须设置技术评审点， 只有通过技术评审才能提交高层决策评审
2. 产品开发周期越长， TR应越多。 两个评审点之间如果超过3个月， 通常应增加 TR
3. 复杂和技术含量高的产品， 应设置更多的TR。 尤其是系列产品的第一个产品。
4. 涉及领域越多的产品， 应设置更多的TR。 比如汽车产品几乎涉及所有专业技术领域， 需要在产品开发过程中设置比其他产品更多的TR - 评审会议必须注意如下要点
1. 会议质量决定了评审质量， 有华为高层曾说， IPD的最大价值是教会了华为如何开会。
2. 评审会参与者会前必须仔细阅读相关材料， 和项目组沟通， 发现问题及时解决
3. 评审会的目的主要是达成共识和识别潜在问题， 尤其是跨部门问题， 而不是在会上解决问题。
4. 会议一开始首先解决上次会议的遗留问题
5. 无论是DCP还是TR， 都必须使用评审要素表， 以免遗漏检查项
6. 主持人要注意控制时间， 避免漫谈和跑题， 会议必须有结论。
7. 会后贯彻会议结论， 明确责任人， 跟踪问题的解决 - 研发过程中的角色
一般说来， 共有9个角色（ 含团队） 参与产品开发过程， 分别是高层决策团队（ IPMT） 、 产品开发团队经理（ leader of PDT， LPDT） 、 财务代表、 质量代表、市场代表、 研发代表、 采购代表、 制造代表、 技术服务代表等。 其他参与角色可纳入这些角色的外围组。 - 企业在管理需求时常见问题
1. 缺乏完整的需求定义和描述框架
2. 错误地认为需求是创造出来的
3. “无节制、 无底线” 地满足客户需求
4. 长中短期需求分布不合理
5. 以产品为中心而非以需求为中心经营企业 - 建立需求管理体系要从4个方面入手
建立需求管理流程、 需求变更控制流程、 需求管理组织和需求质量管理体系。 - 需求管理流程
需求管理流程分为需求收集、 需求分析、 需求分配、 需求实现和需求验证5个阶段。 其中， 需求收集和分析阶段是关键， 需求分配是产品规划的核心工作， 需求实现和验证通常在研发过程中实现。
为了确保最终交付的产品和解决方案满足需求， 必须对需求进行端到端的跟踪； 当需求发生变化， 或设计变更和工程变更影响需求时， 必须启动需求变更流程。 - 角色和岗位
1. 一个岗位可承担多个角色。 在产品开发流程中根据职能把活动进行归类， 有助于工作的分解和流程的阅读。 但并非每个角色都要对应不同岗位， 在一些小型开发团队中， 一个岗位承担多个角色非常普遍。 比如PDT经理同时兼任财务角色， 制造d人员同时兼任采购角色。
2. 一个角色可由多个岗位承担。 在大型产品开发项目中， 这种情况很常见， 比如硬件角色对应的工作， 需要多个与硬件相关的岗位来承担
3. 角色是分层的。 如果一个角色的工作可再细分为子类， 并且这些工作由不同岗位承担， 可设置二级角色， 也就是PDT团队中的外围组， 也叫扩展组。 比如市场角色， 可以进一步分为需求管理、 市场计划、 市场推广等角色
4. 角色可以在组织外部。 比如在开放式创新模式下， 客户、 合作伙伴和供应商都可以是产品开发中的角色， 他们不仅仅提供需求信息、 原材料和零部件， 还会直接参与到产品开发过程中。
5. 机器设备和信息系统通常不作为角色。 - 关于矩阵组织 强矩阵组织方式实质上是把外部市场机制引入到企业内部， 让企业内部功能部门能够感受外部竞争压力。 这种机制的良好运作需要以下几种转变：
- 会议共同行为准则
1. 把话放到桌面上。 以公开、 坦诚的方式面对问题， 展开讨论。
2. 永远尊重并正直地对待彼此。 尊重彼此的职业素质； 讨论是以事实为依据的，对事不对人。
3. 倡导团队协作。 在树立团队精神方面要起到表率作用， 鼓励下属积极进行跨部门、 跨界限的沟通与协作。
4. 一个声音说话。 遵守“内阁原则” ， 永远只在团队内部解决不同意见， 一旦团队做了决定， 就是团队每一成员的决定， 坚决贯彻落实。
5. 恪守团队承诺。 恪守对团队/成员的承诺； 尊重最后的期限； 只承诺能够交付的； 保守秘密。
6. 做到准备、 在场、 参与的一贯性。 要预先完成材料阅读， 永远有备而来， 准时参与并遵从日程； 积极参与讨论， 主动发表观点， 充分分享信息， 及时回应团队成员的发言； 利用好时间并能做决定。
7. 鼓励不同的观点。 既要独立思考又要善于妥协； 要善于倾听团队成员的发言，具有同理心， 能够听出发言人的内心感受； 日常团队成员间多利用非正式的沟通方式加强协商。 - 关于绩效管理
1. 绩效管理是将公司的使命、 愿景、 目标、 战略、 业务、 资源有机地结合起来所构成的一个完整的管理体系。
2. 绩效管理是管理者和员工双方就目标及如何达到目标形成共识， 并促成员工成功达成目标的管理方法。 - 用IPD管理体系来保障流程的有效运作。 IPD管理体系除了包含前面提到的业务流程外， 还包括：
1 组织、 角色和职责。 它们定义了支撑流程运作的各级组织， 主要是跨部门团队， 以及相关的成员角色和工作职责。
2 度量（ metrics） 与考核。 度量指标用于衡量流程运作质量。 华为针对所有流程、 子流程分别制定了衡量指标。 部分流程度量指标用于员工考核， 通过绩效管理和激励机制， 强化行为规范。
3 技术管理体系。 通过业务的分层分级管理， 构建各层级的通用构建模块（ CBB） ， 提高产品开发效率。
4 技能提升。 构建支撑IPD体系运作的个人技能， 包括管理和领导能力、 沟通交流能力等。
5 IT工具。 构建支撑IPD体系运作的各种信息系统。 - 产品呢开发的六个阶段 -- 概念 / 计划 / 开发 / 验证 / 发布 / 生命周期管理
- 五个投资决策点 -- Charter DCP / CD DCP / KO DCP / CR DCP / EOL DCP
- 七个项目过程评审点 -- CD / KO / TL / ES / DR / CR / MP
- 1+5 个试产阶段 -- WS / EVT / DVT / DPVT / 量产
- 企业不能行动一致是因为没有做到四个对齐：
上下对齐： 高层、 中层和基层的对齐。
左右对齐： 不同产品线和部门之间的对齐
长中短期对齐： 长期规划（ 3年以上） 、 中期规划（ 1～ 3年） 和短期规划（ 年度计划） 的对齐。
外部对齐： 整个公司的计划要能满足客户和市场需求， 适应外部环境变化。 - 未做到四个对其，是因为没有满足如下条件
1. 规划的输入不明确
2. 没有基于市场需求进行产品规划
3. 规划在无谓的试错中形成
4. 各领域规划割裂，未转为组织的一致行动
5. 没有考虑平台和技术的规划
图解
- 华为三大业务流程
- MM 方法
- IPD
- IPD思想与体系互相渗透
摘抄
- 正是华为对待管理体系建设的“一根筋” 精神， 在过去十多年中矢志不渝地基于 IPD 基本思想来构建管理体系， 才没有在纷繁复杂的管理体系森林中迷失方向， 不但业绩得到大幅度提升， 在体系构建上也节省了成本。 相比之下， 很多企业在管理体系的建设上就显得不够专一。 当把一种管理体系建设到一定程度， 取得一定成绩或者遇到困难后， 就转向另一个体系， 不但浪费了大量的时间和精力， 也分散了管理层和员工的注意力， 最后成了各路专家教授、 咨询顾问、 培训讲师的试验场。
- 管理体系的建设需要持之以恒， 而不是朝三暮四。
- 是否基于平台和核心技术进行系列产品开发是公司研发实力的最终体现。
- 法国社会心理学家托利得说： “测验一个人的智力是否属于上乘， 只看脑子里能否同时容纳两种相反的思想而无碍其处世行事。 ”
- MM 是工作方法， 也是思想方法， 实际运作中绝非简单地按部就班就能完成规划工作的， 而需要在各步骤之间创造性地不断迭代循环， 最终制订出可执行的业务计划。
- 很多企业因为没有信心或无法应对矩阵架构中的“多头管理” 而选择放弃， 仍信奉传统的“统一指挥” 原则， 导致公司集权和官僚化， 无法快速响应市场需求， 成为创新的障碍； 或者走另一个极端， 把公司拆分为若干个独立的业务单元， 难以实现资源共享。
- 股权本质上是一种风险很大的投资， 和工作积极性并没有直接关系。 那是什么在起作用呢？量化员工的成就（绩效），高效的传达组织的目标， 要把公司、 各产品线和各部门的目标转化为个人目标， 使组织目标和个人目标“对齐” 。上级主管要帮助下级达成个人目标， 在整个过程中要和员工保持持续沟通， 对员工进行物质和非物质激励， 满足员工多方面的需求，而不仅仅是对员工实施“考核” 。
- 好的理念和思想如果没有管理体系来承载， 就只能停留在口号层面， 最终会落空。同时， 管理体系如果没有好的理念和思想来支撑， 就会失去灵魂。
- 规划中的问题还表现在产品规划和平台规划、 技术规划相割裂， 没有充分考虑各个产品之间、 产品线之间的技术共同点， 没有形成产品平台和技术平台， 难以形成技术壁垒。 结果是企业开发了很多产品， 但这些产品没有形成系列。 产品做了很多，但是技术积累很少， 每次开发新产品都要从头做起， 研发成本高， 产品上市速度慢， 质量也得不到保证。 同时， 因为产品之间差异性很大， 导致供应链成本、 销售成本和后期维护成本升高。
- 我们只允许员工在主航道上发挥主观能动性与创造性， 不能盲目创新， 发散了公司的投资与力量。 非主航道的业务， 还是要认真向成功的公司学习， 坚持稳定可靠运行， 保持合理有效、 尽可能简单的管理体系。 要防止盲目创新， 四面八方都喊响创新， 就是我们的葬歌。 --- 任正非
- 在现代分工体系中， 原本属于企业“内部事务” 的工作绝大多数都可以外包， 包括生产制造、 销售、 售后服务、 行政事务、 人力资源、 IT、 企业变革等， 研发、 采购、 质量控制等也可外包给更为专业的机构。 也就是说， 以上这些工作都是“产品或服务” ， 都遵循同样的商业逻辑， 都需要进行规划、 开发、上市和生命周期管理， 在企业内部构成一个“内部市场链” 。 但是， 如若外部机构做得更好， 从财务角度讲， 应外包这些工作， 但从外部采购这些服务需要的沟通和交易成本可能更高。
- 规划不能太多， 也不能太少， 靠企业自己把握； 犹如他对矩阵组织结构的观点： 矩阵是所有组织的终极形式， 但同时矩阵结构是不稳定的结构， 不是偏向职能制， 就是偏向事业部制 -- 《战略规划的兴衰》
- 广义上， 所有达成目标的实现方式都是技术， 比如： 管理也是一门技术。 但在 IPD 体系和本书中采用的都是狭义的定义， 特指和产品密切相关的实现方式
- 根据客户需求开发产品， 还是根据自己储备的核心技术开发产品， 实质上就是我们常常说的产品研发是靠“需求拉动” 还是靠“技术推动” 。 我们认为所谓技术推动是“伪命题” ， 如果技术脱离了客户需求， 必然无法推动产品的发展。 所以， 无论技术预研、 技术开发还是平台开发， 都必须以客户需求为导向。
- 在华为， 坚决反对新官上任三把火， 反对推倒重来， 反对激烈的改革， 华为提倡的是改良、 改进、 改善。 什么叫创新？ “70%的继承是牛粪， 30%的创造是鲜花， 鲜花一定要插在牛粪上， 这才叫创新。 ”
- 很多企业会问： 产品开发过程中需要多少个文档？ 我们的观点是， 视情况而定， 和产品复杂程度和企业管理水平相关。 除机械/结构图、 电子线路图、 软件代码等产品数据和制造体系文档外， 其他都是过程文档。 但从结果看， 是否有过程文档， 并不影响产品的生产甚至上市， 但这些文档体现了开发之前和开发过程中是否“想清楚了再做” ， 过程是否规范， 是否做好记录， 决定了有问题是否可以进行有效回溯。三产品最终质量是由过程决定的， 过程中要做好记录， 形成文档。
- 概念和计划阶段的工作质量决定了产品开发过程的质量和最终产品质量。
- 决策评审点的设置不是固化的， 对于全新产品开发， 不建议裁剪或合并； 对于改进型产品开发， 概念和计划阶段可合并。 相应的， CDCP和PDCP也合并在一起进行， 不过需要同时关注这两个点的评审要素。
- 包括苹果在内的大量案例表明， 高层是否介入技术评审甚至亲自上阵参与开发并不重要， 关键在于高层是否在他所承担的角色上有相应的能力， 为产品做出贡献。
- 子流程是从领域或者角色维度， 也就是袖珍卡中的横向维度把流程进一步结构化。也有企业把这些子流程叫作部门流程， 比如软件部流程、 硬件部流程、 结构部流程等， 但在IPD体系中尽量避免用“部门流程” 来表达， 因为所有子流程仍然是跨部门的。 这些子流程在设计上要与IPD主流程对齐， 包括角色、 阶段、 评审点、 活动、 交付件模板、 术语等。
- 流程的结构化程度与行业特点、 企业历史、 规模、 管理成熟度、 产品复杂度、 产品生命周期、 需求稳定度、 项目组规模度等因素相关。 企业历史和规模越大， 结构化程度一般越高； 产品越复杂， 介入的领域越多（ 包括客户和供应商） ， 越需要将流程高度结构化， 否则会带来跨部门沟通困难， 职责不清； 项目组规模越大， 越需要结构化。 相反， 如果整个行业处于快速变化中， 需求和产品形态变化很快， 产品生命周期很短， 结构化程度就应当低一些， 比如目前的智能手机行业
- 在需求满足上， 技术推动不是万能的， 关键是如何利用技术。
- 要做好需求管理， 首先必须澄清与需求相关的诸多概念， 摆正客户（ 需求提出方） 和供应商（ 需求满足方） 之间的关系， 明白技术在需求实现过程中如何起作用
- 需求本质上不是被创造出来的， 而是采用各种方法不断探索、 发掘和提炼， 同时用技术手段来实现的。
- 质量从本质上讲是需求的实现程度， 质量管理首先要确保需求本身的高质量， 需求质量管理应当成为公司质量管理体系建设的核心内容之一。
- 很多企业IPD流程运作不成功， 就在于没有把组织建设的重点放在跨部门团队打造上， 而只是机械地把流程中的活动纳入功能部门。
- 必须深刻认识到如果企业要达成多重目标， 组织也必须是多重和复杂的。
- 完整的绩效管理过程包括绩效目标和计划、 绩效执行和辅导、 绩效沟通和评价以及考核结果应用4个阶段。 过度而片面地强调绩效考核带来的结果就是把其他3个环节忽略了， 尤其是前面两个环节。如果把这两个阶段工作做扎实，考核结果自然会呈现， 并且双方也容易达成共识。
- 决定员工是否加入公司的因素是薪酬和福利； 决定员工留在公司不离职的因素除薪酬外， 还有公司提供的发展机会和工作环境； 但决定员工是否在岗位上敬业的因素却没有一个与薪酬和福利相关， 这些因素是成长空间、 工作本身、责任、 成就感等。
- 绩效的英文是performance， 原意是“表现” 。 绩效就是“表现得如何” ， 并非通常所说的最终结果， 大有过程之含义。
- 绩效既是结果也是过程。 对不同层级、 不同部门， 其含义不同。 高层要对最终的经营结果负责； 中层既要对结果负责， 也要对过程负责； 基层主要对过程负责。这些区分不是绝对的。
- 绩效管理的最终目标并非仅使员工达到期望的绩效， 而是使他们愿意付出超越职责的努力。 -- 杰克·韦尔奇
- 绩效管理的根本目的是为了引导并激励员工贡献于组织的战略目标， 同时实现组织和个人的共同成长， 它不是绩效考核， 而是一个管理过程。 -- IBM公司
- 绩效管理是管理者和员工双方就目标及如何达到目标形成共识， 并促成员工成功达成目标的管理方法。
- 实践中有一个问题， 研发人员是否会倾向于制定较低的绩效标准？ 一般说来， 合格的研发人员都具有较强的成就导向， 不会主动倾向制定较低的绩效标准。 不过， 如果绩效目标和物质报酬等紧密挂钩， 员工基于风险考虑会倾向于制定较低的绩效标准， 并和主管“讨价还价” 。 这是因为研发工作有一定风险， 制定较低的绩效目标更容易达到。 很多开创性的研发工作只有员工本人才能对工作做出准确的估计， 信息的不对称让研发主管处于不利地位。
- 真正的紧迫感是一种十分主动、 目标非常明确的动力， 因为它会自然而然地引导你真正关注眼下发生的一切真实情况， 很少会误导人们去竞相过问小事， 从事对整个组织意义不大的工作， 或者在信息不畅的情况下采用可能招致危险的方式去处理重大问题。
- 同时， 客户还要有支付能力， 电动车比燃油车发明更早， 直到今天也没有普及， 很重要的一个原因就是电池成本一直居高不下。
- 以产品、 技术来定义自己所处行业的企业要小心， 你的客户的需求是否被“其他行业” 的产品和技术满足了？
- 华为的核心价值观：成就客户，艰苦奋斗，自我批判，开放进取，至诚守信，团队合作，
- 胜则举杯相庆， 败则拼死相救。
- 涌流理论是指这样一种现象， 当人们的技能达到一定程度， 面对与此技能相关的非常有挑战性的工作时所表现出来的状态。 这种状态下行动和意识相融合、 没有杂念、 目标感极强、 思如泉涌、 不担心失败、 忘记时间的流逝等， 因为忘掉自我而达到另一个层级的自我。
- 员工的个人需求，本质上员工是在为自己工作， 而不是为公司的目标，管理者需要深入考虑的问题， 作为管理者决不能粗暴地用自私、 没有大局观来解释员工的行为。 只有把组织目标和个人目标有机结合起来， 才能真正调动员工工作积极性。
- 研发人员的主导需求是什么？ 调查结果表明： 个人成长、 物质报酬、 尊重与自我实现是最重要的3大需求。
-
Charter 必须回答 6 个关键问题：
1. why -- 为什么要开发这个产品
2. what -- 产品是什么
3. who -- 谁来开发这个产品
4. How -- 怎么开发这个产品
5. When -- 开发计划是什么，何时上市
6. How much -- 需要多少投资，收益是多少?
参考文档
 |
 |
原创文章，版权所有，转载请获得作者本人允许并注明出处
我是留白；我是留白；我是留白；（重要的事情说三遍）
