携程跨团队敏捷项目实战

以下是本人一个真实项目的经历，如有雷同纯属巧合。

2018年9月下旬，因同事离职临时接了一个项目，是公司内部各业务线对外提供服务IM工具的一个更新换代，目标是将之前各业务线自行开发的各种IM工具全部替换统一新研发的工具，同时将知识库平台迁移到公司最新的AI平台上。

讲故事前，把相关的项目背景稍微描述下，让各位看官了解。

1. 项目范围：接入业务线从大的讲有10多个业务线，有些业务线内部还有不同业务形态和服务场景的小业务；每个业务基本会分售前售后，还有给外部供应商用的平台。
2. 原有工具：app端大概有2~3个业务线自研的工具，还有微信群等外部工具；online端有独立的工具，H5也有独立的工具，还有自己的知识库。
3. 目标用户：用户1是公司所有终端用户，用户2是各业务线服务部门坐席，用户3是外部供应商。公司内部坐席加起来大概有几千的坐席，坐席服务解答客人问题的工具，有PC端、手机端；
4. 接入工作量：各业务线研发团队需要和我们研发团队对接，完成新IM工具的对接，且部分业务线因业务逻辑复杂需要自行维护分配分层逻辑。

接手项目后， 第一步肯定是了解项目背景和目标，了解过后第二步干嘛呢？熟悉项目团队。

经过几次会议，基本熟悉了项目组织架构，内部涉及6个team，从外到内分别是：

1. app端研发
2. app 服务端研发
3. 客服端研发
4. 知识库AI研发
5. 报表BI研发
6. 产品经理团队

几个team都有自己的垂直汇报领导（职能结构）

接手后发现困难是什么呢？

1. 有1个大业务线已经接入新IM工具，但一直生产灰度验证没有明确的开流量时间表；
2. 另有1个大业务线自己花了2年多时间开发的类似工具，用户使用也很习惯，要改动比较难；
3. 项目内部团队多，各团队开发进度等信息透明化程度不高，尤其联调阶段进度缓慢；
4. 项目阶段目标不够清晰，甚至有些团队成员并不了解；
5. 现成产品无法cover所有业务线的需求，很多业务线都有自己个性化的需求，很难统一，所以每接入一个业务线工作量都很不小。
6. 领导们对项目完成时间过于乐观（12月底完成全部业务线接入）。我接手时好像就接入了1家大业务线。要在3个月时间完成全部接入，难度非常大，项目组内部戏称“不可能完成的任务”。

针对这些项目背景、组织架构、已知问题，采取了以下措施：

1.针对架构， 引入大规模敏捷模式，我任项目SM，负责项目整体的里程碑进度及对外协调，重要问题的升级；

2.产品团队进入各开发team作为PO并兼任SM，负责条线产品需求及优先级安排，同时负责对BU的需求沟通，同时每个PO会负责一个大业务线的对接；

3.加强团队间沟通：做了“集中办公”“War room”“一起加班吃晚饭”等。还好这几个开发team基本都在一个楼层，沟通比较方便，然后我从其他楼层就搬到他们那边，一起办公。War room主要是为了占个小会议室，我们的日站会、临时会议都在这个War room；加班自然不可避免，每天和不同团队同学一起吃个晚饭顺便了解一些他们工作进展也对项目整体非常有帮助。

4.每日站会。除各开发team自己组织的站会外，大项目组每天都会站会，team leader和PO参加，站会除了review白板的重要事件外，主要就是各种问题的碰撞；当然作为SM需要把控会议，我们用了口哨、铃铛来应付大家大声乱讨论问题的情况。细节问题，一般是站会后，留下相关同学再行沟通，站会只需要明确问题的负责人及要求解决时间。

5.物理看板，我来维护。一般根据发布节奏2-3周一次看板，标明阶段目标、当前阶段的主要任务及里程碑事件。详细需求或任务会在各team的白板。每次迭代前启动会，根据阶段目标，分解任务到各team，尤其是一些需要互相联调的点，明确责任和时间点。各team领到任务后内部再行拆细。

6.会议：每个冲刺都有启动会和回顾会。启动会明确目标、团队进行扑克估算、分解任务，认领任务。回顾会：暴露问题，总结经验。

7.“虚拟专家组织”：因为涉及开发team比较多，在遇到一些技术问题，尤其是架构性问题时，需要有一些“专家判断”，所以组织了一个虚拟组织，每当有一些重大技术问题需要拍板时，由他们进来做分析判断。

8.先打一个有把握的胜仗。对于一个周期较长的项目，能取得阶段性的成绩并让大家看到，这对项目推动有积极的作用。我在接手项目后，第一时间和前面提到的“已上线但迟迟无法开流量”的大业务线取得沟通，非常幸运的是这个大业务线的联系人非常负责也很细心（当然也因为太细心提了很多问题，哈哈）。和这位联络人沟通后，我拿到了开流量前置问题的list，然后立马在内部召集各team开会一一过问题（记得大概是50多个问题），然后看下来这些问题都可以解决的。Sure，作为最高优先级处理。很快，一个迭代，这些问题都得到了解决。然后这个业务线在10月下旬开放了流量，打了第一个胜仗，也吹响了全面进攻的号角。

9.Checklist：综合之前项目的经验，我梳理了一个checklist（在confluence全团队可见可维护），标注了需要完成的业务线、对应联系人、计划上线时间、前置任务（比如知识库维护、分配逻辑联调、入口发布、AB分流配置、外部依赖项等）、流量开放任务，完成的事项就打上勾，没完成的会主动去push完成。这样一来，全团队对项目整体的状态、下一步方向都心里有数。

10.到一线用户中去。因为是一个偏业务产品的项目，实际用户的体验和反馈对我们尤其重要，所以我们要到一线去。除了去上海的服务部门职场外，我们还去了南通服务职场，和一线操作用户进行了面对面现场的沟通，了解他们的实操场景及诉求，对于我们了解需求、需求设计有了非常好的帮助。

11.借助外部或高层力量。这个项目可以算是公司级别，涉及全公司的服务部门，所以公司服务中心会有专人监督和支持我们项目，他们会定期召集BU和我们一起沟通问题、解决问题。有些我们搞不定或者认为不合理的问题，就会拉上他们一起和业务线协商，也感谢他们的支持。

12.抓大放小。我既是项目经理，也是大规模敏捷群的SM。因为这个项目过于庞大复杂，工期又紧。需要关注处理的事情非常多，如果作为大SM过于关注细节问题，自然你会漏掉一些重要事件。所以，你必须抓大放小（当然不是完全不管，而是授权给其他同学去负责）。作为敏捷群的大SM需要对项目有一个high level的总览思路，牢牢抓住为达成总目标服务的关键事件并去完成它。（实际上前面提到的checklist也有异曲同工）

最后，故事要讲完了，说下目前项目完成情况。截止18年12月底，目标范围的业务线全部完成接入，当然项目还没最终完成，因为新老工具的流量还在逐步切换，欲知后事如何，且听下回分解。