产品与摩托车

昨天在路上看到骑摩托车的人,善于从生活中总结道理的我,又灵光一现。。。

车开动的时候,摩托是平衡的,稳稳当当,左闪右避,灵活地向着目的地行进。红灯了,骄傲的骑手要停下来,这时候,他一定要稍稍侧身,单脚点地,才能保持平衡。摩托车静止时需要支撑,可行进起来却是玉树临风。

我想到了做产品,做项目的时候,我最大的问题,我总是期望这个产品达到一个完美的状态:代码干净利落,业务逻辑清晰,文档和流程完善。想来我追求的是一个结果,一个静止状态。可产品本来就不是静止的,做产品就像是骑摩托,一开始就想让他稳稳的站住,那他永远平衡不了,永远不能向前。总要行进起来才行,才能找到感觉。也像学自行车时一样,行进起来也许跌跌撞撞,也许甚至需要两个辅助的轮子。产品就是这辆自行车,这辆摩托,马路公路是市场,旁边的车有竞争对手,也有毫不相干的人或事。要想到达目的地,要在乎的一定不是怎样让他稳稳站住,而是找好方向,流畅地开起来。实现功能,解决问题,应对挑战。为了有可能的需求预留接口,即使是举手之劳,也许并没有意义。因为这个需求真的来了的时候,也许不会再有人记得这个接口,或者接口已经不是标准的。外部环境变化之快,谁也无法预言,即使是不远的将来,甚至只是下一个sprint。代码的重用,封装也是一样,有能力做好的封装,提供以后做多态的可能,当然很好,但是你永远不知道谁会接手你的程序,别人是否能看懂你在里面花费的心思。这时候,比文档更重要的是测试,明确的告诉后面的人,后面的功能,我不在乎你怎么搞,但是不要搞坏我的功能。我想程序员之间的合约就是市场标准和单元测试。

有时候,车也会停下来,如果是遇到了红灯,遇到了障碍,那也正好是个机会好好看看地图,确认一下下面的方向。也有的时候,是车真的出了问题,也许是技术壁垒,前面要跨海趟河翻山越岭,车的性能达不到这个要求;也许是技术负债,需要去维修厂检修一下。技术遇到壁垒,解决方法便是要改装车或是干脆换一辆车了。这个产品走到这里,他一路上已经看过了许多风景,迎接了许多赞叹,也许也为一路上的人们送了很多货(客户价值)。也许下面的路不是他能走的;也许下面的路他提升下性能,加个气垫,安双翅膀,还能继续,但无论哪一种,都不必再纠结他之前走过的路了,因为之后他其实就是完全不同的产品了。

如果是需要检修呢,一定要谨记,检修的目标是让他继续奔驰,而不是让他平衡。代码上过去的功能完全读不懂,又没有测试,可如今他运行良好,之后也不太需要有改动,那何必费工夫担风险去折腾他。日常维护成本太大,出了问题要花很长时间找到原因,那就加log,加monitoring,方便以后找到问题,对症治疗,不要自以为是地重构了代码,反而带来了业务错误。数据结构无法扩展了,与其大刀阔斧,是不是可以用服务把原来的数据封装起来,在旁边做个新服务使用旧的这个,数据库也许不够漂亮,可是增加功能的空间又多了很多。这里,最重要的是有针对地完善,修理,而不是为了一个完美的静止状态做过多努力。如果决定修,那就加封装,提供新接口,连接新模块;如果要换,就不要偷懒,不要看过去。重新设计,按照最新的标准编,完整测试。

产品或是模块终有一天会结束他的使命,如果修理厂说他该报废,他的功能已经不符合市场和客户的需求,那就不必留情,重新来过;如果他现有的功能还很重要,也很好用,那就不要为了代码整洁,结构清晰而动他。

骑车或骑摩托,最危险的可能都是急转弯,不确定的时候,不行就下来推着走两步吧,转过去看看,到底还能不能骑上接着走,这样也许浪费些时间,但是至少不会摔了骑车的人,至少还能再一起前行。做产品中的急转弯,大概就是业务重定向和技术转型。这个时候不要加速改变整个产品构架,也许更好的方法是做一个快速简单基础的测试版,推上路,看看市场反馈,也看看新的技术模型能不能适用。急转弯时摔坏了车子不要紧,摔坏了骑车的人,可能就很难再找到最初的动力了。

简单的一些感触,在做下一个产品的时候,在实践之中继续感受,继续总结。

Leave a Reply