1704257919
1704257920
从零开始调教出一个六大角色齐全、稳定高产的百人产品团队，我的经验是需要两到三个季度的磨合，需要1/3的人员调整的代价，需要充分利用国情试用期的30天。
1704257921
1704257922
1704257923
1704257924
1704257925
图 17-3 PM、Test和Dev三权分立
1704257926
1704257927
1704257928
1704257929
1704257930
图 17-4 资源重用并发矩阵
1704257931
1704257932
当然，世上没有十全十美的流程，关键是适合！软件工程大家Ivar Jacobson道，“我相信没有一种技术、没有一种流程能够解决所有的问题，我更相信基于实践的方式。你需要用不同来源的实践，结合自己的特点，改进自己的流程和工作方式，这样才能立于不败之地。”即兼容并包、实践为本，在无流程与过于结构化的严格流程间，找到与企业匹配的均衡点。
1704257933
1704257934
1704257935
1704257936
1704257937
半面创新：实践者的创新制胜之道 [:1704253513]
1704257938
半面创新：实践者的创新制胜之道 第18章 运营体系：一个中心，两个基本点
1704257939
1704257940
创新产品实施完成后，进入上线推广与运营阶段。营销推广参见第11章“6纵后端流程”，本章仅涉运营。我将运营分解分为一个中心“用户至上”，两个基本点“持改完善”与“数据驱动”。
1704257941
1704257942
半面创新：实践者的创新制胜之道 [:1704253514]
1704257943
一个中心：用户至上
1704257944
1704257945
运营的本质就是通过产品与用户对话，是试错、反馈、持改、完善、永远的beta，是不断加强目标用户认知的长期过程。
1704257946
1704257947
以互联网产品为例，其实践大致分为两步，第一步是产品由自己来做，快速开发、满足基本需求即可上线；第二步产品由用户来做，运营担纲责任。它从与用户的互动开始，引导用户参与，根据各种效果、质量与用户反馈来修正功能、调试错误、快速迭代，只求进步不求完美，下一版本给大一些的客户群使用，反复几次再推向所有用户，如图18-1所示。两步的关系，产品是为运营提供服务的基础设施。
1704257948
1704257949
仍以公交服务8684为例，创始人夏天天告诉我，其客服由产品人员担任，收集来自QQ、微博、后台、论坛的声音，每天处理超过150条反馈，积累至少6000条意见，解决超过50%的合理建议。他强调，所有的错都是我们的错，快速解决后把改进的功劳归功于用户，用户收到这样的正反馈，才会愿意继续反馈问题，而且遇到产品的公关危机时，那些你回复过、采纳过他们意见的用户就会自发出来帮你澄清问题。如表18-1所示，我截取一段用户反馈。
1704257950
1704257951
1704257952
1704257953
1704257954
图 18-1 产品交付图
1704257955
1704257956
1704257957
1704257958
1704257959
1704257960
1704257961
1704257962
美国同样。亚马逊创始人贝索斯的信条是“Customers Rule！（用户制定规则）”，为此他建立了“working from customers backwards（从用户需求倒推式）”而非一般企业的“skills forwards（技能前驱式）”理念。如在设计层面，当年贝索斯顶住华尔街和公司内部压力开发第三方卖场时表态，碰到这种与现有利益左右互搏的事，决策依据就是看是否为用户创造了价值，如今公司销售额的1/3来自此项服务；又如执行层面，其技术团队围绕向用户提供的各种服务划分，根据需求和数据做创新，而非为技术而技术。贝索斯最后总结道，当用户觉得需要你的服务时，就为时已晚，即最好的用户体验无需客服。
1704257963
1704257964
当然过犹未及，用户至上的悖论是面临破坏性创新之时，详见第15章。
1704257965
1704257966
1704257967
1704257968