背景

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

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

10年后，突然这样。

2020年年初，我们采用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到爆的表格承载了团队从最初过度到成熟的全过程，也让大家自主的成长，最终精致协作起来。

团队内部

我看到过很多技术管理者的常态，都是高级的管理者，从总监到架构师，大家最喜欢问的一句话，排期定了么？给我一个排期吧。但是当排期给到的时候他们只关注end date和人效，因为这两点最能体现在最终的数字上，当然，本质上这没问题，这两点也是point。

但，这是很多在做数字化转型和伪数字化的团队常常容易触犯的一个大忌，因为大家最终变成了“面向好看的数字结果”来执行的数字加工团队，这句话，大家好好理解下。

无论是CMMI、瀑布式、PMP，这么多年大家不断的在对过程进行各种调优，但是一个敏捷ACP貌似直接给了大家一个可以回到远古去犯懒的理由，这是不正确的。

专家 黏性 沟通

敏捷是一种模型和文化，是构建在专家团队基础上的强黏性的沟通与研发模型，这句话大家找几个关键词。专家团队、强黏着性、沟通，是的，这些一定是基础，就像我在构建团队的时候，我首先让团队的沟通变得黏性化，不用via文档，不垮职能，团队中前后端数据测试产品一应俱全，采购电视大屏，进行kanban早会，对团队进行不断的改进，然后进行技术培训与分享，不断让大家做提升。整个过程我都是在打造一个敏捷团队的基础。

而这2020年的这次疫情，让我体会到这三驾马车中，沟通的重要性与脆弱性。因为敏捷太讲究这种原地沟通方式了，或者说我们经历的很多培训也是这么告诉我们的。

但在我看，其实敏捷中沟通的本质是，让所有人在一个sprint中不仅找到自己的“故事”，也要能理解其他人的“故事”，并且明确这次sprint的“故事”，最终找到自己的“故事”与其他人“故事”的连结点，从而看清整个sprint的结构。

我们拆分颗粒度，小步迭代，不都是希望团队能更加容易的理解目标和自驱的在一次sprint中发挥最大主观能动性么？而这个小小的工具又让团队内部“在线”的找到了“故事”梗概，自我寻找联结，自我调节依赖关系，而且最重要的是，可以“敏捷”化的调整安排。A和B的工作依赖，在文档上3-5分钟就可以调整完毕，按照这个调整的计划双方协作，管理者control，开发完毕还可以回放过程来复盘，一举多得。

总结

一个小小的工具，体现出来团队内部协作的各种细节、边界、自我协调与成长。和教育孩子一样，好的管理者不仅要结果，也更要去帮助团队成长，和他们一同成长。发现问题，用自己的经验和前瞻性验证试错，从而不断解决问题。

大多数结果还是由过程所决定的，管理是“管”与“理”的组合。