这篇文章，我想分享最近处理需求时遇到的各种坑，也提醒自己不要重蹈覆辙。
周五，老林、老周、小麦和我们小组一起进行了一次电话会议，提出要在系统里增加一个共享文档的功能。这个任务指派给我，这是背景。
沟通不顺畅导致的重复工作
我刚到公司三个月，平时很多需求都是直接从老周那儿来的，老林和小麦是第一次对话。所以，在做需求分析时，我直接去找老周沟通需求背景和应用场景。这是我犯的第一个错，我以为老林、老周、小麦既然是一起提的需求，他们之间应该是对这个需求达成了共识。但是，当我将第一版需求定义文档反馈给相关人员时，老林指出我需求理解错误。后来不得不，重新制定方案。
不清楚每个人的岗位职责，导致沟通无效
我犯的第二个错误是，没有分清每个人的岗位职责和职位大小。职位大小决定了谁才是有话语权的人，当多个人一起提出需求时，职位最高的那个人才是需求的源头。老林是解决方案总监，需求是由他提出的，所以我的第一沟通对象应该是他。更为可取的办法是将他们三人一起拉个群讨论，获取具体的需求。
不清晰的deadline带来的严重后果
确定方案后，将需求定义文档发送给相关开发人员进行评估排期。涉及的开发人员有后台、前端，还有设计人员、切图人员等。考虑到这是公司内部的需求，起初并没有设定很明确的期限，导致的后果就是拖拖拖……过了半个月设计人员还没出图，领导怒了，直接通知我们10天以后上线。晕……
附：需求处理可参考的流程
- 确认需求背景
回答几个问题：给谁用、什么时候用、在什么场景下用、怎么用。结合场景和需求推导出应有的功能。 - 制定多个方案
根据功能制定至少制定A、B两个方案。然后查看常用的同类软件，取长补短放在自己的方案里。写清楚方案的优缺点。 - 与需求来源人员沟通确认最佳方案
- 将暂定的最佳方案发给相关开发，评估可行性与开发量。
- 正式邮件通知相关人员，并附上需求定义文档与详细的开发计划。涉及到的工作有：设计、切图、后台开发、前端开发。如果是来自项目上的需求，一定要先拿到现场的版本，因为现场的版本与公司服务器上的版本不一样，很可能你根据公司的版本制定的方案是完全错的。
- 编写功能测试用例与方案文档。
- 验收。接口与需求定义文档的要求是否符合；接口是否能完全满足终端的需求。
以上，笔拙请见谅。
初心：希望这个博客能成为我心中的理想王国，我会按照自己的想法慢慢打磨它。会分享所见、所思、所得。
————web前端业余爱好者、产品小白 ZhangMin献上