“草稿箱”功能很常见吧，编辑内容后，不想发布的话，就先存为草稿。啥时候想公开了，发布即可。
今天发生个啥事呢，让作为Tester的我，哭笑不得。
开发部经理老F，反馈一个客户需求，发到群里让大家讨论。是这样的“咱有没有一个功能，比如我编辑一篇文章，想要编辑5个字，只写了3个，然后去忙其他的，点击一个按钮，但是我点击那个按钮，不能影响我前台页面。等到忙完了，接着编辑剩下的2个字，编辑完成才能发布，页面才会改变。”
老F先起头：“用咱原有的功能，暂存呗”
开发组长小李：“（心里暗暗想着，傻X）暂存，前台就不显示了啊”
实施小静：“如果正在修改还没好呢，前台显示的应该是没有修改前的页面。 ”
老F：“我们做不到。真是奇葩的需求！”
开发组长小李：“我咋感觉很合理呢？”
老F：“怎么实现呢？”
开发组长小李：“实现和需求是两回事吧，需求很合理，实现方式大家讨论”
老F：“...(若有所思了几分钟)”
众人开始讨论编辑文章的时候，需要几个按钮，暂存？发布？
讨论页面上的提示，如何使客户清楚这篇文章的状态，不眩晕。
我测试这个产品时间很短，有些怂，不敢理直气壮地说出想法。于是私聊开发组长小李:“这个需求，不就是草稿箱么，有啥讨论的。”
我像是说出了他的心里话，他表示墙裂同意之后，立即在群里说，“相当于草稿箱的功能”。
小李没有说得更详细，于是，我补充到“像草稿箱那样，只要编辑就自动存为草稿，想发布了就发，不发就在草稿箱一直放着。”
然后去知乎专门回答了一个问题，来验证草稿箱功能。
图1
图2
“知乎是，只要编辑就会存为草稿，并且前台显示的是原来的内容，因为你并没提交草稿。修改的内容就放在草稿箱里，如果提交，前台就显示修改后的内容。”
老F不假思索地说道：“我们可以按照知乎的模式做。”
开发组长小李在我们的小群里逼逼了句：“这就做了？没看需求还奇葩不”
我们差点笑出猪叫。
事件就描述到这里。
我是个不抽烟的女娃，不能像男同事一样，烦闷了就去楼道叼根烟，所以只能在卫生间多蹲会儿坑（公司的女厕所常年人爆满的未解之谜就此打开）。我得自闭一会儿，因为实在不能理解为啥会想不到草稿箱。
蹲着坑，闻着千奇百怪的味道。环境练就人，环境练就人思考问题的速度，我没蹲几分钟就回工位了（女的要不都抽支烟吧，好歹能散散味儿）
思考之后，敲黑板如下：
1.要根据自己的岗位职责，刻意培养知识迁徙的习惯与能力。我是软件测试， 也是社交软件重度患者。写文章、回答问题，草稿箱这种基本功能已经被我用烂了，也可以说是从用户体验的角度，测试得太到位了。所以从产品线新需求 到知乎草稿箱功能，我意识不到自己已经做了知识迁徙，只觉得理所当然这样关联过去。所以正是我的熟悉与知识迁移，才会从测试的角度，立即反应出最符合用户习惯的草稿箱功能。
2.不要闭门造车，以久经市场考验的产品为榜样，站在巨人的肩膀上其实就是走捷径。做产品的，做软件开发的，软件测试的，是不是要反思一下，多关注市面上同一类别的产品，就算不是同一类，某个功能模块也是极其相似。就草稿箱来说，数不清多少个app或门户网站的逻辑都是一样的。经过市场的严峻考验，这些成熟的产品都符合用户习惯，直接借鉴就可以了。玩创意，不是说故意违背用户习惯。所以不要闭门造车了，多关注竞品，多学习，碰到这种需求就不会觉得奇葩了。