林金地 / 效能定律管理顧問
0935-297174、0983-554042
有一個客戶標到一個公家的大型資訊系統開發案，派了一位專案經理帶領十幾位工程師進駐客戶處進行相關的作業。基於我有PMP國際專案管理師與ISO 27001資訊安全證照之故，被委任為本專案的專案顧問。本案有幾十項模組，由專案經理分配那些人負責某幾項模組，進行分工開發，先期作業是做使用者的系統需求分析SA的訪談。
在第一次與客戶開會也是我第一次參與檢討會議時，主席要求專案經理報告專案的執行進度。此時，專案經理報告了每一個工作小組的需求訪談進度，並且表示：「有許多單位的需求訪談進度有嚴重的落後現象…」，於是主席長官就開始質詢相關單位，為何不積極配合承商的訪談進度？在主席長官面前，可以感受到各個單位的人員，開始啟動了：「自我保護的心態」，陸續的表達自我防衛的訊息，包括有：
1.
我們跟他們工程師講，但是他們工程師都聽不懂。
2.
他們也有程式設計師跟隨主談者卻不寫筆記，只有主談者有做筆記而已。
3.
我們花了1~2個小時跟他們工程師講，結果幾天後回報的記錄卻只有幾行字。
4.
到底我們還要安排多少的訪談次數，要不要訂上限，這樣很浪費我們的時間ㄟ。
5.
我們已經很盡力配合了，都是承商的問題，不是我們的問題。
過程中，只見專案經理很卑微的回應：「是，我們會再教育訓練，我們會改進…」。此時，我實在是看不下去了，我知道：「一旦專案團隊一開始就被業主看不起，以後會很麻煩，甚至會很難驗收」，於是我開始發言，發言的重點如下：
1. 請每一個受訪談的單位，先釐清自己的需求範圍，並列出需要訪談的大綱。
2. 每一次受訪前，受訪談的單位要交付相關的圖、文、表或流程。
3. 請專案經理製作：「訪談通知」，在需求訪談前先發給業管單位。
4. 請業管單位協調系統需求訪談的時間、有哪些與會人員、訪談的時段、確認該次
的需求訪談會佔該單位需求訪談總範圍的百分比，如此即可釐清該次需求訪談之後，可能還要剩下多少百分比的內容尚未完成訪談，即可掌握訪談的次數。
5. 如果系統需求訪談之前，相關單位沒有交付應該交付相關的圖、文、表或流程，承商有權利拒絕前往進行需求訪談。
6. 每一次的系統需求訪談，必須當場做記錄，就算手寫或鬼畫符也沒有關係，只要訪談者與被訪談者雙方都看得懂，並且有共識即可。
7. 每一次的系統需求訪談之後，要訪談者與被訪談者雙方都要簽名，也需要專案經理簽名確認本次需求訪談的成果。
8. 如果被訪談者認為訪談者沒有充分了解他們的陳述內容，必須當場提出進行指正，無須等到開會的時候再來反映。
9. 每一次的系統需求訪談都應該有過程的錄音，以利事後進行記錄正確性的比對。
10. 每一次的系統需求訪談記錄，應於隔天打字好之後，交付電子檔給業管單位。
11. 資訊人員與使用者的溝通本來就不容易，因為使用者聽不懂資訊的規格語言。
12. 故要求專案經理製作：「訪談記錄」，於每一次的系統需求訪談時，直接轉換成資訊的語言紀錄，包括：「應該有哪些『新增』、『修改』、『刪除』、『查詢』的功能、『欄位名稱』、『欄位長度』及所需要的『報表』」等。
如上的發言，於會議中已經獲得大家的共識後，我回到辦公室，看一下會議紀錄，赫然發現：「我們在會議中談了很多，但是工程師所做的會議紀錄，居然只有幾行…」。於是，我終於了解為什麼客戶會有如上的抱怨了！我向專案經理說：
找對的人，做對的事！
不是哪一組人負責哪一些模組的開發，就一定要該組人去做系統需求分析SA的訪談工作，如果該組人員沒有口條清楚與擅長於溝通協調及撰寫筆記的人，不應該叫他們去做系統需求分析SA訪談的工作。因為，口才與細心度有一半以上是天生的人格特質，尤其資訊人員多半很年輕，社會歷練有限，如果會技術沒有口條清楚與擅長於溝通協調及撰寫筆記的人，是無法在短時間內作訓練補足的，應該就讓他們專心寫程式即可。所以，趕快找出幾個口條清楚與擅長於溝通協調及撰寫筆記的人，讓他們全程統包整個系統的需求分析SA的訪談工作。我也特別交代專案經理：「此刻PM最重要的工作是掌握客戶的需求與驗收標準，而不是自己跳下去寫程式，如果專案需求與驗收標準不夠清楚，將來可能會面臨程式修改，甚至無法驗收的窘境」。
「找對的人，做對的事！」，意旨在發現每一個人的優點與興趣，善用某人的優點去做他可以把交付的工作做得很好的資源配置。談到這裡，老闆說：「總是要讓不會的人去做，才有讓他學習的機會啊!」，聽起好像來也沒錯，我反問老闆：「你觀察這麼多年來，有多少比率的人，你勉強他們去做不熟悉或沒興趣的工作，而最終真的把交付的工作做得很好的?」，老闆停頓了一會，發現有些事真的是勉強不來。尤其是中小企業，如果可以，直接找對的人，善用每一個人的優點，才是最佳的用人方案，更不要想去改變別人，如果沒有重大的衝擊，每一個人要改變原有的人格特質，其機率是不高的。
沒有留言:
張貼留言