关于需求文档落地、团队默契、责任问题的讨论

最近在项目中连续遇到两个相同的问题，原来以为口头已经说明的任务在验收时却出现了比较大的偏差。

     问题一：一个模块需要新增两个功能，但是新增功能对原有功能有影响，即交付时除新增功能外还需对原有功能进行修改以符合整个流程，结果交付时只做了新增功能，原来的功能没有修改，导致整个流程没法走通。

分析：这个需求经过前期的多次讨论，已经形成了较明确的解决方案，所以在定工作任务时并没有将对已有功能的影响写入文档或进行口头说明，最终导致理解出现偏差。原以为这是一个团队默契和开发经验的问题（即新功能对现有功能的影响也会一并修改），但是发现太自以为是了，任何需求最好还是通过明确、详细的文档进行确认，不能依靠组员的主动分析，主动找你沟通需求来解决。

     问题二：将一个跨系统的调用从跨数据库连接改为WCF服务。开发人员以前未接触过WCF服务，但有一个较完整的Demo可供借鉴，并给予了充足的时间和人力，但开发人员没有很好的控制进度，导致有所延后。

     分析：对技术不熟练，导致进度延后；对服务开发流程不熟练，导致流程不清（一般先写接口文档，再进行开发，实际流程却反过来了）。另外一个问题是没有对需求进行明确、详细的文档确认，需求是将现有业务转换成WCF服务，只需将数据拉取过来，后续业务流程暂时搁置不做，结果开发人员理解为后续流程也需完成，导致理解偏差 。

      结论：需求一定要通过文档进行明确、详细的说明并确认，并作为唯一的验收标准，不能依靠团队默契、开发经验、主动性去解决未明确的问题。