ThoughtWorks爱用持续这两个字，Martin Fowler写了持续集成，Paul做出了持续集成服务器CruiseControl, Jez Humble是勇夺今年Jolt大奖，凭的是一本叫做持续交付的书。

为什么？

如果集成、交付如此重要，怎么敢自大到产品上线前才做一次呢？ 常常做、尽早失败，不断从失败中学习，改进才能保证最终上线的质量。

反观我们的反馈系统，一年做一次，截止日前大家才急急忙忙的收集、提交反馈，萝卜快了不洗泥，这些反馈的质量可想而知。

我的Sponsor大人把反馈总结为三个模式：

• 英文需要提升（放之四海而皆准）
• 技术需要提升（放之四海而皆准）
• 分享需要作的更多（放之四海而皆准）

这样无用又抽象的反馈我也提过不少。我有一个很糟糕的借口，我很健忘，隔的太久，确实是想不起来，这些不疼不痒的反馈提出来反正不会跑偏，又能完成任务，也就提交了。

在我年过30时，才发现反馈对自己成长有多么重要，而一年发布一次的“反馈系统”又不可避免的会产生上面的问题，频繁的去作反馈，频繁的改进调整才是我们的目标。

对个人来说提的频繁的最大好处在于及时，从而更具体，记得清楚写起来就简单省力，这是我前几天提给一位同事的反馈：

……在的邮件结尾你可以向同事表示感谢，我以前也没有这种习惯，后来我发现诚挚的表达感谢能让别人愿意帮助你，愿意和你共事的一个的好习惯……

这样简单具体的反馈更能指导我们改进，让我们从一个个具体变化开始，变成更负责，更完善的个体。

我还作了一个有趣的工具能把收到的反馈绘在时间轴上，帮我们记住自己成长的经历。

一起来持续的提及时、简单、具体的反馈吧

前两天路过索勤他们组，无意听到他长嘘一口气，感叹到构建终于过了，问及原因:

测试太脆弱了，一超时测试就会失败

为什么会超时？

邮件的服务器不稳定

什么测试需要测试邮件？

接下来他在屏幕上演示给我看一个向朋友推荐图片的功能，点击分享后，屏幕背景被遮罩，中间出现了旋转的箭头，暗示用户这是一个需要等待的操作，少许，大概是邮件发送完毕了，一切恢复正常。

考虑到邮件服务器的响应通常是不可预测的，看起来这真的是一个测试的问题了。

但是等等

发送邮件需要是同步的么？

同步模式常常是程序员线性思维的产物。点击、等待、下一步，多么自然。然而，我们生活在一个异步的世界里，我们把衣服扔进洗衣机，跑去打游戏，等到它滴滴作响才爬起来晾衣服。异步才是这个世界的常态，异步的邮件发送是这个正常世界里的再正常不过的一个操作，把异步操作同步化才是罪魁祸首。系统真的把邮件发出去了和系统接受了这封邮件对于用户有区别么？ 其实没有。

想象我们在邮局寄信，我信交给了邮递员阿姨或者投投到了邮筒里，我们就心满意足的离开了，可是这封信还没有发出去呢，对么？我们可能忘记贴邮票，或者超重信会被（当场或者稍后）退回，我们心满意足的离开是因为在心理上，我们相信把邮件交给了一个值得信赖的机构，它会负责任的处理我们的请求。

那么邮局（这个异步系统）为什么值得信赖？

这是因为它有一整套严谨的追踪和异常处理机制，我们可以随时知道信寄到什么城市了，信不能发送时会被退回到发信地址，根据我们留的信息可能还有电话通知。

当我们从异步的角度去设计一个系统时，常常不得不更多的去思考它的健壮性，这其实是一间正确的事情。你可能觉得同步系统貌似更简单，毕竟计算机系统是一个去物理限制的系统，那么考虑以下几件事儿：

• 当后台邮件服务器响应缓慢时，前台操作会被阻塞，用户的体验如何？
• 当用户不耐烦的刷新了页面，或者跳转到其它的页面去了，你如何通知它邮件的成功/非成功发送？
• 当后台服务器暂时出现问题，同步发送的邮件会以异常通知客户，事实上，因为客户根本不期待立即发送，异步系统给了我们一个缓存，并且再尝试一次的机会。

同步系统是一个过于乐观的假设，任何一条假设的破坏都会影响整个系统的正常运行。

这不是一个测试问题，这是一个设计问题！

这是Kent Beck曾经说过的一句话，他说，

• 当你发现配置问题，后退一步，仔细想想，这可能是个设计问题。
• 当你发现交流问题，后退一步，仔细想想，这可能是个设计问题。
• 当你发现测试问题，后退一步，仔细想想，这可能是个设计问题。

后退的这一步，便是我们冷静下来透过问题寻找本质的时间，而不是浅尝辄止，应激式的解决问题。

受够你的唠叨了，酱油男

事情的起因是去年与郑大，米高对一位应聘者去留的争吵，我们各执一词，最后不得不由郭晓出来平息问题，作为一名称职的酱油男，晓向来不屑于用拍板来解决问题，他当时说：“我们必须意识到无论招聘的流程多么严格和客观，错招和错过的人可能一样多…..”。

我们几个把这么一句废话琢磨了几遍，貌似有点道理，我们能不能找到心水的ThoughtWorker，不能单单依赖于面试，后面的观察、培养更加关键，就这么得Interview++就诞生了。

顾名思义，我们把新人加入ThoughtWorks最初的一个阶段当作Interview的延伸，不断的通过TA在团队中的表现来验证TA是否是我们欣赏的ThoughtWorker.

这么一执行的结果是我和郑大在之后的几个月不得不去结束掉3个人的试用期，在写下这段文字时以及选用图片时，我还是避免了使用“解雇”这两个字，我是一名咨询师而不是人力专家，半年后这两个字对我依然沉重，即便我是一个执行者！可想而知，当时我这样的人力菜鸟带着新员工走进会议室，关上门，转弯抹角说出那两个字的内心感受。

为了不再去面对“解雇”带来的罪恶感，在之后，我们尽了最大的努力去帮助新人成长，为了在最糟的情况下可以理直气壮的说出这两个字。

Interview++的执行半年有余了，5位同事离开了我们，这半年里，我发现严格执行的Interview++带来的收益不仅仅在于尽量保证了团队的质量，还在于它很好的教育了现有的ThoughtWorker成为更加负责任的员工。

我们会在每月一次的PM, Buddy会议上讨论新人的进步和不足，更重要的是，我们会问Buddy做了什么帮助他进步？不断的督促老员工确实的负起责任来，如果很不幸TA最终没有达到我们对ThoughtWorker的期望，PM或者Buddy就不得不亲自去说“解雇”这两个字。逐渐的Interview++成了Buddy制度的反馈机制，有了反馈机制Buddy制度才真的、负责任的运转起来。

这篇有点沉重的博客不打算写太长，我有两个收获：

• 体验不同的职责可以让你从不同的视角去审视当前的工作，把它作的更好
• 有反馈机制的系统才能运转