我是2018年年底加入ThoughtWorks，招聘的原因在事后看来也很有意思，某大公司的某部门年底预算用不完，需要找点事做，所以就起了一个项目，TW就为这个项目招了一批人。
这个项目是一个大杂烩项目，把所有能揉在一起的应用都揉在一起。第一次去客户现场是和另一个后端同事，当时是去商量两个模块，A和B，出发之前商量是两个人一起做两个模块。去了之后，就是和第三方的vendor讨论接口，实际上就是甩活，看你如何把一些脏活累活扔给对方，这点恰恰是我的强项，但是我是个新人，所以第一轮商讨的时候，主力是另外一位同事，一轮谈下来，我就和同事商量：“要不这个B你做吧，我做A就好了……”，不得不说，和第三方打交道不强硬就等于吃亏。
于是我就开始了A开发，我在SMZDM没有参与业务开发长达两年，在TW的第一个项目，依然是没有开发任务，天天嘴炮，说服前端接受API，说服上游vendor修改接口。在这个过程中，被灌输了BFF和Contract Testing这两个概念。
契约测试，这个是一个美好的理念，蹩脚的实现，残酷的现实。
BFF，一次性代码，帮前端包鸡包眼的代名词。
到了项目后期，IM的同事下项目，我接手，和第三方对接，这个时候，历练和成长才由此开始。
与第三方无止境的扯皮。
-
讨论的时候：这个接口调一下就行了！
-
第二天实施：你们先调用A，再调用B，然后把xxx弄一下，不就行了吗？
-
讨论的时候：好的，没问题，那我们就这么改。
-
第二天实施：我们没答应，我的原意是回去研究下，我们研究结果是不可行……
与此我也总结出了许多“经验”：
- 不在客户面前说没把握的事
- 只说事情的表现，不帮第三方去猜原因
- 保留证据，并引导第三方犯上面的错
- 不要一次性要求第三方解决N个问题，选择一个，咬住不松口
- 多发问，少解释。除非是客户问你bug的原因，你能甩给第三方，但也要注意前面说的，不要去猜测第三方的原因。
项目后期就非常无趣了，没写代码没实际产出物被diss，小组效率被质疑，BA夹在小组和PM之间为难……
2019年5月，我下了这个项目。
小插曲
在on beach了一个多月之后，某天被RM拉过去“北京的TP点名要你上O项目，和他一起balabala”，同时也从Buddy口中听到了类似的声音。当时的我受宠若惊，TP，什么概念。上了O项目，才发现，原来不是这样，O项目想上契约测试，TP便问了之前项目的一个TL，得知我做过契约测试，并且处于on beach状态，就让我过去了。这个事情不知道怎么就变成TP点名要我了。扯淡的很。
反正上了O项目一周，我就主动要求下项目了，原因很简单
- 不喜欢写测试
- 尤其不喜欢契约测试
- 更加不喜欢帮别人写测试
- 更加更加不喜欢帮别人写契约测试
和PM说了之后，最开始是想在该Account下其他项目做，但是应该是我这种“刺头”没人愿意要，我便再次回到了on beach的状态。