《專案百態 軟體專案管理面面觀》三模式總結

2021-08-20 03:09:41 字數 1216 閱讀 7948

《專案百態:軟體專案管理面面觀》三模式總結

其中顯著的表現為:他們混淆了對緊迫時間的響應和指的讚賞的響應。只要客戶提出了需求,不管是否能帶來收益(甚至不管有用沒有),都會立即轉化成專案,且通常截止日期會短的可笑。這個新專案自然會加重已經在超負荷工作英雄們負擔,使他們更加手忙較短,無限重複在緊急的過程中。

這種「心跳遊戲」型的行動是貿然的,思考極其的膚淺,其結果就是大部分工作都處在不斷變化,無法固定的狀態,需求永遠在變更的路上,沒有真正清楚要開發什麼,給誰用?盲目的去做,他們很明天就改變,緊迫性成為他們唯一的標準,沒有人嘗試按照重要性或者工作價值來給工作排定優先順序

對於「心跳遊戲」型組織,特效藥是不存在的,他們沒救了,除非取消那些令人心跳加速的任務,同時解雇經理,雇用那些明白「組織只有不再忙於處理突發事件才是最有效」的人。但是這很難,通常ceo希望看到組織長久的保持匆忙的狀態,工作匆忙會給人產生搞笑的幻覺。

​ 所以我們不要把所有的事情都變成緊迫的,緊急的,專案組裡不需要所有的人都去關注緊迫的,緊急的事情,杜絕讓自己的團隊變成這種文化的團隊,因為在這種團隊中你很難不被感染。​我們需要化緊迫性為優先順序與約束,必要的時候需要跟領導說「不」。

高效的團隊在會上就開始處理商定的事項, 

高效的團隊認為立即動手反而更容易。 

強團隊的表現:

相比弱團隊的表現

從開工起,專案就完全不可能完成目標,專案團隊中的大多數人都很清楚這一點,卻默默無言。

很多組織過於看重成功,所有任何表達疑慮的人都不會因為說真話得到任何獎賞。事實上,如果誰在專案的前期階段就聲稱死魚的存在,管理層 

的反應多半會如下:

「證明給我們看」,證明成功的可能性為零,或者拿其他成功的案例去睡服你,你必須用嚴密的邏輯與數學證明來告訴他,我們失敗無法避免。否則一旦你提出任何缺乏精確證據的東西,就會被指責為軟蛋或者是試圖逃避辛苦紮實的工作;你是軟蛋還是懶漢?你自己選吧。但是我懷疑你還能在這個奮鬥的組織裡待多久。

在這樣的環境裡,「努力」而無法完成任務比站出來說目標無法達到更安全。確實,有時候我們需要用於面對挑戰,在認輸之前真正的去拼搏一番。非常正確–但區別是,在又確定截止時間的艱難專案中,沒有人回熬到最後一刻才宣告情況的危急。那麼,我們每個人都要聞一聞專案有沒有出現什麼異味只要聞到一絲腥味,你就應該喊出來,因為你非常清楚,如果遇到「死魚」專案,不到最後時刻是沒有人說話的而「死魚」不僅給組織帶來破壞影響,其更加的挫傷了「死魚」專案圖案鬼成員和經理的士氣。無論組織文化如何,沒有人會覺得長期呆在發臭的「死魚」專案裡很舒服。嚴密封鎖「死魚」訊息的成本實在太高。

《專案百態 軟體專案管理面面觀》三模式總結

其中顯著的表現為 他們混淆了對緊迫時間的響應和指的讚賞的響應。只要客戶提出了需求,不管是否能帶來收益 甚至不管有用沒有 都會立即轉化成專案,且通常截止日期會短的可笑。這個新專案自然會加重已經在超負荷工作英雄們負擔,使他們更加手忙較短,無限重複在緊急的過程中。這種 心跳遊戲 型的行動是貿然的,思考極其...

軟體專案管理面面觀之「玩的就是心跳」

響了。我們想這週完成需求的規格說明書。你能過來看看可以做些什麼嗎?規格說明書怎麼了?我們很急,所以新招了許多人來寫規格說明書。我們覺得他們完全不清楚自己在做什麼。如果由我們來指導他們編寫需求,效率不是更高嗎?但是我們這週就需要規格說明書。好吧,我明天過來。兩個小時之後。你能過來看看我們的預估結果嗎?...

《專案百態》讀感系列」蘇式風格「

有些人問了,為什麼交付的產品包含了使用者要求的功能,卻不招使用者待見,很快就被擱置一邊了。喬幫主會這樣回答你,蘋果的產品能俘獲眾多使用者的心是因為注重使用者體驗,關注細節。在我們每個人的專案實踐中多多少少都會更關注需求,功能的實現,而忽視了使用者體驗。但是,請諸位先換位思考下,現在我是使用者,對於乙...