《专题资料（2021-2022年）产品管理中的敏捷发布与轻应用.doc》由会员分享，可在线阅读，更多相关《专题资料（2021-2022年）产品管理中的敏捷发布与轻应用.doc（2页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、产品管理中的敏捷发布与轻应用对于流行的“敏捷发布”概念，我的感情很复杂。一方面我自己就是敏捷发布的忠实支持者，但又看到了对它大量的滥用，甚至我自己也有可能滥用。前些日子看见一个典型案例，一同行说，自己的新浪微博应用，从提出创意到发布只用了 6 天，6 天!这款应用叫“APP 汇”，思路上挺带感的 APP 社交推荐服务。从正面的意义讲，尽早拿出一个可用原型来接受市场检验，再根据真实数据与反馈来调整产品，远比隔靴搔痒的“用户建模、竞品分析”更加可靠。而负面的部分则是，敏捷发布的流行也助长了“一拍脑袋”“一拍大腿”，总结为“一拍系列”的荒谬立项盲目开发。从 2008 至今，我加入到互联网产品行业已经
2、有 3 年半了，根据我的观察经验，凡是一拍系列的项目，成功率不足 1%，死亡率平均是 50%，成功和死亡之间则是“好死不如赖活着”这么一个不上不下的状态。如此惨淡的结果，极大促进了流程管理的专业化，各种用研手段，各种竞品分析，各种数据挖掘竞相攀比，结果呢?成功率可能提升到了 5%，死亡率平均降低到了 35%在管理层看来不过是五十步笑百步。很早很早之前，网易游戏一位不知姓名的高人有句名言：无论是无论是 5 个人的项目个人的项目，还是还是 500 个人个人的项目，失败原因多半都出自的项目，失败原因多半都出自“没抓住用户需求没抓住用户需求”。这句话的真意是，再怎么专业的流程管理，对成功率的提升都是极
3、有限的。否则那些牛逼哄哄的国际大公司，他们通常有着最精密，最谨慎的项目管理规范，岂不是常胜不败?屁嘞还不是一堆烂尾楼。任何产品的成功都有三个必备要素：1、产品处于上升期的市场(天时)2、管理体制与资源支持能促进产品发展，而不是拖累它(地利)3、产品领导者具备这款产品必备的基因(人和)三者俱备，谈何容易。流程管理最多只能验证出“天时”，对于“地利”与“人和”均束手无策，对成功率的提升自然有限。但如果连流程管理都不做，恐怕更是一拍系列群魔乱舞。就算拍得不算太离谱，也有两个后患：首先是初期版本没抓准核心需求，一出膛就砸了口碑，Web 产品的用户不愿意再尝试，APP 用户卸载或不再升级。其次是初期规划
4、的弹性太小，对后期拓展造成很大限制。当然，初期画个大饼则死得更快所以到底是敏捷呢，还是保守呢，见仁见智，根本没个确定的说法。说白了，这得看人。靠谱的人会根据项目背景，选择轻盈或是稳重的流程管理，而不是抓住一根教条死不松手。但这个定律在轻应用时代又有转折，变成一面倒的“敏捷发布为王”。原因很简单轻应用的开发时间平均也就 6-8 周，如果前期准备都要做 3-4 周，饭菜都凉了。当开发成本低到一定程度，敏捷发布反而是更好的风险控制手段。因为流程管理的保障效果仅仅是“聊胜于无”，却要耗费大量的时间，开发成本又完全亏得起，不如信赖产品领导者的经验与直觉。这时，对 PM 的信赖感就是实行敏捷发布的关键。此
5、外还有三个必要环节，对结果亦有决定性影响。第一，轻应用比传统产品更适合敏捷发布，其原因不完全是开发成本低。轻应用本身的定位就是“满足特定用户的特定需求”，对目标用户群的划分粒度比传统产品更细，用户更加典型化而非多元化，降低了用研的难度。第二，必须有一半以上组员是这款产品的忠实用户(尤其是 PM 本人)，这比什么用户模型都他妈的管用。只有强烈的感同身受，才能真正理解用户，理解应用情景，与用户有更多的共鸣与话题。虽然也可能以己推人过甚，但总比隔岸观火有效太多。第三，管理上必须精简岗位，追求一人多能而不是精细分工(降低沟通成本);必须以小项目组的方式组织人力，一脚踢飞该死的提单排期(提高产品归属)。
6、组内成员最好经过了半年以上的磨合，协作默契，彼此友爱。综合以上三点，很容易发现敏捷发布其实与大公司全无缘分。因为大公司压根就瞧不起“小打小闹的轻应用”，立项都难;再说人员调度非常不灵活，第二点完全没保障;第三点更加是镜花水月。如果遇上授权不充分的部门，层层汇报层层审批，谈什么敏捷发布，根本是阉人的春梦。可是越戴着八十斤的镣铐走路，越容易幻想和鼓吹敏捷发布的美好，却忘了“人靠谱”即王道是啊，谁又愿意承认自己不靠谱呢?所以再看到满天下的大喇叭放着“敏捷再敏捷”的口号，我就很尴尬。道理诚然不错，举着这杆大旗胡作非为的人亦如过江之鲫。我每次一谈敏捷，立刻有不少人大声叫好，有时我好奇去看他们做的产品，额
7、头汗珠顿时有如泉涌。罢了，就算我不谈敏捷，难道他们就不会歪歪扭扭地飞跑起来吗?谁没有傻逼的过去，谁不是在三番五次撞墙之后，或许有一天破墙而出。只要能承担失败的代价，你就去撞吧，而我自己又何尝不是如此。唯一的问题是，如果你选择了敏捷发布(轻应用)这条路，那就最好不要在公司的项目上去尝试，不要拿着老板的钱去冒自己的险。另外，绝大多数公司体制也压根不支持敏捷发布，反而受其拖累。不如找一些志同道合的同伴，组一个小队，用业余时间自由自在地做点带感的项目吧对某个构思真有爱的话就要舍得付出。鄙视那些成天喊着“为什么不敏捷”“为什么不创新”，然后 8 小时一到准点下班的人，让公司为自己的鲁莽和无知买单，却不愿意为了公司(和自己声称“很投入”的项目)多干两三小时活儿。