可以利用左方標籤分類 或 最上方 輸入關鍵字搜尋,方便您想看的內容
可點選 完整| 摘要|標題 改變文章顯示模式

2008年12月4日 星期四

到底誰的錯

常常 專案出問題了 就聽到:
專案負責人 說『都是你做不出來』『別人可以你為什麼不行』『能力很差』
工程師說『甚麼都沒給怎做』『講甚麼都不信 只聽自己想聽的』『不尊重專業』
到底 是誰的錯?

誰對誰錯,要先界定從那個角度來看,不然只是各說各話。
以專案的角度來看,我們可以說對整體專案有利的是對,不利的是錯。
這樣還是有點模糊,因此我們要更進一步理解專案的生命過程與不同的人在這過程這中的功能。
不同角色必然有他該有的責任與功能,否則不就是不必要的累贅?
因此對角色功能在專案過程中的作用與責任的正確理解,是專案運行能否順暢最重要的隱性因素,也是釐清問題所在的依據。(但多數人對組織設計與流程設計都沒有共同的理解,往往各自以自己的想法推想行事,當然是衝突連連外加恩怨情仇。去問專案中不同的人,為什麼專案要設定不同的階段,通常你都不會有一樣的答案---如果還有人回答的話。)

正確的專案管理會包括 ,需求訂立、 可行性評估 、設計實做、 驗證這個過程。
或許教科書裡這個過程已經是耳熟能詳,但真正落實每個過程要義的專案卻是鳳毛麟角。
越是前端的決定越是影響重大,這是任何人仔細想想都會同意的事實。
但如果我們仔細看看多數產品的開發,前端的決策都通常是怎麼做的呢?
越前端的部分越是沒有實體,越後端越實體化。
一開始產品不過就是要具備甚麼規格的概念而已,但後端才實際摸的到的東西。
但一切通常已在前端決定了,前端做的錯誤的判斷,後端實體只是呈現這個錯誤罷了!
我們通常看到的前端只是少數人 用喊的,可行性評估在哪?
這點在個人的經驗裡,在傳統的歐美公司做的比較好;台灣多數公司這段做的都不夠充分。
(跟產業發展歷史以及文化性格都有關係)
如果做不出來,再炫的點子也只是海市蜃樓,甚至是白花時間金錢的鬧劇。

一個理想的管理文化是專業分工的,是專業導向而不是階級導向。
譬如『經理』這職稱以專業分工來看指的是工作內容以調度、協調、控管為主;並不是職位位階的問題。但中國人的組織裡,往往都仍帶有強烈的階級意識(官大學問大,經理=官)。
換個方式說比較清楚,若設有專案管理部門,那麼專案管理部裡人人都是專案經理,但以階級位階來說,這專案經理與工程技術部門中的工程師是同等位階。專案管理部經理的位階才與工程技術部經理位階相同。有這點認知才能去除階級意識對於責任劃分的干擾。

在可行性評估階段,各相關專業要提出的是 ,有沒有甚麼風險因素 、有多高 、要克服需要的條件 等等 (在性能 時間 成本 三方面的評估) 。
因為專案負責人專注於整體專案控管,不可能親自負責工程技術細節,專業部門的責任就是盡專業能力提供正確工程判斷資訊。
專案負責人的責任是就各專業提出的問題在專案目標下權衡輕重,取得平衡。

如果專案負責人不理會專業提出的風險,萬一後段證實此風險時,責任事實上是在專案負責人身上。 只是一昧的說,不管就是要解過,或是『要保持正面,不能說做不到』等等帽子,只不過是不願負擔決定責任,掩耳盜鈴的說法。

但要強調的是,專業當然有專業的責任。如果專業能力不夠,所以甚麼都說不能做,當然沒有人會相信專業提出的意見。因此專業的意見提出,必須有根據,有道理;也不能說『我覺得就是這樣』,要有可信的論據。

因此,專案責任的區分,事實上可以很清楚。每個階段每個階段的目的,每個專業的任務,提出的意見,做成的決定等等,都應該具體如實的紀錄。當專案結束,檢討過程時,依據實際上的問題對照過程,可以很明顯的界定原因。

簡單說,如果專業說不能,專案負責人不理會,硬幹,結果證實失敗,責任在專案負責人;
除非能舉證同樣的條件有其他人做的到,如果這樣,是專業水準不夠。
如果專業說能,最後卻做不出來,當然是專業水準不夠。

專案管理的程序本來就要定清楚,記錄清楚。這樣責任區分是很明顯的。
但多數人仍然只是避事怕事,爭功諉過,用各種非技術非事實的方式互相推諉,從不想把事情講清楚劃分明白,或許,一旦劃分明白就沒有閃躲的空間了吧。

copyright by Y.W.T.
.-

沒有留言:

張貼留言

還有其他文章喔. 請利用左上側標籤分類, 或右側較舊文章,進一步觀看。