拿到阿里巴巴的 Offer，即将离开 ThoughtWorks。在刚入职 TW 的时候就有同事告诉我“入职第一天就想着离职的员工才是好员工”，我的 Sponsor 也随时在提醒我做决定的时候想想“当你离职的时候你能在你的简历上写些什么”。正是这种关注个人成长的文化激励着我即使在无聊的项目上也没有放弃学习，为随时可能到来的变化做好充分的准备。

在 ThoughtWorks 的经历

ThoughtWorks 有大牛吗？

有肯定是有的。但刚进公司时，这是曾是我最大的困惑，入职 ThoughtWorks 之前在网上看过不少 ThoughtWorker 的博客，觉得这里应该有很多技术很牛的人。那个时候我对牛人的定义就是写代码很厉害，手也快脑子也快，别人眼里的技术难题他看一眼就能解决。现在加入 ThoughtWorks 两年半，我很少会因为代码觉得某位同事很厉害，反而是在开会的时候，或者看别人 PPT 的时候觉被某个人体现出来的学识折服。同事们口中“厉害的人”的特质可能更倾向于“思路清晰，反应迅速，谈吐流利，做事专业”。后来我明白我期望和现实中的差别是公司性质决定的，ThoughtWorks 是一家咨询公司，这些优秀的同事身上有“咨询公司”所需要员工具备的能力。

项目内外

在 ThoughtWorks，我经历了五个项目，从云迁移到 CI/CD 搭建，再到 2C 应用编写，到现在的 E2E 团队，应该说并没有遇到过特别大的技术挑战，大都数时候都是在写一些业务逻辑，改改样式，有意思一点的项目启动大致也就是如何把开源产品拼凑起来搭建一个流水线。不过敏捷这一套做事方式我觉得还是很有价值的。

而且好在项目比较轻松，给了我很多自由学习的时间看书、写 PPT。在 Session 和 Workshop 中，一遍又一遍重新定义 DevOps，把容器化技术学到了比较底层，整理了客户整个的网络架构和基础设施，AWS 拿到了架构师认证。真正的成长都是在项目之余。

最近一年时间我写了非常多的 PPT，有打单的，有架构设计的，有咨询的，有一段时间我几乎觉得自己是一个 PPT 工程师，也正是那段经历打消了我做咨询或者售前的想法。没有扎实的沉淀就做一味的输出是非常危险的，厚积薄发才是理想状态。这就要说到另一个项目内外不联动的弊端，就是在做对外培训或者分享没有真实案例做支撑，只能讲一些书本上的，自己小 demo 里面的，有时候甚至是别人博客里的一点东西，这种方式可能对于对这种技术一无所知的听众有所帮助，开了开眼界，但是对于真正想要学习这门技术的人来说，同样的内容他们也可以用跟讲师完全相同的方式获得。对于个人收获而言，网上看来的技术不利于深入探讨和沟通。

一些经验和收获

做事方法，是我在 ThoughtWorks 学到最有用的东西，这里给大家分享一下，一部分来自于我平时工作中的总结，一部分来自于培训笔记结合一些实践的体会。

敏捷项目里有 BA、QA、Dev、IM。我把我自己在公司扮演过的角色分为三个：开发（团队成员）、分享者（社区活动）、TL（Team Lead/Tech Lead，团队负责人）。

作为一名开发

如何发英文邮件

邮件是最日常使用的技能，恰巧也是最体现专业性的地方。在 ThoughtWorks 平均每天要写三封英文邮件，沟通需求，会议总结，商讨技术方案。邮件的目的在于传递信息，所以要求高效，因为邮件便于追踪，他还应该承载足够的信息便于日后查阅。写邮件好比写文章，一个简洁有力的开头，详实有条理的中间，一个非常绅士的结尾必定会给收件人一个好的印象。

