作者主要就企業管理軟體領域與我們分享了國內中小企業的軟體管理和團隊管理等方面的思路、方法、見解和經驗。每個領域都有自身的特點，但從軟體需求調研、研發、銷售、實施、支援、服務和團隊建設上的道理都是相通的。如作者所說，企業管理軟體領域對業務技能要求高，技術門檻低，但專案並行多，需求量大且易變動，相比其他領域，需要更強有力的實施、支援和服務能力，作者在這幾方面有比較深刻的體會和豐富的經驗。
自己從事軟體行業也有五年了，一直致力於一線的開發工作，換了兩個公司，參與過幾個產品的研發，接觸的領域較多，所以到現在對各個領域業務也都不精通，不想作者對行業有深邃的眼光和深刻的理解。我在軍隊做過空戰**評估系統、電子戰指揮自動化系統，在通訊公司做過通用協議測試平台，做過voip系統的研發，甚至對函式自動化測試技術進行過研究和建模，目前從事網路安全審計產品的研發工作，開發經驗豐富，但是行業經驗不深。我沒有從事過企業管理軟體的開發，但是也做過企業管理軟體的使用者，作者描述的需求調研、實施場景在腦海裡也是有些印象的。
這本書從一開始就吸引了我，因為這也是目前我的職位所需要而又缺乏的，利用國慶期間，我仔細地閱讀了此書，有很多共鳴之處，亦有很多深受啟發的地方。一直以來，我主要工作在開發一線，最近一年我才真正走上技術兼管理的崗位，歷經研發組長到研發經理，對研發的流程管理和一些具體的思路和方法有很多共鳴支出，如需求的管理、版本分支管理、bug管理、編碼規範等等，對於研發之前的售前和需求調研工作，研發之後的實施、支援和服務工作都停留在概念階段，除需求調研做過幾次，其他都沒有經驗，也無法體會其中的道道，目前也不屬於我的工作範疇。通過此書，我也明白了各個階段工作的重要性，團隊分工和合作的必要性，對比我們團隊目前的情況，有很多可以從中借鑑的地方，比如說實施、支援和服務這一塊，這是產品對外的視窗，我們在一些細節上確實跟作者描述的相差很遠，比如ppt演示方法和細節、產品展現的手段、實施人員培養等等，都是我們需要完善的地方。
以前也接觸過關於軟體過程管理、配置管理、質量度量、軟體測試、軟體驗收等軟體工程內容，但大都停留在理論階段，而且當時學習和培訓時並沒有真正理會，現在拿到具體工作中來還是有很多困惑的地方，具體每個階段、每個職位該怎麼做，怎麼有效的配合，心裡面還是很模糊，這本書正好替我梳理了這方面的知識，將理論應用到實踐中，應該說作者提供了一些很好的思路和方法。適合的才是最好的，軟體過程管理規範、團隊建設是不可能按照標準一步就能到位的，需要乙個逐步建立、逐步完善的過程，不能拔苗助長，急功近利。
我參與過軟體工程管理由國標、**標的培訓，其實其中也有類似於cmmi的軟體能力成熟度的分級，提供裁減的做法，根據公司和團隊目前的發展情況，有選擇性地對國標**標進行裁剪，不影響研發進度的情況下去掉一些目前沒有精力和人力去做的步驟，輕裝上陣，最有效地發揮軟體工程標準的作用，這也是標準裡面建議的做法。很多人都抱怨說cmmi、iso、國標、**標太複雜，實施起來代價太大，所以乾脆什麼文件流程都沒有，這是一種極端的做法，也說明其對標準的理解不到位，標準是提供一些原則性和指導性的思路方法，是前人經驗的總結，是絕對可以借鑑的，而且可以有選擇性地借鑑。
讀《走出軟體作坊》有感
在韓磊給 走出軟體作坊 做序中說道，所謂學我者生，像我者死，學的和像的實在不是同乙個 我 讀者不可不察。有一種開發思路，就像使用關係性思路進行開發，首先把第一優先順序的，互相關聯的功能先設計出來，然後邊開發邊進行第二優先順序的功能設計，這樣就保證了設計 開發 測試 文案在同時進行，將序列變成了並行。...
談《走出軟體作坊》
像書中所說的一樣創新為兩種，一種是創作出以前沒有的技術或方法，另一種是將其他行業的技術或方法應用到沒有使用行業。作者是行業管理軟體出身，對行業管理有著深刻的認識。能將行業管理資訊化借鑑應用到軟體行業，並經過多年自身的總結，可以說這本書對於缺乏管理的軟體行業，特別是中小型公司來說是很好的乙個典範。書中...
如何走出軟體作坊
阿朱這本 走出軟體作坊 以切膚之痛，現身說法，是一件很有價值的事情。當然，此書未必能解決很多公司的問題 也沒有任何書能做到這樣 但至少能引起多數人共鳴，引發大家進一步思考與 少走彎路，這正是當下缺少的。書店裡管理學圖書汗牛充棟，有的告訴你把信送給加西亞，有的告訴你不要有什麼藉口，還有的說是辦法比問題...