本文意在嘗試性總結一下傳統業務軟體企業在軟體研發流程中可能遇到的各類問題。
3. 最後
4. 參考
傳統業務軟體企業。
強勢的甲方，卑微的乙方。
產品專案化，需求產品化。
a. 最終生產的軟體需要進行多地區實地部署，且各個地區針對軟體又有自己特定的需求。
b. 因為進度原因最終造就打著"做產品"的口號開始，但在落地過程中針對每個地方的需求進行跟進式開發。
c. 因為缺乏需求分析導致沒有乙個需求類別認定的流程，又因為監控的缺失導致無法提供充分的日誌資料進行決策分析，最終只能依靠產品經理個人當時的理解進行需求歸類。
d. 因為**分支管理的缺失造成製品包沒有回退修復機制，研發之路上只能進行沒有回頭箭式的奪命狂奔。
2.1 產品側
同時負責多個產品，精力被過度分散。
因業務的特殊性等原因導致對於產品需求的**和進度幾乎沒有控制權。
產品採取"分區域"的方式進行銷售，並有著比較長期的個性化需求更新和bug維護的要求。
專業性缺失。大部分產品經理並未接受到專業的培訓，絕大部分屬於從事相關業務多年從而成為了"產品經理"，細數之前的履歷，有"測試轉產品"，「開發轉產品」，「售後轉產品」，「專案經理轉產品」。
產品經理之間缺乏溝通，互為黑盒，很少進行資訊的共享。直接結果就是除非存在聯結點，否則相同的功能會在不同的產品間進行重新實現。
2.2 開發
公司業務特性決定了乙個研發人員需要同時承擔多個專案/產品的開發維護工作，人員更迭相當快，緊急的專案救火時有發生，導致出現低階問題出現概率較高，職責無法溯源，等問題。
相關技術管理的缺失。缺乏變更控制，缺乏版本管理，研發流程中只存在前進的方向，沒有回退機制；研發部門的各個小組之間技術棧的不統一導致人員調動摩擦成本高，破窗效應嚴重。內部技術棧培訓短缺或者效果不明顯。
技術歷史債較重。新技術和規範的引入瞻前顧後，導致最終或圈地自萌，或不了了之。
持續開發能力缺失。開發環境千差萬別，工具版本各有千秋，無法實現快速驗證，甚至或有意(如因為懶於自測，直接將問題拋給測試，甚至生產環境)或無意(例如本來應該採用單元測試的驗證，卻選擇必須將前後端同時搭建起來之後從瀏覽器端開始)地人為延長驗證時間間隔。
2.3 測試
專職測試人員數量稀少，且僅集中在效能測試或安全測試。
持續測試能力缺失。環境的準備到系統的部署全程基本為人工完成，低階錯誤頻發，測試缺乏可復現性。
驗收測試，冒煙測試以"猴子測試"的形式完成，嚴謹性缺失的同時無法對全流程進行復盤和審計。
與研發之間缺乏有效的溝通反饋機制，雙方互為黑盒。
管理缺失。缺乏基本的量化指標。
2.4 運維
地方專案經理兼職運維人員，除了運維之外，還要身兼收集局方需求的職責，但往往只是個傳話筒，缺乏"需求分析能力"。
待遇低，專業能力缺失。導致的直接結果就是 "將war包丟進tomcat目錄下，然後啟動起來"都可能存在問題。更不談避免埠衝突，收集問題及相關場景都存在問題等等。
任重道遠，但正面問題是開始改變的第一步。我們需要就問題先達成一致，否則只能在各奔東西式的努力中耗盡所有人的心力和熱情，愛因斯坦曾說過"當問題清晰之後，解決方案自然就出現了"。
我在某金融軟體公司工作，隨著客戶數的增多，成本與效率/質量的矛盾日益凸顯。最後總結一下部分最佳實踐：~設想下，從一波人維護一套**，漸漸變成一波人維護幾套**，這樣一來，bug增多，效率下降，抱怨也隨之變多，再加上甲方挖人，最後人員離職，團隊土崩瓦解，game over……
~在這種情況下，一般公司會採取三種應對措施：
一對一服務 - 專案制：多個團隊，多套**，多套標準，服務多家客戶，但這樣一來成本又難以承受，時間一長，肯定資不抵債。
一對多服務 - 標準化：乙個團隊，一套**，一套標準，服務多家客戶，但客戶不買賬，客戶說我的需求都是個性化的，你別拿某某標準來引導我，叫你咋做，你就咋做，不願意？那您走，我找別人家做。
一對多服務 - 產品化：乙個團隊，一套**，多套標準，服務多家客戶，通過技術與配置化的手段，利用soa思想，打造自己的產品化平台，但對技術投入要求較高，尤其是核心人才的依賴較大，中小型企業一般都很難留住這些人，只要他們一走，公司基本完蛋。
離問題越近，修復成本越低。所以快速部署是需要乙個能讓各方收益的需求，而不僅僅"這是運維/售後的問題"。
我們信任的是測試結果，不是所謂的口頭承諾。而這同樣需要快速部署的支援。
《鳳凰專案 : 乙個it運維的傳奇故事》
《看板方法 : 科技企業漸進變革成功之道》
《持續交付2.0》
《持續交付 : 發布可靠軟體的系統方法》
《持續整合 : 軟體質量改進和風險降低之道》
傳統軟體企業之殤
在經過一番靈魂鬥爭之後，我終於做出了乙個自認為非常重要的決定。於今年八月，離開了自己熟稔的傳統軟體開發行業，加入了一家網際網路產品公司。時至今日，不知不覺，已經有乙個季度有餘，趁著通勤路上的閒暇時光，梳理了一些感悟，期待能給同樣遇到瓶頸的同學帶來一些思考。作為一名資深的傳統型軟體開發者，我只呆過為數...
傳統企業與網際網路企業的軟體價值觀
在中國大陸，計算機有乙個更為形象的名字，電腦。從字面可以看出，它是一件幫助人類進行思考的機器。但決定計算機思考什麼，如何進行思考的，就是程式。把人類腦袋中的可重複的 機械性的腦力勞動，變為機器可重複執行的程式，這個過程就是軟體過程。在計算機誕生之初，它所要解決的問題是科學計算，也因此得名計算機。可以...
軟體測試技術之傳統等價類測試
概念 等價類劃分法是把程式的輸入域劃分成若干部分 子集 然後從每個部分中選取少數代表性資料作為測試用 例。每一類的代表性資料在測試中的作用等價於這一類中的其他值。等價類劃分法的應用 等價類是指某個輸入域的子集合。在該子集合中，各個輸入資料對於揭露程式中的錯誤都是等效的，並合理地假 定 測試某等價類的...