终于能理解被频繁改需求的感受了
之前看过不少新闻帖子，程序狠狠抱怨产品频繁改需求，甚至有的产生了肢体冲突。看到这些信息的我当时就想，有这么严重吗？
直到我开始亲自开始做这件事情的时候，我现在非常理解前辈们的感受。在最开始的需求获取阶段，我找到的是考试中心的老师，他是在整个考试安排流程的根节点，我想当然的认为他应该是对整个流程最为了解而且不会有什么差错的老师，因而我没有去找其他老师获取需求*。考试中心的老师很详细地将重修过程描述给我们，我也很认真地听着。而后在纸上将系统各种模型草图做出来后，一鼓作气，一个重修系统的雏形基本成型了，此时有些细节还没有明确*，于是在微信上寥寥几句就将我需要的细节“完善了”，此时虽然有些模块类需要做出修改，但还在小修小补的范畴内。紧随其后，我将系统的第一个版本完成了。这时我想着拿真实数据测试一下，这时我傻眼了，数据的格式和我制定的角色模型并不完全一样，并且致命的是，原始数据缺乏系统程序中的一个关键依赖数据（教研室数据）。于是我赶紧去找相应教研室负责老师去获取信息，想着可以手动制作我所需要的信息，但是在和越来越多的老师交流后才意识到，考试中心的老师作为流程的根节点，可能并不了解整个流程树叶子节点的具体情况，我猜测他自己也没意识到这一点。这一次，因为关键数据缺失，我不得不对系统进行重构整个流程甚至数据库模型进行重写，TAT
最终，程序虽然在DDL之前完成了，但是有着太多不完善的地方，甚至有许多需求仍然不明确的地方，因为这些需求连用户也并不是很清楚的了解。因为程序进行了一次重构，我没有时间做到像乔布斯那样“用户也不知道自己需要什么，直到你的产品出现到他面前”。
学习到的东西
踩到的坑
- 当一个程序设计多方面，多个用户时，一定得在每一个角度，每一个角色做好充分的需求获取。
- 做需求分析的PM一定得是对编程非常熟悉的人，人的思维方式和机器的不同的，以人看来理所当然的东西对机器来说则不然。我在做需求分析时因没有以编程时的思维进行思考，因而错失了许多细节。这些缺失的细节在开始写代码时才发现。
- 需求获取以及各种模型一定要在开发阶段开始之前尽可能充分，重构是一件非常蛋疼的事情。
感受
理论和实践的差距是巨大的，在书上仿佛所有流程都能像一个个箭头一样顺顺利利地过去，实际操作时会遇到各种状况。最后引申一句在密码学书籍里看到的一句话：完美的理论因不完美的人类参与而无法实现完美的效果。