产品在安排需求的时候，经常会碰见需求消化速度慢，上线一再延期，如果你只会“怎么实现我不管””这个需求很简单”“明天上线！”会让场面十分尴尬，掌握必要的项目管理技巧是优秀产品经理需要具备的技能。在做产品汪之前，做过两年的项目，考了PMP证书，期间的经历对于之后的产品管理我认为是有一定帮助的，今天聊一点最干货最易上手的敏捷管理技巧——看板。
看板的英文是“Kanban”对，就是拼音……放下手里的西红柿！看板一词源于日本，先推荐一本书Kanban and Scrum - Making the Most of Both ，写的很不错，有想要的小伙伴可以留言找我要：）
言归正传，敏捷方法有时被称作轻量级方法,主要原因就在于它们不如传统方法那么规范。敏捷宣言的第一条就是“个体和交互胜过过程和工具”——人与人的沟通永远比工具有效。
敏捷中的Scrum 和看板都是过程工具，它们讲的是做哪些事情能够在一定程度上帮助你提高工作效率。Axure也是工具，它让设计更加简单。牙刷也是工具，它让你够得到牙齿，方便清洁。两个方法都各有约束，Scrum 的约束是固定时长的迭代和跨功能团队，看板的约束是要有可见的板（如上图），同时进行的任务数量（work in progress WIP 图中红色数字）要有限制。
先来看一下看板的实际流程是什么？
下面是一个标准的看板，已经提前分配好了WIP，任务安排最多同时2个，研发过程最多同时两个任务，部署最多同时一个任务。
到现在为止一切顺利，产品最多同时提出两个需求，项目经理和研发消化他们，解决之后部署或测试，再进行下一阶段，我们都想这么一直这么下去，顺利开发完成，迅速上线，但是……
这个情况在现实中很常见，研发人员本来可以开始新的任务研发，但是下一阶段的流程被卡死，出现了任务堆积，这时需要分出一部分人力去解决出现问题的流程，如果一味开发新的任务，会导致任务大量堆积在Develop环节，无法使项目最快速度向下推进。
这时候，产品汪们大概就坐不住了，联合研发技术环节一起解决问题，将栓结尽快打通，合力攻克难关之后，项目将会回归到正规，这种一起闯关打BOSS的快感对于团队的凝聚力和战斗力都是一种提升（项目\产品经理请客吃个饭犒劳一下大家是不错的选择哦）。
其次，看板有三个关键的“调整点”
1、 应该有哪几列？
每一列都代表一个状态，或是两个状态之间的（缓冲）队列。应该先从简单的to do、ongoing、Done开始，有特别需求的时候再增加
2、 上限（WIP）应该是多少
如果你的某一列已经到了看板上限，而你也没有任何事情可作，那就去找下游的瓶颈吧（也就是向右边找一下，看哪列里面有堆起来的卡片），找出来以后帮着把它干掉。如果找不到瓶颈，看板上限可能就太低了，因为设置上限的目的就是为了减少给下游瓶颈添乱的风险。
如果你发现有很多卡片安静地坐在某个地方没人动，也就意味着看板上限可能太高了。
• 太低的看板上限 => 发呆的人 => 低下的效率
• 太高的看板上限 => 发呆的任务 => 拖长实现周期
3、 限制到多严格？
有些团队把它当作军规（团队不能超过这个限额），有些团队把它当作指南，或是讨论触发器（上限是可以打破的，但对此应该有一个合理的解释，并就其发起讨论）。每个团队的消化能力是不一样的，想要有一个最佳的值，就一定要尝试，不要过于按部就班。
相信看过这个流程之后，各位朋友对于敏捷开发中的看板都有了一个大概的认识，可以在日常工作中观察或者尝试一下。最后，书里有一段，宫本武藏曾说过（17 世纪的著名武士，以二刀流闻名于世）：勿以器御心。 总之，不要沉迷于工具之中，人与人的沟通永远比工具有效。
