盲人摸象新解——谈facilitator在软件开发过程中的重要性

      先看一看这个故事。

 

      从前，有四个盲人很想知道大象是什么样子，可他们看不见，只好用手摸。胖盲人先摸到了大象的牙齿。他就说：“我知道了，大象就像一个又大、又粗、有光滑的 大萝卜。”高个子盲人摸到的是大象的耳朵。“不对，不对，大象明明是一把大蒲扇嘛！”他大叫起来。“你们净瞎说，大象只是根大柱子。”原来矮个子盲人摸到 了大象的腿。而那位年老的盲人呢，却嘟嚷：“唉，大象哪有那么大，它只不过是一根草绳。”四个盲人争吵不休，都说自己摸到的才是真正大象的样子。

 

      再听听我讲的故事。

 

      从前，有四个人很想开发一个软件，可他们只熟悉软件开发中的一个环节，A比较擅长和用户沟通，搜集需求，B是设计师，C喜欢写程序，编码，D是一个测试人员。A开始需求调研。期间，B经常问A，”你需求出来没有阿？“。A说：“等等，到时候我把需求文档给你”。C，D此时只是听说有一个项目，具体不知道是什么。一个月后，A经过和对方客户人员，操作人员的电话交流，中间也面谈过一次，终于把需求说明书的初稿出来了。B这时正在处理了一个线上bug。A通过即时聊天工具和B说，我把需求说明书发你邮件了阿，赶紧看看。两天后，B看了一下，反馈了一些问题，通过邮件逐条回复了。 A看到后，发现有些问题还不清楚，又打电话给客户，确认问题。期间，A刚好参加了一个会议，两天后，B收到了A的回复邮件。如此反复，又来了两轮，过去了四天。这时，C还闲着，听说需求出来了，也没仔细看。 D开始作测试分析。B开始设计，设计过程中，发现了一个问题，找A作确认，A又找客户作确认。两个星期后，B设计完了，产出了一份设计说明书，同时，和C说，我设计出来了，你现看一下。C看了一下，也没看出什么问题，马上进入开发。开发到一半，发现一个问题，反馈给B，B发现确实是一个问题，反馈给A，A打电话和C说，这个应该是这样这样这样的....。C开始返工，手脚很块，4周过去了，C开发完了。D开始测试，测着测者，发现一个问题，C说没问题，需求就是这样写的阿，D说和需求不一致阿。C翻出他的需求文档给D看，D也翻出文档给C看，发现原来他们的文档版本不一样。C和D研究决定，找A确认一下需求，A说是这样这样这样的，C开始返工。此时，测试已经开始一周了。又过了两周，测试完成了测试。

     项目终于发布了。拿到客户那里，客户说：“这个功能我不太用，好像你少了XX功能吧，那个功能我本来想的不是这样的。”

     A窝囊了，B郁闷了，C愤怒了，D悲剧了 。

 

    我们来看看项目各阶段所花的时间：

    需求：30天

    需求确认：2+2+4=8天

    设计：14天

    开发：7*4 = 28天

    测试：7*3 = 21天

 

    这是一个典型的软件开发场景，大家看看觉得有什么问题和可以改进的地方吗？

 

    让我们回到盲人摸象的场景，四个人摸的正欢，一个智者经过。他实在看不下去了，对胖的说，“你和我来”。智者拉着旁的走到矮的跟前，说：你摸摸。胖的摸了一下，发现摸到的是跟柱子。如此，智者还让老者顺着大象尾巴摸，摸到了大象的屁股。期间，还特意拿来了一个梯子，大家顺着梯子，都摸到了大象的牙。就这样，智者辅助这些盲人把大象全身摸了个遍。

     互相都摸过之后，智者让他们坐下来，对他们说，你们知道猪是什么样的吗？老者说，我以前眼睛没瞎的时候，是见过猪的。智者说，你最开始摸的就是象的尾巴，猪也是有尾巴的，差不多的，你知道了吗？老者说，知道了。

     粗粗的，滑滑的是大象的牙齿，叫象牙。像柱子一样的东西是大象腿，就像你的两条腿一样，走路用的。那个像蒲扇一样的是大象的耳朵。

    现在，大家都知道了大象是什么样的吗？

    “恩，基本知道了”，四个人齐声回答。

 

     我这里说的智者，就是facilitator , 起到的作用就像是润滑剂，他没有做什么，只是帮助大家达成了目标，促进大家都成功。改善了他们之间的沟通，平息了大家的争执。最终，引领大家达到了共同的目标。

 

     同样，在软件开发的场景下，也是一样的。A，B，C，D在软件开发过程的各个阶段，只熟悉自己的部分，缺乏沟通。

     在需求阶段，A信息最丰富，B信息了解很少，C，D基本没什么信息。

     在设计阶段，B信息逐渐丰富，他的信息得到验证，并产生反馈，D开始熟悉需求文档，C还是很少的信息。

     在开发阶段，C信息逐渐丰富，C的信息得到验证，并产生反馈。

     在测试阶段，D的信息得到验证，并产生反馈。

 

      信息的传递和流动是串行的，反馈路径长。如果有偏差，很有可能影响当前正在作的工作，好的结果是经过沟通后没问题，但浪费的是等待沟通结果的时间。更不好的结果就是，A，B，C，D一起返工。

 

      在软件开发这里，充当facilitator的一般就是PM，就是项目经理。PM在A作需求的时候，会说：“A，你把这两天了解到的需求和B，C，D沟通一下”。这样，在早期，就促进了A，B，C，D在理解上就有了共同的上下文，B，C，D也会提问，早期就对部分需求进行了验证。B理解了关键需求，开始思考设计。同时，C也开始对关键的技术进行技术预研，对技术接口进行联调。

 

      A也可以在有了初步需求之后，就召开联合需求讨论会，把客户，B，C，D拉在一起，一起讨论需求，让客户排定需求优先级，C可以估计开发成本。最终保证客户最关键的需求得到满足。

 

     B在早期，就可以召开联合设计讨论会，把A，C，D一起叫上，讨论初步设计，A可以验证关键需求是否满足，C可以确认有没有需要提前学习和熟悉的地方，D可以从可测性角度来审视B的设计。

 

     C在拿到B的设计说明书后，可以直接找到B，说他的实现思路，确认不会跑偏，方案可行。

 

     如果A，B，C都没有主动做这些，那就要求facilitator来促进他们做到。

 

      如果PM是一个Command-Control风格的管理人员，只会分配任务，这时，A，B，C，D的信息是不会自然流动的，也不会改变结果。

 

      如果PM不是，那A也可以充当facilitator的角色，使大家时刻 保持在一个上下文内。

 

     回到敏捷的范畴，如果是一个开放，氛围很好的团队，每个人都可以是一个facilitator。最合适担当的角色是ScrumMaster或者敏捷教练。

 

      改变现状的策略总结：

     1） 使每个PM都具备facilitator的能力。

     2） 使需求分析师具备facilitator的能力。

     3） 设立单独的ScrumMaster角色，独立承担facilitator的角色。

     4） 为团队指定敏捷教练，对开发过程进行指导和跟踪，培养facilitator。

 

     facilitator的几点关键要求：有大局观，温和，喜欢倾听，组织能力，语言表达能力，冲突解决，从多个角度看问题。

 

     盲人摸象之所以不成功，就是因为，其团队缺少了一个facilitator。