關於產品化,公司也進行過相應的**,也是公司的目標。
公司一直在做專案,沒有很好的產品化的思路。
個人認為為什麼會稱之為產品,產品應該是有大部分共性的特點,按照相應的技術標準或規範生產出來的東西。比如螺絲釘,有各種規格的螺絲釘,但每種規格都有統一的標準。比如手機,有相應的通訊標準。
那麼我們的軟體產品如果要產品化,應該是滿足某一規範或標準的軟體,首先應該想到我們應該滿足的標準,有了參照的標準我們才能將它產品化。比如說我們的服務開通系統要產品化,參照的標準就是集團規範。那我們就應該按集團規範對標我們的產品滿足情況。海外版本可能參照的是etom模型等,做乙個標準版。可能每個省或國家需求有差異,作為產品規劃人員,應該將可能的共性需求或有利於產品功能提公升的功能加入到產品改善計畫裡。但對於個性化的需求,我們有類似的功能的話,應該盡量引導使用者進行流程優化等來適用系統。
在產品的實施過程中對於系統的主體功能可能變化不是很大,但是如果要適應不同的地方,系統與對端的介面的變化是比較大的。對於介面做為產品化的考慮應該統一規劃,制定不同的技術標準對接。對內收斂,對外解耦。對於大型應用考慮建立統一的eai平台。
總的來說軟體的產品化,通過兩個維度來實現,一是業務維度,盡量參考已有標準,綜合共性需求。二是技術維度,功能上考慮可以靈活定製,裁剪。與外系統充分解藕,盡量不能因為與外系統的介面而改變核心的功能。靈活的許可權驗證、國際化等等。都是我們產品化需要考慮的。
產品化後,產品如何演進更是我們需要思考的問題。
產品化之說
剛在 一蓑煙雨任平生 的blog中看到 我對產品化的理解 頗有一番感慨。quote 軟體公司怎麼做產品化?我的意見是 1 找到合適的專案和合適的客戶,多做專案 2 在某乙個領域積累行業經驗,建立樣板工程和成功案例,並將專案產品化 指商務概念上的產品 3 提煉管理理念,並將理念和成功案例結合,整理實施...
產品化的困惑
通常乙個專案看著要結束的時候,往往是最痛苦的時候。程式設計師忽熱發現還有很多的非功能性需求需要改進,測試人員會突然提交一大堆的bug,客戶終於看到系統的,於是提出一堆需要改進的問題。所有這些都是產品化的困惑!當我們的專案交付時,其實是將乙個軟體專案變成乙個軟體產品的過程。如果我們是產品廠商,這是乙個...
產品化的理解
我對產品化的理解 產品化的時機是看業務的需要,不管是對前景的落實,還是專案轉化成產品,這些都不是技術人員能考慮的,業務的發展和策劃,如何進行市場細化等如果都由技術人員考慮,產品化的風險很大。風險最大的是對於產品化的理解。提到 產品化 大部分技術人員,包括很多公司老闆,首先想到的是可銷售性,也就是免實...