非典型敏捷管理

最近事情很多。其中一项重要的事情就是完成公司新的信息化系统的推广。

这个新的信息化系统被寄托着公司数字化转型的希望。被选定为公司的业务主线，承担着业务串联的核心作用。该系统产生，收集的数据会被作为主数据，用来完成公司各类系统的整合。

发起建设这个系统的单位最初的目的是为了解决自己的经营需要。但是总经理觉得这个系统可以推广到其他地区的分公司来管理这个领域的业务。于是一个比较尴尬的事情发生了，建设单位完全不知道怎么去向平级单位推广这个系统，因为这个系统推广后，一定会从平级单位手里抢走一大块汁多味美的肥肉。我作为公司的主管人员被指派领导这件事情，从公司管理层的角度去推广系统。

其实这件事情还有一个前序，3年前公司的CFO亲自带队到各地推广一个相同功能的系统结果失败。所以，从我接受的第一天开始，就不停的有人跟我说这件事情做不成，这件事情会失败。

我当时分析了一下面临的情况，

1. 我在7月份被通知要正式开始筹划这个项目，但是当时的项目预算没有批下来，需要等到8月份去申请；
2. 项目的一期建设工作没有完成，系统仍然存在不少bug；
3. 集团公司刚刚颁发了新的信息安全管理规则，系统建设的时候完全没有考虑过这部分；
4. 所属单位没有成熟的业务体系，也没有成熟的信息化管理体系；
5. 我需要在12月底完成基本的业务推广；
6. 我的项目组先期加上我只有3个人，而我们正在为一家典型的国企工作。

这一切看起来真的和大家说的都一样，似乎是一件不可能完成的工作。不过没关系，我相信一切都有可能。

首先，我一再地告诉项目组的核心成员，也就是一期项目建设的负责人，这件事情是能做到的，然后给她提供了一个非常简单粗陋的时间表，问她能不能做到，她觉得不可能，然后我跟他说，你告诉我按照这个时间表我们能做到什么程度，你给我列出来--这里，我尝试做了第一次非典型敏捷管理，我把目标、时间、大概地任务范围告诉了她，但是我需要她来帮我确认我们在一个PI(SAFe中的概念)能够完成工作，同时我开始隐蔽地开始激发她地自主性，我不需要她等待我的指示；

其次，我联系系统开发团队，一起研究并发完成6个分公司（后期做的时候，我把6个分公司合并成了4个）的推广的方案。这个开发团队来自国内一家知名的软件企业，但是当我开始研究系统的时候，我发现这个系统的设计简直太令人费解了，完全是按照我们公司建设单位一群不懂信息化的人的臆想拼凑出来的解决方案，很难想象这家企业怎么做到今天的程度。我接触的是第二任项目经理兼实施顾问。我们俩需要一起面对一个底子就很怪的系统。好在这个顾问能力不错，敲敲打打地把这个系统给搭建运行起来了。但是结果就是这个系统总有这样那样地意想不到的问题，所以我做了一个决定，我把推广地主导工作安排给了我的团队，这个开发团队只作为我们完成系统推广的工具来使用。

第三，我邀请总经理带头组建了核心指导委员会，请目标单位的负责人指派专门的推广对接人，这些推介人就成了项目实施组的成员，到这里我的团队有了7个成员，一个指导委员会，一个开发团队担任的推广工具包，以及一个包含4个业务经理的支援团。由于大多数成员都不坐在一起，他们也不是全职参与，他们只是从事这个生产业务相关的工作，对这个系统也都不是很了解，所以，我说这是一个非典型的敏捷团队。

接下来就是具体的推广过程，我不在这里细说，但是我要说一说我怎么组织和管理这只非典型的敏捷团队。

