加入到互联网产品行业已经有3年半了，根据我的观察经验，凡是一拍系列的项目，成功率不足1%，死亡率平均是50%，成功和死亡之间则是“好死不如赖活着”这么一个不上不下的状态。如此惨淡的结果，极大促进了流程管理的专业化，各种用研手段，各种竞品分析，各种数据挖掘竞相攀比，结果呢？成功率可能提升到了5%，死亡率平均降低到了35%……在管理层看来不过是五十步笑百步。

很早很早之前，网易游戏一位不知姓名的高人有句产品画册设计名言：无论是5个人的项目，还是500个人的项目，失败原因多半都出自“没抓住用户需求”。这句话的真意是，再怎么专业的流程管理，对成功率的提升都是极有限的。否则那些牛逼哄哄的国际大公司，他们通常有着最精密，最谨慎的项目管理规范，岂不是常胜不败？屁嘞——还不是一堆烂尾楼。

任何产品的成功都有三个必备要素：
1、产品处于上升期的市场（天时）
2、管理体制与资源支持能促进产品发展，而不是拖累它（地利）
3、产品领导者具备这款产品必备的基因（人和）

三者俱备，谈何容易。流程管理最多只能验证出“天时”，对于“地利”与“人和”均束手无策，对成功率的提升自然有限。但如果连流程管理都不做，恐怕更是一拍系列群魔乱舞。就算拍得不算太离谱，也有两个后患：首先是初期版本没抓准核心需求，一出膛就砸了口碑，Web产品的用户不愿意再尝试，APP用户卸载或不再升级。其次是初期规划的弹性太小，对后期拓展造成很大限制。当然，初期画个大饼则死得更快……

所以到底是敏捷呢，还是保守呢，见仁见智，根本没个确定的说法。说白了，这得看人。靠谱的人会根据项目背景，选择轻盈或是稳重的流程管理，而不是抓住一根教条死不松手。但这个定律在轻应用时代又有转折，变成一面倒的“敏捷发布为王”。原因很简单——轻应用的开发时间平均也就6-8周，如果前期准备都要做3-4周，饭菜都凉了。当开发成本低到一定程度，敏捷发布反而是更好的风险控制手段。因为流程管理的保障效果仅仅是“聊胜于无”，却要耗费大量的时间，开发成本又完全亏得起，不如信赖产品领导者的经验与直觉。

这时，对PM的信赖感就是实行敏捷发布的关键。此外还有三个必要环节，对结果亦有决定性影响。

第一，轻应用比传统产品更适合敏捷发布，其原因不完全是开发成本低。轻应用本身的定位就是“满足特定用户的特定需求”，对目标用户群的划分粒度比传统产品更细，用户更加典型化而非多元化，降低了用研的难度。

第二，必须有一半以上组员是这款产品的忠实用户（尤其是PM本人），这比什么用户模型都他妈的管用。只有强烈的感同身受，才能真正理解用户，理解应用情景，与用产品画册设计户有更多的共鸣与话题。虽然也可能以己推人过甚，但总比隔岸观火有效太多。

第三，管理上必须精简岗位，追求一人多能而不是精细分工（降低沟通成本）；必须以小项目组的方式组织人力，一脚踢飞该死的提单排期（提高产品归属）。组内成员最好经过了半年以上的磨合，协作默契，彼此友爱。

综合以上三点，很容易发现敏捷发布其实与大公司全无缘分。因为大公司压根就瞧不起“小打小闹的轻应用”，立项都难；再说人员调度非常不灵活，第二点完全没保障；第三点更加是镜花水月。如果遇上授权不充分的部门，层层汇报层层审批，谈什么敏捷发布，根本是阉人的春梦。可是越戴着八十斤的镣铐走路，越容易幻想和鼓吹敏捷发布的美好，却忘了“人靠谱”即王道——是啊，谁又愿意承认自己不靠谱呢？

所以再看到满天下的大喇叭放着“敏捷再敏捷”的口号，我就很尴尬。道理诚然不错，举着这杆大旗胡作非为的人亦如过江之鲫。我每次一谈敏捷，立刻有不少人大声叫好，有时我好奇去看他们做的产品，额头汗珠顿时有如泉涌。罢了，就算我不谈敏捷，难道他们就不会歪歪扭扭地飞跑起来吗？谁没有傻逼的过去，谁不是在三番五次撞墙之后，或许有一天破墙而出。只要能承担失败的代价，你就去撞吧，而我自己又何尝不是如此。

唯一的问题是，如果你选择了敏捷发布（轻应用）这条路，那就最好不要在公司的项目上去尝试，不要拿着老板的钱去冒自己的险。另外，绝大多数公司体制也压根不支持敏捷发布，反而受其拖累。不如找一些志同道合的同伴，组一个小队，用业余时间自由自在地做点带感的项目吧——对某个构思真有爱的话就要舍得付出。鄙视那些成天喊着“为什么不敏捷”“为什么不创新”，然后8小时一到准点下班的人，让公司为自己的鲁莽和无知买单，却不愿意为了公司（和自己声称“很投入”的项目）多干两三小时活儿。