我的本土客户敏捷项目BA体验

 

        以前做Dev时，觉得BA的工作十分专业，也十分有章可循。那是一个非local client的敏捷项目，我们的BA基本上是工作在Story级别的。

 

        准备一组需要和客户确认的stories，画好lofi。如果lofi画的好，和客户讨论的时候，就进行的十分顺畅。因为好的lofi既确定了这个story的scope，又将之前讨论得到的客户的想法形象具体的反应出来，那么，讨论的范围和对象就十分确定，讨论也就十分有效率。

 

        敏捷最讲究第一时间获得反馈。经过上述讨论过程，客户对BA的story分析作出确认，我们就拿到了我们想要的反馈。而在这个story从开始开发到完成，反馈中确认下来的东西基本都不会改变。这是因为，一方面因为，story的开发时间比较短，另一方面客户对着lofi作出决定时对自己的需求十分明确。而story完成后，又会及时的展示给客户看，我们叫做showcase，即使需求有变化，也可以在showcase时即使抓住，作出反应。

 

        这样，通过不断的及时反馈，不论是开发团队，还是客户，都可以将可能的浪费降到最低。

 

        然而，如果客户是“agile不合作”的呢？“agile不合作”的表现有：

        一、对lofi没有任何意见

        客户觉得，lofi只是一个界面的示意图，而看不到lofi应该承载的功能示意和范围示意的用途。所以，在他们看来，也就没有对着Lofi讨论的意义。

        若是可以面对面的交流，也许可以纠正客户对Lofi的认识，而做为一个分布式的项目，通过电话会议，双方在电话的两端对着同一份lofi设计，是无法达到预期效果的。

        二、不参与showcase

        showcase是story完成后获取客户反馈的最有效的途径。既然客户没有Lofi阶段的思考，那showcase的时候，也就没有参照对象。说的直接一点，就是，客户对做好的story，心中既没有肯定意见，也没有否定意见。既然如此，客户也认为，showcase没有意义，所以也就不参与了。

        三、不配合收集final users的反馈

        敏捷很厉害的一招就是迭代式交付。迭代式交付有两个非常重要的好处：让客户尽可能早的得到可运行的软件，优先实现客户认为最重要的部分；尽可能早的得到final user的反馈，因为发现问题越早，修改代价越少。而客户则认为，反馈即是批评，若系统不完善，是绝对不能让用户接触到的，否则，第一印象不好的话，以后哪怕再怎么逐步完善，这个系统也是曾经被人批评过的。

 

        其实，“agile不合作”并不能说是错的。在本土客户所理解所熟悉的开发模式下，他们认为：

        一、自顶向下的功能模块划分比story好理解

        我只知道，我要这样一块功能，至于你们分解成什么形式去做，为什么非要我来确认？

        二、你们应该比我更熟悉我们要什么

        不要问我具体要什么东西，我只知道我的目的和我需要的功能的大概描述，你们不是有领域专家么？给我点建议，我一定乐意采纳。

        三、UE设计完全是开发团队的事

        为什么拿着图来问我，是不是同意页面分成这样几个功能区？为什么要问我，是不是同意这样的设计风格？这不是我需要考虑的问题。

 

        这样一来，最初接触这个项目的时候，我找不到有效的工作方式。