記一個失敗的專案

由於溝通不暢等自身原因,我從一個大公司換到一個不知名的小公司.在這兒負責一個新專案的架構設計.這個公司由於市場定位準確,使用者介面美觀,易用,能方便快速的檢視網路的資訊,解決管理的複雜性,等優勢,在市場上佔有一席之地.

我的優點是對需求分析和架構設計的方法和系統建模流程比較瞭解,缺點是對這個領域的業務規則其實並不是很熟悉,而這個系統的架構設計其實已經由現在的專案經理做過一次,但是領導們總是感覺少了些什麼,軟體需求也是,其實專案經理已經做過一次,但是領導們還是感覺和他們的想法不一致.其實這裡就已經埋下了伏筆,他們到底覺得什麼可以是專案可以接受的提交點呢,好象沒人能說清楚.

這個公司的特點是老員工都是程式設計高手,但是由於原來規模很小,屬於20個人左右開始做大的,關於架構設計和需求等理論知識相對較弱,新來的領導們都是大公司裡的技術骨幹,屬於追求技術完美型別.

這個公司原來也的確有些比如把資料寫死到程式等大公司的DesignRule比較反對,造成維護困難等不是錯誤的需要提高的技術改進點.所以大家都報著美好的願望開始,希望能在這個專案裡解決問題.

但是一進入專案,發現自己理解的架構設計和他們完全不是一回事.我理解的是可行性分析加上UML的4加1檢視, 可行性裡面其實是希望業務需求達到80%的清晰.這個專案由於規劃不當,其實是需求和架構

同時進行的,在評審需求時大家越想越多,想到了怎麼做等等問題,唯一不去想這些需求到底要多少人力,哪些技術實現.

以至3個月後老闆說這個需求還是屬於業務需求,要重寫一份軟體需求.

在做這個架構設計時,業務檢視由於需求太大,遲遲不定無法完成,邏輯和元件檢視基本到是定了,大家對錶達方式都很不習慣,後來發現這是由於大家對UML的檢視元素不夠理解,又講了幾次,這個似乎和他們的想法還是不一致,他們比較習慣於行業的用語和C#的技術,而我比較熟悉JAVA的技術和uml元素.於是大家又花了很多時間討論.基本達到了一致,勉強通過.

到了實現檢視和部署檢視就更麻煩了,裡面涉及到了技術選型,我推薦的J2EE(JBOSS)技術大家還是不瞭解,反而覺得原來的C#簡單.本來這也不成問題,但是領導又要求支援叢集技術,最後這個技術風險也成了最終的問題,以致沒有人能實現得了.

想來從簡單到複雜,從複雜到簡單的分析方式還是很重要的.一個目標再好如果實現不了,就要堅決砍掉或推遲,不要把概念化階段的文件當成專案的最終目標,否則,在前景不明的專案中,失敗的風險高達1/3-1/2.

這個專案另外一個問題就是領導團隊分工不明確,每個人都要發表自己的意見,只知道說什麼不好,卻拿不出一個模板,導致大家對架構設計和需求裡到底要包含哪些內容,什麼樣子就可以驗收,文件的結束標準不清楚,review時老闆都不參加,然後專案經理單獨組織一次又一次的評審會後,又增加一些新內容,比如雲端計算,比如叢集,最後真正變成了空想.其實這些東西雖然好但是並不是我們根本和馬上要做的內容,這樣反覆了4次後,文件增加和修改到60頁,卻發現和他們的想法還是差距很大,那麼他們想要什麼呢,還是不清楚.

於是又組織概要設計,又是4個幾十頁的文件,大家都按照自己的喜好去設計了,好象也沒看出什麼問題,卻還是不知該怎麼做.
這樣過了4個月,感覺拖下去不是辦法.另外換了一個人做專案管理和架構設計,又寫了一些文件.
於是開始組織開發,一個回合下來,做出一個可以執行的產品,領導說你們沒有解決根本的問題嘛.修改一次還是不能達到領導的目標,最後下面的人一大半都離開了,餘下的人也去做其它專案了.這個專案基本就廢棄了.

