关于需求管理之我见

人所知的是有限的，人所不知道的是无限的。 以无限打有限，输定的了，虽然可以通过话术妥善关系，但这个锅就是背定的了。

开发的时候，没有明确详细的需求清单与原型，就一个简单的大方向功能清单，是显而易见的被需求方（业务、领导、测试、客户）用无限打开发的有限

因为源头没有明确的详尽的需求清单与原型。领导习惯于说出一句话让你去悟、让你去分解、去自由发挥。这本来如果只是1on1也还好，就只满足一个人的就好了，但现在既要面对领导、又要面对领导下面的领导、又要面对不同的测试人员。这种需求没清单与没原型确认的情况就好糟心了。

我举个例子：

老大需要某个功能，他大概陈述需要的细节点有1、2、3

由于没专业产品与需求分析师

开发直接自已理解与设计与开发出来 基于1的衍生11 12 13 基于2衍生22 25 26 基于3的衍生 31 39

业务又根据自已的理解 基于1衍生 12 13 15 111 16 基于2衍生22 222 28 29 基于3的衍生31 32 33 34 36

这个时候业务他的认知相对于开发来说就是无限的， 再次着重提下这句话【人所知是有限的，人所不知道的是无限的】

所以才需要这个貌似制纣了老大与业务的需求详细清单与确认书，避免被业务与老大理所当然地认为这1、2、3、4、5、6等等需求不是显而易见是人都知道应该要有的功能吗？

希望业务与各位大佬看到这，要明白你觉得显而易见的问题就更应该提前列出来，否则就100%在开发这里会被忽略掉，因为你的认知对于开发来说属于无限。

要真是不能有这个详细清单，那就请明晰必然会存在你觉得很弱智但开发没开发出来的需求。

再重申且增强下这句话，人所知的有限的是为弱，人所不知道的无限的是为强

我们要守弱，要守着自已知道的有限这个弱。而不要被不知道的无限这个强所迷惑，再去达成自已的目的。

所以开发大可以放宽心。没有足够明细的需求清单、你100%是会被业务、被测试、被领导批判的了，因为他们在用无限打击你的有限。

相信自已，痛苦地做下去，提出整改，积极跟进，即使没效果，也要明晰锅是不是在你这里，这样才能更好地前行