也談敏捷(2)

Allen0805發表於2009-08-25

 

繼續我們的討論。


前幾天,我在google上搜尋thoughtworks,結果發現,很多文章竟然是關於如何通過這家公司面試的過程描述,介紹如何可以得到thoughtworks的offer。說句題外話,中國的工程師其實也很可憐,這麼多人在網上花費大量的時間交流的僅僅是獲得一份工作的經驗,把擠進洋人的公司、給洋人打工看成是人生的一個里程碑式的成就。先賢說中國知識分子缺乏獨立的人格,往往是指政治上的,知識分子經常淪為政治的小妾。而從今天看去,恐怕還要加上商業小妾這一條了,對老闆、對洋人的諂媚幾乎也成了知識分子這個群體的基本特徵屬性之一。從這些面試文章裡可以看到,thoughtwork的面試過程很嚴格,給的待遇當然也不錯,中國的工程師趨之若鶩也是自然的了,最後的錄用比例好像是10:1。我感興趣的則是thoughtwork面試的內容,從那些成功者的經驗報告中透露的一些資訊來看,多數應該是軟體設計、程式開發技能方面的東西,說實話,那些考題如果讓我去做,估計100%的要死菜菜。我的一個曾經部下參加過他們的面試,結果第一輪都淘汰了。

 

從我所瞭解的一些資訊,我們有必要需要來討論怎樣進行敏捷。

 

做軟體,本質上也是一種業務,因此,討論軟體的開發方法,最好把出發點放在業務模式來討論。正象前面說的,敏捷發展到今天,其實也變成了一種觀念,一種業務模式。

 

OK,我們這裡就來討論一下軟體業務的問題。現在所有的軟體公司幾乎都面臨一個問題,就是做軟體不賺錢,軟體的利潤實在太薄。這裡面既有市場環境的問題,同時也有軟體公司自己的問題。話說回來,中國有成千上萬家軟體公司,但是到底有幾家真正懂得做軟體業務的呢。這幾年,關於軟體業務模式的創意層出不窮,方法也多種多樣。有人提倡大客戶服務,這樣模式下,市場的開拓成本不大,而且比較穩定,但是大客戶的預算也經常波動,而且客戶的主管胃口也越來越大,以前的許多假設實際上已經不成立。也有人提倡做人力外包,公司就是賣人頭,好處是現金流壓力小,業務穩定,但是在這種模式下,正是由於公司的收入清晰可見,老闆們很少願意把裝在兜裡的錢再掏出來做公司的能力建設,所以時間長了,外包公司的服務能力一定是向下衰減,直到有一天客戶忍無可忍,另尋新歡。還有人希望從軟體工具方面來解決問題,於是就有了各種各樣的框架平臺,據說這是一顆能夠搞定軟體業務的“銀彈”,於是滋生了幾家做平臺的軟體公司,不幸的是,平臺也僅僅是工具,決定專案成敗的關鍵因素肯定不是平臺,這些做平臺產品的公司最後免不了還是得去做行業專案。有了飛機大炮,也未必能夠打得贏小米加步槍。

 

現在冒出來了敏捷開發,而且已經成為了一種業務模式,很多公司賴以生存的基礎。那麼就敏捷業務模式來講,我們要深入地進行一些討論。既然是業務模式,那麼與之相關的第一個問題就是,敏捷的支援體系是什麼,怎樣建立。說到底,它的業務基礎是什麼。

 

我們來看thoughtwork,它是在XP的思想下來實施敏捷的,所以它需要找的人一定是一些相對比較高檔的程式設計師,既可以寫出高質量的程式碼,同時又能夠快速理解客戶的業務,並且可以隨時因客戶需求而變。但是,如果我們回到現實中間,我們會發現這種模式至少在國內是極度危險的。

 

首先,國內的市場似乎沒用這麼大的利潤空間給一家軟體公司去養這麼多的高檔程式設計師,即使這些程式設計師能夠快速交付他們所承諾的任務(不過就我個人來看,我對國內市場上的程式設計師的這方面的能力的認識還是有所保留的)。只有一種可能性,象thoughtwork這樣的公司可以持續地、從海外接受利潤較好的軟體訂單,這樣才可能管得住這群高檔程式設計師的吃喝拉撒。

 

其次,國內市場上實際是缺乏一個能夠適應XP、同時又相對比較穩定的程式設計師群體。在這裡,我們簡單地給國內的程式設計師群體來做一個分類,來看看程式設計師的基本型別:

 

第一類就是那些優秀、勤奮同時又懂得把握機遇的群體,在幾年艱苦的專案生活之後,多數都進入了各個軟體公司的廟堂,成為了公司的中高階管理者,或者公司的基幹技術人員,例如諮詢師、架構師等等,他們在一定時間後,一般不再承擔一線客戶專案的開發任務。

第二類則是那些資質較弱,或者有一些惰性的程式設計師,在軟體公司幹了10年左右,不上不下,高不成、低不就。這群人多數是缺乏激情、缺乏創新的老程式設計師,靠跳槽加薪,靠在網上曬工資條宣洩自己的優越感。當然,這群人並非一無是處,憑良心講,在開發經驗上和程式質量上,他們的工作績效還是要比剛剛入行的程式設計師強了許多,到底多吃了好幾年的IT飯。但是不幸的是,他們的成本也是年輕程式設計師的若干倍,對於公司來講,這群人的投入產出是不成比例的。在國內軟體公司中,我個人感到,最沒有價值的就是工作了7、8年,每月拿8000到10000左右的高階程式設計師。這群人向上走,既不能帶隊伍做管理,獨立承擔責任,又不能做系統分析設計,在專案組中僅僅是一個優秀的技工而已;向下行,當承擔一些具體工作時,往往又擺老資格,講條件,紀律渙散,動輒在專案中就要跳槽,置團隊整體利益於不顧,是實實在在的雞肋。這群人,我們可以稱之為打工油子。

