德魯克說:
“組織的成員作為個體,發展得越好,組織也會取得更多的成就。這一點正是今天所有經理人培訓和資深經理人教育課程重點和背後的真諦所在。當組織嚴謹的作風和道德精神不斷髮展、組織的目標和處事能力不斷提升時,組織內個體成員的發展空間也愈加廣闊。”
藉著寫部落格把關於軟體開發中新人訓練的想法總結一下,也希望拋磚引玉,得到大家的指正。
綜合來說,一個軟體工程師的培養需要涉及以下四個方面:
1. 產品專業開發領域 指的是產品開發過程涉及的專業技術。如作業系統、資料據等。這裡不討論這一項。
2. 通用軟體開發技能 指的是諸如代碼撰寫、Debug、單元測試、系統分析之類,也包括思維拓展等。
3. 產品應用領域 指的是產品在哪個領域使用,如財務、電力系統、醫院管理、企業管理等。
4. 職業素養領域 指的是對待工作的方式和方法,如時間管理、溝通技巧、職涯規劃之類的。這裡也不討論這一項。
*關于思維拓展方面,也可以歸到第四項目,但我更樂意視其為軟體開發中的通用的技能之一。
在學校學習時,常常有老師在考前畫畫重點,或者被要求抓住思想就可以了,這讓不少同學缺少些深入研究的習慣。學校的學習基本是有廣度沒深度。知識面廣,對初入社會應聘也有好處,至少可以說我學過。但工作後,第一步要做的就是夯實基礎,養成良好的開發習慣。工作後的技術提升,主要注重工作相關的專業技術的學習,比如關注Windows系統的API、MFC、資料庫介面之類的。相比之下基本的軟體開發技術能力很容易被忽視,好像總是夠用了。公司定義好Coding Rule、單元測試以及文檔的規範,員工也未必跟上。大家都知道在代碼會使用幾個APIs,就像你手上多了幾個材料,要想建起大樓,還是要靠運用它們的能力,這就是基本功。我曾經過做過很多嘗試,有系統培訓的概念也是這兩年才形成的。這裡做一些總結。
第一階段,上手期。新人一入職,好奇心強烈,也容易受到打擊,很害怕被放在角落裡自學。所以讓員工熟悉開發環境和工作內容是最好的。先是明確員工的後面工作內容和期預留的學習時間,指好方向。最關鍵的是指定一個人來介紹現在的工作流程、相關的人員、並且簡單過一下現有的代碼,指導對開發環境的掌握等等。看似手把手的教沒有什麼必要,但這是讓新入快速進入工作狀態的重要一步。只要先瞭解到工作的流程和一些基本方法,剩下的就是豐富和完善這個過程了。在這個階段要安排幾次練習,以檢驗學習成果,同時也可以發現一些問題。在這個過程中,只要求知其然就可以了。
這樣大概兩三個月的時間就過去了。
第二階段,快速成長期。
這時可以安排一些開發工作單位了,而系統的學習過程算是正式開始了。這個學習過程有兩條主線: 產品專業開發領域和通用技能領域。對於前者,與工作聯絡密切,各個單位可能不一樣,且不討論。這裡關注的是通用技能領域的訓練,通過兩個方面來展開:開發工作單位上的訓練和讀書計劃(如果用培訓計劃來代替當然更好)。開發工作單位上,主管會Review工作過程和成果,在發現問題的時候加以指導,可以涉及很多方面,總之看到了問題,就要指導一下,說清楚問題在哪?更好的方案在哪?比如提醒一下,這段代碼的寫法可以參考一下<<代碼大全>>第7章,那裡有很好的建議。主管提出修改建議最好能有理有據,如果僅是依據以前的經驗來判斷,難以說服別人。主管也要不斷學習才行。
另一方面就是讀書了。開發工作單位上的指導再細,也無法代替讀書,因為開發工作單位上的指導是分散的點,想要構成系統化的描述,書就要端出來了。在這個階段讀讀<<程式員修練之道>>和<<代碼大全>>(軟體構建的部分)。雖然這兩本書的中文名讓人覺得膚淺,但內容確實非常精彩。我就讓我們組人手一本<<代碼大全>>。書光讀也不行,還要講出來,要分享,這樣能加深理解。如果人多,交叉章節的學習分享就很好辦了。也可以讀讀思維拓展的書,比如<<突破思維障礙>>和其它思維導圖的書。不僅強調具體的開發技術,也要不斷學習工作上的小方法論。思維訓練的工作的價值非常之大,舉例來說,經驗與創新能力並不成正比,甚至經驗與生產力也並不成正比,究其原因就是思維容易被固化。
大概在畢業一年的這段時間裡,工程師能力會得到快速提升,需要特別關注。
第三階段,成熟期。當工程師能夠獨立承擔開發工作單位,開始表現出強烈的自信心,你對他的指導也越來越少了,這一切都顯示他正在走向成熟。那再給他加把勁吧。安排一次面對面的詳談,涉及優勢、劣勢、職涯規劃、興趣愛好等等。這個時期開始對工作有些不滿,比如工作的挑戰啊,或者工作內容的轉變之類,所以這段時間離職的可能性比較大。主管要認真加以分析,很多時候都有理想主義的影響因素,當然這些不是在這裡探討的內容。我們要關心的是在工作的第二年,我們能帶給他什麼收穫? 所以在面談過程可以收集到很多資訊,在後期的工作安排可以適當安排些機會給工程師。在技術學習上,則依據他們個人的定位來選擇:
如果想繼續深入技術,可以讀讀<<重構>>,<<Effective C++>>, 也可以重新讀讀<<C++ Programming Language>>。
如果除了深入技術,還有興趣系統設計,就可以讀一下<<設計模式>>和一些UML類的書,<<大象>>是本不錯的系統設計的書。
如果對軟體工程比較有興趣的,未來想做PM或Leader的,可以讀一下<<軟體需求>>,<<人件>>,<<日月神話>>,還有測試相關的書。
這裡只談較為通用的技術培養。至於產品相關專業開發領域的學習,可以做出類似的規劃。我比較喜歡拉出一個技術架構樹,也算是成長的一個願景。
這個階段一定要加入另一個訓練類別,就是領域知識,不是專業開發領域,而是產品的應用領域。好多年前,我剛開始工作時,涉及到一些資料報表,就在客戶的辦公室裡上了一課。第一次知道了原來數字靠左、文字靠右就是報表的基本要求。相較之下,我使用的Cystal Report有多麼強大與之相比一文不值。這一課讓我至今受益頗多,以至於後來我甚至準備考一個會計證。工作時,去學習一下產品應用領域的專業知識,一方面與客戶溝通會更為 有效,最終把事情做對。如果在第一年就開始學習也不錯,只要時間允許,不產生額外負擔就行。Eric.Evans寫了<<領域驅動設計>>很值得學習,同時“領域驅動開發”也很重要。喬布斯說:"米開朗基羅懂很多關於採石的知識,他不是只知道如何雕塑"。(引自<<喬布斯傳>>,
P518)
這樣大約兩年堅持做下來,工程師的綜合能力就會很紮實,你可以視他為正式的工作夥伴了。再往後的規劃需要考慮更為廣泛的範圍,也會受制於公司的組織規劃,我還沒有能力系統的展開討論,再學習吧。
作為一個工程師,發現周圍沒有什麼可學的了,或者認為這全在自學了,就會導致人才的流失。為工程師規劃好前幾年的成長計劃,對於培養人才梯隊非常重要。比如精心做了三年的成長規劃,多數的工程師就會做完三年。這三年就是軟體工程師培養系統的價值。當然如果公司制度對於三年以後的職涯發展支援也比較到位,就會留下更多寶貴的人才資源。
我們需要的是開發工程師,不是程式員!
(圖片來源:http://www.nirmal.com.np/home/the-difference-between-a-web-programmer-and-a-web-developer-nepal.html)