在供应链专家程晓华先生的博客《供应链管理中的“混蛋现象”》一文中看到一个场景描写:
去年我在一家公司做审核的时候,审到MPS(主生产计划)的管理流程,我指着最新版MPS问他的主计划员,这个MPS的制定依据是什么?他说,我其实是考虑了客户的库存、产线产能、产品的颜色搭配等等,然后做出这个MPS的。那我说很好啊,但是,譬如说就这个产品颜色吧,您在制定这版MPS的时候,具体的计算逻辑是什么?我说您能否证明给我看看?搞到最后,他也没有“按照他的逻辑”把那些数据“凑出来”,只是说了一句,反正我一直就是这么做的!也没出过啥事啊!
程晓华先生用这个案例说明供应链管理中“做了不说”的害处,其实类似的场景在IT需求调研的过程中也经常出现。常有业务方的需求者提出一些需求,如果你要挖掘这些需求背后的原因,他会像上面一个案例一样,给出类似一些含糊的原因,粗听下来很有道理,可是如果你再坚持深挖下去,比如要求定量的数据分析来支持其观点,几乎没有人能拿出数据支撑。也许定量分析对于国人的要求太高,但你退一步,要求其拿出一个具体的业务场景案例,通常你会得到如下结果:
1、拿不出具体的业务场景案例;
2、拿出的场景案例不能得出其要求的需求结论,其需求是案例的主观演绎结果或是其认为的解决方案,但推导过程有误,造成述说的需求其实偏离真正的业务场景;
3、需求人的演绎结果或解决方案其实只解决了真正问题的部分表现,而没有涵盖所有可能,或者解决方案非常复杂,最后都带来成本的大幅攀升,完全不值得;
4、需求其实可以用管理的手段在源头来解决,而不是演化成复杂的应用需求。
需求分析常见问题之五
上述四种可能的需求偏差必须通过需求的细节和深入挖掘才能发现,简单地接受需求或者浅层的挖掘都发现不了问题,最后带来巨大的损失。
用需求的细节来评判需求
发表于:2017-01-09
作者:网络转载
来源:
- 周排行
- 月排行
-   浅谈需求捕获的技术和方法
-   三步轻松做出靠谱需求分析
-   电信行业性能测试——需求分析
-   挖掘需求背后的隐式需求
-   你真的会需求分析吗?被遗忘的需求动...
-   需求管理之客户需求何时休?
-   IT项目需求分析的注意事项
-   需求分析——用HMW分析法需求
-   IT项目需求分析的注意事项
-   浅谈需求捕获的技术和方法
-   三步轻松做出靠谱需求分析
-   软件项目中,需求怎么做?
-   软件测试的生命周期&测试流程
-   关于“需求”的初步探索