怎麼才能以通俗易懂的言語來闡述我要表達的東西呢?講故事?畫圖表?考慮半天也沒有好的方法,所以暫時就用這些生僻,晦澀和看似"專業"的字眼來說一遍我的各種觀點,以後再來各種潤色,現在不是流行迭代嗎?
傳統"軟件工程"中給出的大概流程順序是:
- 需求調研
- 詳細設計(數據庫設計)
- 編碼
- 測試
- 回饋
- 實施
不論從過去到現在衍生出多少方法論,其實在軟件行業大概都在遵循這一流程.
但是在這看似經典的線路流程指導下,90%的企業信息化過程都是失敗的!這個90%是我妄自推測出來的,你可以當作我是從某某醫院裏面出來的.
事實是,在這10多年的職業生涯裏面,見過無數的企業,見過無數*N的信息化系統,我還真心沒見過讓我一開口就能誇讚的,所以我妄拿了這個90%來下定論;剩下的10%是保留給那些我沒有見過的那些優秀的公司,人和信息化系統的.
(俺是真心願意學習那些優秀和成功的經驗,互相分享)
於是,基於我見過的無數失敗和其他不在這裏耗費文字的原因,來談談#企業信息化#這個經典僞命題,分享一下爲啥會是90%的產生!
------------------------------------------------------------------------
在我的觀點中,"軟件工程"的流程定義從開始就錯了:它的第一個流程環節是需求;而我的定義是在前面加上一個環節:"業務":
- 業務
- 需求
- 設計
- 編碼
- 測試
- 反饋
- 實施
我不是在這裏玩文字遊戲,因爲確實有很多人把需求等同於業務!
需求是啥:你去問A,B,C,D;TA們回答你甲,乙,丙,丁;一問一答,有問有答;收集一些紙質文檔或者電子郵件回來,統一整理成電子文檔發回給他們審覈,幾番交鋒後這就是需求了!
對嗎?不是嗎?然後就開始設計編碼了! 然後雙方無數次互相妥協,最後出來了一個互相將就的四不像.
如果多吃幾次飯,多喝幾次酒別人還會給你留點薄面;否則,"他媽的,他們做得是什麼東西,全是他媽的一坨si"
那些做出來才發現不是TA們想要的,各種改,時間無限期拖長,人員變動都是老生長談了.無意義
有幾個人敢說不是這麼做的?站出來!!!你是耍太極還是玩八卦?
業務是什麼:你先去坐在TA們旁邊看,然後自己坐在TA那個位置上把TA所在的事情全部多做幾遍,問出你所不理解,所不知道的所有問題,尋找答案;如果你問的問題對方也漸漸難以回答的時候,你就可以出師了!
這就是對基本業務的理解!
如果你只是搬張凳子做在旁邊看,問一些看似不明白的問題,這就是眼高手低!
假設一個企業的某個崗位需要換人,新人接上來需要幾天纔可以過渡過來???而那些搞需求調研的人員又在對應的崗位上呆了多久?你就真的是聰明到可以推測出未來了嗎?
雖然老是有人說要花1/3或者1/2的時間理清需求,但是可以依然毫不猶豫的說依然會失敗!
搞清需求和理解業務,不是名詞概念上的混淆和對比!而是完全的角度不同,態度不同,心態不同,結果自然完全不同
回過頭來,我們再從流程學上來看,如果你的開始環節都錯了,剩下的各個環節越順暢就越失敗,因爲你的方向錯了!
