背景

2020 年疫情突发，突然的 offshore 办公模式。

让我一下子感觉回到了 10 年前，在日本工作时，与日美中三方开会的场景，offshore 的工作模式真的太费管理者了，那个年代，视频会议也没现在这么简单，没有钉钉，没有微信，每天感觉都在 Email 上浪费各种各样的时间。

10 年后，突然这样。

当时，我们采用 jira 来进行任务的管理，敏捷化的各个甬道，todo，doing，done。也会根据情况在 kanban 上贴各种小条。

我一般会把任务切分成 6-8 周的研发量，其中包括研发+测试。产品需求的时间我会要求产品团队单独评估与跟进。从 Idea 到实际落地，整体时间基本控制在 12 周内，如果遇到非常紧急的开发，我们要求 6 第一个版本采用 6 周上线的策略，用上线同步试错。

原来的方式

我自己喜欢采用 OmniPlan 进行整体的规划，jira+OmniPlan，每天晨会。但是对于整个团队的多条产品线的全盘情况，不仅我无法掌控，产品经理的负责人也无法掌控。虽然 jira 可以管控，虽然 gitlab 也有甬道，但是我发现敏捷化的管理太讲究“作战”这个扎堆的行动准则了，也是因为我的风格导致大家的沟通粘性很高，协作模式也变成了沟通密集型。

很多排期最初都是我帮助团队一起去拆分，然后大家落在自己的 jira 任务中，我会和产品负责人、测试、技术 leader 沟通好，自己管控一版基于 OmniPlan 的甘特图，重点项目我也会参与团队的晨会一起。

问题

团队组建不久，无法见面，很多隐藏在需要沟通才能 get 的情况如何解决？

排期与跟踪

排期之前是我画好后可以随时通过投屏 show 给大家，开发团队内也不是所有人都用 mac，OmniPlan 也不能好正每个人都可以维护。如果所有人都只看 jira 了，就会出现没有一个 High level 的计划书指引，以前都是我们采用 face to face 的沟通方式在 gantt 上直接确认。

offshore 的研发方式，最重要的是需要整个团队 share 一份计划书，这个计划一定是可以共享，可以同步编辑，并且还展示出所有的 WBS，或者从 WBS 到排期的拆分，这样也方便进行全盘的跟踪。

怎么办？

突发奇想

前几天的沟通交流太费劲了，虽然我们已经把钉钉用到了极致，但是对于任务的梳理，以及任务间的依赖，尤其是前后端同学，后端与大数据开发同学之间的牵连，在 offshore 的模式下增加了很大的沟通成本。寻求一个超级轻量级、有效、免费、甚至于不需要注册的管理工具迫在眉睫。

我突然又想到了 10 年前东渡的经历，那个时候我们经常会采用一个 Excel 文档，做一些基础的格式，不同国家的同事远程登录维护，Excel 文档打开可共享模式。

而现在腾讯和钉钉都有自己的在线文档，是否可以用 excel 做一个简单的 WBS 任务列表，让大家在线维护一份基于 excel 的简陋的进度表？通过这个文档，我们 online 把大家 join 到一起。

说干就干

从想法到画出表格，我用了 3 个小时，当天 push 给了大家，jira 成为了我们记录工时的工具，不曾想，这个非常简陋的表格 format，变成了我们一整年研发的管理工具。

大的表格结构

下图我们 2020 年 3 月，回到公司可以聚集办公后的一个大版本开发的管理文档，后续我们用这种方式跟踪了很多的产品研发，效果很好，虽然简陋，但有效。

细节

• 可以自动计算完成率

• 可以指明当日

• 可以设置一些目标计划

• 可以计算每周的完成情况

产品负责人、架构师、产品经理、研发、测试全都可以共享去看这个文档，也可以进行调整和修改

思考

这个文档用了非常久，但是 jira 也在用，二者也不矛盾。渐渐的，jira 变成了工时和 bug 统计的工具，看饱和度，看人员工作分布情况。

而这个文档，则成为了我把控每一个产品每一期迭代的小工具，产品负责人与产品经理也可以用它和开发沟通进度以及调整时间，大家反馈都很好。

所以，在一个 sprint 中，我们都关注什么？

我深入的思考了一段时间，因为我的团队其实经历过初期的 0-1 的建设；经历过各种新技术的研究；经历过在各个技术责任人都到位的情况下，在一个产品上不断迭代的过程。针对这三个不同的阶段，我定义为三种不同的团队类型

成长型团队

这个时候，团队还较为零散，还没组建完成，最大特点是职能缺失，比如后端兼顾了一些前端，产品兼顾了一些测试，数据开发和数仓开发可能是傻傻分不清楚的状态。这个时候，每个人都会关注自己的精力分配，一个人掰成两个用，一个 sprint 中，更多的人都在找自己的平衡点和边界，然后是和团队之间的边界。我们去排期一个任务的时候会发现，不是任务决定了人，而是一个人能揽下多重的担子，最后发现，sprint 中就 4 个人，每个人身上有杂七杂八好多事情。

研究型团队

任务是一个非常弹性的预研性质的工作，很难预估完成时间，如果遇到坑可能会战线拉的很长。所谓任务弹性，我们会持续关注 ROI，以及投入的角度与方法，是多个人多个任务多个角度的去研究，还是一个人多个任务的去不断尝试。

成熟团队

团队规模大，职能完备。在稳定的技术架构和选型基础上，进行快速熟练的迭代开发。这个时候，更多关注的是团队内部的协调、边界、范围以及依赖。举个例子，前后端的联调，虽然有各种好用工具的加持，但对于时间点的协调，总会出现小小的偏差，更多的时候靠研发点对点的沟通。

关注细节也要高瞻远瞩

三种团队，在三种不同的阶段，但都有一个共同点，即敏捷的管理思路，所有的安排、规划和追踪，都要 kanban 化，这样从底层打通沟通，方便所有的协调。但是，如果仅仅是割裂开的故事看板，任务小纸条，如何在成熟型团队研发的大规模开发中找到边界和依赖，甚至于如何找到最优化的排期呢？貌似敏捷化天生就很难做一个长期的的大型开发么？

其实不然，敏捷毕竟是一个文化与工作方式的抽象模型，我们可以结合瀑布与敏捷的优点来叠加的进行管理。瀑布讲究的是阶段流程的依赖以及详细的任务分解，敏捷可以把原来瀑布里面所有的阶段融合成一次 sprint，快速迭代。

实践过程中，很多敏捷就是把大瀑布切小了而已，原来做 10 个功能，产品->需求->研发->测试，一个轮回，需要 10 个月，现在先做 1 个功能，还是经历产品->需求->研发->测试，用 1 个月，美其名曰，敏捷。在我看，这个无伤大雅，只要符合企业气质、文化、能够最大限度交付价值，那就 OK，不需要照本宣科的 follow 什么。

但是，无论是瀑布还是敏捷，在我的实际经验中，我们都需要根据团队所处的不同阶段，给予他们一个“视角”，这个“视角”就是可以 zoom in 和 zoom out 的视角。既可以关注到自己的细碎的 task，也可以看清整个 sprint 的价值与目标，方便他们以主人翁的姿态来做事，更要在团队的不断成长工程中内部磨合出边界和依赖方式、协作方式，这些磨合都是在一个有效的体系上自主训练的过程。恰恰，这个 low 到爆的表格承载了团队从最初过度到成熟的全过程，也让大家自主的成长，最终精致协作起来。

好的团队是自驱的，也是自我学习自我训练的。