• Say Hi：Dear 常用于正式场合，Hi 更常用些。
• 简短的开始，表明意图：一句话告诉接受邮件的人，你写这封邮件是希望对方做什么，这样可以省去不需要详细阅读邮件的人的时间，也可以抓住目标观众的眼球。
  • 有件事(问题，项目)想跟您(各位)确认/请示/请教/汇报….
  • I am writing to…
  • I was wondering if you could…
  • Let me explain/share/offer/provide/add…..
• 邮件中部，写明来龙去脉：用词清晰简洁，最好分点论述，如有配图最好放在邮件尾作为附件查看。如有祈使句务必使用问句，避免过于生硬。
  • Could you please…
  • I would appreciate it if you could…
  • If possible, I wonder if you could…
• 结尾，表达沟通意愿：
  • If you have any questions, please let me know.
  • If there is anything unclear, please feel free to ask me.
  • If you need any further information, please let me know and I shall be pleased to provide it.
  • Happy to help if you have any questions (or need further information).
• 签名：保持邮箱设置有签名的习惯，写明你的姓名、联系方式，对公邮箱还需要写明公司和职位。问候语使用：
  • Thanks,
  • (Best/Kind/Warm)Regards,
  • Yours sincerely,
• 邮件主题：类似于邮件第一句话，不过要更加简短，确保所有收件人看到主题就知道你要说什么，最好加上标签如【重要】[help] 等等。

如何 Feedback

Feedback，其实主要是沟通。Feedback 的一条准则我非常喜欢，叫作基于事实而不是基于判断，听起来很容易但做到却很难。典型的一个场景就是互相指责“我觉得你该xxx”。如果一个讨论是基于双方的主观意愿进行的那就容易变成“各说各的”，很难达到一致，讨论效率低下。Feedback 有一个模型用于解释我们应该基于什么样的事实进行反馈：如下图所示，信仰，态度，习惯不要给 Feedback；以及注意对事不对人，以帮助他人为出发点，越具体越好。每次我在和别人争论事情或是想要给某人提意见的时候我都会思考一下：这种情况是不是适合给 Feedback，我提这个意见真的是为了他能有所提升吗？他采纳我的意见之后真的会变得更好吗？思考这些问题可以避免善意的提醒变为指责。

Feedback 结构可以是：”我看到。。。我觉得。。。你是怎么想的？ “。好的 Feedback 还要及时，越早越好，不然容易变成翻旧账。除此之外，给 Feedback 之前要确保安全的环境，可以在沟通之前先问“现在合适吗？”，如果大家都在情绪激动的时候还是要以安抚情绪为主；给完 Feedback 以后接受者不要忘了说“谢谢”。

作为一名分享者

如何做 Session

在一家技术氛围很好的公司通常都是很鼓励分享的，我在 ThoughtWorks 最高产的一年做过二十多次分享。从 “Why” 到 “How”是我在帮别人 Rehearsal 的时候经常提到的点。很多人在讲 Session 时容易犯的错误是只讲“How”不讲“Why”，例如技术人员喜欢在 Session 一开始就介绍某某工具的历史，如何使用，有什么特别好的功能。这些对于第一次听这个话题，没有足够上下文的人来说太细节了。你需要为了听众回到你刚开始接触这个工具时的场景，回答一个问题：“我们为什么需要这个工具”。你可以通过“这个工具解决了什么样的问题”引出，例如说开发或者运维过程中存在着一、二、三的痛点，列举痛点一定要让人一目了然，最好有真实简短的案例作为说明，或者有数据支撑。有了问题的铺垫，然后才是“这个工具如何解决了上述问题”，可以使用对比的方法，例如使用这个工具之后，某某指标下降，开发体验如何得到了提升云云。最后可以再加一个还有哪些工具是为了解决同样问题产生的，从各个维度进行对比，帮助不同的项目场景做技术选型的一个参考。还可以提及为什么我们当下的业务场景没有使用其他工具。亦或是使用这个工具的成本，引入了什么新问题。还可以结合这个工具最新的版本和社区声音展望一下这个工具未来会有什么功能，现场讨论一下，都是可以的。

