怎么才能以通俗易懂的言语来阐述我要表达的东西呢?讲故事?画图表?考虑半天也没有好的方法,所以暂时就用这些生僻,晦涩和看似"专业"的字眼来说一遍我的各种观点,以后再来各种润色,现在不是流行迭代吗?
传统"软件工程"中给出的大概流程顺序是:
- 需求调研
- 详细设计(数据库设计)
- 编码
- 测试
- 回馈
- 实施
不论从过去到现在衍生出多少方法论,其实在软件行业大概都在遵循这一流程.
但是在这看似经典的线路流程指导下,90%的企业信息化过程都是失败的!这个90%是我妄自推测出来的,你可以当作我是从某某医院里面出来的.
事实是,在这10多年的职业生涯里面,见过无数的企业,见过无数*N的信息化系统,我还真心没见过让我一开口就能夸赞的,所以我妄拿了这个90%来下定论;剩下的10%是保留给那些我没有见过的那些优秀的公司,人和信息化系统的.
(俺是真心愿意学习那些优秀和成功的经验,互相分享)
于是,基于我见过的无数失败和其他不在这里耗费文字的原因,来谈谈#企业信息化#这个经典伪命题,分享一下为啥会是90%的产生!
------------------------------------------------------------------------
在我的观点中,
"软件工程"的流程定义从开始就错了:它的第一个流程环节是需求;而我的定义是在前面加上一个环节:"业务":
- 业务
- 需求
- 设计
- 编码
- 测试
- 反馈
- 实施
我不是在这里玩文字游戏,因为确实有很多人把需求等同于业务!
需求是啥:你去问A,B,C,D;TA们回答你甲,乙,丙,丁;一问一答,有问有答;收集一些纸质文档或者电子邮件回来,统一整理成电子文档发回给他们审核,几番交锋后这就是需求了!
对吗?不是吗?然后就开始设计编码了! 然后双方无数次互相妥协,最后出来了一个互相将就的四不像.
如果多吃几次饭,多喝几次酒别人还会给你留点薄面;否则,"他妈的,他们做得是什么东西,全是他妈的一坨si"
那些做出来才发现不是TA们想要的,各种改,时间无限期拖长,人员变动都是老生长谈了.无意义
有几个人敢说不是这么做的?站出来!!!你是耍太极还是玩八卦?
业务是什么:你先去坐在TA们旁边看,然后自己坐在TA那个位置上把TA所在的事情全部多做几遍,问出你所不理解,所不知道的所有问题,寻找答案;如果你问的问题对方也渐渐难以回答的时候,你就可以出师了!
这就是对基本业务的理解!
如果你只是搬张凳子做在旁边看,问一些看似不明白的问题,这就是眼高手低!
假设一个企业的某个岗位需要换人,新人接上来需要几天才可以过渡过来???而那些搞需求调研的人员又在对应的岗位上呆了多久?你就真的是聪明到可以推测出未来了吗?
虽然老是有人说要花1/3或者1/2的时间理清需求,但是可以依然毫不犹豫的说依然会失败!
搞清需求和理解业务,不是名词概念上的混淆和对比!而是完全的角度不同,态度不同,心态不同,结果自然完全不同
回过头来,我们再从流程学上来看,如果你的开始环节都错了,剩下的各个环节越顺畅就越失败,因为你的方向错了!
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
