標籤:sp 檔案 問題 bs 代碼 as 時間 工作 nbsp
上一篇雜七雜八的說了說軟體項目的問題,這一篇說說碼農本身。最近事情一直比較忙,沒來得及更新,直到剛看見公司代碼裡有同事在標頭檔裡加了一個函數和.cc檔案的一個函數實現的功能一模一樣,甚至代碼都完全一樣,可是這哥們就這樣隨心所欲的增加了代碼的重複,實在是無語。感慨之際,迫使我今晚把這篇文章趕出來。上次還有評論說,軟體的管理不是要非人化,而是相反,應該更加人性化。我個人的理解是,項目本身的設計,實現,和測試應該盡量減少對人為主觀因素的依賴,對於對開發人員的管理,那必然得人性化。好了,不廢話,開始。
作為管理者,如果一件事情(大到一個功能,小到一個bug)沒做好,那麼我們應該怎麼看呢?比如上面提到的問題,一個軟體工程師,無視已有的代碼,直接添加了一個實現功能一模一樣的甚至代碼完全相同的函數,我們怎麼辦?把他直接叫過來罵一頓嗎?出了問題,直接劈頭車臉的責怪,絕對不會解決問題。
我以為,我們首先要想兩個問題,是他不能做好嗎?還是他不想做好?有的人會說,我去,這麼簡單的事,怎可能是不能做好,必然是不想做好,還用想什麼。其實不然,當我們把這件事拿到一個大的項目中來看的時候,就存在各種可能性,這也就是我們要做到人性化的地方。當一個人不能把事情做好,可以有兩種可能性,第一是沒時間做好。當項目非常急,客戶等著要,老闆一直催,甚至訂單就在那等這個項目的時候,軟體工程師承受的壓力其實非常大,生怕由於自己影響公司的銷售,因此在迅速完成項目並緊鑼密鼓的測試的時候,很多人沒有心情靜下心來去看看已有的代碼,這麼簡單的東西,隨手就寫一個,趕緊把任務完成絕對佔據他的最高優先順序。如果遇到怕腦袋的經理,隨便的就答應銷售甚至客戶,根本沒有仔細考慮工作量(原諒他吧,因為如果說開發人員眼裡重要的是項目,那麼他眼裡就是如何儘快把項目變成利潤),那麼這種情況應該經常出現,尤其是在小公司,這種情況更常見。如果出現這種情況,就該管理者本身進行反思一下,是不是有點不切實際了。一個人不能把事情做好的另一種可能性就是技能不夠。有一句話說的非常好,五年的工作經驗不能與一個技能用五年。在工作中,很多人覺得自己在開始的時候,進步非常快,但是越到後來隨著對工作環境的熟悉對代碼的瞭解越沒什麼進步,甚至停滯不前。把手頭的工作做順手了,按部就班的就能完成工作任務。但是很少有人去仔細看看自己以前的代碼哪裡寫得不好,那些問題考慮不周,有那些方法太笨,自己後來有沒有為這些不好的地方學習,現在有沒有更好的方法實現,更很少有公司會對員工不斷進行培訓,增加員工的技能,是員工更加高效的完成任務。作為管理者,如果員工本身沒有學習,就更要經常地組織一些學習交流培訓,讓進階工程師講講他們的項目的設計,講講他們代碼中用到的演算法,設計模式,通訊機制,以及遇到的問題等等,這些對初級工程師的成長非常有協助。因此,當一個人不能把事情做好的時候,管理者應該首先反思自己是不是對任務量估計不足,定目標定得太草率了。其次應該反省一下,團隊的水平是不是長久以來都停留在某個水平上,這就提醒你需要對你手下的兄弟培訓了。當然,作為碼農,也要有一顆成長的心,願意不斷的學習一些新東西,看看書,溫習溫習演算法,這樣才能幹五年就有五年的工作經驗,而不是一個經驗用五年。仔細想想,一個經驗用五年,是多麼悲哀的一件事啊。
如果不是那哥們不能做好,而是他就不想做好,那該怎麼辦呢?有人說開除他,都TM不想幹了,留著也沒用。其實這一點也可以分兩個角度來看。第一就是外因使得他不想幹好,比如公司對項目的要求本身就不高,而且團隊中大家都這樣,隨便乾乾就得,幹得太認真也沒啥用,領導也看不到,誰乾的多幹得快誰漲工資多,對自己要求太嚴沒啥好處。作為碼農,對於寫代碼是一件良心活,我深有體會,把qa混過其實不難,但是要把每一點都做得很好,難度很高。這種情況下,管理者應該及時察覺那些平時平時做事認真寫代碼卻矇混的人及時找他們談談,看看是不是自己忽略了很多人傾注在代碼的心思,同時看看是不是項目中的標準太低了。簡單的說一個例子,對於同一個任務,你去問兩個不同的人,你多長時間能做完?兩個人很可能給出的時間差距很大,不要因此就斷定一個人在跟你磨時間,而要多問一句,你說的做完的標準是什嗎?很可能你就聽到一個人說,完成所有的功能,並對每一個功能點構造測例通過這些測試,並考慮可能出現的異常情況邊界情況以及對它們進行處理,而另一個人說的是寫完代碼。這就是在公司沒有統一規定時每個人對做完的標準定義不一樣。通過這些,其實我們也可以更好的瞭解一個人,請珍惜那些給出第一個答案的碼農。不想幹好的另外一個外因是,和領導有矛盾,比如領導喜歡頭腦風暴,員工喜歡深思熟慮,那就就會出現領導覺得員工不好使,而員工覺得領導一點腦子都沒有的情況。如果領導深思熟慮,而員工頭腦風暴型,那麼領導會覺得員工浮躁一點不靠譜,而員工覺得領導畏首畏尾難成大事。此時,作為管理者,首先應該盡顯去發現跟自己風格不一致的那些員工,並注意跟他們的相處,因為畢竟你是領導,你是需要琢磨怎麼管人的,而他更多的是在考慮項目。如果矛盾逐漸加深,很容易員工離職。還有很多細微的問題,都需要管理者注意,一定要盡量做到知人善用。相信我們都見過有些員工因為不能從事自己喜歡的領域或者自己擅長的領域離職的情況。其實這些都是管理者本身的問題。
對於不想幹好的另一個可能性是員工本身的內因,這其實也是兩個因素。第一就是對自己要求不高,同時公司又沒有一個很高的標準,那麼員工自己的惰性就會使得他把目標定在完成任務上,而不是做好任務上。我就見過有的人把自己寫完代碼的功能直接扔給qa測試,測出問題就修修,沒問題就這樣。我也見過,有的人在一開始寫代碼就開始想自己的功能怎麼測,在哪裡測,用什麼方法測,那些地方可能有功能問題,那些地方有異常情況沒處理,那些地方可能有效能問題,他把這些一一都記錄下來,會在交給qa之前,自己用測例確保所有的功能正確,所有自己考慮到的地方基本沒問題,然後再交給qa,讓他們幫自己測那些可能自己沒想到的問題。對於這樣的員工,一個嚴格的流程和要求,就可以解決問題。第二個內因就是員工的態度不好。這個世界上有人把工作當做一切,就有人把工作當做吃飯生活的手段,有的人真的只想幹點活拿點工資,平時過點自己的小日子,有嚴重的在公司都幹自己的事,看看小說,上上網,事情來了湊合做一做,然後繼續自己的生活。這部分人我們真的傷不起,如果你很在意團隊的一起拼搏的感覺,並且你有非常大的氣場,不妨跟他談談,改變了他的心就改變了他的態度。要麼你就不在意團隊一起拼搏,大家就井水不犯河水挺好。否則的話,早點散了吧,為了大家都好。
一轉眼又囉嗦了這麼多。關於軟體的專案管理先就寫這麼多吧。本來打算把培訓,svn,branch,release,測試,bug管理,等等,都寫寫,但是又覺得太細節了。目前就先這樣了,有需要的話,以後再寫。
談談軟體的專案管理之道(二)