挨踢項目求生法則-團隊建設篇

摘要：

知道什麼是挨踢項目吧？什麼！不知道？那IT項目知道了吧？爲了避免讓客戶踢、不讓老闆踢、項目組成員之間不互相踢，俺爲你們分享一些減小被踢機會的心得體會。就算不能讓項目成功，也至少不會死得那麼慘吧！我將分戰略篇、團隊建設篇、需求篇、設計篇、編碼篇、測試篇、實施篇和計劃篇爲你分享。

做者：張傳波
www.umlonline.org/school/

 

什麼叫挨踢項目？

IT項目，特別是軟件開發項目，都屬於「挨踢」項目的範疇。挨踢項目的幾大特色：

1.需求不肯定。
2.技術不肯定。
3.工期限死。
4.預算限死

兩大不肯定和兩大限死，你想不「挨踢」都難！

 

由「踢皮球」事件想到的

事件回放：

某項目部署給客戶後，重現了一些之前已經解決的問題，而這些問題測試時並無出現。經檢查，發現測試的版本不是部署的版本，不知道爲何老版本部署給客戶了。領導要追究責任，因而你們各有說法：
開發人員說：我是按要求打標籤的，沒有問題。
測試人員說：我是在提交區中取版原本測試的，我沒有出錯。
實施人員說：我是按照開發給個人版本去部署的，我沒有過失。
最後終於有人說：是以前已經離職的某某弄錯版本號致使的。

詳情可參閱《案例分析：項目組內踢皮球事件》一文：

http://www.cnblogs.com/umlonline/archive/2011/10/28/2226933.html

該事件暴露了不少問題，但我想說的是團隊建設的問題，沒有任何一我的首先從本身身上找緣由，第一反應就是推卸責任！

唐僧四師徒西天取經，若是每一個人都是這樣，不是本身內鬥死，就是被妖怪吃掉！優秀的團隊能「自動」解決不少問題，如何才能打造良好的團隊文化呢？

 

良好團隊文化的源泉是什麼？

良好團隊文化的根本其實就是老闆的管理思想了，不一樣的管理思想，老闆會設計不一樣的部門規劃和考覈辦法。

有朋友提到他的Boss喜歡工廠化管理，硬生生將員工分紅兩類人，設成兩個部門。一個部門叫設計部門，負責需求和設計；一個部門叫實施部門，負責編碼、測試、實施。設計部門經過一個任務管理系統向實施部門下單，實施部門根據這些工單來工做。該老闆還設計了自覺得很牛的考覈辦法，若是實施部門不能按時按質完成工單，則會影響考覈；若是設計部門的工單被實施部門退回，則會影響設計部門的考覈。因而兩個部門之間的扯皮時間每天發生，之前完成一個工做很簡單的，如今要扯來扯去。設計部門自認爲需求、設計等文檔已經寫得很清楚，實施部門認爲已經按照這些文檔完成工做，或者是認爲這些文檔說得不夠具體，要退單。當文檔主要用來任務交接的時候，文檔就會變成茶几上的杯具！

還有一些老闆喜歡用bug數量、文檔缺陷率、工期延誤率等所謂客觀的量化的數據來考覈，一樣只不過是杯具的另外一種形式而已。

軟件研發活動是人類複雜的高級智力活動，是須要team work的活動。若是明白這個道理，若是懂軟件開發，就不會設計出這些傻瓜的管理措施，將軟件研發團隊的每一個人變成機械人、卸責人。研發團隊中的每個人都應該是值得尊重的、有血有肉的、充滿激情和戰鬥力的專家！

 

做爲Team Leader應該怎樣作？

Boss的想法咱們沒法控制，雖然沒法從根本上改變公司的部門設計和考覈制度，但做爲Team Leader來講，在能力範圍內仍是能夠作不少事情的。Team Leader應尊重每一位Team Member，平等地對待他們，充分發揮他們的潛力，給予足夠的支持和成長空間等。對你們好，你們是知道的，未來會給你帶來更大的回報。

下面一些法則供你參考。

 

法則1：一榮俱榮，一損俱損

項目組由項目管理、需求分析、軟件設計、編碼、測試、實施等各方面的專業人士組成，每位成員在本身專業領域內發揮主導做用，並能夠爲項目的成功提出非本身領域內的建議。最終的項目成果是各位專業人士共同努力的結果，全部人對最終成功承擔同等的責任。

若是系統部署後，系統出現了一個嚴重缺陷，請問誰應該負責？

項目經理？測試？開發？……

都不是，而是項目組全體都要負責！

