很多人总觉得做产品迭代就是接接需求、改改Bug、画画原型,觉得这活儿谁都能干。真动起手来,你会发现里面的坑比路还多。我带过不少项目,也踩过不少雷,今天就把我平时带团队搞迭代的那套大白话流程给大伙顺一遍,全是干货,没那些虚头巴脑的词儿。
第一步:把那些乱七八糟的需求全给拽出来
我刚开始带项目那会儿,最怕的就是老板拍脑袋,或者是业务方在那瞎指挥。后来我学聪明了,我直接弄了个共享文档,谁有想法谁往里填,不管是想加个按钮,还是想改个颜色。填完之后,我先拿眼扫一遍,把那些逻辑不通、纯属捣乱的直接划掉。剩下那些看着还行的,我就得去拉着数据部门的兄弟,看看后台数据。比如有人说登录太麻烦,我就得看登录流失率是不是真的高。咱们干这行,不能听风就是雨,得拿数说话,没数那就是耍流氓。
第二步:关起门来吵一架,定好主次
需求搜集完了,这时候千万别急着给程序员发任务,不然他们能把你骂死。我习惯每周二下午开个“过堂会”,把几个核心开发和测试喊到一起。我会把筛选出来的需求一个一个念,这时候大家的表情最精彩。开发会说这个实现不了,测试会说那个容易出Bug。这时候就得我这个当经理的出来镇场子了。我会用最简单的排序法:哪个做了能马上让公司赚到钱,或者让用户少骂两句,就先做哪个。至于那些锦上添花的玩意儿,统统往后排,甚至直接扔进垃圾桶。咱们精力和时间都有限,好钢得使在刀刃上。
第三步:原型设计别搞太花哨,能看懂就行
我以前见过有的经理,原型图画得跟艺术品似的,阴影、配色整得一套一套的。结果?开发一看图,光去抠界面了,逻辑一塌糊涂。我现在带团队,原型就一个要求:路径要全,逻辑要死。你点这个按钮跳哪儿,报错了怎么显示,没网了怎么办,这些都要标得清清楚楚。我宁愿画个黑白灰的线框图,也得把业务流程跑通。画完之后,我还会拉着那个最爱抬杠的开发,让他对着图跑一遍流程。他要是挑不出理儿了,这需求才算真的定下来了。
第四步:盯死进度,别让项目由于小事烂尾
正式进入开发阶段,我每天早上都会搞个十分钟的站会,不让坐,就在工位旁边站着说。我就听三件事:昨天干了啥、今天干啥、有没有卡壳的地方。最怕的就是某个小问题卡住了,开发在那钻牛角尖,憋了两天不吱声。这时候我得赶紧介入,找资源帮他解决。而且我最忌讳中间加塞儿,哪怕是老板过来说要改个小地方,我也得硬着头皮顶回去。你今天改个小地方,明天延后一天,这版本就彻底没准心了。
第五步:上线前后的“生死时速”
上线前那天晚上,我铁定是睡不着的。虽然测试已经跑了八遍,但真到了灰度发布或者全量上线,还是得提着心。上线后第一件事,不是去喝酒庆祝,而是盯着后台的实时数据监控和客服群。用户骂得最凶的地方,那就是我们下个版本要改的第一条。我会把这回迭代遇到的所有槽点和掉进去的坑,随手记在手机备忘录里。这就跟咱们过日子一样,吃一堑长一智,下次迭代就能少走点弯路。
说白了,产品迭代没啥高深莫测的东西,就是一股子细致活儿加上一颗大心脏。你得能抗得住上面的压力,也能理解下面兄弟们的难处。折腾这么多年,我发现最好的产品从来不是设计出来的,是这么一圈一圈磨出来的。别怕出问题,出了问题能赶紧兜回来,这才是本事。

还没有评论,来说两句吧...