来来回回，断断续续的聊天让小刘不胜其烦，他根本没法专注到自己的工作上。
过了一个小时，问题还是没能解决，小刘不得不跑到小张电脑前，按F12打开控制台进行现场调试。
终于，小刘发现网络选项卡中有个401错误，但是前端没有把对应的错误消息显示给用户。
就这么一个简单，本来5分钟就应该应该被识别和解决的小错误，却让程序员浪费了一个下午的时间。
很多的时候，程序员花了很大精力也没法复现错误，只能在Bug系统中加一句：
不能复现
，把Bug打回去。
测试也很委屈啊：我这里明明看到了，每一步都有截图，你怎么就是复现不了，你是故意的吧？
问题的本质就在于，
开发没有办法获得测试人员进行测试时的“上下文”
，这个上下文中可能有数据库的数据，其他系统的状态，网络条件等等。
测试用例执行完，上下文就消失了，这就给定位Bug带来了很大的难度。
怎么解决这个问题呢？
2020年，工作了6年的Dani Grant（丹尼·格兰特）准备创业。
她和联合创始人Irtefa 做了很多次头脑风暴，在Notion上整整列了140个点子。
他们一厢情愿地觉得这些点子都有成为独角兽的潜力，准备大干一场。
但是他们并没有意识到，
这些看起来很酷的点子并没有解决真正实际的痛点问题
。
在创建公司的前夕，丹妮和Irtefa开了一次会，决定从这140个点子中挑选一个，开始创业。
开会前，丹妮偶然问起了Irtefa他所在的团队工作情况，Irtefa当时还在Cloudflare（一个CDN公司）工作。
Irtefa吐槽到产品团队和工程团队中间来来回回的沟通实在是太让人沮丧了，产品团队很难有效地报告一个问题，工程团队更是难以复现和解决问题，正像文章开头描述的那样。
两人突然意识到，这才是我们要构建的东西啊：
一个浏览器的扩展，
可以让任何人轻松地通过一次点击，就创建一个程序员友好的Bug报告
。
这个Bug报告有多友好呢？
它记录下了所有的操作步骤：
对操作过程进行了录像：
记录下了所有的HTTP请求和响应的数据：
当然也支持各种简单的标记：
他们把这个产品叫做
Jam
。
说起来容易，做起来很难，
让用户接受一个新产品是非常困难的
。
刚开始的时候，Jam只有几千用户，经历了7次失败的发布，直到Jam的第8版，才被用户所接受。
在官网上能看到丹妮的一些早期博客，可以看出他们在不断探索，也在不断挣扎。
产品在2023年有了爆发性的增长：
用户数增长10倍，达到了75000的里程碑。
全球的巨头如HP、Dell、Salesforce、联合利华、Autodesk 、迪斯尼等公司都开始使用Jam 来简化Bug报告的流程，Jam的用户群已经覆盖150多个国家。
2024年2月，Jam获得了890万美元的A轮融资，由GGV Capital 领投。
Jam的团队保持了最精简的状态，只有15个人，丹妮从之前工作中学到的经验是：当事情很重要时，会安排更少的人，而不是更多。
丹妮希望将来Jam能像Instagram那样，20个人支持100万用户。
看到Jam这个工具，恐怕有人会这样说：
不就是一个Chrome插件吗？我也能做。
我想说的是，当一个问题出现的时候，大多数人只是抱怨一下，也就忍了。
有少数人会想着怎么去解决它，比如可能会想到在对Bug截屏的时候，可以把上下文也“截下来”，形成一个快照，发给程序员。（没错，这就是我最早遇到这个问题时，立刻想到的办法。）
但是我再想具体怎么做的时候，发现很难，因为服务器端的上下文根本拿不到，没法弄，于是就把这个想法给放下了。
其实服务器端的信息拿不到，浏览器端的信息完全可以拿到啊，把这些信息形成快照，发给程序员，也能极大地帮助定位Bug啊，这就是Jam所做的事情，它把问题做了拆分，专注于解决一小部分问题，获得了成功。
