如何优雅地改需求 

admin  

我:对了,那个,有个地方可能要改一下...

工程师:你看着我的眼睛!


我:...

我:我有一个好消息和一个坏消息,你想先听哪个?

工程师:我不听我不听我不听


我:...

我:诶,跟你商量一下,有个地方换个方式话,以后你维护起来会不会更简单...

工程师:噢?站起来说。

上面是与我司工程师の日常,当然稍有夸张,不要在意这些细节。我们来说正题。

真实情况下,要是新入行的研发盆友,遇上刚毕业的小白PM,不会那么琴瑟和鸣,更多是一场场撕X大战。改需求,已经成为一个老梗,(PM)常常被大家吐槽,资深(被虐太多的)工程师对改需求早已见怪不怪。但哪怕是做了几年下来,脸皮已经厚可敌国的我,遇到需求要改,也常常是如履薄冰。

今天先不说怎么避免改需求,既然已经要改了,怎么才能优雅地改,尤其对产品经理同学来说,这个「姿势」很重要。

1.改设计

设计是最容易发生频繁改动的地方,尤其对于产品架构形态还不稳定的产品,不停的尝试最佳效果方案,或因各方「反馈」吐槽,顶不住压力,或因老板喜好、大手一挥,就改改改了,因为设计是「看起来」修改成本最低的地方。

千万不要学支付宝家一个版本一个大改,整个交互框架重构,每次都要重新找半天,都不能让我们愉快的花钱了!对成熟产品来说,框架重构,简直是莫大的挑战,往往还是一个「灾难」,君不见豆瓣一个改版,激起民愤千丈,最后还得妥协改回去。要优雅的改设计,建议尽量不要动框架,动作太大,姿势会难看。

在不影响核心需求满足路径的情况下,其他分支页面可以改,要与设计师、工程师充分沟通修改目的,让大家清晰知道,当前是处于试验期,所有方案都可算作「临时方案」,心理上做好随时可能调整的准备。这样,即使反复修改,至少小伙伴是已经有底的,在准备方案时自然会提前考虑一些扩展灵活性。最好在改版前,多出一两套设计方案,多论证几轮,筛选出明显不靠谱或改动成本巨大的方案,即使要改,心里也要有数,是冲着验证哪一个方面去的。


2.改逻辑

这其实是产品中的「大忌」,核心功能逻辑确定以后,除非业务方向调整,一般情况下是不作变动的。如果是在基础逻辑上,去补充、完善或调整,这种层面的修改,尽量多思考全面,不遗漏场景,不造成冲突影响。

常见的一种bad case,因为修改一处逻辑,引发两个点冲突,进而引入新的一条逻辑来解决冲突,这种补丁套补丁的方式,越往后,积弊难返,过一段时间则要重构大修。伤筋动骨,还背着包袱,改出来的东西可能龇牙咧嘴,说好的优雅呢?


变化是常态,尤其创业产品。但盲目的修改,没有客观确凿的验证充分情况下,就贸然推翻过去的需求话,可能错掉正确的方向不说,反复折腾消磨了团队人员激情,最后对「各种修改」一个麻木状态去应对,不再主动思考去帮助完善修改方案,这才是产品最大的损失。