今年项目的一个改进点好像走到了需求这里，曾经我们在做改进的时候，会说，最终用户离我们太远，我们对需求优先级排序没有话语权，用户需求到底要做成什么样我们没有办法确认。。。。找了一堆的理由，来说服我们自己，在做改进的时候，把需求推得远远的，但从前两年到今年，需求实例化还是一个概念，还是从《实例化需求》和TID大会上舟师傅的工作坊的一些零散的概念，到逐步引入到团队一点点去实践，再到今年被LTE反推着去更进一步做这些实践，一步步走来，会让我不断去反思。是的，那些我们认为的“借口”和“问题”真的存在吗？为什么今天，我们又会那么急切的想要在这里发力？究竟要解决的是谁的问题？什么问题？
- 找用户，找场景
- BA在做需求分析的时候，更容易把需求的波及影响评估清楚，尤其是对于项目周期特别长的大项目，这对于项目后期的新增需求对已有业务的质量和兼容性等评估非常重要。
- QA在做特性的测试方案设计和测试用例开发时，更容易从对整个系统全局的角度来评估出该新特性的引入，如何开保证高质量的交付，所波及到的用例有哪些。
- 开发人员在做需求的时候，可以很快速找到一些实现方案的具体业务逻辑，便于快速研讨出更合理的方案。且便于职责共享的团队的业务知识共享和知识传递，更关注于“如何做”的层面。
- 团队成员在对外支持的时候，可以根据这个业务知识体系，能够快速进行答疑，甚至可以提炼和抽象出一些典型场景的特性FAQ，便于团队做外场支持。尤其是，一个需要面向多产品线，多用户场景，多版本和补丁的项目来说，这一点对于后期的技术支持和问题定位尤其重要。
当用户和场景确定后，在后面的文章中，我们再继续探讨如何做？和做什么？以及谁来做的问题。
图片发自简书App
