《走出軟體作坊》已經一周歲了。在這一年裡得到了許多朋友的鍾愛，也收到了許多朋友的來信。
仁者見仁智者見智。有人從書中看到了心態和堅持，有人看到了樸實的創新（原來創新就是這樣，不要整天大戰略大構思大藍海），有人看到了術，有人看到了方**。每個人都或多或少能收穫到一些東西，這已經達到了這本書想要傳達的目標了。
於是，就成為了困獸。看著方法不錯，但現狀無法改變，焦躁。焦躁過後是恢復到過去，繼續撞鐘，反而心態更不如過去。有人忍不住了，給我打了**，希望當面請教。
這是書中的乙個忽略。直到這一年經過，我也才認識到關鍵的那個開始點在書中沒有講明白。我只是安排組織結構、過程管理、未來發展、企業文化、個人修養這幾方面講下來，至於如何從現狀扭轉，先從哪個點切入，這點當時始料未及。
所以我在這裡給大家講講。
我們想扭轉公司現狀，也是如此。先設立防火牆。
走出軟體作坊，我是以研發部門為中心的。當然，和我交流的大部分人都是研發部的。大家都是共同的視角，共同的許可權，想解決需要變革整個公司模式的問題。
我們不可能變革其他部門，只能從自己先下手。要走出的第一步，就是給自己設立防火牆，不要讓自己的問題擴散到別的部門，也不要讓別的部門的問題擴散到自己部門。
這個防火牆怎麼設立呢？首先得有人。沒有人，說句髒話，就叫幹個屁啊。
但是，這立刻會面臨到乙個很現實的問題，沒有人。確實沒有人。老闆也不給人，每個人都忙的很厲害。沒有人啊。
向老闆申請人。這幾乎是不可能的事。一般在現狀，沒有作出成績還要人，這是不可能成立的事。雞生蛋，蛋生雞。有人是捨不得孩子套不住狼，有人是不見兔子不撒鷹。我們一般遇到的都是不撒鷹的主兒。所以大家不要抱怨，有啥人就用啥人，能改善多少就改善多少，盡力了。
就現在這三五個人，大家看著辦。為了拯救自己，不做也得做。抱怨起不了任何作用。
ok，我們說有人。要有什麼人？
我說的是是開發專案經理。這個人得單提出來，不能開發編碼，專門做需求管理、bug管理、團隊中每個人的工作計畫、工作推動、團隊內部資源調配、團隊內矛盾解決、執行過程中異常問題處理、每天向各個協調方報告工作進展和工作困難。我說的各個協調方包括客戶、客戶老闆、自己的上司、自己的老闆、銷售部門、實施部門、支援部門。
我們整天在忙，其實在窮忙。很多穿插進來的事情和異常讓我們常常不得不停下手中的工作，接**、查詢客戶的bug、臨時修改bug、給客戶更新、跟蹤客戶更新後使用情況。我們本想完成的計畫，都成了空話。當月底檢驗計畫的時候，總會有一大堆的理由說是因為什麼什麼異常，所以無法按照計畫執行。
對，這就是沒有防火牆，每個人都直接受到各種**的直接干擾。而開發專案經理，就是防火牆。
售前方面的方案製作、需求討論、打單演示，銷售部門反饋回來的客戶現場提出的需求和問題，老闆在客戶現場發現的問題和需求，實施部門在實施過程中發現的需求和問題，客服支援部門在日常支援中轉過來的需求和問題，在專案開發過程中客戶的各個業務部門包括客戶it部門提出的需求和問題，這麼多的衝擊，需要有乙個專門的人來統一歸口，遮蔽。任憑外部這麼多異常的穿插，有專案經理一人擋關，開發人員在研發內部安安心心的按照專案經理的工作計畫紮實的開發著。
不管收到多少需求和問題，每個人都覺得自己的問題是最簡單的，是最需要立即解決的。每個人都會這麼想。但現實就這麼擺著，有100件事，就三五個人，看著辦。累死也不可能把這100件事1天內幹完。
專案經理把來自各方的需求和bug，統一彙總到乙個excel中。和各方討論明白到底想要的是乙個什麼功能，細節是什麼，會引發的問題是什麼，都要專案經理來做好功課。確實要開發的，就根據現在的開發進展和開發計畫、開發負荷，排好後續的開發計畫。
其他人著急啊，著急也沒有用，你看，所有的需求和bug都在這裡，其他人也在提，不光是你銷售部門乙個部門在提。你看，我們的工作內容，已經排出來老長了。都很明確，大家沒有偷懶，大家確實很忙，丁是丁，卯是卯，就是到了老闆那裡，拿出來這些excel，老闆也沒有辦法。就這點人啊。
這就是第一道防火牆。
第二道防火牆就是增加測試人員。軟體不穩定，實施有問題會直接找開發人員，客服支援有問題會找開發人員。因為這些是軟體bug，就得開發人員跟蹤和修改。怎麼讓軟體穩定呢？我和很多人都聊過，在長久的不間斷的修改**接客戶**做跟蹤支援的，程式設計師們普遍很累，對這種狀態很膩，有厭煩心理，甚至有了蝨子多了不嫌咬的無賴狀態。
這是人的正常生理和心理。程式是程式設計師用手乙個個敲字母敲出來的，這是個手工作業活。人是肯定要受各種生活和工作的影響。人不是冷血動物，人也不是機器。人是感性的，人是需要生活的。
這種狀態存在，我們就要去解決問題，而不是一味強壓。有時候，強壓也失去了作用。想解決，臭罵一頓也沒有辦法。說吧，想不想解決？想，那我們就擺好心態，繼續往下看。
測試人員一方面會使軟體質量提高，這樣bug少了，未來的程式設計師的支援就少多了，實施部門和客服部門的工作就輕鬆了，當然部門衝突也就會少了，合作也就比較改良了。
另外，測試人員需要兼任技術支援人員。因為測試人員為了能測試出更多的bug，把軟體問題消滅在開發內部，所以他對軟體的細節了解的僅次於專案經理和開發人員。測試人員比實施人員、客服支援人員、銷售人員要了解軟體深的多。他來做技術支援，他解決問題查詢問題比實施人員、客服人員要快的多、準的多。這樣就不需要干擾程式設計師了。程式設計師就可以正常的按照開發計畫一步步繼續了。
而且，在實施過程或客戶應用過程才發現的bug，那就是測試人員當初沒有測試到的地方。為什麼沒有測試到，為什麼忽略了，以後要加強注意。這也是對測試人員工作質量的乙個反饋。
所以說，測試人員兼任開發部門技術支援人員，對測試本崗位工作非常有好處，是對測試工作的促進和提高，也給研發部門設立了第二道防火牆，防止實施部門、客服部門對程式設計師的干擾。
只要程式設計師能安心工作。他寫的**質量就會提高，bug減少，功能細節完善，思考周密。如果整天讓他救火，程式設計師只能以救火的心態來工作。人不可能長期處於高度緊張救火的狀態。
有了這兩道防火牆，負向轉到的企業文化、部門衝突、工作質量、工作效率才能慢慢再回到正向轉動上來。這就是開始的切入點。
沒有人不要緊，要緊的是，研發團隊需要承擔更多的工作。但這是理順前，走向正軌的必然付出。在老闆沒有看到效果不投入人力之前，研發團隊要想變好，是必然要付出更多的。大家不要想著和過去一樣付出就能達到更好的效果。我們在現有人手下，有些人需要承擔更多的開發工作，這樣才能擠出乙個人來做專案經理，專心管好需求、bug、工作計畫、協調、推進、匯報。這樣才能擠出第二個人來做測試與技術支援。這必然會有人職業轉型，會有人承擔更多的**開發工作。但其實，專心開發**，一切雜事都遮蔽了，開發質量和開發效率都會提高，反而比過去工作更順溜了。程式設計師，最擅長的還是自己本職的開發工作。
但冰凍三尺非一日之寒。所以不要一有救火，整個改良就都放下了，重新回到過去的狀態了。這是不對的。從負向到正向，必然有很大的逆摩擦。堅持，咬牙，挺過，負向的車輪才會靜止，然後正向轉動。想實施改良的人，必須要深刻認識到這個衝擊，要承受得住，要有勇氣來面對挑戰，要有勇氣來面對失敗。
你是否有這種犧牲付出和堅持推進的勇氣？
談《走出軟體作坊》
像書中所說的一樣創新為兩種，一種是創作出以前沒有的技術或方法，另一種是將其他行業的技術或方法應用到沒有使用行業。作者是行業管理軟體出身，對行業管理有著深刻的認識。能將行業管理資訊化借鑑應用到軟體行業，並經過多年自身的總結，可以說這本書對於缺乏管理的軟體行業，特別是中小型公司來說是很好的乙個典範。書中...
如何走出軟體作坊
阿朱這本 走出軟體作坊 以切膚之痛，現身說法，是一件很有價值的事情。當然，此書未必能解決很多公司的問題 也沒有任何書能做到這樣 但至少能引起多數人共鳴，引發大家進一步思考與 少走彎路，這正是當下缺少的。書店裡管理學圖書汗牛充棟，有的告訴你把信送給加西亞，有的告訴你不要有什麼藉口，還有的說是辦法比問題...
讀《走出軟體作坊》有感
在韓磊給 走出軟體作坊 做序中說道，所謂學我者生，像我者死，學的和像的實在不是同乙個 我 讀者不可不察。有一種開發思路，就像使用關係性思路進行開發，首先把第一優先順序的，互相關聯的功能先設計出來，然後邊開發邊進行第二優先順序的功能設計，這樣就保證了設計 開發 測試 文案在同時進行，將序列變成了並行。...