产品管理：敏捷发布与轻应用

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