提出问题->解决问题->发散上升。这样的结构在我看来就是一个扎实的 session，可以看出，在这个结构中，“工具是怎么样的（How）”这个问题是最不重要的，因为听众只是想要在你的 session 中对这个工具有个感性认识，知道它的一些使用场景，就达到了参会目的。至于具体如何使用，我相信大部分人可以借助文档在很短的时间里通过看文档学会，前提是他们真的需要知道。

千万不要把你在网上博客里看到的内容随便就拿来讲 Session，因为你讲出来的东西，别人花一两个小时在网上看看博客也能看得到。

如何做 Workshop

Workshop 工作坊，不只是培训，还可以作为一种讨论的形式，用来形成计划或方案。例如针对一个困难、复杂的问题，搜集信息、找出问题、统一目标、制定方案、拆解任务，每一个环节都可以是一个 Workshop。我们在日常工作中除了培训最常遇到需要 Workshop 形式就是给团队（客户）引荐某种技术、实践或者解决方案。要让客户买单，让团队达成一个共识可不是一件容易的事情，会议上不能只有你一个人说话，因为不说话的人，脑子里想的可能和你以为的完全不一样；也不能所有人都说，这样容易失去焦点。因此如何组织好一次高效的会议，和做一个 Workshop 需要的技巧其实是一样的。

• Workshop 开始前（5P）
  确保所有人员、物料到齐，发邮件，订会议室，沟通团队成员时间，跑动要积极一点。
  • Purpose：参与者共同制定目标、有备选第二目标、有明确的产出、了解背景
  • People：识别干系人，并邀请到工作坊中，其中包括：执行者、决策者、信息输出者、受结果影响的人
  • Process：议程、时间、地点、技巧、物料、可能遇到的问题、以及问题解决方案
  • Product：行动方案、达成了共识、工作坊的遗留问题、收集到的信息、明确产出物
  • Pitfalls：可能会出现的问题、例如: 成员不积极、期间产生激烈的冲突、没有相关信息输入、设备物料出现故障、工作坊目标无法达成
• 工作坊开场（4P 1I 1G）
  主要是调动情绪和明确产出，同时宣布纪律和流程。有很多小技巧，比如大家一起制定 Ground Rules，保证每个人都同意不玩手机，以集体的名义向个人施压；还有我最喜欢的 Parking Lot，很多时候会议上会有人把话题带偏，或是有的人就钻到一个牛角尖里出不来，这个时候作为会议组织者可以说“这个问题我们放到 Parking Lot 里面接下来再讨论”，既让问题的提出者得到了尊重，又保证会议可以正常进行下去。
  • Purpose：明确目标和产出
  • Process：明确议程，介绍工具、设置预期、工作坊中提醒大家保证按计划进行、进展如何
  • Parking Lot：介绍如何使用、避免遗漏有价值的议题、重视参与者的输出
  • Participants：参与者的角色和重要性（明确职责）、赋予他们工作坊中的相关责任、介绍参与人角色，避免尴尬
  • Icebreaker： 调动参与者情绪
  • Groud Rules：保证秩序、共同制定规则、设置规则警察、避免“破坏性行为”
• 工作坊进行中
  主要是调动气氛，掌握好发散->收敛->发散->收敛的节奏，确保关键角色（Stack Holder）在每一个环节对问题的认识都达到了一致，灵活使用各种发散收敛的工具，借助可视化（画图，贴纸）进行视觉传达。
  • 调动气氛的核心是吸引学员注意力并点燃自己
  • 注意肢体语言、口头表达的精炼程度、面部表情、语音语调、口头禅等
  • 12种调动气氛的方法：鼠－热情、牛－案例分析、虎－控场、兔－会讲故事、龙－会微笑、蛇-会放视频、马-讲笑话、羊-做游戏、猴-给奖励、鸡-会运动、狗-热点问题、猪-提问题
  • 用视觉的笔记形式，更好的辅助工作坊。
