老生常谈之变动的需求
今天我啥也不想说，只想说说变动的需求。
Q：产品和开发最害怕的事情是什么？A：需求突然的变动。--以上仅针对我和我的同事们。以及，产品其实又分为需求方的产品、开发方的产品，我是开发方的产品。一般搞事情的都是需求方的产品（的领导）。
在成为产品的日子里，需求变动是十分频繁的事情。日常举栗子：某个明媚的早晨，客户告诉我他们领导想加一个模块。一整个模块，几乎没有任何规划，领导说要加，就要求开发这边马上动工开发，甚至有点期待明天就能上线这个功能 。后来这样的事情出现的频率渐渐变高， 我已经从一开始的大惊小怪、大呼小叫变成了现在的mmp了。
现在，如果需求有变动，我会怎么做？
需求分析
首先充分了解需求，分析需求的可行性，然后分析必要性。
可行且必要的时候和开发沟通实现的难点、时间长度。分析出来的结果，整理成需求规格说明书，可以单独作为一个文档，也可以在以前的需求规格说明书里添加。需求初稿出来了，时间来得及的情况下，可以准备一个原型（Axure、手绘、PPT）。以上材料一并发送给客户，请他们确认需求准确性以及原型。最终通过邮件的方式给相关的小伙伴、领导发送需求已经原型。截止到邮件这一步，应该好几天已经过去了~~
记录
记录是个好习惯，但是我没有！现在要养成记录的习惯。通过excel来记录，比较直观地记录每一次需求的变更。以下是我将记录的字段：时间、提出方、模块、描述、优先级、计划完成时间、完成情况。
归档
归档工作是非必选项，只是有强迫症才会做。我会按照项目来归类文件，但是项目做得时间长了，迭代的周期多了，文档也就会多很多，因此仅按照项目来划分文件以及不太够了。计划按照迭代的周期来划分。每个人整理的习惯不一致，这句话说完，脑子里旁白了一句：说的跟有人要来看似的。
后续：其实不是要写给谁看，就是鼓励想记录一下工作，想变成大腿！！