軟件中某個功能作得很炫很好用，請問誰應該受到表揚？

項目獎勵發下來了，請問誰能夠分到這份獎勵？

以上問題相信你應該有答案了！

項目組全體是共同承擔連帶責任的，要死一塊兒輸死，要活一塊兒活。若是項目組中有人受罰，有人會獲得好處，這個Team是很難團結和有戰鬥力的。 

 

法則2：讓 Team Member 當家做主

項目組中不免有部分紅員是新手，經驗和水平不足，某些工做可能一時不能勝任。而咱們每每迫於項目進度壓力，某些任務就會直接安排給他作，不讓他提出本身的想法和看法。而咱們這些接受了中國式教育的人，很多人喜歡以「接受任務」的方式來工做，而不是主動迎接挑戰。因而有時候你可能遇到一些成員會跟你說「今天工做已經完成！」「我按照任務要求來作的，我沒有錯！」之類的活活會氣死你的說話。

不要剝奪項目成員當家作主的機會，應相信每位成員在他的專業領域內都是專家，在他的專業範圍內，他能夠說了算！只要知足項目的大框架，只要出發點是爲了項目成功，那麼這段代碼應該怎樣寫、這個功能點應該如何測試等之類的決定，徹底能夠交給Team Member來作主！項目成員可能一時沒有魄力獨立作決定，可能擔憂犯錯誤，不要緊，要多多鼓勵他！犯錯不可怕，由於還有「法則3：鼓勵犯錯！」

 

法則3：鼓勵犯錯！

少作少錯，不作不錯。若是犯錯誤會受到懲罰的話，那麼前面八個字就會應驗！

犯錯幾種狀況：

1.常常挑戰高難度工做，犯錯是不免的。

2.作一些以前沒有經驗的工做，犯錯也是不免的。

3.犯一些低級錯誤。

4.犯一些以前曾經犯過的徹底能夠避免的錯誤。

對於狀況一、2，絕對是須要鼓勵的！對於狀況三、4，要幫助他避免這類的錯誤。

軟件研發工做大部分是高難度和複雜的，加上進度壓力大，犯錯是不可避免的，如何在總結中前進。一個在工做中歷來不犯錯的人，他不是神，他應該是那種「少作少錯，不作不錯」的人，或者是專挑低難度工做的人，你喜歡這樣的人？

 

法則4：言傳身教

曾經見到這樣的一些領導，當下屬有問題求助時，他會板起臉孔，擺出領導的樣子，而後說：你本身不會解決問題嗎？你應該本身列出解決方案後纔來找我！

我贊同領導不該該幫下屬解決全部問題，有些問題應該由下屬本身搞定，但下屬是不可能搞定全部問題的，有些問題超出能力範圍和職責範圍，做爲領導就應該出手。

做爲Team Leader，應着重幫助Member養成良好的工做習慣和工做方法。中國式教育培養出來的學生，可能會喜歡直接獲得答案，而不求工做方法。這個中國式教育的錯，就只能由咱們來補了。

 

法則5：擋住騷擾團隊的外來干擾

Team Leader應當住來組團隊外部的干擾，讓團隊能夠專心工做。擋住麻煩是Leader的職責之一，而不要由於嫌麻煩，而讓你的Member去處理這些麻煩。

 

法則6：全力維護團隊利益

某部門的員工的薪金近年來不多獲得提高，緣由是該部門經理對外是好好先生，每一年都不會主動積極爲部門爭取加薪的預算，老是被別的部門搶去預算。

某項目出了問題，老闆找來項目經理，說要找人負責任，不然很差向客戶交代。如下三個選擇你會選哪一個？

A.該問題確實主要是由於某Member致使的，全部他來負責是應該的。

B.這是團隊的責任，要全體負責。

C.儘管是主要由於某人出錯致使的，但做爲PM的我應該負主要責任。

做爲一個Team Leader，不管任何狀況下都不該該「出賣」本身的Member，應該本身一力承擔！回頭你能夠關起門來，批評這位犯錯的Member。

 

法則7：咱們是一我的

法則7是最重要的，其實只要能作到「咱們是一我的」，其餘法則天然就作到了。你不會和本身的左手做對的，右腳不會和左手打架，你的身體哪一部分受傷，你都會以爲疼，一我的的手腳動做是很容易協調的。若是咱們團隊能凝聚在一塊兒，達到「咱們是一我的」的效果，那麼咱們將望風披靡！

 

若是本文對你有幫助，麻煩點擊一下「推薦」，謝謝！

 

做者：張傳波
www.umlonline.org