产品待办事项列表：从文档到讨论及需求渐进细化
在软件开发过程中，产品待办事项列表的管理以及需求的处理方式至关重要。以下将详细探讨从依赖文档转向注重讨论，以及需求渐进细化的相关内容。
从文档转向讨论
在软件开发中，存在一个误区，认为只要把需求写下来，用户就能得到他们想要的东西。但实际上，用户最多只能得到所写下来的内容，而这未必是他们真正想要的。书面文字具有误导性，看似精确，实则不然。
例如，我想举办一个为期三天的公开培训课程，和助理沟通后发邮件让她预订丹佛的凯悦酒店并提醒了日期。第二天她回复酒店已预订，我表示感谢后处理其他事务。大约一周后，她询问我接下来的安排，原来她所说的“酒店已预订”是指我们常用的房间已被占用，而我理解为她已按要求预订好了酒店。这就是一个书面交流易产生误解的例子，如果当时是面对面交流，我愉快的语气可能会让她察觉出我们的理解不一致。
除了容易产生误解外，书面文档还存在其他问题：
1.使人暂停判断：书面文档看起来正式、官方且完整，尤其是经过精心排版后。比如客户给我发的去乡村俱乐部开会的详细路线，其中一个左转的指示有误，但由于文档看起来很具体准确，我还是按照文档继续前行，结果错过了正确的路线。如果客户只是简单口头描述，可能就不会出现这样的问题。
2.缺乏意义迭代：在阅读需求文档时，对于一些具体的要求，如文件夹名称长度为 127 个字符，由于文档的性质，我们不太可能像在对话中那样去质疑。而在对话中，我们会通过不断询问来确保理解一致，但文档中缺少这种意义的迭代。
3.降低团队整体责任感：书面文档会导
