案例分析：項目組內踢皮球事件

你的項目出了嚴重問題，客戶向你公司的領導投訴，你的領導興師問罪要追究責任！這是測試的錯？開發的錯？PM的錯？還是研發流程的錯？中國教育制度的錯？社會的錯？反正、總之、一定、必須不是我的錯！

摘要：

你的項目出了嚴重問題，客戶向你公司的領導投訴，你的領導興師問罪要追究責任！這是測試的錯？開發的錯？PM的錯？還是研發流程的錯？中國教育制度的錯？社會的錯？反正、總之、一定、必須不是我的錯！

 

事件回放：

某項目部署給客戶后，重現了一些以前已經解決的問題，而這些問題測試時并沒有出現。經檢查，發現測試的版本不是部署的版本，不知道為什么老版本部署給客戶了。領導要追究責任，于是大家各有說法：
開發人員說：我是按要求打標簽的，沒有問題。
測試人員說：我是在提交區中取版本來測試的，我沒有出錯。
實施人員說：我是按照開發給我的版本去部署的，我沒有過失。
最后終于有人說：是之前已經離職的某某弄錯版本號導致的。

思考：

1.該事件反應了什么問題？將來應該如何改進？

2.這么多問題中，最大的問題是哪個問題？

在繼續往下閱讀之前，建議你先寫寫對以上問題的想法，然后再繼續閱讀。

本事件并沒有什么標準的答案，下面分析僅供大家參考，歡迎大家提出自己的想法！

 

作者：張傳波
www.umlonline.org

 

事件的補充說明：

這是發生在我以前公司的真實個案。第一次聽說時，我覺得很不可思議，也覺得非常的丟人！

客戶當前版本是1.1，我們打算為之安裝1.2版本，安裝后客戶反饋怎么以前已經解決的缺陷又再次出現了？檢查后發現，原來我們安裝的是1.0版本的程序。相當于大家辛辛苦苦地奮戰了數天，最后竟然沒有將工作成果給客戶，而是將以前的東西給客戶了。作為軟件公司來說，這是一個超級低級的錯誤！

經過檢查，終于發現了問題的真正原因：開發人員A讓實施人員B直接在他的電腦上取安裝程序，而不是根據研發流程的要求到配置庫中取，而該開發人員A讓實施人員B所取的版本，是1.0版本的老程序，而不是最新的1.2。這個原因主要是通過實施人員B得到的，但開發人員A已經離職了，“死無對證”！

似乎整個事件需要負責任的就是這位已經離職的仁兄，而該仁兄已經離職，更加是百口莫辯。我的領導對于這樣的結論，苦笑說：呵呵，這樣好，推到一個離職的人身上！

 

問題1：某些人員失職，沒執行流程！

開發人員A和實施人員B違反了相關規定，嚴重失職，應為此負責。而開發人員A已經離職，故應由實施人員B來負擔主要責任。這樣處理是否合適呢？

問題2：研發流程和公司制度有漏洞，應進一步改善！

研發流程雖然規定了要從配置庫中取安裝程序，但沒有版本確認的步驟，而且安裝程序應該由配置人員提供，而不應該由實施人員直接問開發人員要，這是流程中需要改善的。

于是配置管理員提出建議：規定所有的安裝程序只能由配置管理員提供，不能通過其他途徑！

但項目經理、開發、實施都反對，因為經常需要加班，往往在加班的時候需要提供安裝程序，但這個時候配置管理員往往已經下班了，無法向配置管理員要安裝程序。如果配置管理員就算沒事干都好，愿意一起加班的話，可以這樣規定。

于是配置管理員就再無意見了……

另HR提出，此事其實是開發人員A付主要責任的，出現這樣的問題原因之一是離職交接沒有做好，工作沒有檢查好。此意見一出，項目組、負責交接A工作的開發、同意A離職的部門經理，幾乎全部暈倒了！交接已經做得很不錯了，什么問題都要防住，你叫這個交接怎樣做？

研發流程和制度確實需要不斷完善，但如果老是從細節上規定，是不是有點本末倒置呢？研發工作中的問題總是很多的，不太可能規定所有細節的，而且一旦規定了一些細節，似乎避免了一個問題，但會帶來更多的問題。

問題3：喜歡做好好先生、好好小姐！

