今年负责一个老产品新团队，和几年前的指标组一样，现在的团队没有采用什么研发方法，于是我开始了团队的看板之旅。
12月22日给材价整个部门的产品研发相关人员做了一次kanban工作坊培训，
以及敏捷导入前的动员
第二天晚上，23日，我基于目前团队现状设计了一张看板卡片，样子如下图所示：
不熟悉的人看了这卡片估计也不知道如何用，所以我现在简单说一下这个卡片的设计。
看板卡片的设计
整个卡片基于敏捷中的故事卡片设计，简短的名称让团队马上知道要做什么，使用故事的写法“作为…，我想…，是为了…”来描述用户需求，在如何演示中写的是产品方案，完成定义是测试，其余的是重要性、估时等。
现在再次看看看板卡片
- 上部分：
- 圆圈：代表目标，简短文字表达用户需求
- 人：谁提出这个问题/需求的人，当需求完成时产品需求人员必须找这个人进行验收。尽量是外部用户，能保证需求来自于真实用户，而不是自己YY的
- 日历：卡片提出时间
- 中间左边：
- 左边上部分为故事描述方式，这里需要严格按照这个格式书写，虽然我知道没有哪个团队一开始能做好，例如把方案也写入了用户需求。
- 下方为演示和验收内容，这里的演示部分由需求人员填写，验收由测试人员填写
- 中间右边：
- 依据团队角色各自标记估计时间和实际完成时间
- 每个圆圈代表1个小时，如果估时为8小时，那就在第一排第8个圈上面给圆圈填充实心。实际完成时，使用划横线方式来看实际时间
- 如果出现任务过长，或者参与人员为多人并行，可以在对应角色右边贴上粉色小纸贴
- 下方：
- X：有些需求有最后期限要求，那就在这里填写，每日站会看板的时候需要关注这个时间来定当天开发策略
- +：把故事卡片从backlog挪入开发阶段的时间
- V：需求上线时间
- @：生产周期，上线时间和卡片进入研发时间的间隔，通过这个时间能看到我们的平滑交付能力。
- 星星：问题提出人验收后对此故事完成的满意度打分，保证用户不只是在调研阶段参与进来
看板设计
看板设计是基于研发价值链，我们的看板并没有什么特殊的地方，从左往右依次是：
- idea：任何提出的想法都可以贴在这里，我和团队说了，包括学习都可以，只要学习的确对我们产品有价值。如果整个部门都实施看板，我其实希望这里还有来自外部团队人员贴的卡片。此处不需要用前面设计的看板卡片，用黄纸贴就行，写清楚大意，留下姓名即可
- backlog池：产品需求人员从idea、用户、自身分析等各种途径收集过来的用户需求。从上往下，依据优先级排放
- backlog doing/done：使用前面介绍的看板卡片把产品backlog的用户需求进行细化。在需求人员从backlog池挪到这列的doing时需要和团队进行简单的交流，保证团队所有人员都认可需求的价值。在挪到done之后，剩余阶段人员对故事完成进行估时
- 设计 doing/done：UI、UE、开发的简单设计等工作
- 开发 doing/done：开发工作
- 测试 doing/done：测试工作
- 发布：灰度或正式上线
暴露的问题
看板和卡片设计完成就是开始填写。在填写之前，我给大家对上述内容进行了讲解，并重申了广材网今年工作重点，以及看板方法执行的决心。
为了让大家知道如何填写卡片，我特意举了一个例子。这是我前天自己在卡片上写的（卡片版本不是最新的，大家就看内容）
然后让大家来做
这时候大家的几个明显的问题出现了。
- 需求能力需要提升。
设计卡片时，我把“作为___，在____我想____是为了____”描述的空格留的都比较小，这个目的是让产品需求人员能够简化语言，明确用户需求是什么。负责写故事的人会说卡片设计太小了，根本写不下。我把空格设计的比较小是有原因的，只要真的把需求想好，一般都是能够写下的，如果不能写下，那么可以看看是否文字不够精简，或者是不是把需求方案也写入用户需求了。- 写看板卡片其实就是在做编写需求文档的工作，然而需求人员其实是需要具备较强的需求能力的，这包括需求获取、需求分析和需求设计工作，最后才是需求文档。例如上面的例子来说一下需求分析吧，找到最近的城市其实目前用户有两类需求，一类是只按照相对距离来找，还有一类是在优先省内再按距离。这两类需求要是经过分析，就会出现一个抽象的需求，查找周边城市。而具体的需求是具体的规则，这样设计的需求就容易被人理解，也容易扩展和实现。
- 当前需求面向的客户是谁？谁都知道是用户，所以如果在卡片上写”作为用户“就等于没写，至少你要把你的具体用户角色写上。然后不断的细化拆分成更具体的用户角色
- 在需求培训中，我会给大家一个简单的需求公式：需求=问题+场景+方案。而”在___”就是场景，看看例子中大家填写的是“在搜索材料时”，使用广材网的都是找材料，所以这个场景写了也和没写一样，这个时候必须让需求提出人去获取到底什么场景下需要这个需求，我想应该是“在没有找到本地材料时”才会有这个需求，那作为需求人员就应该明确写下来
- “是为了___”是用户要这个需求的目的，同样是前面的问题，如果写了就不能太笼统，一定要细化，否则写的都是产品的大帽子，那写了和没写一样。
- 认真填写故事部分，不仅可以帮助需求人员梳理需求，还可以作为与研发团队交流的重要交付物，因为需求的工作不只是产生需求而不管实现，你不仅要生了需求还要负责养活，提出需求之后还要去关注交付和运营需求，这就要求你必须有理由去说服开发心甘情愿的去做这个功能。
- 缺少与用户的互动
- 需求提出人上写的都是CPC，这是产品人员的姓名，并不是用户，也就是说这个需求不能追溯到哪个用户提出的
- 我严肃要求，以后这一栏不能填写自己，即使是自己分析出来的，这里要填写的也要是能给我们做验证的客户
- 然后正如前面”搜索“卡片上的，把“CPC”该为为了“分站”。我一样提出，这里的客户尽量是外部客户，毕竟我们后台能找到很多VIP用户，要找到用户其实还不是那么难
- 除了填写需求提出人之外，我还要求产品人员在填写这一栏时，要告之用户，等产品开发完成后参与验证，并打上满意度
- 开发和测试能力需要提升
- 开发对有些任务无法预估时间，说明在技术上我们还有很多无法有把握如何完成，这需要团队的搜索技术学习
- 测试在看板移入研发阶段后无法及时补充看板卡片的如何验收内容，说明测试需要了解敏捷的工作方式，尽早参与到需求阶段，以及如何快速的理解需求编写主测试用例
- 估时严重超时，不可能敏捷。
- 我设计的各阶段最多时间为8个圈，也就是2天，之所以这么设计是因为如果每个任务阶段时间工日超过2天，那一个故事基本要超过1周才能完成，这基本上做不到快速交付，就无法流动任务，那也就谈不上敏捷了
- 对搜索排序这个需求，问后发现这个需求说做了一个半月。有时确实存在大需求，那这个时候怎么办，一定要学会如何拆解需求，把大故事拆成小故事，这样才能保证有价值的需求能够快速交付
- 开发、测试估时也是一样，任务估时比我预期的也长
- 缺少基于产品的互动交流
- 团队以往的工作方式是基于任务，无法保证工作的投入
- 由于团队之前产品和开发的沟通交流不顺畅导致产品的完成不确定，氛围不好
- 我再次重申敏捷的学习更多在于团队的面对面的沟通，不仅仅是自身技能的学习，还有基于产品的客户学习
- 团队整体缺少承诺意识，跨部门缺少协作
- 有些任务工期明显很长，太长的交付能力会让用户觉得你的承诺不靠谱
- 敏捷要求我们对需求设定优先级，而不是统一对待所有需求，在人力有限情况下，我们更需要做有价值的需求。需求优先级的判定也是需要一些能力的。昨天在给全国分站培训上，有同事反馈一个下载报价单是乱码的问题，我问这个问题哪天反馈的。一问吓我一跳，已经提出一年了。会后我问了负责产品的同事，说是另一个部门的问题，但一直不解决。这个团队协作问题说到底还是大家对需求优先级的统一判断不一致导致。
- 敏捷推崇延迟决策，推迟承诺，当我们决定把backlog池拉入需求阶段时才代表你开始承诺去做了。这不是说我们不要过早承诺去做，我们要做到理性的承诺，否则给予太高的期望，但你都没时间去做，这样就会带来负面的影响。而如果你一旦把这个需求拉入到了研发工作中就代表你开始承诺去完成它，你就要投入精力专注的去兑现你的承诺。
看板是一种很好的敏捷方法，但推行敏捷需要依据团队能力来设计，目前来看，广材网暴露的问题还有很多，看板后续还会不断完善，推行看板中的另一些要素，也希望对看板感兴趣的团队一起来践行，因为我相信全部门来践行看板所带来的价值会更大。
