今天是陶然的专访，主要讲解了基于本身企业，敏捷实施的问题和解决方案，对于正在实施敏捷的小伙伴可以有一个很好的参考，我们一起往下读。
陶然个人简介：
资格证书：ACP敏捷管理专业认证PMP项目管理专业认证工作经历：PMO；3年半SAP项目经验；7年项目管理经验；现任职于成都某大型知名消费金融公司；服务客户包括电网、政府及金融。01.解决问题到使用敏捷Q：陶老师，您好，非常感谢您在百忙之中接受我们《敏捷人CLUB》的专访，我们知道您是清晖的老学员了，并且您这在主导公司实施敏捷，对于敏捷相信您也一定有自己的见解，期待您的分享。
陶然：大家好，我叫陶然，感谢《敏捷人CLUB》提供的专访，让我有机会和大家一起分享交流，希望今天交流的内容，能够对大家有所帮助！Q：陶老师，您先给我们做一个自我介绍吧，关于您的职业情况和怎么接触到敏捷的？陶然：好的，我从毕业到现在一直是从事IT行业的，到现在大概是十年时间了。因为本身也是计算机专业，在大四的时候，和小伙伴一起创业，开了一家软件公司，当时是做软件外包，但那个时候，我们更多是为了生存，当时采取的就是模块化的方式，不断向我们的用户交付产品，但是我们那个时候还没有敏捷的概念，我们当时只是觉得这种方式可以让用户更快的看到我们在做些什么，知道我们的进度，他们可以了解这个项目的整体情况等。当时也是比较年轻，最后创业也是没有成功。大学毕业之后，我就从事了一个SAP的MM和WM的一个顾问工作，其实SAP这个软件的话，它其实就是一个模块化的东西，然后更多的是一种配置化的形式来进行使用，然后在做SAP的时候，我就慢慢从顾问转到了项目经理，然后慢慢接触了项目。在近10年的工作时间里，大部分时间服务客户主要是电力行业和政府行业，在最开始的时候，我们基本都是采用瀑布式的方式来进行交付，后来我们在实际的工作当中发现，用户的需求是不断的变化的，所以我们当时就没法按照PMBOK里面的管理方式照搬来管理，因为我们的客户非常强势，我们只有接受，并没有改变他的这种可能性，就导致一个问题，就是我们项目没法正常的进行交付。那这个时候我就在想，我们应该怎么来改变现状？我们应该怎么去减少因为客户需求变更导致项目的延期？在这个时候，我们就开始采取敏捷的方式进行项目的交付，我就和产品，研发，测试，包括我们对应的相关干系人，一起对项目的需求进行梳理，然后把我们所有模块全部切分清楚，就是我们的各业务功能模块化，然后按照各业务功能，各业务功能按照迭代的方式进行交付，然后才是每两周交付一个版本给客户使用，然后跟据他的意见，不断的改进。Q：了解，就是说我们需求这一块是用了敏捷的内容，其实整体的一个开发模式其实不是敏捷，是吗？陶然：我们有一部分是纯敏捷的这种方式，但是这部分很少，因为我们公司的文化氛围就已经决定了必须更多以瀑布式的方式进行，敏捷这块领导也想来推进，但是推动其实是一个比较难的过程。Q：能不能给我们举一个实际的例子呢？因为其实我听下来，我能理解概念，但是下放到项目里面，可能我还是不太理解咱们应用的敏捷的过程。陶然：首先，我就说现在我们做的项目，做的是一个贷款项目。其实用户他们并不是特别清楚，他们想要什么东西，如果我按照原有传统瀑布的方式来进行交付的话，就比较困难，因为我们时间很紧，整个的研发周期大概只有两个月时间，客户需求不明确的时候，我们就很害怕这个项目会失败，最后我们就采用了敏捷的方式。首先我们从需求开始，需求这块，我们的产品经理、项目经理，研发和调试人员，包括我们业务部门都一起参与了需求的讨论。从前端的进件，以及贷前贷中贷后的每一个环节，去了解他们的需求，他们具体想怎么来做，我们了解完需求之后，根据业务需求，我们自己出对应的一个原型设计，包括实施方案。最开始客户给我们的信息需求也很少，我们只能根据他的需求，然后在结合外面的类似产品的观察，来进行一个大概的设计，设计这块的话，我们就把些大的流程串起来，我们先按照模块化的方式，进行开发，比如说我们从最简单的从用户的登陆开始，然后到三要素验证、四要素验证，包括后面我们的授信、放款、还款等等每个流程，我们采取模块化的方式，然后由每个专业的研发小组来进行相关模块的功能研发，研发完了之后，通过一个初步的测试，做出来后给客户进行使用，我们整个研发部分的话，基本上是两周一个迭代。我们日常也会开对应的站会，时间也不长，5到8分钟，开会期间不会说具体的问题，只说昨天做了什么，今天做了什么，然后有什么问题。像我说的这个项目，周期大概两个月，我们用了一个半月左右的时间就研发完了，提前半个月进行对应的测试工作，完了之后，在进行UAT，UAT基本上也没什么太大问题。02.应用敏捷过程中的问题与解决方式Q：了解，咱们这个运行的过程中，有遇到过什么问题？陶然：我觉得问题还是有的，现在我们第一个问题就在于我们的项目范围，还有成本进度，三个变量的控制。我们做项目，内部也有对应的考核标准，其实我觉得从敏捷的角度来讲，如果你要做敏捷，那么我们项目的范围成本进度，这个东西是一定要是可协商的，为什么呢？因为第一从敏捷的角度讲，要随时可以接受技术的变更，然后我们必须对项目的进度进行对应的调整；第二、如果说我们发现这个项目进度不合理，我们需要对项目进度进行调整，然后要完成我们规划工作的内容的话，我们还需要对它的范围进行调整，就是说我们的范围，进度，成本，我们的三个变量，我们要有一个可变的，否则我们就没法往下执行，或者说我们没办法达到用户的需求。我们现在也是有对外的项目和对内的项目，像我们对外的项目，更多的是一种外包的合同性的方式，这种项目的期限和费用其实是固定死了的，开始签合同的时候，根本不会对一些详细的需求做很明确的了解，有时候很大的一个需求，可能一句话就代表了，如果是这样的方式的话，对推敏捷就是一个非常大的一个障碍，这是一个因素。第二个，其实就在于团队成员的管理，现在我们做敏捷，这个团队大概有7、8个人，有研发、测试、产品、项目经理。因为我们的研发人员资历普遍5年经验以上，他们其实更多习惯了一种瀑布式的开发方式，来对应工作的开展，他们不喜欢用自管理的方式来做项目。比如说，我告诉他要做什么，他就做什么，需求里面有些东西可能是有些问题的，但是他可能不会思考，他会是执行模式的，你说了我就做，你不说我就不做。所以团队成员管理方面的问题是，一、我们团队的每个人员对应的水平参差不齐；二、这个团队成员一定要有对应的责任心；三、要有对应的应变能力和学习能力；四、对于他们自已的思想要帮他们进行一个转变，所以，最主要的困难是在于团队成员的管理。第三点：变革怎么说呢？我觉得像传统瀑布这块的话，它其实并没有一个比较灵活的框架，不管是业务框架还是技术框架，它没有一个很灵活的框架来适应足够多的变化，其实我们在推敏捷的时候，也要去还技术债，我们在做项目过程当中，发现我整个技术架构、设计方式或理念有可能都会推翻或者重来。我觉得这三个是比较困难的点。Q：目前有什么好的解决办法吗？还是说其实我们现在是在慢慢的调解。陶然：刚提到的第一块内容，即关于项目的范围进度成本三个变量的产品这块，我们在给业务进行沟通的时候，一般要求甲方给我们一定的灵活空间，就比如说我们一般会在合同签订的时候，会要求我们的需求变更范围不能超过百分之多少，因为加钱是不现实的。内部层面，是要求项目经理一定要去深挖对应业务方的需求，看他真正想要什么内容，这样我们在做的过程中就会少走很多弯路。团队管理，我目前不定期的给成员进行一个宣讲灌输，关于为什么要做敏捷，怎么来做敏捷，我们按照什么方式来做等；然后第二个，我们会提高考核指标，考核指标会按照工作成果来进行考核；第三个是加强我们的团队建设，因为大家水平参差不齐，我们这边采取互帮互助，培训的方式来加强团队的凝聚力。第三点关于技术方面，我觉得这个债是没办法，肯定必须要还的，我们现在采取的方式是，我们尽量把原来很耦合的东西拆出来，让它不要有那么高的耦合度，然后该还的债还是要还。对我来讲，我觉得SAP就是一个非常好的软件，它就把所有东西都是模块化，耦合度都不高，各搞各的。我现在也是要求我们团队成员，不管做任何产品，做任何项目，都要按照这种思想来做。Q：项目时间会很紧嘛？因为债的问题其实很多是因为时间不够才会有的。陶然：我们最开始就会来考虑，在我们做需求或者做对应的详细设计的时候，我们就会去想，我们怎么来做能适应用户的各种变化。比如说举个例子，我们数据库的表结构怎么设计，然后后续怎么来做，我们就会去想这种问题，但是我们不可能一次性把问题想得特别全，我们只能说根据我们现有的一些经验，现在的一些发展，去做一个平衡，这是第一。第二个是我们在实际工作中，包括在研发过程中，我们发现某些部分是需要进行调整的，这样的情况我们会拉入到我们的一个迭代当中，但是我们的项目会分三个迭代或五个迭代，按这种方式，慢慢的去把债给还上，但时间会比较长。03.关于敏捷要着重注意什么？Q：了解了，听下来您目前的企业对于敏捷转型还是处在前期慢慢建设的过程中，那么您认为在整个的敏捷项目管理应用中，最重要的是什么？或者说哪一块我们可能是要着重去抓的。陶然：我觉得主要是两部分要抓，第一个在于我们团队成员的管理，第二个在于我们的技术变革。为什么这么说?因为针对于我们合同这块，其实你是有办法去解决的。第二，如果说真正的去推行敏捷，不是说自下往上推，一定是自上往下推的，那其实这个内容也是能解决的，只要领导人他能意识到这个问题。所以，我觉得最重要的还是人，你的人怎么来把你的敏捷的思想、方法落地，那就需要一个团队，那么团队怎么来做、怎么来管，怎么来激发他们的这种激情，怎么去激发他们的这种责任心，态度等就很重要。再就是我的技术的变革，我债要怎么还，什么时候还完，然后怎么来做。Q：你们对敏捷团队成员选择，有什么不同吗？陶然：最开始的话，我们是一个大部门，这个大部门大概有多号人，但是，当时我们并没有进行组内划分，我们都是按系统来的，我们有很多系统，每个系统都有对应的人来管。当时我们公司就做了一个变革，就按组来，比如说我们按照老核心业务组、核心业务所、数据组、平台组等，按照这种方式来进行管理，这就会涉及到人员的划分，我们就会选对这个系统比较熟的开发人员进入到我们这个团队，就是我们还是有一个选择的过程的。Q：了解，自己有选择成员的权利的话，相对来说敏捷团队会比直接上来一个好很多。陶老师有了解过DOF吗？陶然：我们的公司也在推，但是这部分是我们的研发和运维组在推，我了解的不是特别多。昨天我还在想，要不要报一个DOF的班，学习一下到底是怎么个玩法。我们公司的DOF，我觉得就是一个初级阶段，或者是在一个推动阶段，第一我们从管理来讲，我们现在采取了一个云平台的管理方式，运维方面，我们其实更多的是倾向于CICD这种方式，但这块的话，尤其测试这部分，我们现在其实并没有完全的去落地，并没有完全去推CICD这部分，并没有走自动化测试这些东西，其实这部分我们目前是落后的，所以，这块我也想去好好学习一下到底是怎么个玩法。Q：对于最近很火的业务敏捷或数据化转型，您怎么看？陶然：我知道像兴业银行、招商银行他们都在用敏捷，前段时间他们也在招人，要求还蛮高的，然后包括现在成都整个市场，因为我每年我都会看关于项目经理的岗位的要求，包括每个年底我都会去面试一下，虽然不跳槽，但都会去了解一下这个市场，我发现现在很多公司也在往这个方向走。不过我们公司会有一些限制，因为我们公司是消费金融，更多的会考虑合规的问题，和银行和电网一样的，不敢去冒险，不愿意尝试新的东西，除非使用很广泛了，才敢去用，因为一旦出问题影响很大。其实互联网公司倒可以这样来搞，他们和我们不一样，他们更多的是以科技为主导，是完全可以根据市场的变化，快速的变化，因为他们的成本也不是很高。Q：我理解下来，你们每一次变动成本应该都是很高的。陶然：对，比如说我们的需求变更，现在我们所有涉及到大的项目变更都会要求上会，参与的人员，包括领导，大BOSS都会来参加。每次的变动领导都会来提问，都会问到引起变动的根本性问题。其实领导问的问题都很刁钻，他们更多的是从合规、风险、审计的三个方面来考虑，因为站在他们的角度，是比较求稳的，他们并不想去做一些大的变革。Q：了解，陶老师可以给我们讲讲您关于敏捷的心得。陶然：第一、我觉得不管是瀑布还是敏捷，我们的核心都是要从客户的价值出发；第二、要以人为本；第三、我理解敏捷更多的是，需要一个具有一定适应性的、一定经验性的过程控制方法来做这个事情。另外还有两点，就是上面有提到的，怎么样进行对应的团队管理，团队管理一定要让团队学会自管理的方式，然后提高整体团队整体水平；另外，我们一定要考虑好，一定要具有适应变化的能力，这个说出来就是技术债的问题，我们要考虑如何用一个足够灵活的框架来适应我们对应的变化，其实平衡点很难把控，因为现在确实没有一个足够灵活的方式来适应，但是我们希望我们能做到。Q：了解，如果说让您用一句话来表达敏捷，您感觉什么表述是比较合适的？陶然：从客户价值出发，以人为核心的，处理复杂系统的具有对应的、适应性的、经验性的过程的控制方法。04.关于学习和服务Q：您这边是之前是在咱们清晖学的ACP、PMP是吗？陶然：是的，ACP是冯老师，冯老师讲课我觉得讲的还是挺好的，考点和干货都有，PMP是余老师，余老师的风格我个人比较喜欢，比较生动、活动型的。Q：那给我们清晖服务提点建议吧。陶然：总体结果我就不说了，当然是挺好的，包括班主任、老师等，我考试结果也非常好，尤其是我们的交流课，就像线下交流，论坛这种，我觉得是最好的。这些活动能学到很多，我觉得都是干货，之前有一堂课我印象特别深刻，那个讲课的老大哥，是我们整个金融行业IT里面很资深的人，他当时也在学ACP，分享出来的都是干货。就是为什么我ACP在清晖学，PMP也在清晖学的原因，后续我会在考虑PGMP。Q：我也很喜欢这种交流的形式，后续也考虑办线下活动，今年也是疫情的原因，线下办的很少，所以我们就安排了线上的交流，基本上是以讨论的形式来做的，因为我们的讲座太多了，讲课形式的讲座更适合前期打知识的基础，所以，为了让大家解决真正职场的问题，我们就想到了以大家交流的方式来办社群活动，就包括之前请到社群里面的一个经验比较丰富的一个成员孤寂，最近也是请到敏捷教练罗静等。我看您也有报名是吧？陶然：对，我报了名。Q：您也可以看一下大概的形式，提一些意见，咱们后续可以持续的改进，因为我们是想让大家多交流，然后学到的更多职场上实用的东西。陶然：是的，不管是培训还是什么方式，我觉得更多的还是需要交流，因为交流才能输出，只有被动接受使用起来可能不行，因为每家公司不一样，比如说，像我们这种以瀑布为主的公司，可能大家在推敏捷上会遇到很多共性的问题，我觉得这方面都可以拿出来进行讨论，然后形成一个操作方法，一个解决方案等，或者说形成一个探讨的方向。Q：对，我们也是这种考虑。陶老师给我们一些建议吧，不管是咱们下次的社群活动，还是说咱们