怎样的项目才能称为“成功项目”?
作者:鄒溪源,長沙資深互聯網從業者,架構師社區合伙人!
引子
這個故事講的是一家擁有百年歷史的制造業大廠的信息化轉型過程中的波折。這家企業擁有超過三萬名員工,它是某行業的領先品牌,但是在信息化程度上卻非常古老。
有許多人說,國企的項目都是坑,相當一部分項目都是為了騙經費而忽悠人的,換一撥管理層,基本上就得換一撥項目,油水全被領導撈走了。我很遺憾,沒能經歷這些事情。這個項目實打實都是做出來給基層用的項目,也確實獲得了各方較高的滿意度。
以中臺為政治正確的互聯網開發者們會說,這個項目從商業層面和技術上來說似乎毫無價值,首先它不是互聯網產品,其次它沒什么技術含量,什么大數據,云計算,容器,微服務,無服務,它都不需要,這甚至有點像我們身邊許多人十年前就做過的項目,技術上平淡無奇,看起來毫無挑戰。
顯然并非如此,每個項目存在都有價值。作為過程中的親歷者,我希望通過總結這個項目過程中存在的不足,引起思考和引發討論。尤其是隨著時代的進步,像這樣信息化轉型的傳統制造業企業,或許越來越罕見,這樣的項目看起來非常獨特,但也是軟件項目中的一個典型,對于未來從事行業互聯網開發的軟件從業人員來說,也許能帶來一些思考。
背景
2015年開始,制造業企業開始流行起一種新的趨勢:工業4.0,在這個大背景下,國內則提出了中國制造2025的計劃,旨在通過幾年努力,實現中國制造業的智能化水平在上一個臺階。
該大型國企作為該某領域的領先品牌,其生產的產品遠銷國內外,也是軍民融合的典型代表,但是在過去的發展過程中,由于產品本身比較特殊,許多關鍵步驟仍然是采用手工完成,無法完全實現自動化替代,包括檢驗管理體系也同樣建立在一大堆紙質表單的基礎上完成。集團管理層看到了中國制造2025帶來的巨大機遇,也想奮斗一波,但要做的事情實在是太多了。
康威定律說,一個組織的軟件架構設計,實際上是組織管理形式的體現。在9012年的今天,為了維持這樣一套以紙質表單為核心的檢驗管理體系,需要維持龐大的管理體系,帶來了巨大的管理成本,對于組織來說本身成為了一種巨大的負擔。更何況這種管理形式,問題實在是太多了。
1,需要花費大量的時間和精力來維持現有組織,哪怕是非關鍵崗位的離職,都可能影響一些流程的開展。(紙質資料的交接,其實跟口口相傳沒什么區別)。
2,過程資料存儲困難,為了存儲資料,更是需要專門安排檔案室和檔案保管員,一旦出現產品質量問題,需要進行問題追溯時,要從檔案中檢索問題要花許多時間。
3,一旦發生災害或事故,例如火災洪災,就意味著過程資料將成為廢紙,產品的關鍵過程信息將無法尋覓。
在互聯網技術飛速發展、實體經濟受到巨大沖擊的今天,原有管理模式,過于臃腫,已經無法適應組織發展的需要。行業越來越不景氣,企業的管理成本居高不下,負擔越來越重,每年裁員裁了許多人,卻沒能從管理效能上帶來多大的提高,因此提升企業的信息化管理水平其實勢在必行。
但是如果要實現一步到位,直接構建基于工業4.0的智能制造新體系,在這個行業都不太現實,畢竟許多產品都是屬于定制生產、小批次制造,部署全套自動化制造生產線成本非常高,事實上新生產線也在建設,但是一直沒有投產,老的生產線也得維持好,這樣才能持續創造價值。做好眼前能做的,實現檢驗管理的信息化(無紙化),然后再逐步實現制造業的智能化,只有實現了這一小步,才有未來的無限可能。
立項
之前提到中國制造2025的大背景,還有一個小背景。企業內部企業的中高層普遍都是八十年代末畢業擁有更高學歷的管理層,不乏清北的高才生。他們那些大學同學正是這一波大時代的受益者之一,有許多同學都借助于企業的騰飛實現了個人價值,但是留在這家國企的高管們,卻看著企業越來越差,也想有所作為,卻感覺一個拳頭打在了棉花上,他們的壓力很大。
然而,大家都清楚,傳統國企的體質僵化,很多時候看起來兩個字所謂“變革”,實際上卻有點像個美夢而已,就拿“信息化”系統建設來說吧,信息化對于國企來說并非第一次提起,許多國企的老員工,乃至管理層其實已經經歷了過去十年信息化失敗之苦,許多信息化系統在領導們的支持下,看似搞得轟轟烈烈,熱熱鬧鬧,但是最終都難逃被拋棄的下場,而每個信息化項目的失敗,都會讓好幾位負責對應信息管理工作的牽頭人背鍋,并最終從公司離開。
在IT從業人員看來或許很簡單的信息化建設,從來沒那么順順利利,極有可能會由于基層的抗拒最終失敗,并給信息化建設的參與者帶來職業生涯上的污點。
于是在國企把信息化提上議程之后,獲得了兩種不同的聲音。很戲劇性的,不懂信息化的業務部門是信息化的支持者,他們說這個事情一定要搞,砸鍋賣鐵都要上,再難也要上。另外一種負責信息化工作的信息中心的負責人對信息化的態度很明顯,要我支持,沒問題,我可以把網絡做好,但是要我參與軟件的研發過程,恕我無能為力。
因此最終牽頭組織這個過程資料信息化的,是平時對這一塊需求最大的檢驗管理部門。在他們的推動下,項目正式提上了議程。
這是個涉及面非常廣泛的項目集,包括了三個項目,分別是面向民用領域單一事業部的A項目,面向融合領域的B項目,以及面向整個集團全方向的C項目。事實上集團曾經購買過現成的產品,但是都沒能用起來,所以這個項目集最終是以定制開發的形式承包出來。
A項目
A項目作為最先立項的項目,萬事開頭難,承受了巨大的壓力,許多人在等著看一出好戲。
A項目的負責人W部長今年三十八歲,在此之前他一直是從事檢驗管理出身,對產品檢驗有自己明確的要求,他奠定了整個項目的基調。沒有設定特別宏大的目標,不是做一個通用的大系統,就做一個簡單實用的系統,能夠給基層帶來方便,為管理層帶來便利就夠了。
項目的早期,承建單位曾經試圖引入新技術和更加友好的用戶體驗,但是w部長卻不這么認為,他說在這樣的老國企,沒必要用新技術,一切以滿足可用性為目標,操作越簡單越好。于是最終承建方設計了一個基于cs的數據采集系統和基于bs的管理系統。不僅功能盡可能的簡單,而且連流程都能省就省,盡量讓參與者減少學習成本。
這個設計簡單實用的系統,恰好滿足了敏捷項目所要達到的構建簡單項目、實現快速迭代小步快走的管理目標。駐場開發期間,及時發現問題和解決問題,讓軟件得到了非常充分應用,獲得了甲方的高度評價。
而且如果說早期項目的應用的推進需要靠組織的強勢推動,到了后期就令人欣慰了,由于這個系統無需特別復雜的操作流程就能完成資料的錄入,提交和匯總,基層崗位的工作人員只要會用計算機、簡單培訓就能迅速上手,無形中為項目的快速鋪開奠定了良好的基礎。而且承建方與甲方的基層人員之間溝通融洽,有問題及時反饋,及時處理,為項目推進帶來了非常不錯的效果。
在項目運轉正常一年之后,主導項目工作的部長調任了,新接手的負責人是曾經不太看好這個系統的車間主任,他也被基層工作人員帶動,成為了這個項目的擁躉。
B項目
借著A項目成功的東風,馬上啟動了B項目。
前面提到了,B項目是面向融合產業的,因此對這個項目的要求也相對而言更高。
當這個項目完成立項后,B項目建設方的組織架構也發生了比較大的變更,首先是之前推動A項目的集團公司大領導由于工齡屆滿,已經退休,而集團的整個管理層都相繼發生了變化,包括推動項目立項的一位高級工程師也從公司離職,意味著項目早期干系人已經完全換了。
組織架構調整其實是為了給年輕人機會。調整后,B項目負責整個項目的,都是87后的年輕人。
這群年輕人們,相對于A項目的負責人來說,對信息化有了更加深入的認識。事實上而言,A項目建設,其實不過是一個類似于協同辦公的一個模塊,他們認為這個項目沒什么技術含量,甚至有點low。他們經常出去考察學習,對用戶體驗和功能應用都有很多想法,他們渴望真正打造一個能夠真正打造一個符合企業未來發展目標的信息化一體化平臺。
這些想法再跟現有政策、以及組織架構混合在一起發酵,最終變成了一個無比巨大的項目,用專業術語來說,就是一個“大泥球”系統。
在項目立項之初,合同上原始需求其實只有19個條目,而且為了讓這些內容容易落地,前期的推動者甚至盡可能的減少流程的復雜度,但是等合同簽訂后、組織結構調整完,新的干系人們在原合同的基礎上,對范圍進行了大幅修改。最終等需求調研落地,變成的是一個基本上涵蓋了公司大部分審批事項、涉及幾十個流程,涉及全公司數百人、超過十幾個小系統的大項目。
為了完成這個項目,雙方投入了最少20個人,超過十人的研發團隊駐場開發了超過半年時間,也沒折騰出幾個讓甲方滿意的東西。建設單位現場條件惡劣、涉及流程復雜、涉及特殊的管理機制,要開發的功能點特別多,不斷的完善,不斷的修改,整個項目研發前前后后折騰了至少一年時間之后,才通過直接負責人的認可,但是給領導匯報時,卻根本不可用,得推翻重做。
項目到今年項目依然沒有上線,這離合同交付日期已經超過兩年了,顯然可以稱之為“失敗項目”了。
承建方雖然早期意識到了項目風險,但是建設方過于強勢,無法拒絕;建設方貪多求快,忽略了組織本身的復雜性、低估了軟件研發的工作量以及軟件實施的難度,最終雙方都竹籃打水一場空。
C項目
C項目是在B項目完成了到一半時啟動的新項目,其目標是將A項目成功的經驗,推廣到全集團。(不包括B項目的事業部)。
C項目的實施異常順利,合同期一年,實際上只花了8個月就把項目做完了。
總結
當我年輕時曾經向其他擁有豐富經驗的項目經理請教什么樣的項目才是成功項目時,他們說:
“剛剛好”:剛剛好滿足客戶的需求,就是一個不錯的項目。
一個充滿智慧的回答。不過“剛剛好”其實很難把握這個度,我覺得一定是功能簡單、實用即可。
在這個故事中,那個最簡單實用,幾乎沒有什么技術含量的項目在組織中獲得了很大的成功,而一開始就打算做成全流程信息化的系統,最終卻一敗涂地。
這恰好就像我們經常見到的項目,簡單純粹的產品才能最先站穩腳跟、獲得不錯的用戶反響,那些一味畫餅的PPT項目,都是忽悠人,幾乎沒幾個成功了。
除此之外,每一個軟件行業從業者,越愛鉆研技術,越容易陷入技術的迷思,總以為靠技術能改變世界,仿佛一個項目沒用上什么新技術就容易就無法體現出自己的價值來。然而一個組織的技術體系,必須依托組織的實際組織架構而存在。再優秀超前的技術,脫離了土壤都是空中樓閣,永遠沒有最優秀的技術,能真正為組織帶來價值的技術,才是最合適的技術。
長按訂閱更多精彩▼
如有收獲,點個在看,誠摯感謝
創作挑戰賽新人創作獎勵來咯,堅持創作打卡瓜分現金大獎總結
以上是生活随笔為你收集整理的怎样的项目才能称为“成功项目”?的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 使用.NET Core创建Windows
- 下一篇: 深入Dapper.NET源码