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
1704234661
1704234662
图8-7 三节课的响应速度
1704234663
1704234664
对大多数微信用户来说，这只是一个有趣的小玩法罢了。但职业敏锐度让三节课团队意识到，完全可以趁着业内人士新鲜劲还在的时候，借势做点事情，让三节课从中受益。而达成这一目标的关键，就是响应速度。
1704234665
1704234666
下面，依次列出他们采取行动前后几个小时内发生的事情。