《小Team 專案管理》第二問 --- 專案經理是救火隊長？

標籤：style   blog   http   color   os   資料   

       在一些企業中常常會發生這種事情，公司業務繁忙，項目堆積成山，Team Dev總共也就六七個人，恨不得一個人當兩個人使，行內話稱：”女人當做男人使，男人當做牲口使“，急於改變現狀的專案經理更是焦頭爛額，滿腦子的念頭就是”怎麼辦？怎麼辦？？？“。好吧看來我須要參與進來了，於是挽起袖子開始了一次《速度與激情》的編程之旅。

      

       那我問你，你的準備工作做好了嗎？你是最初接觸項目需求的人，可能在你的腦海裡，你的筆記本上畫滿了各種各樣的符號，圖示，用例，你的電腦上有各種各樣的UML，一切看起來都是那樣的個性和專業，請問你有沒有想過你明確的需求，你手下的員工有沒有明確，你可能會鄙夷的的告訴我：“嗱，這不是都給他們了嗎！“；好吧那我們如今就看看你給手下成員的”需求說明吧！“

          

 

       很不錯，看來你對xmind用的很熟練，上面總共分為七大功能塊，每一個功能塊有相應的查詢項目和資料編輯項目，除了滿篇的刪除操作外，我想我和其它員工一樣從中僅僅能擷取這種資訊量，試問使用者資料都是很重要的，我能這樣輕易地刪除資料嗎，第一個問題：這些資料要不要進行備份，備份的模式是什麼移動到備份表還是在表中加入欄位進行假刪除操作？第二個問題：多個關鍵詞的標籤合并，有沒有牽扯一些規則，還是說全部隨意的幾個關鍵詞我能夠隨意進行合并？第三個問題：郵件發送可選，那麼郵件發送的頻率有沒有限制，發送的時間有沒有限制等等等等……

       當這些問題接踵而至出如今基層開發人員腦中的時候，他們又會以何種方式去處理呢？經過我的經驗大概有這樣幾個情境：

（1）、程式猿A（思維明銳，善於交流型）：直接去找專案經理，這塊的需求應該詳細是什麼樣？然後專案經理開始了滔滔不絕的解說。

（2）、程式猿B（思維明銳，不善於交流型）：展示我能力的時候到了，既然是刪除，這種需求又不明白那我把假刪除和資料備份的方式都做上吧。

（3）、程式猿C（思維遲鈍，不善於交流型）：刪除就刪除，功能看起來非常easy，早就想把那些煩人的資訊所有刪除掉了，然後一個delete語句搞定。

（4）、滑頭型（喜歡照貓畫虎，鑽空子）：這個功能先放一下先做其它的，等A,B,C做好了這些我隨便問一下他們調個介面不就完事了嗎，看我多聰明。

      一個月後，客戶怒氣沖沖的打來電話，“張總，我僅僅是點了一下button為什麼我全部的客戶資料都沒有了，你們這種產品我還敢用嗎.. ….“。

       看看吧，你還覺得你的“需求文檔“是這種完美嗎？當一個項目這樣走下去的話，那麼不單單是項目的生命週期要截止了，我想連公司和老闆的生命週期也要截止了吧，假設你老闆心寬也許會躲過一劫。

       通過上面的範例我們應該可以深刻的體會到一個詳盡完好的需求說明，對於項目開發工作來說是多麼重要的一件事情，建議一些團隊在項目開發前讓每一個人都能對項目涉及的需求，功能有一個明白的認知，或者文檔說明，或者立會學習，類比探討，鼓舞員工瞭解業務。古語云：“磨刀不誤砍柴工“，假設需求不明白即便是都遇到像A這樣稱職的程式猿不厭其煩的奔波於你和他們的辦公桌之間，我想整個團隊的工作效率將大打折扣，事與願違，得不償失。

       而相對一個項目的管理者，你的職責和本分是管理好項目，做好項目的總體控制，而不是挽起袖子去進行實際操作，你見過打仗的時候打仗元帥充當敢死隊隊員的範例嗎？有時候不要浮於表面的努力，不要去時時刻刻充當救火隊長的角色，假設遇到資源不夠的情況，既然公司是為了趕時間盈利，就應該和老闆去討論進人的事宜，我想迫於你的專業性和壓力應該可以說服老闆，《代碼之殤》中寫的非常好，死亡行軍僅僅會導致更糟糕的代碼和品質，僅僅會換取團隊成員的萎靡不振，其它什麼也做不到，個人認為一個公司假設專案經理撲在編碼上抽不開身，不能從全域把控團隊的運作，那這個公司不管是管理還是運作一定非常混亂。

      不知道大家是否也有同感，如有問題能夠留言討論，謝謝。