如图所示，你看到的只是那1%甚至更少，只有不断的挖掘才能知道的更多
本次系统在迭代的时候，进入UAT阶段，由用户验收功能的时候，用户使用bug提交系统提交了一个bug，开发人员直接转给了我，我一看，这哪是bug呀，这是需求，于是赶紧电话确认，聊了半天，最后发现我们的问题是，业务人员以为这个功能是理所当然必然会有的，故未在需求上进行确认和指出，最后这个功能由于缺失，上线后也无法正常使用，得呢，得再继续优化并再继续完善
回首望去，类似的案例有很多，几乎每次都是相同的情况，业务总是说“我以为这个是肯定有的，这么简单的啊，还要提需求啊？”，“这个不是标准配置吗？没有这个功能我提这个需求干嘛呢？”
而我总是解释或争辩说，“不是，我们聊需求的时候不是这样说的”，“没有，你没有提就是新需求，最差也是个需求变更，如果是变更，就得往后排”
尤其是在系统还没有上线，在0到1的孵化过程中的时候，这样的案例比比皆是
我心力憔悴，他们心有怨言
现在看来，需求是没有做完的一天，所有的需求，都得分轻重缓急，而不同的角度，不同的角色，轻重缓急的看待又是不一样
受时间，资源限制，不可能对一个需求完完全全，透透彻彻了解清楚后，再开始进行开发，那样，每个需求可能对系统的改造都是推翻从来
所以我现在的做法是，在需求范围确定后
1、先嚼一遍需求
对每个需求先从产品的思维角度，对系统的影响程度，要修改的范围，要测试的点有个大概的度的把握。
再自己提问题给自己，为什么要这个需求，需求的出发点是什么，有没有更好的解决方案，对历史数据是否有影响等等，尽可能的问倒自己并记录下自己的问题和答案
通过大致的梳理后，会对这一版的需求有个大致的了解，整个过程不会很长，快则1至2个小时，慢则半天，期间可能还会和研发或测试的同学进行沟通，前端怎么实现简单又美观，后台现有数据是否满足，测试的逻辑梳理是否有漏洞。
整个流程梳理下来，研发主管及测试心里会有一个大概的底，并且在此过程中会给很多的建议和意见
2、和业务部门进行详聊
每次详聊，我们的业务同事已经知道我的套路，先问为什么要提出整个需求，需求的目的是什么，要解决的痛点是什么，你们希望的流程是什么样，再他们描述的过程中，我也会逐步的抛出我理需求时候遇到的问题，给出我的解决方案征求他们的意见
以前是我单打独斗，现在整个team人员较为充足，我会拉上我们的开发，研发主管一起旁听，从他们的角度去分析需求对系统的影响和提出他们的疑问
整个过程耗时会比较长，至少是3个小时左右的一个用户访谈时间
3、整理文档
和用户访谈结束后，我会用最快的速度，整理出需求文档，从需求目的，需求逻辑，和需求实现3个层面去描述需求
需求目的主要是回答为什么要这样做，这样做的好处，解决的问题等等一些比较宽泛的问题
需求逻辑主要是梳理整个需求的逻辑，对数据的修改的点，对历史数据的处理，需要测试的点，在这模块会罗列出很多逻辑性的文字，作为业务方需求确认的重要信息，以及开发人员，测试人员的开发和测试的出发点
需求实现主要是从图片上展示系统页面如何实现需求，有哪些按钮，有哪些列，有哪些字段展示，此作为和业务部门确认界面，开发同事照此研发
4、需求总结
文档整理后，会再花点时间和业务部门进行再次确认，确认文档中的逻辑内容无误，确认界面上展示的字段无误，也可能经历多次修改。带大家确认后，会进行归档，归档后，无大的逻辑变更的情况下，不再接受业务方的变更。我们会找时间再给研发的同事进行需求的具体讲解
其实需求的整理还有很多步骤，以上4步，是我经历过太多带血带肉撕裂的痛慢慢领悟总结出来并现在正在实施的一套方案
在产品的路上，我还是个小学生，还在不停的摸索，求学
望未来，更进一步