去年Q3接了个跨三个部门的ToB定制项目，一开始全员喊敏捷，最后差点把客户急到换供应商。
现在想起来都臊得慌。
最先踩的坑：把站会开成了周报念稿会
一开始照着网上抄的敏捷方法论要求，定死每天早上9点开15分钟站会，每个人轮流说昨天完成了什么、今天计划做什么、遇到了什么阻碍。
结果呢？开发的人说“昨天改了3个接口，今天改剩下的”，产品的人说“昨天跟客户对了需求，今天继续对”，运营的人说“昨天整理了反馈，今天整理更多反馈”。一开始觉得大家挺配合，直到有次站会开了40分钟，负责客户对接的小姑娘憋了快10分钟，才细声细气说，客户那边临时要加个多级审批流，没人敢接——大家都觉得这是产品的事，跟自己没关系。
那天站会散了我站在走廊抽烟，突然反应过来：我们把站会开成了没有感情的流水账播报台，谁都不敢把真正卡壳的事说出来，怕被别人觉得自己能力不行。
后来直接把站会规则改了：15分钟到点就散，每人只说三句话：我昨天卡在哪了，我今天要拉谁搭把手，哪件事等别人给我反馈。其他无关的废话不许说，说超时的人自己给全组买奶茶。
就这么个简单的规矩，原来藏了整整一周的跨部门对接问题，第二天站会就被抛出来，产品和开发当场就约了10分钟的小会对细节，没再拖过。
后来栽的跟头：把用户故事拆成了没人敢接的“大饼”
那会觉得敏捷要做颗粒度拆分，结果产品经理拆任务的时候，直接把整个项目拆成“完成客户后台搭建”“完成数据看板上线”这种大颗粒度的活，每个任务估时都是两周起步。谁拿到都犯怵。
开发组刚拿到任务的时候，第一天坐在工位上不知道从哪下手，过了三天问进度，说“还在搭框架”，离交付还有一周的时候，才发现数据看板的取数逻辑跟客户要的根本对不上，返工都来不及。
脸都烧了。那天跟客户开周会，对方的项目负责人直接问，你们说的敏捷，就是把活攒到最后一周才告诉我们做不对？
后来硬着头皮把所有大任务全部拆碎，定了个死规矩：所有拆出来的任务，必须能在1到2天内做完，做完就能拿出个能演示的东西，不能出那种要攒两周才见得到影的活。比如原来的“做数据看板”，拆成“把客户需要的3个核心指标的取数逻辑跟客户确认清楚”“把第一个指标的基础图表做出来给客户看效果”，每拆完一个，就找对应的负责人问“这个活你拿到手，明天能不能给我个初步结果？” 不行就接着拆。
就这么改了之后，每三天就能给客户发个小版本看效果，客户那边的信任度直接上来了，之前的投诉再也没出现过。
最容易被忽略的细节：协作的“缓冲带”从来不是靠喊出来的
一开始觉得敏捷就是要快，要把所有人的时间排得满满当当，谁都不许有空隙。结果有次负责前端的小伙子连续赶了三天的版本，第四天直接烧到39度请假，他手上对接的支付跳转页面没人接，整个项目进度硬生生卡了两天才补上。
那会才反应过来，我们之前对敏捷的理解完全错了——敏捷不是要大家像齿轮一样无缝衔接，人又不是机器，哪能永远不出故障？谁都有家里有事的时候，有临时被拉去开别的会的时候，有对着一个bug耗两三个小时改不出来的时候。
后来我们定了个规矩：每个任务的排期，都要留20%的缓冲时间，不许把日历填得连缝隙都没有。比如一个人一周5个工作日，最多排4天的活，剩下的1天用来处理突发问题，帮别人搭把手。而且每周五下午的复盘，不许上来就说“我这周效率很高，完成了所有任务”，要先说“我这周遇到了啥之前没预料到的问题，下次怎么提前避坑”。
上次那个发烧的前端小伙子，后来我们给他排任务的时候，每周都留了一天的缓冲，再遇到突发事，他手上的活根本不会卡，同组的人顺着他留的文档，10分钟就能接上进度。
前阵子跟那个之前拍桌子要换对接团队的客户吃饭，他说现在跟我们合作最省心的一点，是永远不会到节点了才收到一堆意料之外的坏消息。我碰了碰杯，没说什么。毕竟哪有什么天生顺畅的协作，都是当初踩过的坑，一个一个填出来的。
