本文讲述了2014年研发管理部敏捷教练团队在平安一个创新银行产品项目中，指导引入全面敏捷实践、帮助产品在3个月内快速发布MVP的故事。本项目曾在《IT经理世界》（2014年11月刊）被作为封面报道。
“平安银行大厦14职场，一排排完全开放的办公桌，贴满了写有需求目录便签纸的墙面，以及每天早上八点半站成一圈紧张讨论的站立式会议，一切都让这个团队与众不同。
5月26日，这里迎来了一位特殊的客人-C行长，C行视察了直通银行项目团队敏捷实施情况，对敏捷及精益思想给予了高度的肯定”——摘自平安银行通讯稿
困难重重
时光回到2014年4月份。
我们接到一项教练指导邀请，平安银行正在启动一款创新银行产品的建设，在国内银行同业内，已经有2家银行发布了同类产品，我们需要与时间赛跑，尽快推出并且做得更好。
我们进场时，发现存在重重困难：
1. 业务已聘请某咨询公司规划了革新方案，但咨询公司只管战略规划，如何落地大家心里都没有底
2. IT技术方案存在不确定性，对于如何实现这一创新业务模式，技术实现方案还不能敲定
3. IT人力内外部比例悬殊，当时逐步到位开发团队有30人，但其中28个是外包人力！只有2个内部人力……1个作为PM管理项目，1个作为SA分析需求
4. 不论是IT还是业务，都涉及多方关联，其中多数系统关联都需要跨专业公司的对接合作
5.IT与业务之间为传统协作模式，习惯于相互制约、界定责任。业务很不高兴经常听到IT人员说“这个无法实现”，而IT人员要求业务完全细化需求文档，于是业务集中人力“拼命”写文档，业务自己都承认，文档细节都是“拍脑袋”出来的、未来不一定是这样
6. 上线时间已向高层承诺，作为一个全新的业务模式及产品，只有3个月的建设时间，时间非常紧张，压力很大
与业务的第一次亲密接触
当时的情况，除了由研发管理部派遣的项目经理，不管是IT方还是业务方的人员，对敏捷开发都没有概念。
IT内部的还好办，知识的传递和技能的培养可以直接安排，但如果希望全面导入敏捷变革、用一种崭新的合作方式来工作，与业务方（平安银行和平安科技是2家专业公司）的沟通就显得非常重要。
我们安排了与业务、IT方关键人员的第一次圆桌沟通，主要的沟通策略如下：
●关注业务的问题和感受，再收敛引导双方都觉得现状必须改变
a.强调双方的相互理解，例如
b.IT要理解业务，需求的细化是永无止境的过分细化没有意义；
c.业务也要理解IT，对于知识工作的工作量评估存在评估，IT可以逐步给出“信心指数”越来越强的估计和计划，但也要理解这不是绝对的承诺
●对于需求渐进明细、开发及早启动的做法，符合业务期望，但阐明对业务造成的影响和变化，例如：
a.业务需要对需求进行优先排序，明细范围可协商
b.业务人力需要有持续的投入
●以提升需求梳理效率作为切入点，明确的引导以下沟通方向：
a.揭示现行做法的风险
b.回到大家共同的目标
c.探讨怎么做才能尽快推进项目
沟通的结果挺理想。我们并没有主动提出要引入“敏捷开发”，沟通到后面，反而是业务方主动提出来：
“看来这样搞不下去，要不我们试试现在外面流行的敏捷开发模式？”
OK，那就卷袖子开干！（本资讯于2016-07-12首次发布）
