敏捷实践系列(二)

大话西游里有一段因为没有沟通的经典, 结局如何大家都知道。

唐僧:你想要啊?悟空,你要是想要的话你就说话嘛,你不说我怎么知道你想要呢,虽然你很有诚意地看着我,可是你还是要跟我说你想要的。你真的想要吗?那你就拿去吧!你不是真的想要吧?难道你真的想要吗?……

悟空:…

一. 敏捷项目沟通尤其重要

敏捷开发多采用短迭代,要求尽快交付可以工作的软件,所以项目的需求文档就很难像原来的瀑布开发模式一样面面俱到。这就要求我们多进行沟通以确保双方的理解一致。根据以往很多项目的经验来看,失败的项目很多都是缺乏沟通,成功的项目必然是沟通做的比较好的。

二. 敏捷经常出现的沟通问题

你以为你以为的就是你以为的

有时候,我们很多人做项目,拿到项目的需求以后,自己简单看了看,然后就开始做了,等到我们做完一个迭代以后,拿给客户看时,完全不是客户要的东西,因为我们对项目的需求的理解比较片面,就是自以为是。

不敢沟通

还有的人,尤其是新入团队的人,客户写的东西或者说的东西,自己没有完全理解,然后又不问,他总觉客户已经说过了,已经写过了,然后再去问客户,是不是不妥?如果按自己的理解或者猜测万一对了呢?, 然后就碰运气。 事实上我们的猜测都常常都是错误的,尤其是在我们对项目没有更全局的了解的情况下。

拖延

还有一类沟通的问题,就是我们自己也发现了问题,需求上的,或者客户的流程上的,但是我们总是心想等到明天沟通,明天再等明天,其实是希望这个问题自动消失,但最终的结果往往越来越严重。

不敢沟通客户的问题

在我的一些项目里,比如我们团队觉得客户那边需要提高,比如需求都很碎片化,客户的UI改来改去,希望客户能提供一个比较接近Final Design的设计,但是总觉得说出客户的问题不好意思,或者对客户的不尊重,实际上我们提出问题和自己的想法才是对客户最大的尊重。

沟通方法单一

我们很多人习惯了一种沟通方式,不管什么问题都是同一种,所有的问题都写邮件或者所有的问题都用语音,这也是很没沟通效率的方式。

三. 敏捷项目如何沟通

平等沟通的意识

首先,我们要理解,敏捷项目里的沟通,不管是与客户还是与团队成员,大家都是平等的,沟通项目相关的问题都是平等的,尤其是把客户也当做自己团队的一部分,客户也是希望项目做好的那一个人, 只有这样,我们才能畅所欲言,无所顾忌,更不会有想法掖着藏着。

多种沟通方式结合

小平说: “白猫黑猫,抓住老鼠就是好猫”,沟通也一样,下面是常见的几种沟通方式。

面对面

视频

语音

IM 文字沟通

邮件沟通

这几种沟通方式的效率一般情况下由高到低,所以我们尽量选择沟通效率比较高的方式, 因为当我们能看见对方的时候,我们可以根据对方的表情就可以看出来对方是否真的理解了自己所说的。

但是实际当中我们需要多种沟通方式的有效结合,比如离岸团队面对面的机会比较少,我们可以视频和语音,但是视频语音由于他强调及时性,需要大家的时间都合适,但是视频语音也有缺点,很难有文字记录,虽然可以录音,但是视频和语音很难搜索内容,也较难在组内传播。 那么文字沟通有时候就体现出了很多的优势,有历史记录,多人可以参与等。

但是IM得文字沟通也有一些不足,比如很难通过图形沟通,对图形标注等,除此之外,很多时候很难及时给出答案等,那么邮件的优势就是不需要客户立即回复,也给客户更多的时间思考,同时格式化的文档更容易把一件事情描述清楚。

所以,我们在沟通的时候,要结合情况选择最适合,最快速能够把问题沟通清楚的方式。

一图胜千言

软件项目很多时候,图形化的沟通非常重要,我们很多项目的设计,以及架构,开发人员难以达到统一的认识,就是缺乏图形,设计图或者架构图。我们都知道,人对图形的记忆力要好于文字。

系统之间的交互,软件如何部署,项目的架构封层等,这些用图形来表示往往一页纸就可以,而且大家看后,很容易理解,很容易记住。因为只有别人对你的想法理解了,别人才能够发现你的问题,才能给出建议。我觉得软件项目,非常重要的两张图,一个是 Architecture Diagram, 一个是Use Case Diagram, 这两张图可以大大节省项目的开发沟通时间。