第三類則是那些工作時間不長,涉世不深,還保留了一些朝氣和單純的年輕程式設計師群體,他們可能能力、經驗不足,但是多數追求上進,至少還有些熱情,當然成本也相對較低,這些可能是現在軟體公司應該重視的資源。

做軟體開發要培訓團隊,就我的認識來講,培訓那些初出校門的年輕人其實是建立基幹團隊的最佳途徑。當初戚繼光訓練戚家軍時,最反感的就是老兵油子,寧可從頭招募培訓農民、礦工等良家子弟,也不要那些頗有些實戰經驗的老兵。

 

一般而言,在中國,學而優則仕,同樣在商業環境裡也是技而優則仕,做官是每個人的終極出路。程式設計師的職業發展肯定是不能體現在程式設計師崗位上。發展幾年,如果有一些業績了,肯定會轉行,或者做管理,或者做諮詢,或者乾脆去做銷售,優秀人才的人生追求在客觀上會不斷地削弱優秀的資深程式設計師的群體。這是國民性造成的,也是行業待遇體制的原因。雖然很多歐美公司都在宣揚一種老程式設計師的文化,但是程式設計師畢竟不是科學家,科學家越老越值錢,而程式設計師則是和女人相似,越老越沒有人要:老的科學家是國寶,老的女人這裡就不說了,而老的程式設計師幾乎與老的女人有的一拼。這就是中國的文化環境。少數幾個歐美公司的老程式設計師文化,最終只能讓國內那些老程式設計師做冤大頭。

 

所以,在國內,程式設計師團隊的組建只能依託於年輕的群體,要能夠形成年輕程式設計師源源不斷的資源梯隊。到了30歲左右,程式設計師就應該主動尋找發展的機遇,過了30歲還在專案組做程式設計師的人,就要考慮自己的職業生涯的風險了。一個人,在30歲或者35歲的時候,還在抱著簡歷求一份基層的程式設計師職位,本身就是一件很悲哀的事情。至少我在篩選簡歷的時候,對30歲以上的程式設計師是有所保留的,尤其那些在簡歷中動輒要高價的人。其實,在公司裡,超過一定薪酬的人是必須找獵頭或者熟人推薦的,行業中幾乎沒有公司會在公共渠道獲得的簡歷中尋找中高階的人員的。

 

 

鑑於此,回到我們要討論的專題,我們要實現敏捷。按照道理來講,敏捷最關鍵的基礎是程式設計師,而程式設計師資源應該是一些30歲左右的人群。但是在國內這個人群又恰恰是相對平庸或者是打工油子的那一群人。嗚呼,在這樣的基礎上進行XP,實施敏捷,謬矣。所以,現在很多公司的敏捷模式實際上是要檢討的。

 

目前,我們能夠利用的只能是一些沒有太多經驗,但是還有一些朝氣的人,這是我們真正可以利用的資源,我們要在他們的基礎上開始敏捷。OK,相信很多公司都在探索,我們也在探索。

 

既然如此,那就讓真正優秀的人發揮作用吧。

 

每個軟體專案,基本的規律是必須有一個象毛主席那樣的指路人,這是“先知”,一眼可以看到20年後。先知們會把專案的需求、設計、架構、程式、團隊、計劃和後期的擴充套件,全部瞭然於胸,清清楚楚。如果這種前提存在,我相信,至少專案很少會走彎路了,而敏捷也不是夢了。另外,Thoughtwork的面試也不會那麼辛苦了。比較一下,一個軟體公司是分散財力養一大堆高階程式設計師,還是集中財力養幾個優秀的業務分析師、系統架構師,哪種模式更容易管理,哪個模式風險更小,我想答案是相當明確的。

 

事實上,XP走的是群眾路線,靠程式設計師的能力來應對客戶的需求,調整軟體產品的功能,交付合格的產品。但是,但是就像上面講的,在國內的環境下,這種群眾群體是不存在的,而且這個人群的職業素養也是令人不安的。而另一種方式是先知路線,靠的是毛主席式的指路明燈,洞察一切,給整個團隊做導師,引導大家在正確的時間,用正確的方法,做正確的事情。這種模式可以依託目前國內的群眾環境來完成。只要路線對了頭,沒有敏捷也會有敏捷。路線一旦掌握群眾,群眾就可以搞場運動,創造歷史了。

 

這種先知模式產生的敏捷開發方法,其根本是對方案諮詢能力的考驗。其實,在一個團體裡,當優秀的程式設計師轉變成為管理者或者中高階的技術領導者,一定會面臨一個問題:就是他們的知識如何在更高的層次上進行放大,轉換成為更大的商業價值。而敏捷模式提供了一根槓桿,讓優秀程式設計師沉澱的知識,通過方案能力來撬動巨大的商業回報。

 

這是一種軟體業務的商業模式,群眾可以在先知的指導下迅速接近軟體的目標,交付符合客戶需求的產品。一個軟體公司必須有幾個先知,否則幾十個甚至數百人的團隊,茫茫然地摸索,能夠開發出高質量的產品,才是奇怪呢。我們都知道做軟體最難的不是如何做,而是做什麼,這就是先知路線的基礎。

 

雖然書本上有很多軟體方法,指導我們分析、設計、開發產品,但是這些方法在經驗目前顯得多麼地蒼白,現實實在是太複雜了。

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

相關文章