Global Sources
電子工程專輯
 
電子工程專輯 > EDA/IP
 
 
EDA/IP  

專家開講:給工程師的企管知識──正視風險

上網時間: 2014年02月07日     打印版  Bookmark and Share  字型大小:  

關鍵字:風險  產品  專家開講  創業  工程師 

1981年,我和兩個大學同學創立了第一家電腦輔助設計軟體工程公司,目標是協助IBM大型主機的程式設計師改善工作流程;當時該類商機是很龐大的,而無論是我們自己或是我們的目標客戶之潛在收益都十分可觀。

我們的最初想法是開發一系列分階段的編程工具,終極目標是提供一個工作站,緊密整合了編輯器、語法檢查器(syntax checker)、編譯器,以及模擬 IBM 大型主機之COBOL環境狀態的執行期仿真器(runtime emulation),並搭配測試工具以及完整的編碼分析。我們計劃在短時間內開發出編輯器以及語法檢查器,並將之交給客戶使用、取得回饋。

但是到了風險資本業者面前,他們卻要求開發計畫要有改變;那些投資人(主導我們的公司董事會)堅持,不應該一開始只提供編輯器/語法檢查器等功能有限的產品,而應該只供應功能完整的最終版本產品。為了取得資金,我們只好屈服,也因此放棄了取得對我們的解決方案之早期回饋的機會。

光是這一個決定就使得風險因素明顯提高,我們需要完成開發的軟體數量增加了,可收到客戶回饋的時程延後了,公司的支出變多,也遭遇了推出一款有效產品的常見延遲;此外,我們必須擴大訓練員工,包括一般行政職員以及現場應用工程師團隊。

最後公司仍因為各種因素而失敗了,主要原因還是根自於需要順從那些對我們的前景規劃不了解的董事會成員們;因為失去取得早期回饋(透過實驗性設計)的機會,我們延遲了檢驗產品概念的時程,而每一次驗證的延遲都使得風險提升,或多或少。

除了開發時程延遲,另一個最大的失敗原因來自於最初的功能最小化產品;我們原規劃了一套緊密整合的編輯/語法檢查器,不過後來選了一種比IBM COBOL程式設計師所使用之功能更強的編輯器,雖然比較好,卻不是正確的選擇。如果我們按照一開始的產品開發計畫,就會在公司創立第一年發現問題,我們卻在超過兩年的產品開發時程中才發現失誤。

在我的職業生涯裡面,見過也經歷過許多次這樣的事情發展;我已學到一個基礎原則:設計產品時,可以在開發週期的最初先以一個功能最小化版本(也稱為基本產品)為起點;這是一個規避與控制風險的策略,你可以從企管大師Alex Osterwalder所創的Canvas企業生成系統或是其他當代的企業與產品規劃方法中,看到這種技巧的應用。

我個人所採取的產品開發策略是專注於降低風險,你不能也不該完全排除風險,但你應該要考量風險帶來的效應,並在問題發生時掌控你的因應方式。而這種企業經營學其實已經存在近三十年,收錄在Osterwalder的著作《Business Model Generation》,也被創業大師Lean Stack運用在他的Lean Stack系統中。

總之你不應該對你無法(或者不想)看到風險的產品或創業構想陷入太深,如此你也將失去降低那些風險的機會。

編譯:Judith Cheng

(參考原文: Business for Engineers: Risky Engineering Behavior,by Henry Davis)





投票數:   加入我的最愛
我來評論 - 專家開講:給工程師的企管知識──正視...
評論:  
*  您還能輸入[0]個字
*驗證碼:
 
論壇熱門主題 熱門下載
 •   將邁入40歲的你...存款多少了  •  深入電容觸控技術就從這個問題開始
 •  我有一個數位電源的專利...  •  磷酸鋰鐵電池一問
 •   關於設備商公司的工程師(廠商)薪資前景  •  計算諧振轉換器的同步整流MOSFET功耗損失
 •   Touch sensor & MEMS controller  •  針對智慧電表PLC通訊應用的線路驅動器
 •   下週 深圳 llC 2012 關於PCB免費工具的研討會  •  邏輯閘的應用


EE人生人氣排行
 
返回頁首