當面對乙個需求時，產品人員會在完成時間與資源投入上與研發人員進行「談判」，有時要麼威脅，要麼懸賞。產品人員關注的是系統可以做這事，可以做那事（以後可以做）；而研發人員則為了自身利益著想則是想先把這事做了再說，於是兩者便很快達成協議。至少在這一刻，研發人員只能聚焦到乙個點上，因為單純做一件事簡單，所以重實現輕設計的惡習被養成！我已經遇到好多已經快編完碼才迫於形勢（質量要求）來參加設計評審的事情了。
隨著時間的推移，我們的產品便由這些大都是「臨時」或「應急」的專案拼湊而成，於是我們的應用系統便越來越龐大而臃腫。龐大可以理解，但臃腫是我們無法接受的。臃腫發展到一定程度，會嚴重影響效率，制約著業務進一步發展。我們在不停的增加機器，不停的更換效能更高的伺服器。然而這不是通用的解決方案，有時候我們對現有系統已經不能在做什麼了，於是「架構公升級」便被提到日程上來了。這是個自然規律，我們的業務系統也需要「進化」。然而就像生物界的「進化」一樣，有些物種被替代了，而有些則變得更加強大。「替代」的代價是巨大的！這意味著先前的投入被歷史所埋葬，遺留價值渺小甚至沒有。
我不得不承認目前國內的一流的b2c公司就是以這樣的方式支撐著如此巨大的業務，並且有的以每年200~300%的速度在發展。他們的業績非常的漂亮，但有多少人知道多少研發人員度過了多少個不眠之夜？這些公司技術大都落後於業務半拍或一怕甚至是瓶頸問題！小一點的公司因為業務量的問題，可能沒有那麼嚴重，但其技術實力我是不那麼樂觀的。
這是不是說明我們的技術很被動的呢？技術服從於業務我很認可，但技術永遠跟在業務後面跑我不認同！
產品產生過程
相關系統分析員向使用者初步了解需求，然後用相關的工具軟體列出要開發的系統的大功能模組，每個大功能模組有哪些小功能模組，對於有些需求比較明確相關的介面時，在這一步裡面可以初步定義好少量的介面。系統分析員深入了解和分析需求，根據自己的經驗和需求用word或相關的工具再做出乙份文件系統的功能需求文件。這次...
產品經理從點子到產品的思想過程
點子與方案 當產品尚未成形，什麼都沒有的時候首先作為產品經理要有建立在對市場和使用者的理解上進行乙個方案，在相對成熟的公司也要清楚產品是怎末從簡單的點子和想法，借助當前的基本的產品框架和定義成長為當前的狀態。這裡提到的方案，或者產品的框架定義，可以稱之為產品模型和商業模式。產品的模型不僅僅基於使用者...
軟體專案管理涉及的產品和過程
在這些專案計畫之前，應該首先進行專案定義，也就是定義專案範圍，其中包括建立產品的目的和範圍。可選的解決方案技術或管理的約束等軟體開發者和客戶必須一起定義產品的目的和範圍，一般情況下，該活動作為系統工程或業務過程工程的一部分。持續到軟體需求分析階段的前期，其目的是從客戶的角度聽譯該產品的總體目標。但不...