12.5團隊討論
由于大部分人都反映以前的項目太忙,每人都加班,但是勞而無獲,阿超把一隊人馬都帶到小河邊開會,大家一邊曬太陽,一邊討論時間安排問題。
阿超:要弄清這個問題,首先要說明員工到底有多少時間用在工作上?或者說,有多少時間花在寫代碼上?
小飛:又來了,員工的時間是取之不盡,用之不竭的,不過,上次我們的加班費還沒有著落呢。
果凍:報告超總,我每天工作10小時,一周7天,天天如此。
大牛:玩游戲的時間也算上了么……(眾笑)
員工每周只有40小時上班時間,每天8小時。上班時間是你出現(xiàn)在公司的時間。而項目工作時間是指你在精力集中、無干擾的情況下為項目進行開發(fā)的時間。根據(jù)我的經(jīng)驗,每人每周最多只有四天時間,32小時實實在在地在做項目。其余的8小時花在下面三個地方——
日常事務(wù),我們的確要花很多時間處理瑣碎而又不得不做的事:交流、開會、討論、寫E-mail、玩游戲等,對于一些員工來說,8小時還遠遠不夠。
作為緩沖,如果你任務(wù)沒完成,那就首先用這個時間來填補。這意味著如果你項目的任務(wù)沒完成,那就少一點開會/討論/玩游戲,等等。
在項目過程中有不少突發(fā)事件,你要應(yīng)急,可以先從這里撥出時間,如果不夠,可以再從32小時工作時間中拿。
軟件學(xué)院的同學(xué)們不理解為什么一周要有8小時“非開發(fā)時間”,我們有工作經(jīng)驗的同事不妨說說,我們在沒有直接開發(fā)/測試/設(shè)計軟件的時候都在干什么:
我沒看見你在寫軟件,你到底在忙什么
?。ㄒ粕焦镜耐录w創(chuàng)作)
(1)人員調(diào)動和安排工作環(huán)境。
(2)數(shù)據(jù)遷移。
?。?)安裝,定制辦公及開發(fā)軟件,調(diào)整Windows桌面背景設(shè)置。
?。?)從網(wǎng)上下載代碼和其他技術(shù)資料(還有電影),并研究。
(5)進行各種內(nèi)部測試(如Beta)。
?。?)演示軟件,為演示軟件而做的雜事,如制作PPT等。
?。?)維護以前版本的系統(tǒng)。
?。?)為單位別的人員(特別是剛買了高檔laptop的領(lǐng)導(dǎo))提供技術(shù)支持。
?。?)項目管理系統(tǒng)(如TFS)的管理和維護。
?。?0)支持用戶及其他技術(shù)文檔的寫作/復(fù)審。
?。?1)培訓(xùn)(技術(shù)培訓(xùn)/聽課;公司的非技術(shù)培訓(xùn))。
?。?2)技術(shù)會議。
(13)公司大大小小和技術(shù)無關(guān)的會議。
?。?4)讀/寫E-mail。
(15)寫工作總結(jié),等等。
大牛:當(dāng)然,也可以從40小時以外抽時間。
阿超:是的,如果在規(guī)定時間沒有完成任務(wù),也許要搭上自己的時間,或者是剛到公司,要學(xué)的東西太多了,或者是工作規(guī)劃時估計不夠,或者是個人時間運用的效率不高。這些情況下,都要加會兒班。但是如果我們想讓公司、團隊和個人得到長期的發(fā)展,加班不能是常態(tài)。
荔荔:員工培訓(xùn)的時間呢?
阿超:在項目過程中,我們的精力主要應(yīng)該放在項目上,這時我們的培訓(xùn)時間應(yīng)該從8小時機動時間內(nèi)劃分,或者用業(yè)余時間。在項目告一段落時,我們可以花更多的正式時間來進行培訓(xùn)。最好的培訓(xùn),是在工作中學(xué)習(xí)。
我原來還想增加日常事務(wù)的時間,但是大智總裁覺得不妥,他認為40小時都應(yīng)該是項目工作時間,8個小時已經(jīng)太多了。最后決定先按照我的折中方案試試看。
果凍:智總真是太英明了。
阿超:所以,我們的項目是基于一線人員每人每周32小時的工作量來安排。
對于管理人員(組長)來說,每人每周再有8小時用于管理工作,管什么呢,管人、管技術(shù)、管進度。
所以,項目管理人員,包括每周只有24小時用于直接的項目任務(wù),另外16小時用于管理,以及日常事務(wù)。注意,管理人員的管理時間也是非常重要的,他們雖然沒有在寫代碼,但是花在不寫代碼的這部分時間對項目的成敗有更重要的影響。
歸納起來:
一線員工:每人每周32小時的工作量,8小時日常事務(wù)。
管理人員:每人每周24小時的工作量,8小時日常事務(wù),8小時管理。
對開發(fā)人員的期待:
?。?)從用戶的角度考慮問題。
(2)設(shè)計和實現(xiàn)代碼時允許緩沖區(qū),但是一旦代碼完成,質(zhì)量必須是最好的。
?。?)代碼的行數(shù)和工作績效無關(guān)。
(4)真正好的工程師是能夠用簡單的辦法解決復(fù)雜的問題。
(5)模塊的最終質(zhì)量決定了工作績效。
對測試人員的期待:
?。?)盡早參與設(shè)計。
?。?)盡早發(fā)現(xiàn)問題,最好在問題要發(fā)生前就能阻止問題的發(fā)生。
?。?)發(fā)現(xiàn)的缺陷的數(shù)量和工作的績效沒有直接關(guān)系。
?。?)模塊的最終質(zhì)量決定了工作績效。
對項目管理人員的期待:
?。?)推動項目的發(fā)展,從技術(shù)層面說,就是在出現(xiàn)不同意見的時候做決定。做出后來發(fā)現(xiàn)是錯誤的決定,也比沒有及時做決定好。
(2)從管理方面推動項目的發(fā)展,不僅要注意現(xiàn)有的任務(wù)的進展,還要注意有哪些東西應(yīng)該做而沒有做。
?。?)整個大模塊,或整個產(chǎn)品的質(zhì)量決定了管理人員的績效。
?。?)自己所領(lǐng)導(dǎo)的團隊的績效也決定了管理人員的績效。
小燕:蕓蕓是程序經(jīng)理,是不是程序員的經(jīng)理?然后測試工程師是不是也受程序員和程序經(jīng)理的共同領(lǐng)導(dǎo)?
九條:測試工程師馬上就有幾座大山壓在身上了。
蕓蕓:不會吧,我正在實習(xí),還沒有畢業(yè),怎么可能領(lǐng)導(dǎo)別人呢?
阿超:在團隊中,不同專業(yè)的人員為了完成一個項目或功能在一起工作,大家是平等協(xié)作的關(guān)系。
大牛:圖12-2是官方的人員關(guān)系圖,你看,沒有領(lǐng)導(dǎo)關(guān)系,只有協(xié)作關(guān)系,這樣大家該放心了吧。
大拴:從圖上看,分工真詳細,但是我們沒有這么多人來玩這么多角色,怎么辦?
圖12-2人員的關(guān)系
阿超:事實上,大部分的團隊都沒有這么齊全的隊伍,很多項目也并不需要樣樣齊全的正規(guī)軍來做。對于小型的團隊和小型的項目,可以根據(jù)表12-1來這樣合并角色:
表12-1合并角色
體系 結(jié)構(gòu) |
產(chǎn)品 管理 |
程序 管理 |
開發(fā) |
測試 |
用戶 體驗 |
發(fā)布 管理 |
|
體系 結(jié)構(gòu) |
N |
P |
P |
U |
U |
U |
|
產(chǎn)品 管理 |
N |
N |
P |
P |
U |
||
程序 管理 |
N |
U |
U |
P |
|||
開發(fā) |
N |
N |
N |
||||
測試 |
P |
P |
|||||
用戶 體驗 |
U |
||||||
發(fā)布 管理 |
|
?。≒:可能;U:不可能;N:不推薦)
如果我們盡量合并角色,會得到表12-2。
表12-2合并角色之后的關(guān)系
合并后的角色 |
主要職責(zé) |
管理人員(程序管理,發(fā)布管理) |
主要進行項目具體的管理工作 |
開發(fā)人員(體系結(jié)構(gòu),開發(fā)) |
主要負責(zé)項目具體的技術(shù)設(shè)計和開發(fā)工作 |
質(zhì)量控制人員(產(chǎn)品管理,測試,用戶體驗) |
主要負責(zé)產(chǎn)品質(zhì)量,用戶對產(chǎn)品的認可和接受程度 |
這就是我們目前的角色分配。