很多互联网公司中经常看到这样一种景象：产品经理、技术、运营、设计围在一张桌子前，闹哄哄地进行关于产品迭代的头脑风暴讨论会。一脑暴就是一整天，重点偶尔跑偏，沟通不时急赤白脸，最终决策者拍板决定一个方案，大家分头去执行，over。
这样的方法效率高吗？是我们能达到的最优结果吗？在这个决策的制定过程中，每一个人都尽了全力吗？
脑暴暴不好的下场
读过《乌合之众》的人知道，人一进入群体中，会表现得无异议、情绪化和低智商，可是做出一个决策往往需要不同领域的人共同探讨。如果有一种流程，既能保留个人的聪明才智，又能发动群体的力量；既能缩短会议的时间，又能做出正确的决策，那就了不起了。
谷歌作为一个了不起的公司，创造出了这个了不起的流程，它几乎被用于谷歌的任何项目，从搜索引擎、电子邮箱，再到无人驾驶汽车。传入谷歌风投之后，又帮助了100余家初创公司成功起步，它们中的许多如今已是人尽皆知的业界标杆。
用这个流程做产品迭代只需要5天，它的名字就叫做《设计冲刺》
书名：设计冲刺
作者: [美] 杰克·纳普 / [美] 约翰·泽拉茨基 / [美] 布拉登·科维茨
译者: 魏瑞莉 / 涂岩珺
出版社: 浙江大学出版社
出版年: 2016-8
其实五天完成产品迭代介绍起来十分简单：
周一 拆包，把一切已知摆上桌面
周二 写写画画，每个人都贡献点子
周三 决策日
周四 完成原型产品
周五 交卷，检测
当然，这本书不会像“要把大象装冰箱，拢共分几步”这样草草带过，而是每一步都详尽地介绍了具体操作过程，以及容易被忽略的细节，还有许多颠覆我们惯常操作流程的地方，比如：
▼为什么需要五天
更短的时间将使得团队成员筋疲力竭，没有时间制作原型、进行测试。更长的时间会出现干扰和拖延，并让团队成员更坚持自己的意见。五天时间带来的紧迫感让人更容易集中注意力、打断不必要的争论，同时又有时间制作原型、进行测试。
▼为什么不进行脑暴
接下来我审查了我组织过的每一场头脑风暴的成果，然后我注意到了一个问题。真正付诸实践并且获得成功的想法并不是来自大喊大叫的头脑风暴，那些更棒的点子来自于个体依然用过去习惯的方式思考创意时——坐在办公桌前时，在咖啡店等咖啡时，洗澡时。这些有嗯们独自想出的点子更胜一筹。当讨论会的狂热劲头散去，头脑风暴产生的点子其实并没有那么特别。
▼为什么不解释方案
解释方案有各种弊端。如果一个人为自己的方案提出了强有力的理由，或是他天生就富有个人魅力，他就很容易左右你的评价。
提出方案的人很容易为自己平淡无奇的想法找到华丽的说辞，或者是给说不通的方案做牵强附会的解释。但在现实生活中，这些人无法到现场自卖自夸，他们的方案必须要自己站得住脚。如果团队里的专家都不能理解这个方案，那么用户为之困惑的几率就更大。
设计冲刺这个流程，算是精益创业在产品验证方法论上的一个可操作的具体形式。读完这本书你会发现，从优化产品到制定营销策略，从为公司命名到评估新商机的可行性，这些棘手难题解决起来，只要5天，这在瞬息万变的互联网界，足够让你占尽先机了。
发表回复 取消回复