原型或者草图

敏捷项目流行边做边改,但是我对这个是不太认可的,客户付钱是让我们把事情做对而不是把事情改对。那么怎么样能够在做之前尽量就明白要做什么?那就是先做一个原型,我说的原型是不需要花太多时间的,如果花太多时间就得不偿失了,比如UI我们可以先在开发之前先画出Wireframe, 如果需要交互,我们可以先做交互的Prototype. 现在有很多工具比如Invision都可以建立静态图形之间的交互,这样可以大大减少返工的时间。

提出问题时尽量给出方案

很多人只问问题,所以导致客户回复的很慢,因为客户需要思考,但是有的时候客户思考后给我们的方案又不适合,所以一来二去就浪费了很多时间,那么好的方法是就是,我们给客户提的问题,想想是不是我们没有方案呢? 还是我们有多个方案不能确定是哪一个方案呢?很多时候我们其实有方案的。

我们都知道我们上学的时候都喜欢做判断题,其次是选择题,其次是填空,最不想做的就是问答题,想想我们要想得到客户的快速反馈,我们是不是想想应该给客户出比较容易做的题呢?

其实,凡是我们提的方案被客户采纳的,我们做起来也更顺手,也就更有效率。

总结

最后,沟通最主要的两点:

  1. 如果你想要,就一定要说,不说,别人怎么知道你想要呢? (敢于沟通)
  2. 要想尽一切办法, 让客户觉得:“你以为你以为的就是你以为的” (确认自己的想法)
相关内容:

拒绝内耗!AI 时代企业信息化降本60%的秘密

说个扎心的:很多企业上了一堆ERP、OA、CRM,系统越堆越多,人反而越来越累,数据还各说各话。问题从来不是系统不够,是没人把数据真正用起来。这篇讲的“从建系统到建能力”确实是新思路。AI不是再加一个系统,是把底层逻辑换了。不过关键还是那句,得有懂业务又懂AI的人掌舵,不然AI也只是又一个吃灰的新系统。

AI 实验室 Shinetech Way 37 阅读

AI时代做软件,90%的人都搞错了方向

AI给了工具,但没给判断力。见过太多人拿AI糊出个demo就以为能上线,结果需求没理清、架构一团乱,越改越崩,最后推倒重来更费钱。AI把入门门槛砸低了,把做好的门槛抬高了——这话说到点子上了。会用AI的和会写提示词的,根本是两码事。

AI 实验室 Shinetech Way 30 阅读

AI这么能写代码,企业还要不要花钱做软件定制?

真正踩过坑的都懂:AI写代码是快,但那快出来的东西上线才是噩梦的开始。数据对不上、流程跑不通、出了事没人兜底——省下的开发费,后面加倍还回去。这篇说的”AI降低了写代码的门槛,却拉高了做好系统的门槛”,一句话戳中要害。工具再猛,业务风险还得人来扛。

AI 实验室 Shinetech Way 55 阅读

软件开发不养大型团队,“超级程序员+AI”赋能顶配开发能力

以前做个系统动辄拉一二十号人,周期按月算,钱按百万烧。现在真没这个必要了。但别被”AI会写代码”忽悠瘸了,它能写片段,写不了需求拆解和架构。写出来的东西对不对、稳不稳,还得懂行的人盯着。门槛不是降了,是更吃真本事了。这波”精兵+AI”确实比堆人靠谱。

AI 实验室 Shinetech Way 59 阅读

我们如何从领域驱动开发当中获益–王德水

领域驱动设计,遇见你之前 我们公司推行和实践敏捷已经很多年了,SCRUM已经成功应用于大部分项目,得益与业界敏捷开发大师以及国内很多优秀工程师的分享和宣传,我们使用了很多优秀的软件开发实践,比如测试驱动开发(TDD),行为驱动开发(BDD), 持续集成(CI)等等为我们带来了很多收益。由于我们公司以……

Shinetech Way 技术趋势 敏捷实践 1909 阅读

Mind Matter项目分享——设计不仅仅是设计

Mind Matter软件旨在促进企业的战略发展,并帮助推动战略的实践。其核心业务是开发下一代战略软件和服务。与各种类型和规模的企业组织合作,共同定义、设计和执行战略。 目前开发的软件作为一款简单精巧的协助工具,帮助用户定义、设计、讨论、决策和交付发展战略。 Mind Matter项目自2017年9……

Shinetech Way 敏捷实践 1953 阅读