太需要有一個結果來證明我的能力了。

4年多前，具有綜合專業背景的我離開資訊產業部的研究所來到了一家民營的醫療器械企業，任研發中心的臨床資訊系統專案經理，但萬萬沒想到，我所主持的技術研發專案的失敗，卻不是因技術不過硬的原因。

上層分歧給專案帶來麻煩
我剛來的時候，這個專案已經立項了，只是一直沒找到合適的人來實施。總覺得我是在受命組建一個新的部門，組織文化是空白，不會有任何問題的，可是上層的一些分歧卻給我的工作帶來了麻煩。
公司的總經理和技術副總在工作上有矛盾。作為總經理招來的部門級主管，我在上班前一直沒與技術副總見過面，不知道這是不是算總經理犯的一個錯誤，雖然越級的人事安排也許有他的考慮。
總經理介紹了他的一個同學作為我們的技術合作單位，我開始與其有一些初級的技術交流，技術副總一次偶然得知此事。於是我有了一大罪過：“你們探討的問題都是代表公司的，到底誰是技術副總？
總經理找我談話時，我好半天沒緩過氣來。如果就資料庫內某個欄位的定義、用哪個晶片更好點的問題都要請示技術副總，我這個崗位還有存在的價值嗎？
我開始反思，認識到自己犯了一個很嚴重的錯誤：初來乍到，別人還沒認清你的特點，信任度還沒建立起來，怎麼就沒注意請示彙報呢！隨後，我向副總承認了自己沒有及時請示彙報的錯誤，並澄清了我們只是進行了一些技術交流，沒有任何的越權行為。我開始注意調查，發現其實質是副總對該專案不是很熱心，並因此與總經理產生了分歧，加上以前的許多事情，矛盾一下爆發了，我又是總經理招來的人，合作方又是總經理的熟人，這個事情就愈發的嚴重。

直接上司有時比董事長管用
無奈之下，我只好把合作方砍掉，並且事事早請示晚彙報。
不能在同一個地方跌倒兩次，我總結發現，直屬上司的支援比董事長都好使。高層只能在戰略上支援，戰術上還是直屬上司的配合。正應一句話“縣官不如現管”。另外就是新到任的職業經理一定要對履新的崗位進行認真調查，入職前與未來的上司和下屬進行溝通是非常必要的。
這次事件平息了，但有些事我不得不變得無所作為。很多審批許可權在副總手裡，於是專案一拖再拖。8個月後，在公司上層不斷的施壓下，專案組終於開始組建。

成也老專家，敗也老專家
我們的團隊中，有一位資深工程師，一位從業不久比較熟練的軟體工程師，另外聘請了一位老專家作技術顧問。
隨後的階段，那位老專家起到了保駕護航的作用。然而，如果沒有對老專家的“過度信任”，也不會有產品推出後的狼狽局面。因為該裝置要用到手術室中，手術室的電磁環境不但頻率複雜，強度還不小，可惜這是產品銷售後才得到的發現，為時已晚。開發中，也曾有人提出這個問題，用不用考慮一下干擾問題，那位老專家一句話：“我們以前做過的都沒什麼問題。”問題是該老先生原來是做非手術室裝置的，其電磁環境條件比手術室要好得多。我嘗試著提了點反面意見，被很不屑地化解了。
“阻礙社會進步的不是少年人的無知，而是老年人的固執”，終於有了切實的理解。在技術工作中，作為專案經理，別相信任何不經調查就得出的“沒問題”的口頭保證，尤其是所謂資深老專家對新問題的結論。昨天的經驗往往是明天失敗的導火索。在預研階段，要把所有可能的試驗結果都呈現出來，再做定奪。預研即使失敗，損失也小得多。

研發人員指揮生產的惡果
產品開發過程平靜而又順利地結束了。我們決定採取使用者購買後測試的方式。由於使用者測試過於漫長，在進入這個測試之前，產品就歸檔轉生產了。
在我供職的這家民營企業，其高層和80%的中層幹部都來源於一家老牌的國有醫療器械企業。這家公司長期從事手術床裝置的相關業務，後來的新人也都是為那兩個專案配的，所以新專案除了我和我的團隊之外，無人過問。我們求教於別人，經常得到友好而又歉意的一笑。
圖紙完成了，生產部只安排了一個小夥子學習生產這個產品，沒有安排專門的工藝人員轉化工藝檔案。這時手術床的裝置產量已經不小了，並且中了幾個大標，中標的機器都是成熟老機型，生產人員也較熟練，所以生產部就把主力都安排到那邊去了。對生產部來講，中標機器的生產是主要任務，我負責的機器就降到次要而又次要的地步，物流的供貨也是優先別的機型。
我太急了，太需要有一個結果來證明，急功近利的結局就是不懂生產管理流程的專案部開發工程師全力配合生產，犯了瞎指揮的錯誤，導致生產過程檢驗不規範、裝機不符合要求、生產檢驗文件不全、零件編號混亂，一句話，亂了，一切全亂了。
但是，機器還是源源不斷地被髮走。我暗自禱告，產量一大，我們開發的產品佔主體時，一切會好起來的。

越俎代庖的代價
剛開始的裝機和培訓，服務部門的工程師沒有人特別熟悉這臺機器。於是服務部的經理找到我求援，希望開發工程師能出差。為了確保機器能順利推廣開，我應承了下來，服務支援文件、服務工程師的培訓就這樣耽誤了下來。如此週而復始，最後只要有客戶諮詢或投訴，就直接轉到專案部，使專案部的很多具體工作進行不下去。
這還不是最糟糕的，開發工程師並未經過服務培訓，而我們專案部的工程師對那些又不瞭解，其安裝和使用者培訓卻又要做，可想而知，結果自然是不到位，最後對機器、服務的抱怨都集中到了專案部上。
拆東牆補西牆的救火沒能使流程理順，這時又出現了機器抗干擾差的投訴，這原本透過預研可以提前預防，現在也尾大難調。只好找了一所大學的教授協助解決，雖有改進，結果也不是很理想。不過我實在沒精力拿使用者進行試驗了，加上這番折騰，這個專案的利潤被服務、退貨、換貨耗掉了一部分，銷售渠道對產品的反應也很不好，抗干擾差、服務差、發錯貨，等等。面對危局，我無奈建議公司決策層停掉該專案。
這個故事結束半年了，每每回想，總是感慨：專案不是在最後才失敗的，也許它一開始就是一個錯誤，也許它的路線方向就是錯的。

[@more@]

專案研發為什麼失敗？（轉）

相關文章