为什么我们做的不是客户需要的

近期发现了一些问题，只是其中一个故事。

2010年底，其他部门的同事T，发信来要求我们提供一个文件，但是当时这个项目是被暂停的状态，所以我们让最好T等到项目恢复，T答应了。2011年4月份，该项目重新启动，T又发信来要这个文件，并且提出了一个新需求，要把某个字段以新的格式打印。APO受到需求后，转发邮件给team，并和team讨论工期。team在panning meeting中将这个需求加入了sprint backlog。同事E做了开发，其他同事进行了检查测试，最后将文件发给T。

但是T反馈，他们提出的需求（以新格式打印字段）并没有实现，文件中依然是老的格式。

问题出在哪？

用5个why来分析：

为什么T的需求没能被满足？

因为E不知道T对格式的新需求

为什么E不知道T对格式的新需求?

应为邮件太长，E没有注意到这个需求

为什么其他组员没有注意到这个需求？

其实有人知道这个需求，但是没有发现E的misunderstanding

为什么组内的理解都有不一致，但大家却没有发现

因为没有流程能让这个问题暴漏出来

提高措施：

1. 邮件技巧：及时的总结是必要的。显示工作中经常遇到非常长的邮件讨论，最后看邮件的人，也许已经不知道其中的起源和细节了，所以转发邮件时，最好把提纲和主要细节higelight出来

2. 需求管理：对于内部同事提出的需求，为什不定义成user story？因为user story工具中有DoD（Definition of Done）和 CoS（condition of satisfaction）， DoD和CoS应该请stakeholder来review，以避免需求理解不一致或需求遗漏的情况再次发生。

所以下一次如果有内部的需求，也应该该走user story处理的流程，项目经理/需求分析师收集需求--》组内分析，定义DoD和CoS---》请需求发起人review CoS，请质量经理review DoD---》进入sprint backlog---》实现、测试---》交付