本文约2100字,建议阅读5分钟。
为什么外企或国企的职业经理人空降创业公司多数都会折戟沉沙?十有八九是因为他们不懂“过度沟通”。在敏捷化的企业或团队里更是如此,应对瞬息万变的市场和业务需求,消除闷骚程序员和技术“小白”客户间的鸿沟,力求产品做到最优,可以说唯一的方法就是时时地沟通,不断地沟通,反复地沟通,过度地沟通!
就像大话西游里唐僧的经典台词:
“你想要啊?悟空,你要是想要的话你就说嘛,你不说我怎么知道你想要呢,虽然你很有诚意地看着我,可是你还是要跟我说你想要的。你真的想要吗?那你就拿去吧!你不是真的想要吧?难道你真的想要吗?……”
这段貌似搞笑的“废话”,在敏捷开发中,却是一条真理——沟通务必明确、透彻,穷尽所有疑问!宁可矫枉过正,不可闭门造车!
沟通!沟通!沟通!
敏捷开发多采用短迭代,要求尽快交付可以工作的软件,所以项目的需求文档就很难像原来的瀑布开发模式一样面面俱到。这就要求我们多进行沟通以确保双方的理解一致。根据以往很多项目的经验来看,失败的项目大多都是缺乏沟通,成功的项目必然是沟通做的比较好的。
很多人做项目,拿到客户需求以后,自己简单看了看,然后就开始做了,等到做完一个迭代拿给客户看时,完全不是客户要的东西。这就像女朋友说喜欢吃水果,你不由分说就买了十斤香蕉送过去,因为你喜欢吃香蕉。结果被骂了,女朋友喜欢苹果樱桃火龙果……就是不喜欢香蕉。这都是对需求的理解比较片面,又不提前沟通,自以为是的后果。
还有的人,尤其是新入团队的人,客户写的东西或者说的需求,他没有完全理解,但不敢问,总觉得客户已经说过了,已经写过了,再去问是不是不妥?显得不专业,没面子……如果按自己的理解或者猜测万一对了呢?于是就碰运气。事实上我们主观的猜测常常都是错误的,尤其是在我们对项目没有全面了解的情况下。想想你被女朋友骂过多少次?“女孩儿的心思你别猜”,对客户也是一样的。
还有一种情况,就是我们自己发现了问题,需求上的,或者客户的流程上的,但是我们总是想等到明天再沟通,明日复明日,其实内心希望这个问题自动消失,但最终的结果往往是滚雪球一样,越来越严重。回忆一下分手的前女友,有没有恍然大明白的感觉?问题是不可能自动消失的,发现问题要主!动!沟!通!
很多时候,我们都不敢对客户说“no”。比如我们觉得客户的需求太碎片化,UI改来改去,业务细节不够明确,希望客户能提供一个比较接近Final Design的设计,但是总觉得给客户提意见不好,显得对客户不够尊重,会影响满意度和结账“效率”。实际上我们提出问题和自己的想法才是对客户最大的尊重,因为在项目中双方利益是一致的,就是把结果做到最好。女朋友需要的是值得依靠的男友,而不是言听计从的奴才,一味的顺从换不来爱情!
我们很多人习惯了一种沟通方式,不管什么问题都这一招,所有的问题都写邮件或者所有的问题都用语音,这也是缺乏沟通效率的方式。约会、情书、电话粥、语言留言、啪啪啪……十八般武艺轮番用,绝对比你只会聊QQ好使。
敏捷开发的正确沟通方式
首先,要树立平等的意识,统一立场,统一战线。敏捷项目里的沟通,不管是与客户还是与团队成员,大家都是平等的,沟通项目相关的问题都是平等的,应该把客户当作自己团队中的一员。客户花了钱,目的只有一个——希望项目做好,双方的目标利益是一致的。在此前提下,沟通应该知无不言,言无不尽,即便争执都是沟通方式之一,所有不以把项目做到最优而藏着掖着“打死不说”的行为都是可耻的。
小平同志说: “白猫黑猫,抓住老鼠就是好猫”,沟通也一样。下面是常见的几种沟通方式:
面聊
视频
语音
IM 文字沟通
邮件沟通
这几种沟通方式的效率一般是由上到下递减的。当我们与对方面对面的时候,根据对方的表情就可以看出他是否真的理解了我们的意图。
在实践中我们需要多种沟通方式的有效结合,比如离岸团队面聊的机会比较少,可以用视频和语音,但是视频语音由于强调及时性,需要大家的时间都合适才行。而且视频语音也有缺点,就是内容很难搜索,也较难在组内传播。而IM文字沟通在这两方面就体现出了优势,有历史记录,可多人分享等。
邮件沟通的优势是不需要客户立即回复,而且可以图文并茂加附件,给客户更多的时间思考,格式化的文档也更容易把一件事情描述清楚。
所以,我们在沟通的时候,要结合具体情况选择最适合、最有效的方式,多快好省地把问题沟通清楚。
一图胜千言
很多时候,图形化的沟通非常重要,对项目的设计、架构如果开发人员难以达成统一的认识,就是缺乏图形、设计图或者架构图。我们都知道,人对图形的理解和记忆力要好于文字。
系统之间的交互,软件如何部署,项目的架构封层等,这些用图形来表示往往一页纸就可以,而且大家都能一目了然。而只有别人对你的想法理解了,才能够发现你的问题,才能给出建议。我觉得软件项目,非常重要的两张图,一个是 Architecture Diagram, 一个是Use Case Diagram, 这两张图可以大大节省项目开发的沟通时间。
敏捷项目流行边做边改,我个人对此不太认可,因为客户付钱是让我们把事情做对,而不是把事情改对。那么如何避免不断修改?那就是先做一个原型,我说的原型是不需要花太多时间的,如果花太多时间就得不偿失了,比如UI我们可以在开发之前先画出Wireframe, 如果需要交互,我们可以先做交互的Prototype。现在有很多工具比如说Invision都可以建立静态图形之间的交互,这样可以大大减少返工的可能性。
很多人只问问题,导致客户回复的很慢,因为客户需要思考。然而有时候客户思考后给我们的方案仍不适合,一来二去浪费了很多时间。
我们上学的时候都喜欢做判断题,其次是选择题,再次是填空题,最不想做的就是问答题。那么将心比心,我们要想得到客户的快速反馈,是不是也应该尽可能给客户出比较容易做的题呢?
所以好的方法是,我们给客户提问之前,先想想我们是不是有其他可行方案?或者我们有多个方案,只是不能确定用哪一个?很多时候,其实我们是有可选项的。
实践证明,凡是我们提的方案被客户采纳的,自己做起来也更顺手,也就更有效率。
敏捷之美 ∣这里只有干货
联系客服