成为咨询师
本文旨在帮助开发完成向咨询师的转变，内容不但涉及向UX学习，还包括思维方式的转变。我尽量采用一些亲历的例子来说明该如何做，也会适当的解释为什么需要这样做。不过在展开详细讨论之前，首先来澄清这里提到的三种角色。
开发（Developer）角色
开发是指那些喜欢写代码，享受写代码，喜欢纯粹，讨厌办公室政治，永远穿T恤的有些偏执的程序员。跟他们打交道，有这样一些注意事项：
- 不要让他们帮你盗
QQ号 - 不要让他们帮你修电脑或者装Windows系统
- 不要跟他们讨论
人文/政治类的问题
开发往往还单纯的可爱，除此之外，他们还有这样一些特点：
- 逻辑清晰
- 与人争辩时往往可以通过清晰的逻辑而获胜
- 单身
业界已经有很多关于开发的描述了，我这里也有一个描述开发的列表：
用户体验设计师（UX）
UX是指用户体验设计师，在本文的上下文中，更偏向与非视觉设计的那些设计师（产品设计师）。在项目中，他们会做用户调研，竞品分析，信息架构简历，交互设计（纸上原型，低保真）等活动，并负责开发纸上原型，验证这些原型等。
和UX打交道，也有一些应该注意的点，比如：
- 不要叫他们美工
- 不要对他们说诸如：“帮我美化一下这个页面”，“这个颜色得再亮一些”之类的话
- 不要跟他们讲关于程序员的笑话
事实上，人们对UX的误解很深。提到UX人们的第一反应是PhotoShop，P图/切图。这仅仅是他们日常工作中很小的一部分。大部分UX还要做很多用户研究，信息架构整理的事情。老实说，我在去年5月之前的对UX的认识和大部分开发的认识是一样的，但是在后来的项目上和多个UX合作过之后，我彻底改变了原先那种偏见，开始敬佩他们，并向他们学习。
设计工作可以细分为这样一些不同的方面（图片来源网络）：
UX的一项特别的技能在于能从复杂的现实世界中抽象出清晰的信息（用户画像，体验地图甚至最后的用户故事）。这项技能不但重要，而且还很牛逼。
知识的诅咒
《反脆弱》里有个有意思的例子：人们仅仅创造了非常有限的词汇来描述颜色，比如蓝色，红色，而任何一个视觉正常的人都可以轻松的识别出数百种不同的颜色。也就是说，人们可以很轻松的理解相当复杂的事物，但是很难向别人描述该事物（想象一下向别人描述一只章鱼的颜色）。
人们对于现实世界中的事情（特别是复杂的业务场景）往往只能意会而很难言传，再加上知识的诅咒（我在《如何写一本书》里，详细讨论了这种常见的陷阱）的存在，当用户在描述A的时候，在没有上下文的人听来，很可能是B或者C。这种情况在软件开发中非常常见，也是很多项目之所以延期的原因（大量并无必要的返工，需求澄清等）。
在项目前期，UX需要和客户坐在一起，将客户的需求分析清晰。分析细节包括业务场景，用户画像生成，信息架构，体验地图等等，这些信息并不是天然就显现的，恰恰相反，它们需要UX经过很多轮的辛苦引导，从用户的脑海里提取出来的。
这里需要UX的核心能力是：
- 有目的的抛出问题，引导客户进行发散
- 有节奏的收敛，形成共识
- 不断修正过程中的错误
- 可视化能力（这可能是大部分人觉得唯一和UX相关的点）
咨询师
咨询师是指那些根据自己的丰富经验来帮助客户解决具体问题的人。这些问题并不一定局限在技术上 —— 比如架构的设计，具体前端/后端技术的选定，还包括一些流程的改善。比如引入新的工程实践来缩减项目的周期时间，帮助团队发现问题，建设团队的能力，作为各个团队间的润滑剂帮助项目成功等等。
咨询师工作中的一个常见的场景是：
- 列出目前遇到的问题
- 确定各个问题的优先级（和各个利益方）
- 制定方案
- 给方案加上时间，形成计划
- 细化计划中的条目，并促成它
引导/启发
我在印度的某一期TWU当教练的时候，发现了一个很有意思的现象，国外的同事在组织培训时更强调用引导/启发的方式，让学生们自己得出结论，并在课堂上进行讨论，以期教学相长。只有在过程中有启而不发的情况出现时，教练才会适当抛出自己的开发，并再次启动讨论。
与我一直的认识不同的是，这种方式效果很好。通过一些适当的启发，学生很容易自己讨论出一些有趣的看法，然后教练在这个基础上做一些总结，并帮助他们分析不同看法/想法之间的优劣。
我非常认同这种模式，后来自己组织的其他培训/workshop也都尽量采取这种方式。咨询师在客户现场，也应该采取这种引导的方式帮助团队来完成能力建设，而不是事必躬亲。
角色转化
从开发者视角切换到咨询师的第一要诀就是：让团队解决自己遇到的问题！乍听起来，咨询师好像变成一个多余的角色了：既然团队自己可以搞定，还要咨询师干什么呢？咨询师的职责是让团队意识到问题，理清思路，制定解决方案，并逐步实施。
使能/赋能
我们来看一个简单的例子：在客户现场，你发现团队往往在集成时会花费很多额外的时间和返工，开发过程中大家各自为政，没有人知道一次commit会给软件包造成什么影响。
如果你是一个咨询师，应该如何解决这个问题？一个常犯的错误是，直接上手帮助团队搭建持续集成（CI）环境，并设置CI纪律（比如build红了不许过夜，红的时候其他人都不许commit等）。
一种更好的做法是：做为咨询师，首先需要帮助团队认识到这个问题，你需要让所有人都知道，我们现在的问题是什么。在所有人都清楚了这一点之后，你需要提出（或者引导出）持续集成的概念（因为根据经验，这是一种可以很好的解决集成时额外的返工现象的好办法）。
但是对于不熟悉持续集成的团队来说，搭建一个持续集成环境是一个非常复杂的任务。因此你需要分解这个任务为一些更小的，可以被解决的问题。
- 申请虚拟机资源
- 安装jenkins（包括安装JVM，创建用户等）
- 配置本地构建脚本到jenkins（构建脚本，自动化测试等）
- 申请显示器资源（作为CI Monitor）
- 将结果显式在CI Monitor上
有了任务之后，你需要分别为这些子任务分配owner。对比搭建持续集成环境这样的大任务，这些小的任务已经非常具体，更重要的是，他可以被团队中任何人理解并解决。
学习做引导
除了思维方式的转变，以及自身过硬的专业技能（比如clean code/重构能力，自动化测试，DevOps，持续交付经验等）之外，开发者需要从UX那里学习如何发现问题，并将问题可视化出来的技能。
当你发现团队面临某个问题是，可以通过组织一个类似头脑风暴的会议来帮助团队梳理：
- 提出问题
- 维护会议纪律，保证所有人都贡献自己的想法
- 将想法/问题归类
- 找出问题的解决方案
- 制定计划（包括时间点和owner）
关于如何做引导的详细信息，还可以参考我的上一篇文章。
进一步的阅读
除了上边提到的
- 思维方式的转变
- 向
UX学习引导的技巧
之外，事实上还有很多技巧和内容需要学习：