挨踢項目求生法則（1）——團隊建設篇

 

摘要：

 

知道什麼是挨踢項目吧？ 什麼！ 不知道？ 那IT項目知道了吧？ 爲了避免讓客戶踢、不讓老闆踢、項目組成員之間不互相踢，俺爲你們分享一些減小被踢機會的心得體會。 就算不能讓項目成功，也至少不會死得那麼慘吧！

 

我將分團隊建設篇、戰略篇、需求篇、設計篇、編碼篇、測試篇、實施篇和計劃篇爲你分享。

 

 

什麼叫挨踢項目？

 

IT項目，特別是軟件開發項目，都屬於「挨踢」項目的範疇。 挨踢項目的幾大特色： 1.需求不肯定。 2.技術不肯定。 3.工期限死。 4.預算限死 兩大不肯定和兩大限死，你想不「挨踢」都難！

 

 

由「踢皮球」事件想到的

 

事件回放：

 

某項目部署給客戶後，重現了一些之前已經解決的問題，而這些問題測試時並無出現。 經檢查，發現測試的版本不是部署的版本，不知道爲何老版本部署給客戶了。

 

領導要追究責任，因而你們各有說法：

• 開發人員說：我是按要求打標籤的，沒有問題。

• 測試人員說：我是在提交區中取版原本測試的，我沒有出錯。

• 實施人員說：我是按照開發給個人版本去部署的，我沒有過失。

• 最後終於有人說：是以前已經離職的某某弄錯版本號致使的。

 

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

 

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

 

 

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

 

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

 

有朋友提到他的Boss喜歡工廠化管理，硬生生將員工分紅兩類人，設成兩個部門。 一個部門叫設計部門，負責需求和設計； 一個部門叫實施部門，負責編碼、測試、實施。 設計部門經過一個任務管理系統向實施部門下單，實施部門根據這些工單來工做。

 

該老闆還設計了自覺得很牛的考覈辦法，若是實施部門不能按時按質完成工單，則會影響考覈； 若是設計部門的工單被實施部門退回，則會影響設計部門的考覈。

 

因而兩個部門之間的扯皮時間每天發生，之前完成一個工做很簡單的，如今要扯來扯去。 設計部門自認爲需求、設計等文檔已經寫得很清楚，實施部門認爲已經按照這些文檔完成工做，或者是認爲這些文檔說得不夠具體，要退單。 當文檔主要用來任務交接的時候，文檔就會變成茶几上的杯具！

 

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

 

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

 

 

做爲Team Leader應該怎樣作？

 

Boss的想法咱們沒法控制，雖然沒法從根本上改變公司的部門設計和考覈制度，但做爲Team Leader來講，在能力範圍內仍是能夠作不少事情的。

 

Team Leader應尊重每一位Team Member，平等地對待他們，充分發揮他們的潛力，給予足夠的支持和成長空間等。 對你們好，你們是知道的，未來會給你帶來更大的回報。

 

下面一些法則供你參考。

 

 

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

 

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

 

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

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

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

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

 

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

 

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

 

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

 

 

法則2：讓 Team Member 當家做主

 

項目組中不免有部分紅員是新手，經驗和水平不足，某些工做可能一時不能勝任。 而咱們每每迫於項目進度壓力，某些任務就會直接安排給他作，不讓他提出本身的想法和看法。

 

而咱們這些接受了中國式教育的人，很多人喜歡以「接受任務」的方式來工做，而不是主動迎接挑戰。 因而有時候你可能遇到一些成員會跟你說「今天工做已經完成！ 」「我按照任務要求來作的，我沒有錯！ 」之類的活活會氣死你的說話。

 

不要剝奪項目成員當家作主的機會，應相信每位成員在他的專業領域內都是專家，在他的專業範圍內，他能夠說了算！ 只要知足項目的大框架，只要出發點是爲了項目成功，那麼這段代碼應該怎樣寫、這個功能點應該如何測試等之類的決定，徹底能夠交給Team Member來作主！

 

項目成員可能一時沒有魄力獨立作決定，可能擔憂犯錯誤，不要緊，要多多鼓勵他！ 犯錯不可怕，由於還有「法則3： 鼓勵犯錯！ 」

 

 

法則3：鼓勵犯錯！

 

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

 

犯錯幾種狀況：  

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

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

3. 犯一些低級錯誤。

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

 

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

 

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

 

 

法則4：言傳身教

 

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

 

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

 

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

 

 

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

 

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

 

 

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

 

某部門的員工的薪金近年來不多獲得提高，緣由是該部門經理對外是好好先生，每一年都不會主動積極爲部門爭取加薪的預算，老是被別的部門搶去預算。 某項目出了問題，老闆找來項目經理，說要找人負責任，不然很差向客戶交代。

 

如下三個選擇你會選哪一個？

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

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

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

 

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

 

 

法則7：咱們是一我的

 

法則7是最重要的，其實只要能作到「咱們是一我的」，其餘法則天然就作到了。 你不會和本身的左手做對的，右腳不會和左手打架，你的身體哪一部分受傷，你都會以爲疼，一我的的手腳動做是很容易協調的。

 

若是咱們團隊能凝聚在一塊兒，達到「咱們是一我的」的效果，那麼咱們將望風披靡！ ◈◈◈精選好文◈◈◈

 

• 爲何阿諛奉承之輩能在公司橫行這麼久？

• 老闆對你說公司要裁人，你該怎麼辦？

• 技術總監到底要不要寫代碼？

• 漫畫 |《程序員十二時辰》內容過於真實 ...

• 爲何我有那麼多時間寫公衆號？