下面的文章编译自 Intercom Blog 中的 《There are no small changes》，其实已是前年的博文了，恰巧国庆期间又读到，想想自己也常借着“只是个小改动”的破理由在团队面前瞎指挥，坑坏了小伙伴，所以必须翻译出来，告诫自己要自持。
我们想把评论内容限制在 140 个字符内，因为我们有可能通过手机短信把评论内容发出去。这只是个小改动，对吧？
错。
做产品，永远没有「只是个小改动过」一说。
拿上面的情况来说。
一个天真的程序员可能三两下就把代码写好了，毕竟者只是一个 if 语句。但对产品经理而言就没那么容易了。接下这个「小改动」之前，你得问几个问题。比如，如果超过 140 个字符怎么办？要停止文字输入，还是提示信息错误？如果是提示错误，该在哪儿提示？提示信息该说什么？谁来写这些提示信息？我们要怎样给用户解释说只能输入 140 个字符？错误标示如何体现？有没有视觉样式？如果没有，谁来设计？
也许刚才那些问题都能一一解决，但仅仅解决服务器端问题是不够的，我们还要着手解决客户端，比如，谁来写 JavaScript ？JavaScript 是不是要按服务器端那种样式来展示错误？如果不是，新样式是怎样的？如果不需要 JavaScript ，产品要怎样运行？如何确保以后的更新都能让服务器端和客户端生效？
等等，还没完，我们还要站在用户的角度去看。
对于「只能输入 140 个字符」这个莫名其妙的理由，用户已经觉得不可理喻了，现在我们还要让他们一边输入评论内容一边数数自己输入了多少字符？这体验得多糟糕！对，我们得加一个计数器。
噢，这又带来了一些问题……
谁来写这个计数程序？如果我们从网上下一个程序，谁来做测试？还有，计数器的数字该在哪里显示？视觉效果如何？当用户已经输满 140 个字符了，数字应该有哪些变化？还是，我们要停止内容输入？如果这样的话，用户粘贴一些信息进来怎么办？我们应该让用户继续编辑还是设置提醒？
即便我们搞定了计数器、错误提示样式、服务器端、客户端，那也只是冰山一角。做产品的时间本来就很紧张，现在突然要增加这么多问题，那还得了……不仅如此，用户会奇怪为什么之前有些人能写上 80 个单词的评论，而自己却只能写 140 个字符？很明显，我们还需要继续完善：更新文档、API、iPhone 、Android APP 等等。对了，以前（超过 140 字符）的评论怎么处理？要直接砍掉过多的内容还是保持原样？如果输入内容时还要增加表情符号，那……
你看，这仅仅是一个 If 语句。如果更复杂的程序呢？
结论：当你在用对的方法做产品时，绝不会有「小改动」出现。一个产品经理在答应添加/修改一个功能之前，必须明白需要付出什么代价。你一个轻易点头，就可能坑了团队的许多时间。通常，当你没有做好全盘计划时，一个只要两分钟的事情就可能花费两个小时。
好产品不是大陨石一下子从天而降，而是建房子，需要一砖一瓦仔细铺盖。应承一个功能轻松至极，代码实现出来却未必容易，而要做好维护那简直就是噩梦。要做一个好产品，就不许轻易答应，因为，永远没有「小改动」。
网友评论