1. 在一开始的时候就定义好每个迭代的目标，同时将IT技术性强、业务规范相关的工作打包起来，脱离成员的工作范围，她们只要在遇到这些事情的时候上报就好。这样，他们在每个迭代里只要完成一种常规的管理工作就好了，而这些管理工作、流程优化工作能充分发挥他们的积极性以及创造性。从进入项目之初的坐等指导，抵触任务，到主动推进、积极参与，逐渐的有了敏捷团队的气象
2. 尊重每一位成员，给大家发言的机会，这在国企的环境中是比较难的，很多人习惯于听从领导的指挥，不愿意主动发言；领导们习惯于给出指示，不愿意听从员工的意见。我坚持做到了听从大家的意见，慢慢地所有的员工都开始主动发言，同时也敢指出我的错误--敲黑板，这个是多数在中国实行敏捷管理的团队做的不成功的原因。
3. 要提到的另一个非典型的地方就在于，我很难把所有的成员同时聚集在一起开每日站会，哪怕是远程语音会议都不成。所以我们用了微信群（后来改用了公司内部软件群）、较为频繁的局部会议、不定期的全员会议的方法来保证所有人都能及时知道其他人的进展，所有人都了解其他人的困难，所有人都愿意主动站出来帮助其他人。
4. 像我在另一篇文字里写的，我合理的安排好每个迭代内的工作量。这点在整个推广过程中非常重要，刚刚说过，我的成员不是全职在这件事情上，他们会接收到来自他们的直属领导分派来的工作，他们的工作效率，处理速度是很难精确预估的，所以，合理安排好每个迭代内的工作量，既要保证进度，又不能给成员太大的压力，这个就是很考验能力的地方。在整个过程中我们也计算失败过，这个时候的总结会就非常重要，我们不仅找到了原因，还借机解释了项目的目的、价值等，帮助一线的员工在思想上与我们保持一致。
5. 感谢在IBM的经历，当进入到10月下旬，我获得了两个新的核心实施组成员的加盟，让我有能力同步开动了四个项目小组，但是四个小组的绝大多数成员都是来自各个分公司的一线工作人员，他们习惯于听从指令，偶尔偷奸耍滑，想要绕开规则，持续发生重复错误。这个时候在IBM实践过的部落管理方法就起到了很大的作用，尤其是其中的专家团的概念（在不同的小组间共享领域专家），通过各个专家的串场、分享经验、每个小组都快速推进，而且基本上在其他小组中发生过的错误都会被避免或者快速解决，注意，这个时候我的核心团队就已经变成了SOS,
6. 因为公司里以前完全不错在敏捷管理的影子，因此在我决定采用敏捷管理的时候，是没有人能理解这个东西是什么的，所以整个过程中我只能担任一个PM + SM + PO的角色。

这个项目的规划是做到2022年的6月底，但是在2021年11月底，整个项目正式启动两个半月的时候，我们就基本上完成了核心业务的上线，解决了常规的业务逻辑问题，并且在每家分公司都建立了一支稳定的核心用户团队。到这个阶段，公司给推广工作提出的技术目标就已经基本上全部实现了，剩下的工作就是不断地改进系统，提高用户体验，同时增加系统覆盖面。

---

说一下这个项目为什么要用敏捷的方法来管理，也说明也一下我是怎么看待敏捷管理的。

首先，我来这家公司的时间不长，没有很好的人脉网络，在这么短的时间内让我独自制定详细的推广步骤，完成与人交流，处理好业务逻辑是不现实的。但是当我决定采用敏捷管理的方式激发每个成员（他们来的时间都比我长得多）的能动性，我就间接的拥有了一个很大的人脉网络，在沟通、协调、管理方面有了很大的便利性。

第二，敏捷管理不是仅适用于软件开发，我也用这个工具管理过运维，云迁移，市场开发等工作。我还在2017年到2018年用这个方法管理我个人的运动养生。

第三，我认为的敏捷管理是通过将大的工作块不断地拆解成小的模块，并按照固定的周期有计划的完成，期间要不断地停下来矫正方向，调整方法，创新提高。所有符合这个模式的工作都是敏捷。

第四，敏捷管理的核心一定不是看板和每日站会。

第五，敏捷管理是我见过的，用过的最好的一种梯队建设工具，不仅可以快速培养志同道合的合作者，而且可以实现组织的快速扩张。到今天，我已经基本上不怎么需要关注推广工作了，反倒可以开始回归我在公司内地正式工作当中去。