他其實是一本書名叫做「最後期限—專案管理的 101 個成功法則」，但有礙於名稱太過矯情，所以簡化了一下。能夠寫出這本書的作者診的不簡單，能夠用故事的方式說明管理所會遇到的一些困難，讓我們用情境去學習，是值得翻一翻，當作軟體開發管理的好書。
這本書已經具有敏捷開發以及扁平式管理的概念，所以是現代喜歡扁平式管理的人可以去閱讀的。這些是我對於這本全部的內容所做的整理：
專案管理是什麼？為什麼在現在的社會，總是到處聽到他的名稱，究竟，專案管理為什麼重要，為何存在，在下面的文章會為大家細細解答。現在，就跟著我們的想像來管理專案吧！
想像你現在正在一個砲聲隆隆的戰場，你的手中拿著一個望遠鏡，正在窺探敵軍的走向，一切的動向都在你的預測中。敵軍的先鋒部隊正如預料的走向山谷，敵方的偵察機在十分鐘前尚未靠近基地就被摧毀了，你現在所需要做的就是等待，讓所有的事情如你預料的前進。忽然，你發信給哨兵，告訴前線的將軍更改一些戰術，之後，你慢慢放下望遠鏡，看著戰爭，在你的手掌間開打。這就是戰爭中管理的重要，而你，就是專案戰爭中的專案管理者。
專案管理者最大的功能，就是營造一個環境，創造一個氛圍，讓所有團隊裡的成員都有合適的環境可以做出好成果。幸運的話，他們就會成為最頂尖的團隊。要讓團隊知道，他們在某個領域是頂尖的，就算他們不好，也要讓他們有核心理念。一個團隊，最重要的就是要團隊擁有「靈魂」，讓他們覺得，自己的存在獨一無二，此時此地，自己選擇在這裡的努力，是值得的。專案管理者需要的並不是操控，而是領導與校準。
既然說到的專案管理者，那就不免俗要說到管理的核心理念。最常遇到的困擾有下列這四種：
- 選擇好員工：人資的重要。
- 為他們分配對的工作：把對的人放在不對的地方，傷害大過一個平庸的人。
- 讓他們保持積極：所有團隊都會面臨到的核心問題，讓他們覺得自己的工作有意義。
- 幫助團隊凝聚起來，並維持凝聚力：這就是為什麼一個好的團隊會遠勝於很多明星員工的團隊。
- 把專案掌握在手中：如何控制專案的時間與成本。
選擇好員工：
在開始一個專案前，最重要的就是找到好員工。而找一個好員工就像選一部好電影，一個影評未免太過偏頗，兩三個影評才能從不同的方向看同一部好電影，也才不會被偏見埋沒。重點是，好的電影可能還有相關的好電影，所以，不訪問問好的員工，他身邊可能也有好的人才。先把需要的材料準備好，面試才有效率，結果才能更好。
此外，多聽，少說。如果在面試時雙方沈默，別因為尷尬就嘗試說一些什麼，讓有潛力的面試者說些什麼，通常這段尷尬，是讓有潛力的面試者證明自己的時候。
分配對的工作：
先說，絕對、絕對、絕對不要讓一個組織的人數超過九個人，我們可以知道當人數上升時，每一個人的溝通成本就會呈指數上升，兩個人的溝通只需要一個對話框，九個人的溝通管道就需要三十六個對話框，資訊的傳遞效率就會極差。更好的方式是，讓每一個人的資訊都能讓別人知道：像是討論室別設立個別辦公室，讓大家的意見可以快速交流。在會議室加上一塊專案進度表，讓每一個人都可以追蹤整個專案的進度，也可以讓專案透明化，減少許多不必要的溝通成本。有好的工作人數後，我們才能開始降低風險與生產力。我們常常聽到豐田模式，這樣的生產流程就是很多公司想要成為的，但是，如果把改善流程當成目標而非手段，嘗試在短時間內改善效率，實際上只是浪費時間。所有的流程改善都是「長期的」，需要時間及成本去做流程改善。因此我們可以知道，要讓一個團隊磨合並擁有高效率，是需要時間的，所以現成的團隊（已經有默契的團隊），會遠比新團隊好。
為什麼短期內沒辦法做出流程的改善呢？因為在一天的時間中，可以改善一些效率，但是不多，而且如果為了效率而嘗試減少錯誤，員工就會因為害怕犯錯，而做一些保健性的改善（一些基本工作），因此並沒辦法大幅改善效率。能夠減少的只是非系統性浪費的時間。控制失敗，遠比優化成功更能提高績效。
但是，這並不代表就不需要做大幅的流程改善。好的流程與持續的流程是很好的目標，但是是指對於長期而言。但是，專案的確可能從「單一的」、謹慎選擇的方法中獲得足夠收益，並抵消為這次改善所付出的時間與金錢。
有標準的流程是好的，但是過於局限於標準流程，就會失去走捷徑的機會。
專案管理，要控制的風險，就是系統性，或稱為「根源性」風險，但是像「時間來不及交付」、「成本開銷太大」，這只是我們看到的結果，我們要控制的是「原因」，也就是「根源性」的小風險。開發專案不可能沒有風險，專案管理就是要控制「根源性」的風險，所以我們需要在問題開始時，就發覺這個問題，這時可以雇用一個「風險控制人員」，並為專案建立風險統計表。此外，也讓問題發生時壞消息可以傳播到主管或高層，建立一個沒有恐懼的企業文化。還有一個有趣的觀點，就是如果風險空管人員傳播給員工「我能行」的想法，也就間接代表說明「沒完成，代表你不行」一樣會產生類似的效果。
像是半匿名制就是不錯的方式：
準備一個帳號可以讓大家偷偷提供問題，讓大家可以老實的提意見，當然會有惡意攻擊的問題，但是當我們需要他時，他的價值就無限。
對於新的僱員，不要一開始就給超過他成功難度的專案，要讓他先完成他相等難度的專案，之後再讓他嘗試更具有挑戰性的專案，把有挑戰性的專案延到下一次。
當人在一個地方工作，他們必須要感受安全，才有可能做出一些冒險與變化。同理可證，如果使用威脅的方式，或是濫用自己的職權去管理員工，會讓成員沒有自信。最嚴重的點在於，如果他們真的沒有達到目標，你還必須執行懲罰。一開始的時間不足，就算趕鴨子上架，也還是做不完，最重要的就是動態限制。動態，在一個專案是勢必存在的。
那是不是代表，如果避免掉這些風險，團隊就可以安然無憂？然而，這樣的思維其實非常危險，因為只要在執行一件偉大的專案，那就不可能逃避風險，因為偉大，總是伴隨著風險。
現存的管理書籍，強調的是存在於團隊中的規章制度，但這樣為什麼不能被成功的複製到不同的組織？因為團隊的組成，是人。團隊人員間的每一個互動、溝通、信念，都是影響團隊成功的關鍵。別忘了，團隊也是一個系統，只要工廠的精神還在，那再蓋一間並不會多困難；只要政府制度不改，就一定還會被推翻。
就算已經有萬全的準備，組織內還是會有只注重自己利益的人，會影響到專案的進行，甚至會影響到人員的編排。
把專案掌握在手中：
在專案估計的速度上，「功能點（Function Point）」扮演了一個很重要的角色，他能讓你較有系統性的估計團隊的速度，也能因而預估專案的完成期限。但有趣的是，功能點並無法直接被衡量，他只能透過而要有一個好的模型估計專案，就需要把自己的直覺量化成程式的系統或是實質的參考資料，這樣最後才能有效的去計算實際情況（當然一開始模組是不準的，藉由後面加入的資料慢慢修正）
有了功能點，接下來最重要的就是隨時把已經做過的歷史資料與所需時間做數據分析，算出每一個功能點需要的時間，這樣才能有效預估專案的整體速度與效率。也可以借助資料庫，把預期的工作量畫成一條趨勢線並借用他估計專案大小，相同的，周圍的震盪可以打它納入允許誤差範圍。這時，可以不斷的修正方程式，直到方程式與現實有很大的相關性。
再來就是開會了，想必大家對於這個內容又愛又恨，開會是所有的組織解決問題必要的手段。但要怎麼避免成為人人眼中害怕的冗會呢？下面有幾個技巧可以告訴大家：
- 在開始會議之前，要先有一份明確的會議議程，經確定義這次的開會要解決什麼樣的問題。以及誰可能需要參與會議，但是要讓大家都知道所有的會議議程及內容。
- 在解決所有的問題前，要先徵求大家的同意，讓大家同意某人解決問題。
- 在知道現場的與會者後，如果發現人數過多，在決定完要討論的東西，就可以讓沒有事的人離開—會議越精簡，越成功。
- 讓某些人離開，是為了讓他們更有生產力，讓他們去做真正有意義的事，而非代表他沒有能力，再請他們離開時務必說清楚。
- 在離開時加個「臨別贈言」，要讓與會者說出他對這次開會的期望，在同意他們離開後，加上一個拍三下手或是敲桌子的儀式，這個非常重要，讓離開的人覺得他們是光榮的。
很多的專案是關於軟體設計的，這邊就提供大家一些有關軟體專案的小技巧：
- 別管高階設計，幾乎所有的高階設計都沒辦法實際轉換成產品，只能透過低階設計時的才開始思考產品。所以，把真正的打程式的時間延後，把低階設計做到好，這樣才不會再組裝產品時發生大問題。而且大多數的 Bug 都是發生在產品功能的銜接上，有些程式的衝突會讓原本個別運作的程式，只要組合在一起就毀掉了。
- 軟體除錯的時間會佔掉一大半的時間，所以儘可能地減少除錯的時間—代表就要增加設計的時間。
- 這條也適用在其他行業：別加班！別加班！別加班！
- 管理文件的規格模糊，代表之中存在不被看見的衝突。
- 如果一份規格文件不存在輸入與輸出，那這份文件就什麼都還沒開始。但是朋友們，當心了。當人嗯看不懂文件時，往往是先質疑自己，而非質疑文件。
- 如果在前面的低階設計（只所有的輸出與輸入的架構，所有的模組都已經詳細的設計過了）已經夠完整了，而完整的設計造成組件內部錯誤的機率是很低的，所以當在設計完成一半後，就可以嘗試取消程式檢驗，而只做程式功能接合時的測試。
激勵員工：
如果不關心別人、不照顧別人，就別想讓他們為你做一些非凡的事，如果要讓他們改變，就必須要去了解並讚賞他們。
還有在管理之中，絕對不要開罵，因為憤怒是會傳染的，而被罵的員工，其實並不會變得更好—你有看過被打的狗很開心？如果經理用打罵的方式管理員工，只是顯示經理的無能，因為他找不到其他的方式管理。
當然，不可能有不會吵架的團隊，而這樣的衝突絕對是必要的。在建立、安裝系統的地方衝突特別多（因為會有根基上的意見不同）。那遇到了衝突難道就只能等他們雙方降火？其實不然，我們應該要在衝突剛開始時，就要開始調解（而非談判），別拖。而要解決的是問題。
結語：
其實，一直以來我都在擔心我不是個襯職的領導者，因為在座的每一位並不完全知道我剛剛跟你們分享的這些內容，是在經歷一次渡末團隊的失敗後的領悟，坦白說，這次的內容是出於自私，我說的這些內容，其實是出自於曾經討厭管理位置的人整理出來的。在我看來在做的一些人，在團隊中總能扮好自己的好角色，但我想更重要的是，這些問題在每一個人的未來都有可能遇到，到時可能的迷失與茫然...相信我，連我都能熬過當時的困境，並去擁抱他，我相信你們也可以。希望大家在之後的每一個團隊，都能換一個方式思考。
沒有留言:
張貼留言