需求是否有用户问题或用户目标的支撑

 确认需求，评估制作时间，加入to_do文件
加入to_do文件的需求必须确认两个细节：

a.该需求是否清晰、具体，“感觉”类的需求一律不接，比如做成喜马拉雅感觉、做成魔戒中某个情节的感觉……

b.需求是否有用户问题或用户目标的支撑，可以是来源于线上数据分析的结论、可以是来源于电话回访之类的用户调查、可以是来源于竞品分析后的规则抽象。缺少的必须补充完成，否则不加入to_do文件。

确认无误后，评估需求的制作时间，如3天，然后加入to_do文件。

这里的3天仅是代表一个时间段，不是说从现在开始计时，3天后就要交付这个需求，因为你还得根据项目时间节点、需求本身重要性对文件中的所有待做需求进行优先级评估。

结合中间可能涉及测试验收，你需要在每个需求前后预留半天左右时间，最终确定时间计划表；有时我们还会遇到一些临时插入的紧急需求，就需要调整计划表，并将调整后的信息同步到位。

1.2 给doing文件设置极限值

doing文件的容量一般设为3天，代表我们处理问题的极限，超过这个极限需要等这个doing完成，再拖进来。这样做的目的是保证我们不会失控，能够聚焦当前任务，脚踏实地把每一件小事做好，累计起来就是了不起，大跃进带来的后果就是啥也做不成！

1.3 更新项目进度

已做完需求会进入项目开发，你需要每天更新项目的进展情况：什么时候进入开发、预计多久可以测试验收。验收过程中需要将问题、当前实现、预期效果列下来，并通知开发进行调整，调整通过之后，将需求拖至done文件。