因为需求文档问题，项目组整个春节都在加班

项目开发中，文档撰写究竟有多重要？
昨天接到领导通知，支援隔壁兄弟项目组。同样是报表开发，他们人还比我们多。为啥还需要我们项目组支援呢？不问不知道，一问吓一跳。原来是需求分析这一关出了问题，用户测试时发现数据对不上，而今甚至连可复盘的需求文档都不完整。好家伙，难怪他们大过年的也在加班。

问题背景
在需求分析阶段，由于项目周期紧，BA（Business Analyst）在和用户沟通后，没有给出足够清晰的业务分析文档，甚至很多逻辑直接口述给开发人员。而项目到了后期，用户进行验收测试（UAT，Uaer Acceptance Test）时发现数据对不平。那咋办？检查项目代码，再次确认业务逻辑咯。而在此过程中一个很重要的依据就是需求分析文档，这记录了项目一半以上的工作。可惜需求文档并不完整，无法给项目复盘提供有力的支持。同时因为缺少文档，某些业务逻辑连BA自己都无法自圆其说。如此一来，BA要和用户重新确认需求并落实文档撰写，开发人员基于新的文档，好几处逻辑需要修改甚至重新开发。Deadline近在眼前，项目却面临推倒重来的风险？尽人事，听天命；项目组整个春节都在家加班。

BA、用户、开发铁三角
可能有小伙伴会问了。开发不是可以直接和用户沟通吗？当然可以。在和用户谈需求的时候，开发往往也要在场，技术和业务结合自然最好。但时间紧张的时候，就几乎只有BA和用户谈需求了。而且用户往往是国外友人，需求分析的第一关就面领着语言和业务的双重考验。同时由于金融领域的业务复杂性，为避免理解上的偏差，BA往往有着金融专业背景。作为一枚小开发，不得不说在此面临的窘境：我知道我的数据从哪里来，中间经过了怎么样的处理，最终存储到哪里去。但有时候我不知道为什么要这样处理，业务背后的意义又是什么。故而在和用户的沟通上，BA充当了一个重要的桥梁，让开发能够专注于业务的实现。专人专事，在这样一个年轻的团队，取得了不错的效果。

如何应对口述业务的场景？
不要嫌麻烦，把口述的内容形成文档，反复邮件确认，可以避免后续潜在的很多问题。这里突然想起去年的时候，也是因为项目周期紧，BA没有时间进行系统化的文档梳理。没办法，每次口述完业务，我都通过邮件进行二次确认，一个报表开发完后，形成了一串长长的邮件列表。虽然麻烦，但也为后面的复盘带来了很大的便利，有争议的地方也可以直接拉出邮件：“看吧，我是严格按需求文档来开发的！”

开发人员暂时不理解业务怎么办？
虽然了解了业务处理逻辑，但感觉还是没理解透怎么办？除了反复的请教、确认外，还有一个方法——数据流分析。作为一个软件工程专业的孩子，数据流分析法是我用的最顺手的策略之一了。项目周期紧没时间慢慢理解业务了？没关系！对于程序开发来讲，先理清楚以下三个问题就可以支撑起初期的业务实现了。

1. 数据从哪里来？呈现出什么样的格式？
2. 数据要经过什么样的处理？
3. 数据处理结果要到哪里去？

总结
工作场景中，远不止是需求分析，许多情况下都需要有书面的文档记录，此中的意义远不局限于复盘。