案例分析:項目組內(nèi)踢皮球事件
作者:網(wǎng)絡轉載 發(fā)布時間:[ 2011/11/15 14:22:09 ] 推薦標簽:
你的項目出了嚴重問題,客戶向你公司的領導投訴,你的領導興師問罪要追究責任!這是測試的錯?開發(fā)的錯?PM的錯?還是研發(fā)流程的錯?中國教育制度的錯?社會的錯?反正、總之、一定、必須不是我的錯!
事件回放:
某項目部署給客戶后,重現(xiàn)了一些以前已經(jīng)解決的問題,而這些問題測試時并沒有出現(xiàn)。經(jīng)檢查,發(fā)現(xiàn)測試的版本不是部署的版本,不知道為什么老版本部署給客戶了。領導要追究責任,于是大家各有說法:
開發(fā)人員說:我是按要求打標簽的,沒有問題。
測試人員說:我是在提交區(qū)中取版本來測試的,我沒有出錯。
實施人員說:我是按照開發(fā)給我的版本去部署的,我沒有過失。
后終于有人說:是之前已經(jīng)離職的某某弄錯版本號導致的。
思考:
1、該事件反應了什么問題?將來應該如何改進?
2、這么多問題中,大的問題是哪個問題?
在繼續(xù)往下閱讀之前,建議你先寫寫對以上問題的想法,然后再繼續(xù)閱讀。
本事件并沒有什么標準的答案,下面分析僅供大家參考,歡迎大家提出自己的想法!
事件的補充說明:
這是發(fā)生在我以前公司的真實個案。第一次聽說時,我覺得很不可思議,也覺得非常的丟人!
客戶當前版本是1.1,我們打算為之安裝1.2版本,安裝后客戶反饋怎么以前已經(jīng)解決的缺陷又再次出現(xiàn)了?檢查后發(fā)現(xiàn),原來我們安裝的是1.0版本的程序。相當于大家辛辛苦苦地奮戰(zhàn)了數(shù)天,后竟然沒有將工作成果給客戶,而是將以前的東西給客戶了。作為軟件公司來說,這是一個超級低級的錯誤!
經(jīng)過檢查,終于發(fā)現(xiàn)了問題的真正原因:開發(fā)人員A讓實施人員B直接在他的電腦上取安裝程序,而不是根據(jù)研發(fā)流程的要求到配置庫中取,而該開發(fā)人員A讓實施人員B所取的版本,是1.0版本的老程序,而不是新的1.2.這個原因主要是通過實施人員B得到的,但開發(fā)人員A已經(jīng)離職了,“死無對證”!
似乎整個事件需要負責任的是這位已經(jīng)離職的仁兄,而該仁兄已經(jīng)離職,更加是百口莫辯。我的領導對于這樣的結論,苦笑說:呵呵,這樣好,推到一個離職的人身上!
問題1:某些人員失職,沒執(zhí)行流程!
開發(fā)人員A和實施人員B違反了相關規(guī)定,嚴重失職,應為此負責。而開發(fā)人員A已經(jīng)離職,故應由實施人員B來負擔主要責任。這樣處理是否合適呢?
問題2:研發(fā)流程和公司制度有漏洞,應進一步改善!
研發(fā)流程雖然規(guī)定了要從配置庫中取安裝程序,但沒有版本確認的步驟,而且安裝程序應該由配置人員提供,而不應該由實施人員直接問開發(fā)人員要,這是流程中需要改善的。
于是配置管理員提出建議:規(guī)定所有的安裝程序只能由配置管理員提供,不能通過其他途徑!
但項目經(jīng)理、開發(fā)、實施都反對,因為經(jīng)常需要加班,往往在加班的時候需要提供安裝程序,但這個時候配置管理員往往已經(jīng)下班了,無法向配置管理員要安裝程序。如果配置管理員算沒事干都好,愿意一起加班的話,可以這樣規(guī)定。
于是配置管理員再無意見了……
另HR提出,此事其實是開發(fā)人員A付主要責任的,出現(xiàn)這樣的問題原因之一是離職交接沒有做好,工作沒有檢查好。此意見一出,項目組、負責交接A工作的開發(fā)、同意A離職的部門經(jīng)理,幾乎全部暈倒了!交接已經(jīng)做得很不錯了,什么問題都要防住,你叫這個交接怎樣做?
研發(fā)流程和制度確實需要不斷完善,但如果老是從細節(jié)上規(guī)定,是不是有點本末倒置呢?研發(fā)工作中的問題總是很多的,不太可能規(guī)定所有細節(jié)的,而且一旦規(guī)定了一些細節(jié),似乎避免了一個問題,但會帶來更多的問題。
問題3:喜歡做好好先生、好好小姐!
事件中其實很多人大概知道問題所在的,但不指出來,不想得罪人,要做“好人”。如果要追求責任,那么好將錯賴在一個不能追究責任的人身上,是那位可能是很無辜的已經(jīng)離職的仁兄。或者將錯賴在制度和流程上,這招是絕的,沒有人需要負責,這是制度的錯、社會的錯!
問題4:沒有人首先從自己身上找原因,每個人首先想到的是推卸責任!
研發(fā)工作中的很多成果,是經(jīng)過一系列的環(huán)節(jié)和各人的配合作出來的,任何一個環(huán)節(jié)有問題,都可能會導致終成果出問題。那似乎將各環(huán)節(jié)責任、流程等定義好,可以很好地追求責任了?
如果某個環(huán)節(jié)都留下一些隱患,但不至于馬上出問題,但經(jīng)過多個環(huán)節(jié)累積之后,問題爆發(fā)!這時應該哪個環(huán)節(jié)負責呢?
如果前面某個環(huán)節(jié)出現(xiàn)一些問題,但下一個環(huán)節(jié)的人發(fā)現(xiàn)了并及時提出來,終不影響終成果,這是不是一種很好的效果呢?
如果每個人除了做好本職工作,還主動提醒他人,主動提供一些有利于項目的建議,幫助項目成功,這是不是非常好呢?
軟件研發(fā)中的問題,往往不是某個環(huán)節(jié)造成的,而是各種因素作用逐步導致的。項目需要團隊一起努力、互相糾正、互相提醒,每個人都應該為項目的終成功負責!某項目出問題了,是不是應該整個項目組都應該負責呢?是不是大家應該首先從自己身上找原因呢?
哪個問題更加嚴重?
個人認為問題4是嚴重的問題,流程、制度、職責等這些,如果為了解決某一問題而去修改和細化,可能會陷入無休止的類似工作中。這和修復一個bug的道理是一樣的,每修復1個bug,可能會帶來10個bug.過于從細節(jié)上細化流程和制度,我個人是不太贊同的,會陷入某種死循環(huán)。
我們喜歡說依法辦事,往往用法律來比喻,我們研發(fā)過程也需要有法可依。法律規(guī)定的一般是不能做什么,但我們流程中規(guī)的的往往是必須做什么、應該做什么等,一旦規(guī)定應該怎樣做,很容易出問題。研發(fā)活動是很復雜的智力活動,不應該在一些細節(jié)上套太多的框框條條。
做好團隊建設,樹立良好的團隊觀,項目團隊應該是“一榮俱榮,一損俱損”的!要打造這樣的團隊是不容易的,但也不是很難,其實取決于公司領導的管理思想。以目標來驅(qū)動,鼓勵創(chuàng)新,允許犯錯,獎勵自我批評,這些都有助于良好的團隊建設。但有些領導喜歡工廠化管理,喜歡將工作細化,喜歡根據(jù)工作職責來考核,喜歡根據(jù)問題多少來考核,這樣難以避免這些踢皮球事件了。
這個事件我有什么責任?
說了這么多別人的問題,我是不是應該從自己身上找找原因呢?
我不直接負責該項目工作,是公司的常務副總,公司中的大部分員工都是經(jīng)過我面試進來的,我一直在盡力打造良好的團隊文化,而研發(fā)流程大部分是由我制定的,或者是經(jīng)過我批準的。要興師問罪的是公司的大領導,不是我,其實如果要問起罪來,可以說公司內(nèi)部的跟研發(fā)相關的所有問題,我都需要負責任!因為這些事基本上都是我管的。
出現(xiàn)踢皮球事件,我覺得很無奈。自己一直以來期望做到的團隊“一榮俱榮、一損俱損”,在事到臨頭的時候,只是一種口號而已,我需要檢討自己的做法和想法。那種美好的團隊建設可能只是一種烏托邦,可能難以實現(xiàn)甚至無法實現(xiàn),但我覺得我還是應該繼續(xù)為之努力的。
其他的一些想法:
這只是一個小小的案例,但相信很多朋友會經(jīng)歷過類似的情況。推卸責任可能是人的本能反應吧,我也會這樣。大家都能主動從自己身上找原因,這可能是一個遙遠的夢。
我曾經(jīng)試過參加一個會,兩個高層在PK,老板在一旁看,PK一大通后,后那項大家都不想干的工作落到了一直沒有出聲的我的頭上,剛才PK的兩個人,都一致同意讓我來做這項工作!我只能說:很無語……
有些事情我們可能控制不了,但如果咱們能帶領一個團隊的話,我們應該在能力范圍內(nèi)做一些對團隊各人都有益的事情,盡量打造好的團隊氣氛,擋住影響團隊氣氛的外部的不利影響。對你的團隊成員好,將來得到的回報肯定會遠遠大于你的付出!
相關推薦

最新發(fā)布
性能測試之測試環(huán)境搭建的方法
2020/7/21 15:39:32軟件測試是從什么時候開始被企業(yè)所重視的呢?
2020/7/17 9:09:11Android自動化測試框架有哪些?有什么用途?
2020/7/17 9:03:50什么樣的項目適合做自動化?自動化測試人員應具備怎樣的能力?
2020/7/17 8:57:06幾大市面主流性能測試工具測評
2020/7/17 8:52:11RPA機器人能夠快速響應企業(yè)需求,是怎么做到的?
2020/7/17 8:48:05Bug可以真正消滅嗎?為什么?
2020/7/17 8:43:03軟件測試基本概念是怎么來的?軟件測試生命周期的形成歷經(jīng)了什么?
2020/7/16 9:11:10