• 工作坊之后
  一个漂亮的收尾可以提现出专业性，整理工作坊的产出并发送邮件应该是最简单的方式，不要忘了把 Parking Lot 里的东西加上。还可以用各种方式搜集到与会人员的反馈，帮助你下一次做的更好。最后有一些关于 Workshop 的小 Tips:
  • 内容设计围绕学员进行设计、调整
  • 交互与气氛>讲义与脚本
  • 白版与贴纸>播放PPT
  • 现场投入>照本宣科
  • 寓教于乐>灌输知识

作为一名 TL

如何和团队成员沟通

沟通太重要了，敏捷里的所有会议，都是在强调沟通。如果说N v N 的沟通是要确保每个人围绕观点充分表达，那么 1 v 1 的沟通就是要走心。作为一个团队领导和团队成员沟通的时候是有很多技巧的，比如在一次谈话开始前可以准备以下步骤：

• 定方向：说明讨论目的；说明讨论重要性；建立积极氛围。
  开场即说明此次约谈意图，避免听者猜测，带来隔阂和不信任感。也让谈话建立起一个关注点。

• 理情况：了解问题原因；对象担心和顾虑所在；分享自己的观点和信息。
  这一步属于谈话的发散阶段，主要是让被谈话者多说，一定要在每段谈话的结尾说“还有吗？”，给对方充分的时间思考，确保挖掘完对方所有的想法。

• 想方案：积极鼓励对方的参与，共同思考解决问题的方法。
  在开始这一步之前先总结理情况的一步，对前面的发散有一个收敛，如果对方是倾诉式的表达，一定要先表示“我认同你的感受”，然后将对方表达的内容总结出来“你说了以下几点，一、二、三。。”然后将问题快速地排一个优先级或者把问题归纳到三个问题以内，再来想解决方案。想解决方案的时候先问对方“你觉得可以怎么样”，同样在回答完之后不要忘记问“还有吗？”，确保所有解决方案都被相到。

• 明做法：与对方就行动步骤达成共识，并进一步商讨如何追踪。
  明确行为产出，应该是谈话产出的重要内容，一起定义做到何种程度我们认为是“好”了，可以确保我们的目标更加一致，也便于后期追踪验收。

• 做总结：突出讨论重点，以积极的语调结束谈话。
  其实整个谈话过程 Leader 都是起到一个 facilitator 的作用，提出问题，引导，帮助梳理，最后是总结。总结的时候要注意高亮出谈话的重点帮助被谈话者记忆，最后加上一句发自内心的肯定：“进公司以来你一直表现不错，相信这次挑战对你来说不算什么！”给别谈话者正向地影响。

如何 Retro

Retro 又称迭代回顾会议，常发生在两个迭代之间，用于总结前一个迭代的得失，以求下一个迭代做的更好。在 ThoughtWorks retro 无处不在，做了一个 Meet up 之后，一次培训的结尾，一个项目的结束，都会有 Retro，我个人甚至把 Retro 带到了生活中。Retro 的 Well/Less well/Suggestion 事实上建立了一种思维模型，告诉我们在一个事情结束之后我们如何从好和不好的角度审视它，以及制定下一步的改进计划。Retro 还可以确保团队成员充分沟通，TL 可以借此了解每个成员对于团队的想法。

关于阿里巴巴

如果说 ThoughtWorks 是一个愿景类公司，阿里巴巴的定位则要更实务一些。可以预见在新的岗位上会有更高强度的工作节奏，和更关注真实用户的产品。希望能在阿里巴巴成长为一个在云计算领域有一定影响力的人，有着扎实的基本功，出色的沟通表达能力，和宽阔的技术视野。这一切，都是要坚持不懈的努力才能换来的。