我對產品化的理解
產品化的時機是看業務的需要，不管是對前景的落實，還是專案轉化成產品，這些都不是技術人員能考慮的，業務的發展和策劃，如何進行市場細化等如果都由技術人員考慮，產品化的風險很大。
風險最大的是對於產品化的理解。
提到「產品化」，大部分技術人員，包括很多公司老闆，首先想到的是可銷售性，也就是免實施，「軟體產品的製造成本為零，微軟就是這樣發財的」，這是很多人跟我這麼說，為什麼要做產品。
基於這種考慮，技術人員往往把主要精力放在體系結構設計，把焦點放在可配置性、零實施等環節，小型軟體可能可以做到，而對於絕大部分中小軟體公司，主要做的都是企業管理軟體，採用這種思路會是一種災難，企業管理軟體是靠業務驅動的，即使是國外的成熟軟體實施週期也不會比定製開發少多少，基於技術架構而不是業務來做產品開發，還沒做出第一套就想著零成本複製，還沒有業務應用，就想著軟體提供的組織機構要支援複雜的矩陣式，甚至虛擬組織，基於產品的二次開發被看作是一種罪惡，從精益的角度上看也是一種過度設計，是一種浪費。如果基於這種想法來做產品，可以說產品失敗的風險是非常大的，技術上對於一般的中小公司而言，是無法保證的。
企業管理軟體，切入乙個行業和領域，是可以產品化的，不過產品化在很大程度上講，我認為是一種商業名詞，是一種結合管理思想、實施方法等個性化元素的東西，無法輕易複製和實施，不具備大規模的銷售可能。公司想做好，靠的是諮詢顧問，他們所要的是best practise，技術在這個領域對顧客的影響是微乎其微的，專案成功靠的是實施，我看國外的產品實施跟二次開發也沒什麼區別。
如果不是通用產品或者系統軟體，做企業管理軟體想零成本實施不太可能，產品所提供的功能永遠無法滿足客戶的業務要求。而且靠銷售軟體產品掙錢，遠遠不及靠實施顧問掙實施費掙錢掙得多，後者才會給企業客戶帶來管理上的提公升。
軟體公司怎麼做產品化？我的意見是：
1、 找到合適的專案和合適的客戶，多做專案；
2、 在某乙個領域積累行業經驗，建立樣板工程和成功案例，並將專案產品化（指商務概念上的產品）；
3、 提煉管理理念，並將理念和成功案例結合，整理實施方**；
4、 找到下乙個專案，在專案開發過程中將原系統重構。
在剛開始的時候，別想著掙大錢，先老老實實做專案，只是要從業務的上多下功夫，對公司而言更重要的是抽象和提煉管理思想和業務規則，整理好實施方法和專案管理的經驗，多做幾個成功案例，產品化才有良好的基礎。
產品化的理解
我對產品化的理解 產品化的時機是看業務的需要，不管是對前景的落實，還是專案轉化成產品，這些都不是技術人員能考慮的，業務的發展和策劃，如何進行市場細化等如果都由技術人員考慮，產品化的風險很大。風險最大的是對於產品化的理解。提到 產品化 大部分技術人員，包括很多公司老闆，首先想到的是可銷售性，也就是免實...
對軟體產品化的理解
產品化的時機是看業務的需要，不管是對前景的落實，還是專案轉化成產品，這些都不是技術人員能考慮的，業務的發展和策劃，如何進行市場細化等如果都由技術人員考慮，產品化的風險很大。風險最大的是對於產品化的理解。企業管理軟體，切入乙個行業和領域，是可以產品化的，不過產品化在很大程度上講，我認為是一種商業名詞，...
產品化之說
剛在 一蓑煙雨任平生 的blog中看到 我對產品化的理解 頗有一番感慨。quote 軟體公司怎麼做產品化？我的意見是 1 找到合適的專案和合適的客戶，多做專案 2 在某乙個領域積累行業經驗，建立樣板工程和成功案例，並將專案產品化 指商務概念上的產品 3 提煉管理理念，並將理念和成功案例結合，整理實施...