1704234561
同样，需要见过更复杂的流程，知道每一个环节是为了防止出什么状况，才能合理地简化。最后，设置了四个关键节点。这些节点是除了产品、技术、运营之外的其他关键团队成员也要一起参与的，已经没法再减了。
1704234562
1704234563
►立项会议： 确定项目目的——为什么、做什么（时间控制在半小时以内）。
1704234564
1704234565
►需求评审： 确定项目怎么做（对相对较小的项目，可以和立项会议合并，总体时间控制在2小时以内）。
1704234566
1704234567
►功能评审： 简单地讲，就是在测试环境下演示一下产品，以确定做出来的是不是团队要的（1小时左右搞定）。
1704234568
1704234569
►发布上线： 确定产品是不是用户想要的，以及用户还要什么。通过获取用户反馈来让产品的优化形成一个螺旋上升的闭环。
1704234570
1704234571
以上说的是主流程，还有两个常见的分支流程也简单提一下。
1704234572
1704234573
►需求变更 ：这在项目过程中不可避免，一开始可以简化成某个人拍板，决定是否接受变更。
1704234574
1704234575
►日常需求： 即零散、随机出现的小需求。开始只掌握一点，即所有需求必须经过产品经理，运营等角色不能直接找开发，确保产品经理知道所有的需求信息，以便统筹安排。
1704234576
1704234577
文档的简化
1704234578
1704234579
在项目开始阶段，文档只保留PRD、设计稿、代码三件套，其他文档，都用看板、白纸加上拍照留存来解决。既然看板可以代替很多文档的职能，接下来就看看其在项目中的实际应用。
1704234580
1704234581
看板实践
1704234582
1704234583
看板这种看起来很原始的线下手段，事实上在研发项目过程中特别好用。与在线软件相比，它最大的好处是，所有不时路过看板的人，只要抬头就能看到所有关键信息。
1704234584
1704234585
任务卡片
1704234586
1704234587
看板里经常用到的基本元素是任务卡片，它其实就是一张如图8-4所示的便签，上面一般会呈现几个关键信息。
1704234588
1704234589
1704234590
1704234591
1704234592
图8-4 本地化的任务卡片
1704234593
1704234594
►任务描述： 一般是一个词加一句话（如果一个词可以讲清楚，也可以不用一句话）。比如，前端可以写一张叫“Detail页面制作”的任务卡片，产品可以写一张叫“后台订单管理需求细化”的任务卡片。
1704234595
1704234596
►工时评估： 对于2～4周的项目，评估精确到1～4小时的粒度比较合理。如果一张任务卡片上的工作量超过8小时，则需要分拆。对工时的评估，一开始不准确很正常，通过每天的站立会议回顾和改进，很快就会越来越准。
1704234597
1704234598
► deadline： 写明日期即可，因为人人都信奉deadline是第一生产力。
1704234599
1704234600
►优先级： 任务越多就越需要重视和完善这个信息。
1704234601
1704234602
图8-4任务卡片的角部，还能看到三个很明显的小标志，这是我们团队的实用小创新。在一张任务卡片相应角部位置做出标记，就表示这一任务具有如下的特定属性，可用来提醒团队注意。
1704234603
1704234604
►左上角标： 表示此卡片的任务延期。少量的任务延期是正常的，也是允许的，但要进行监控。如果发现项目里有很多人出现大幅延期，则说明计划制订不合理，需要及时调整；如果只是个别人出现大幅延期，则更可能是个人问题，需要延期人自己加班赶上进度。团队要达成共识，让别人等、浪费别人时间是可耻的。
1704234605
1704234606
►右上角标： 表示突发任务。少量的突发任务也是正常且允许的，但如果有大量突发任务，则说明缺乏经验、计划不足，或者有“外力”经常干扰项目进程。
1704234607
1704234608
►左下角标： 表示持续任务，可以一直贴在看板的Doing（正在做的）任务列表里。比如，对产品经理来说，“处理用户反馈”就算一个持续任务。而非持续任务都应该从看板的Doing列表及早转移到Done（已完成的）任务列表。
1704234609
1704234610
►右下角标： 未定义的备用标记。团队在做项目的同时会不断优化项目流程，如有需要可以临时定义这个新的角标。