1704234611
1704234612
还可以灵活运用卡片的不同颜色。比如，我们团队有4种角色，正好对应4种颜色的卡片，这样可以让看板更加清晰。
1704234613
1704234614
看板应用
1704234615
1704234616
在日常工作中，一个完整的看板应该怎么应用呢？看一下如图8-5所示的看板，其横坐标是Todo（未开始的任务列表）、Doing和Done，纵坐标是各种团队角色。当时，团队每天下班前，也就是18:00开站立会议，大约持续15分钟，会上每个人只说三句话。第一句“今天做了什么”，说某个任务的同时指着看板上对应的任务卡片，如果任务完成，则把卡片从Doing一列拿到Done一列，如果延期了就涂上左上角标；第二句“明天打算做什么”，同时指着Todo一列的相应任务卡片，并把它拿到Doing一列；第三句“碰到什么困难、需要什么帮助”，与大家一起讨论，但不展开，具体的细节可以约着会后私聊。
1704234617
1704234618
而Todo里的便签，是平时每个人分解完任务后，随时贴进看板的。
1704234619
1704234620
实践中还根据需要确立了一些规则，比如团队里每个人都要轮值汇总周报，以及担任周会召集者。
1704234621
1704234622
通过以上项目流程的执行和看板的运用，一个10人左右团队、2～4周一次迭代的研发项目基本可以得到妥善和有效的管理。
1704234623
1704234624
1704234625
1704234626
1704234627
图8-5 本地化的看板
1704234628
1704234629
1704234630
1704234631
1704234632
人人都是产品经理2.0：写给泛产品经理 [:1704229238]
1704234633
人人都是产品经理2.0：写给泛产品经理 8.4 天下武功，唯快不破
1704234634
1704234635
每个产品都要通过不断的规划和迭代一步步成长，而互联网产品的特殊之处在于成长得格外快。几个月以内，就能亲历一个互联网产品“看他初乍到，看他起高楼，看他宴宾客，看他楼塌了”的全过程，这可比以“几十年”一个变化周期的传统行业刺激多了。
1704234636
1704234637
做产品，成功当然最好，但最差的不是失败，而是半死不活地一直拖着，其间的机会成本会大到很难负担得起。互联网产品追求快速，首先要强调研发周期的缩短和迭代频率的加快。因为迭代周期越短，同样时间段内获得的尝试次数越多，用来纠正和改进的机会也就越多。
1704234638
1704234639
下面，就让我们从速度的视角来体会一下这个“快生快死”的行业。
1704234640
1704234641
8.4.1 互联网速度到底有多快
1704234642
1704234643
在产品早期的验证阶段，团队灵活，流程简单，还没有太多的用户，最能体现出互联网速度。有的产品从发现问题或机会，到讨论出方案，再到上线，大约可以做到两三个小时，甚至不到一个小时。
1704234644
1704234645
给大家两个鲜活的小例子，第一个来自豆瓣。10多年以前的豆瓣，还是由创始人阿北一个人来写代码。如图8-6所示的这个帖子发布的时间是某个周日将近23点，跟帖的若干条讨论也就发生在几分钟内。阿北通过和用户紧密而及时地互动，在几分钟内就完成了对豆瓣页面这个小调整的一系列优化。
1704234646
1704234647
1704234648
1704234649
1704234650
图8-6 早期豆瓣的迭代速度[5]
1704234651
1704234652
第二个例子是互联网产品运营社群“三节课”贡献的，展示了产品和运营是如何配合完成一次快速响应的。
1704234653
1704234654
1704234655
1704234656
1704234657
2016.4.21 号，微信群里曝出一个很有意思的玩法——用户可以通过修改自己的名字、撤回已发出的消息等操作，在群里留下如图8-7所示的有意思的系统提示。
1704234658
1704234659
1704234660