虽网上评价不高，但了解其他公司的实践始终不是坏事，需要有“取其精华去其糟粕”的心思，最佳实践不一定对所有企业都适用，适合的才是最好的。
本节案例主旨：产品创新/用户体验&团队管理/组织发展
第一篇 产品创新/用户体验
企业战略+产品技术变革，以用户需求来寻找最佳的产品形态，从客户需求驱动产品管理，以用户价值解读产品精神。从交互设计到设计决策，再到情感化产品设计思路。
UC核心用户需求：快+省->持续改进->快速迭代快速反馈快速创新、灰度发布（公司内测、论坛内测、特定渠道灰度发布）->提前收集关键体验数据：简化不必要的产品研发流程，敏捷模式+注重工具完善、知识传播和数据统计分析->持续研究产品优缺点+自主创新或的产品改进&研发各环节人员进行不断教育使用极致养成习惯。面对用户的诉求和建议，要分清楚哪些是真正的需求，哪些是误导->从表面到紧紧抓住用户最内在的需要，采用最合适的方法满足用户需求。
“车机”：车内娱乐系统，对车内环境的研究、人的生理心理研究、用户需求判断设计出解决方案=机械化驱动->强调情感化+信息娱乐化。
调研（方法：宏观-用户需求分析、技术趋势、文化背景、微观-竞品分析、人机环境分析、焦点小组、用户访谈、实地研究、Benchmarking、Persona；输出：用户需求、场景分析报告、竞品分析报告）
概念设计（方法：头脑风暴、工作坊、用户场景、情景版；输出：设计原则、典型界面、概念演示视频）
详细设计（方法：专家评审、焦点小组、纸面原型；输出：设计规范、详细架构、详细设计文档）
软件开发（输出：软件版本）
用户测试&迭代开发（方法：用户测试、专家评估、版本检视；输出：易用性问题、改进点、迭代优化版本）。
从人因角度看，感官、情绪、环境、硬件等对设计及操作有较大影响；从用户需求看，重点功能、扩展功能、附属功能（1-5）。
在保证重点功能品质下，逐步完成扩展功能的设计和规划：重点功能是指用户使用频率较高，同时用户也觉得非常重要；扩展功能是指用户使用的频率很低或者没有使用过，但用户感知其重要性较高；附属功能是指用户使用频率低或者没有使用过，同时觉得其重要性较低；
从使用场景角度分类->从而得到设计理念和设计整体构思：安全第一+愉悦享受(Safety/ Easy to Use/Reliable/Engaging /Unique等)－以安全为前提，人机交互、流程逻辑、页面布局、视觉设计有机结合。
中兴挪威ICT项目
UCD以用户核心，认为用户体验是需求的重要部分，需要前期就进行交流 + 认为界面上的功能交互设计必须紧密结合用户场景 + 认为用户体验工作要贯穿研发过程，指导产品上线 + 认为在整个产品设计过程中，要邀请用户一起参与。
UCD设计团队：设计经理－负责与客户同步对功能需求的理解，转化为交互设计方法，以及指导Demo的完成－交互设计师（负责梳理业务流程，以及输出产品功能的交互设计方案）、视觉工程师（视觉设计，定义界面视觉规范）、前端工程师（负责将交互和视觉设计方案通过Html实现形成Demo）、国际化工程师（理解功能需求基础上，翻译Demo和及时优化）。
获取用户和组织对系统的最佳满意度为中心，形成闭环：获取用户对产品体验的基本需求、详细了解和理解系统的使用背景、明确用户与组织的非功能性需求、针对用户反馈问题提出解决方案、根据用户需求评估产品设计方案。
实践过程：概念阶段（输出《用户研究报告》，详细分析用户特征-国家、用户、文化习俗、工作生活、地理与气候、经济与通信等，竞争产品和任务场景）-客户深度交流（F2F&Demo）+竞争产品分析+客户资料分析、设计阶段（ 输出《UCD设计说明》，说明设计理念和设计要点）、开发阶段（输出《易用性测试报告》，系统评估分析用户体验关键点）、交付阶段（输出《满意度问卷调查分析》-问题清单+调查问卷，满意平均分）。
几个关键实践：和客户一起参与设计，从头至尾；有一支专门的UCD设计团队做支持，全体人员合作分工、设计管理建议闭环问题反馈和解决机制，每次输出专业规范、ISO 13407。
人类机器人系统：将用户的经验和专业知识应用于我们的软件中－第一手经验和采访设计出原形，在纸上进行－快速迭代发现解决问题。UCD：Plan->Research->Design->Adapt->Measure。
Netflix在AWS：在线视频服务队计算、存储和网络等方面的需求量很大、敏捷性+灵活性。分阶段迁移，最佳实践：考虑到可能的故障而设计-假设会出问题（高可用性：备份恢复自动化+持久化Chaos Monkey检查应用服务在AWS上的鲁棒性）、基于云的产品特性（松耦合、Auto Scaling）、基于云的大数据分析（EMR分析）、灵活的开发和管理模式（开发运维部门紧密集合+运维自动化）－开源展示实力和互联网分享精神。
第二篇 团队管理/组织发展
快速迭代，构建互联网化地团队管理，从精益思想到精益团队管理，以及如何发挥自组织团队管理，打造阿米巴模式小而美团队。如何使用敏捷驱动的团队？如何建立组织中的可视化看板？掌握动态运营管理机制。极客精神（一群以创新、技术和时尚为生命意义的人）提升团队效能、跨界管理、游戏化的员工管理、顶层设计下的组织转型。
快速提升初见团队需求分析能力：控制人力成本基础上提高团队产出，需求端良好管控+培训新员工。多模式地方搜索、广义签到、优化产品体验、用户参与。
Facebook的LBS服务发展的启示：立即满足用户需求非常重要，保证数量增长和增长潜力，理解用户需求需要收集大量的用户行为进行分析－理解用户需要和产品创新需要进行很多的测试；内部测试－甚至无专门正式的测试团队，帮助产品开发团队集思广益和调整产品思路；容错系统，合理处理系统设计外的情况；增长，增长，再增长－一个发布不是开发的结束，而是另一个开发的开始－不断观察用户的使用习惯和结合用户的建议，可以帮助产品迭代和发展，贴近用户的需要：执行力+质量+稳步发展很重要。
大型研发团队的知识管理实践：人来-新人加入团队，如何让新人快速成长、快速融入产品团队？人往－技术骨干离开时，如何减少损失、规避风险？不重复发明轮子， 可以看到的是：知识库条目、条目被学习次数、促进了线上技术交流、技术创新、技术创新复用次数。
在研发团队实施知识管理需要：
“老大”很重视知识管理－由于很难量化其价值－业界难题；知识管理要与项目结合才会有人去主动应用，才能体现其价值－企业知识库沉淀的内容是实际项目研发过程中具体的、有效的实践经验和教训-离您最近的知识库；
知识管理PPT（People：有专人负责知识管理－负责宣传和推广/负责开发和运维/负责创新的组织，评审和应用推广－一线业务部门挑选骨干担任知识官－发现业务部门知识管理需要/推进创新与知识在业务部门中的应用/知识库内容审核、Process：要有配套的制度与流程，如考核、激励、宣传、积分体系等，知识管理可以与业务部门KPI（绩效\晋升）结合，知识官津贴。辅之以物质奖励：沉淀、分享、学习都会有机会参与抽奖和竞拍－程序员比较喜欢数码类产品以及技术书籍；精神奖励：优秀内容推首页，重点推广。Tools：知识库，工具和组织。
四个步骤推进：整体规划（与公司战略结合，搭建激励、考核、宣传制度-知识官团队和知识库-系统工程）、分步实施（由点刀面，逐步推进） 、重点突破（从需求最迫切部门开始，从公司战略产品开始，容易见成效并积累经验）、小步快跑（快速迭代、快速试错，出现问题可以及时调整）。如果是小型团队（几十个人）：可以没有知识库平台， 知识库管理制度，知识官团队，但只要从自己做起，定期总结心得与经验，分享给小伙伴们，逐步影响周边的人。
管理界格言：您想要得到什么，就要考核什么（You get what you measure）。
自组织团队的实践与讨论：以客户需求和测试为驱动、团队组织结构松散，但效率很高、项目协调人员在团队组织中占较大比重、团队成员不一定水平一致，但目标明确、基本一致的职业道德水平和文化修养、责任分散在每个成员身上、项目经理及各个部门的Leader，多数充当服务者的角色-行政上的权利很少使用、这是一个崇尚英雄的团队。
三个最佳敏捷实践（不好说）：测试驱动、快速迭代、建立自组织团队Mishkin Berteig-管理者为团队成员提供培训，团队成员不断改进工作（自我管理+管理者服务）－如何让团队成员朝着目标一起努力是团队自身需要解决的问题。服务+领导：第一是管理者必须绝对可靠和真诚-管理者必须问团队问题，并给与充分彻底的回答、其次需要足够的勇气帮团队解决一些难题、最后必须对团队目标有比较清楚地认识，并带领团队实现目标，而在这一过程中，管理者不能强迫团队做任何事情。
现实世界的自组织团队：应该由足够的宽容度容得下各式各样的人才，但宽容并非毫无节制，团队需要对个人有一定的“塑造性”。团队内的成员彼此影响，大家通过长时间的磨合以及团队整体文化的熏陶，性格与价值观趋同，做事方式方法形成默契，自觉性和自发性-某位成员没法被塑造是，团队自我净化能力进行“清理”-团队规模较大应该考虑更多如何发现并保护我们团队的自组织上面。
几点管理意见：规章制度很重要但要“因地制宜”；关注管理水平的时效性，避免为了管理而管理-如果员工绩效本来就不错，是否需要新的管理手段或者政策破坏这种和谐局面；管理人员充当服务者角色比管理者更加有效；网状管理结构强调的是职权的分散而不是简单的复制。
从绩效考核到绩效管理：岗位职责梳理和价值观培训，统一组织绩效判断依据-通过晒目标的方式，让管理团队对研发中心的绩效目标、互相协作方式达成共识－为团队制定相近的绩效辅导方案，逐一沟通－双周会，集体评估－多个交付小团队－扁平化结构，集体绩效。
避免固定不变的绩效管理模式、避免绩效考核和敏捷不匹配、避免绩效考核的斗智斗勇、避免绩效考核强推SMART目标、尝试晒目标、尝试人员盘点、尝试职责分工岗位层级梳理-让每个人清楚自己的位置、尝试设定与考核分离、尝试稳定的团队为业务负责、尝试绩效从有到无、尝试持续变革绩效管理模式。
几小时组织的，也是个人的－组织绩效到个人绩效；绩效知识工具，工具的好坏在于使用者；管理着员工的绩效层次。
作者总结－管理者绩效成熟度：用绩效控制工作、绩效辅助理清工作、绩效是团队做出来的、绩效是自己做出来的、创造让员工成功的环境；员工绩效成熟度－为指标工作、为工作工作、为团队工作、为自己工作、工作就是工作。
团队管理中的反激励和应对措施：反激励是本来是激励，但实施后确实相反的结果。
反激励之一：能者多劳－任务分配时尽量公平优先，然后才是能力强的人适当多做一点，以帮助团队尽快完成；管理者做任务调整的时候，心理要明白：每个人都应该完成一部分工作；管理者考核绩效是要看到那些额外的工作。
反激励之二：口头奖励的通货膨胀－要注意控制数量，分清层次－什么是好，什么是很好，什么是非常好；表扬时要真诚，并让员工感受到；建立物质激励和精神激励对应关系，不要让精神激励仅仅停留在口头上，基层员工最重要的是物质激励。
反激励之三：快速升职－管理者要清楚家底子，对团队和部门内的晋升空间要心里有数；开辟虚拟晋升空间，如技术专家；当破格提拔时一定要三思：是否有负面作用，正面作用>负面作用；资历绩效标准达到了-该升还是要升的。
反激励之四：工作越清闲越不满意－让团队每个人接近满负荷，然后忙闲搭配，不能长期超负荷；每个人的工作都具有挑战性；鼓励技术员工学会展示自己的工作－但不要花主要精力。
反激励之五：安抚式晋升－考虑晋升标准和案例，每次晋升都要三思而后行；如果员工有抱怨，关键是要理解员工的郁闷之处，提出提高的办法；遇到抱怨按照原则来，也要自己反思-真的达到标准？
反激励之六：谁擅长，就分给谁－分配任务要兼顾效率和培养，在工作中学习非常重要，老带新；工作需要新鲜感。
可能还包括别的反激励：是不要给员工打破规章的特别待遇？为了鼓励整个团队轮流坐庄？完全相信员工，还要不要做监督？严格要求可能带来副作用。
激励工作有三个要素：员工是否开心、团队是否开心、管理者自己是否开心-关于用自己的方式。
游戏式管理系统：经验值管理系统，采用实时记录的方式，充满乐趣地完成自己的工作，促进自我激励和管理－但遇到的问题是离职率高、个人业绩没有有效提升、员工没有归属感、忠诚度低等－敢于构想（来自日常工作），缜于思维（以人为本，反复推敲规则，公平竞争，必须有明确的和被重复推演的计量规则和计量标准）：薪资由等级决定，按经验值来，让员工给自己涨工资。
明确获取经验值的路径：岗位经验值－日常工作，根据当前岗位和职级情况获取每日固定经验值；项目经验值－参与完成项目和任务越多越能获得经验值；员工可随时查询自己的经验值状态。未来企业内部管理系统应做到：高效的沟通、智慧的工作、规范的管理、活泼的形式、简单的投入。
解读惠普的全球研发管理方法：技术创新、概念创新和产品创新。清晰明确的愿景和目标（建立创新文化，建立创新平台）；高效合理的团队；强有力和持续的推进（详尽计划）－按季度推进，全方面活动－电视媒体、海报、传单、现场采访、现场答疑和继续派送，创新日－创新明星；降低准入门槛（人人参与：ideas-solution-value）来推进创新产出：不仅仅是技术层面或项目业务领域，可以是流程改进、对管理的建议、关于工作环境的创新、关于工会人力资源等方面的创新；全面有效的激励机制－老大精神和行动上财力人力的支持－与绩效挂钩－不断曝光持续宣传－蝴蝶效应和鲶鱼效应；高效的平台：在线平台（网页=idea portal&solution zone）+ 离线支持和合作（ superman来借力实现创新落地）+ 专家团队（虚拟团队评审和鉴定）+ 知识管理的过程（创新被广泛使用，持续过程）
一个跨国银行的敏捷转型
敏捷中心（团队代表、组织内敏捷教练、组织外敏捷教练）和敏捷教练（辅导团队：收集团队需求，资质判断和准备、教练带着一起做、教练陪伴一起做、自己做、关闭；收集痛点和改进机会，寻找一个团队或几个团队试试，判断分析试行结果，推广到更多团队，观察部署情况，再识别改进机会）
敏捷意识和方法的全员培训（按阶段普及：管理层+基本/敏捷流程/高级篇）
全球经验积累和分享（先驱－复制有效实践、发现收集团队痛点、帮助团队解决问题；wiki知识看做资产，鼓励全球所有员工积累和分享知识，人人参与编辑，人人做贡献。选定一些实践作为所有团队必须遵循的标准，比如－相同固定的迭代周期，敏捷中心发表评估检查表，敏捷中心提供关键度量指标）
避免half_arsed Agile（制度化敏捷实践，允许团队在组织过程资产基础上定义自己的制度，当与组织矛盾提到中心来解决：准备－启动团队敏捷扫描、团队章程定义、培训；启动－设立角色、使用产品代办事项、开始仪式和实践；路程：制度化敏捷实践、提升角色设置，仪式，实践；日常工作：保持迭代改进、帮助解决问题、提议新实践）
自我诊断，团队驱动（成本和重要性－敏捷评估检查表）
注重代码质量（SQALE：低成本快速建设、提升团队对clean code的认识、定量技术债务、代码质量等级评定）。 Indices:可维护性、有效性、可修改性、可靠性、可测试性。
背景和目标：更快响应客户，系统仍然稳定可靠运行。
大型敏捷组织转型需要平衡组织、团队和个人的利益和诉求：正确理解团队自组织、给团队提供知识资产，允许团队裁剪、坚持组织底线要求；避免变形一半的敏捷：给出检查表，团队自己认识出不足、团队和组织互动协调改进；敏捷中心和教练：前期导入培训启动、中期近距离辅导、后期指导、承上启下避免生硬敏捷转型。
敏捷驱动：方正VRE模型（价值－角色－激励），敏捷技术分享+敏捷兴趣小组，敏捷最重要的是价值和人－自组织+松结对。
价值驱动力Value Driver－做产品前搞定资源，搞定人（产品经理和团队，包括外包资源），通心路（团队同一频道，聚焦在一个点上－开例会畅谈以后发展和工作是为了什么：有价值的团队，产品价值、生命周期、销售预估、销售策略、市场细分、竞争分析都过一遍－团队凝聚力－和团队成员一起分析这些价值点）、理思路（自己怎么做项目、做产品）、练套路（团队习惯）；
角色驱动力（Role Driver）－尽量少接触否定你的人，团队成员自己去找自己的位置，新产品开发不仅仅是公司的事情，也是自己的事情－把握好每次机会，然后让他参与大框架决策、实施、反馈，也就是适当授权。沟通技巧包括：了解他是什么样的人，建议大家了解下DISC行为分析、让不同类型的人去做他们喜欢的事情－前期每周认命一个负责人，感受项目难题以及怎么去处理，并总结自己的经验、告诉他我们的目标是什么，我希望达到的效果，做好了我的感受是什么，做坏了我的感受是什么，要及时批评和表扬，后期测试人员为主导的项目经理。
激励驱动力Motivation Driver。要激励别人，首先要激励自己，平时学会赞赏别人，有人喜欢做擅长的事情，有人喜欢挑战的东西，分析团队每个人的性格和适合的方法，了解每个人的需求，双因素理论－让大拿爽，并且让团队成员按照自己预期的方向走得更爽。