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

摘要：

知道什麼是挨踢項目吧？什麼！不知道？那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.犯一些之前曾經犯過的完全可以避免的錯誤。

對於情況1、2，絕對是需要鼓勵的！對於情況3、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