事件中其實很多人大概知道問題所在的，但就不指出來，不想得罪人，要做“好人”。如果要追求責任，那么最好將錯賴在一個不能追究責任的人身上，就是那位可能是很無辜的已經離職的仁兄?；蛘邔㈠e賴在制度和流程上，這招是最絕的，沒有人需要負責，這是制度的錯、社會的錯！

問題4：沒有人首先從自己身上找原因，每個人首先想到的是推卸責任！

研發工作中的很多成果，是經過一系列的環節和各人的配合作出來的，任何一個環節有問題，都可能會導致最終成果出問題。那似乎將各環節責任、流程等定義好，就可以很好地追求責任了？

如果某個環節都留下一些隱患，但不至于馬上出問題，但經過多個環節累積之后，問題爆發！這時應該哪個環節負責呢？

如果前面某個環節出現一些問題，但下一個環節的人發現了并及時提出來，最終不影響最終成果，這是不是一種很好的效果呢？

如果每個人除了做好本職工作，還主動提醒他人，主動提供一些有利于項目的建議，幫助項目成功，這是不是非常好呢？

軟件研發中的問題，往往不是某個環節造成的，而是各種因素作用逐步導致的。項目需要團隊一起努力、互相糾正、互相提醒，每個人都應該為項目的最終成功負責！某項目出問題了，是不是應該整個項目組都應該負責呢？是不是大家應該首先從自己身上找原因呢？

哪個問題更加嚴重？

個人認為問題4是最嚴重的問題，流程、制度、職責等這些，如果為了解決某一問題而去修改和細化，可能會陷入無休止的類似工作中。這和修復一個bug的道理是一樣的，每修復1個bug，可能會帶來10個bug。過于從細節上細化流程和制度，我個人是不太贊同的，會陷入某種死循環。

我們喜歡說依法辦事，往往用法律來比喻，我們研發過程也需要有法可依。法律規定的一般是不能做什么，但我們流程中規的的往往是必須做什么、應該做什么等，一旦規定應該怎樣做，就很容易出問題。研發活動是很復雜的智力活動，不應該在一些細節上套太多的框框條條。

做好團隊建設，樹立良好的團隊觀，項目團隊應該是“一榮俱榮，一損俱損”的！要打造這樣的團隊是不容易的，但也不是很難，其實取決于公司領導的管理思想。以目標來驅動，鼓勵創新，允許犯錯，獎勵自我批評，這些都有助于良好的團隊建設。但有些領導喜歡工廠化管理，喜歡將工作細化，喜歡根據工作職責來考核，喜歡根據問題多少來考核，這樣難以避免這些踢皮球事件了。

這個事件我有什么責任？

說了這么多別人的問題，我是不是應該從自己身上找找原因呢？
我不直接負責該項目工作，是公司的常務副總，公司中的大部分員工都是經過我面試進來的，我一直在盡力打造良好的團隊文化，而研發流程大部分是由我制定的，或者是經過我批準的。要興師問罪的是公司的大領導，不是我，其實如果要問起罪來，可以說公司內部的跟研發相關的所有問題，我都需要負責任！因為這些事基本上都是我管的。
出現踢皮球事件，我覺得很無奈。自己一直以來期望做到的團隊“一榮俱榮、一損俱損”，在事到臨頭的時候，只是一種口號而已，我需要檢討自己的做法和想法。那種美好的團隊建設可能只是一種烏托邦，可能難以實現甚至無法實現，但我覺得我還是應該繼續為之努力的。

其他的一些想法：

這只是一個小小的案例，但相信很多朋友會經歷過類似的情況。推卸責任可能是人的本能反應吧，我也會這樣。大家都能主動從自己身上找原因，這可能是一個遙遠的夢。

我曾經試過參加一個會，兩個高層在PK，老板在一旁看，PK一大通后，最后那項大家都不想干的工作落到了一直沒有出聲的我的頭上，剛才PK的兩個人，都一致同意讓我來做這項工作！我只能說：很無語……

有些事情我們可能控制不了，但如果咱們能帶領一個團隊的話，我們應該在能力范圍內做一些對團隊各人都有益的事情，盡量打造好的團隊氣氛，擋住影響團隊氣氛的外部的不利影響。對你的團隊成員好，將來得到的回報肯定會遠遠大于你的付出！

 

 

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