企业大部分问题都可以归结为沟通问题,沟通也是一个历久弥新的老大难问题。的确,沟通要遵循很多基本原则,诸如:营造环境、耐心倾听、平等对话、换位思考、表达明晰、及时反馈等等。
很少有人反对沟通中的基本原则,但是现实中的沟通问题,依然纠结难解。说明光有原则远远不够,还需要找到切实可行的方法,把原则落实到行动中去。显然,落实沟通原则比了解沟通原则,要困难很多。
互联网的飞速发展,也让软件开发站在了时代的浪尖之上。软件开发是一项多行业、多工种协作配合的创造性活动,风险极高。从团队组建到项目结束,处处都是陷阱和危机。稍有不慎,就会全盘皆输。
为了提高软件开发的效率和成功率,一门新的学科“软件工程”应运而生,也相继出现了多种软件开发模式,诸如CMM、CMMI、RUP、Agile等等。软件工程自1969年诞生以来,看似花样百出,实际上面对和解决的依然是古老的沟通问题。
越来越多的软件开发团队,在尝试Agile敏捷开发过程。如果继续细分,敏捷开发过程又包含了多种模式,如AMDD、AUP、XP、FDD、Scrum、OpenUP等等。抛开其中的细节,会发现各种敏捷开发模式,都把“沟通”放在核心位置,而且都不约而同地推出了各种各样的沟通“仪式”。用看似轻松、有趣、儿童化、游戏化的沟通仪式,让沟通无处不在、无时不在。
沟通的仪式,在实际沟通中至关重要,却又常常被忽视。
让我们看看敏捷开发过程中的几个小仪式。
先看团队组建
团队是沟通的前提,敏捷团队应该是完整的, 包含和项目相关的所有人员。产品、开发、测试、运营、客服,不分高低贵贱,全部都要进来团队。团队人员不能多,十人以上就要考虑拆分。宁愿多个小团队,不要一个大团队。
团队应该坐在一起。同一个城市、同一个房间、相邻的办公桌,抬头低头都能见。不要相信异地协同,不要相信在家办公。不管部门,只管团队,属于一个团队,就坐在一起工作。
团队的沟通方式应该原始一些,最好是言语和眼神,其次是白板和卡片,最后考虑文档和邮件。
除了在公司一起工作,团队也应该一起外出活动。喝咖啡、看电影、唱歌、旅游。不要小看这些小动作,经年累月地坚持下来,团队就会逐渐变得有凝聚力和战斗力。
再看每日晨会
任何团队都要开会,开会本身也深刻地反映出了一个团队真实的文化氛围。敏捷团队应该每天在一个固定的时间开会。是每天,而不是临时召集。是固定时间,而不是临时协商。
团队不能坚持每日开会,最常用的借口是工作很忙,时间很宝贵,天天开会很浪费时间,团队有必要的时候一定会开会。看似很完美的借口,如果把会议当成喝水、吃饭、睡觉、做礼拜等等必须完成的事情,就一定能挤出时间。
敏捷团队应该站着开会。只有团队成员,杜绝不相关的人员旁听。所有人员都站着,不用考虑职位,不用排定座次。站在一起说话,废话就少,整个会议容易控制在15分钟之内。
每个成员应该依次发言。准备一个道具,比如玩具小熊,开会时候依次传递。谁拿着道具谁才可以说话,没拿着道具的先闭上嘴。有些领导废话多,习惯随时插话,三分钟能讨论清楚的,弯来绕去能扯上三小时。
用真实的道具,确保团队所有成员都能依次、完整地发言,是避免会议冗长无序的好方法。退一万步说,团队中真有马云、周鸿祎这样的“超级侃爷”,每天也只能在固定的时间“祸害”一个小团队。舍小我,为大我,这已经为其他团队、为公司,做出了巨大贡献。
发言三件事。昨天做了什么,今天要做什么,需要哪些资源。说清楚这三件事,不需要上网查询资料,不需要绞尽脑汁编撰。做了啥直说,没做啥不说。
只需要几次尝试,团队成员基本就能开好立式晨会。
最后说说工作看板
让工作看得见,一直都是管理者的梦想。丰田的精益管理做到了,卡普兰和诺顿的平衡计分卡、战略地图做到了,敏捷开发过程也做到了。做法不同,思想相通,而且比预想的简单很多。
准备一块看板。不是做一个软件系统,不是找一台显示器,就是墙上一块实实在在的板子,白板黑板都行。
准备一堆便签。能够写字,能够粘在前面准备的看板上。怕粘不住,就再准备几盒图钉,把便签钉在看板上。
成员都来写便签。团队每个成员,自己写自己的工作。不是领导分派,不是同事指定。自己把自己要做的事情,写在便签上。前面说的每日晨会,结合便签,就更容易说清那三件事了。
当然,团队成员如何在一起清理要做的任务、如何让每个成员都知道任务的真实含义、如何把任务写到便签上、如何让团队成员自己认领已有的任务,敏捷开发流程有自己独特的方法,这些方法一点都不神秘,就像幼儿园大班的孩子一起游戏,虽然很“幼稚”,但是很可行,很有趣。
便签贴在看板上。这应该是敏捷开发过程中最有“技术含量”的事情了,看板可以分成四个区域:要做的事情、正在做的事情、做完了的事情、不再做的事情。每天的晨会,说完三件事之后,就是自己移动便签了。正在做的便签,贴到“正在做的事情”那一栏,做完了的便签,贴到“做完了的事情”那一栏。
工作看板很简单,但是团队之外的任何人,也可以一眼看出整个项目的进展。简单,但是神奇。或者说,因为简单,所以神奇。
第一次接触敏捷开发过程,很容易产生一种错觉:这是不是太儿戏了。的确,敏捷过程追求的,就是让复杂的软件开发,变得像儿童游戏那样简单、那样有趣。进一步学习,会发现敏捷过程非常非常强调沟通。整个开发过程,就是通过一个一个的小小“仪式”,来切切实实地把沟通落到实处。
仪式,可以培养和强化习惯,习惯可以转变为信仰,信仰蕴含着无穷的力量。宗教,为什么如此成功,除了锤炼千年的理论体系,那些延续千年的仪式,也是极为重要的因素。对于很多信众而言,信仰建立的过程,更多是对仪式仪轨,从陌生到熟悉、从熟悉到依赖的过程。
仪式,比原则更容易被大多数人接受。仪式,简单可重复,更容易带给成员安全感、认同感。我们太过强调空洞的原则,效果堪忧,不如辅之以简单可行的仪式,也许会更有效果。
沟通,需要原则,需要仪式,更需要对仪式的坚持。