這次聽了IBM的開發會議,還是很有感觸的.
架構是一個逐步求精的過程,我們要不斷修正,包括需求,最好從瞭解核心需要解決的問題和使用者使用的場景開始,儘量小型化和把風險列出,Just Enough,一開始不要追求技術的完美,等大家都清楚了我們要的是什麼後,再逐步求精.架構是需要原型驗證的,以求證技術上可行和讓大家從一個簡單的架構開始學習和能力提高.

這個專案經理是個老員工,是一個技術專家型的員工,卻比較缺乏專案管理的能力,對專案的範圍管理,溝通管理,時間管理,成本管理,風險管理知識瞭解不夠,決策層也普遍屬於技術型,不夠了解專案管理的要素,產品的市場需求,決策知識和如何劃分重點.

還有一個問題,就是領導到底應不應當是技術專家?很多大公司裡面技術專家和領導職位是分而規劃的,而小公司往往期望其合二為一,當然這樣有決策效率高,成本低的好處.但是其實所有的人都不是完人,都有自身的侷限.領導過分干預技術決策的話,會導致員工失去方向,無法發揮主觀能動性,而領導也由於糾結於細節,失去了專案的整體如時間進度業務價值等把握能力,不容易正確決策.這個問題我一直沒考慮好.

而總結我個人,其實也有很多問題,和老員工包括領導的溝通不夠積極,沒有站在他們的立場上考慮問題,應當多做些技術交流和講座,包括一起做些開發測試工作,瞭解他們的想法和需要,幫助他們在Java技術上提高就好了.自身對領域知識也瞭解不夠,應當沉下去,多做寫基礎工作,謙虛學習就好了.

設計架構時,應當同時做寫原型程式實現和對架構不斷修正,也許就會離目標近些.專案的溝通也有些問題,其實應當多組織上下層,技術和業務的交流,大家報著一個積極向上,解決問題的心態就好了.總之,

回想起來,這個專案的圈,餅叉都有些問題,特別是餅,業務和技術目標都太大,不切合實際,可行性不正確是這個專案的根本問題.
再次,其實如果真的是沒有java專家的話,不如當時把業務需求,軟體需求,架構需求說清楚,目標劃小些,用他們原來熟悉的C#實現了關鍵的需求,另外找個Java團隊熟悉了JBOSS技術後,再重做一遍,可能成本稍微高些,但是成功的機率會大很多,畢竟,業務和技術都是全新的專案風險真的是太大了.這是一個實施策略的問題,

而且我在尊重員工,重視員工行為規範的寬鬆的外企裡面呆習慣了,對民營企業拼命加班,嚴格懲罰員工,禁止員工上網等的軍營式管理行為非常難受,其實仔細想起來很多時候磨練也是一種鍛鍊,對於人的成長長遠看也是有益的.關鍵是要調整自己的心態.
其實不是環境改變人,就是人適應環境,所以在換工作前千萬要了解這些情況,會少走些彎路.

我們很多時候不得不在犯錯中成長,在痛苦中成熟.
滿招損,謙受益.
高調做事,低調做人.
不要當眾批評人和群發郵件.
即使領導不對,也要服從,
小公司裡一切都要聽老闆的,要讓老闆滿意就足夠了.但是年輕人的話還是到大公司裡鍛鍊,能培養正確的做事方式,然後再自己創業好些,否則基礎知識還是不夠紮實.

還有你付出了多少就期望多少,很多民營公司裡成本是第一位的,所以要考慮好,你拿多少錢必定對你的期望有多高,是否能達到和適應,大公司裡願意培養人,而大多數在生死存亡線上掙扎的小公司裡很難做到這一點.所以要改變自己的期望.

這是我在這次失敗中總結出的幾點教訓.
希望明天能更好.

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/24478210/viewspace-707798/，如需轉載，請註明出處，否則將追究法律責任。