“作坊式”開發雖然只是對軟件開發形式的一種比喻的說法，但深究起來卻還真是一個不小的話題。在此我粗淺地探討一下作坊式開發被廣泛采用的一些原因，不談所謂“作坊式的企業”之類大的話題，只就“開發方式”層面上的相關思路理一理，對工程化管理內容也不再贅述。所述之言為個人觀點，觀者仁者見仁、智者見智。
這里講到“作坊式”，主要是指傳統手工作坊的生產模式而言的。所謂作坊式生產模式大同小異，一般情形是：由一個掌握了某種技能的“匠人”，帶領幾個不需太多技能的“伙計”進行全程生產，匠人的技能是由其師傅“口傳心授”的，其他人基本上插不上手。生產過程中由匠人以他的一套“規矩”來安排，不需什么規程、制度，更不需要做什么“計劃”、“方案”。匠人在作坊里的“技術權威”使得老板也不敢對其“指手畫腳”，否則他會 “撂挑子”，事情成敗取決于匠人的能力。在這樣的情形下，生產過程基本上是無序的、無約束的，老板作為“管理者”角色的職能幾乎談不到，甚至受匠人的擺布，除非老板是一個非常高明的匠人。
果真以作坊式這樣的含意來比喻我們的軟件公司的開發過程，那我們的軟件開發技術骨干們將無不怒發沖冠了，IT業畢竟被稱作“高新技術”行業，而拿我們掌握技能的骨干技術人員比作小作坊的“匠人”，這無論無何是一種惡劣的、污辱性的詆毀！但不幸的是，我們大多應用軟件的開發過程的確以“作坊式開發”比喻是較為恰當的。
公正地說，就以此方式我們還是成就了好多成功的應用開發項目，甚至可以說此法支撐起了軟件開發的初期事業。比如，DOS時代國內眾多的電腦編程高手開發出了一大批膾炙人口的個人軟件產品，如嚴援朝的CCDOS，王永民的五筆字型，吳曉軍的2．13，朱崇君的CCED，以及求伯君的WPS等等。DOS時期是個人英雄主義的時代，一個人就可以叱咤風云。
如果你承認我們幾千年民族手工業正是由作坊里的匠人們支撐的，那作為剛剛有二三十年歷史的應用軟件開發業，沿襲了我們的民族傳統，應該說不是什么丟人的事。同樣，我們繼承了DOS時代先輩們的一些生產模式，似乎也無可厚非。
但是，在我們的“作坊”里還是有了太多的項目失敗，這種失敗或者表現為無法實現的不可為、或者表現為開發周期的不可控制、或者表現為項目結果為用戶所不認可、或者表現為項目最終的嚴重虧損，這種失敗的慘痛出乎我們的意料，以至于我們無所是從。再加上技術人員、資金嚴重匱乏的困擾，軟件開發管理舉步維艱。
作坊式的軟件企業中，很多東西都是裝在開發人員的腦子里面的，往往會因為一兩個開發骨干走了，就造成整個公司的癱瘓。賭注完全押在這一兩個人的身上，資本投入風險很大，如果研發骨干一個人另謀高就，公司投資等就將全部付之流水，作坊式的運作模式嚴重阻障了軟件企業的成長。
軟件開發本身確實是一項復雜、艱苦而又充滿著風險的工作，唯其如此，幾十年來中外軟件開發業的專家和學者們在大量的失敗項目中總結著失敗的經驗和教訓，陸續創立了相關的學說并應用于指導軟件開發的實踐，取得了一定的成果。在項目開發過程上借鑒一般工程過程建立了軟件開發的“工程化理論”，在開發方法上總結有結構化分析方法、組件式開發、凈室開發以及目前較為推崇的面向對象的分析開發方法等等，在軟件開發質量管理上有CMM、ISO等一些成熟的體系。這些規范化理論和方法在不斷的改進發展中日趨成熟和完善，并對軟件開發過程的工程化管理和規范化實施起到了革命性的指導作用。
事實上，但凡專業的軟件開發人員在大學里就學過《軟件工程》這門課，所有上面提到的一些理論知識都全面涉及，在此就不講其具體內容了�？v觀這些指導性的理論以及我們所采用的開發方式，我們說，作坊式開發對小型應用軟件開發項目是有一定的用武之地，在一定程度是不違背快速開發理論的；但對于稍成規模的小型軟件（更不用說中、大型的軟件）項目的開發過程，那就必須遵從于工程化理論的原則和方法，落實規范化的管理，否則失敗的風險將伴隨著整個開發過程，而且越到后期失敗的可能性會越大，一旦失敗，其經濟損失也就會非常巨大。
那么，既然有這樣的工程化理論，為什么往往不為我們所廣泛忠實地采用和貫徹呢？這是問題的癥結所在，值得探究！歸結起來，主要有以下一些原因：
首先，市場對軟件工程化開發的意義理解不夠，沒有形成廣泛的支持。
“應用軟件系統”本身的內含都包括哪些？對于用戶來說往往只局限于“在計算機上運行的程序”這樣一個膚淺的理解，不知道還應有計劃、調研分析、方案、設計、質量監督、測試、培訓、系統說明文檔等等的內容；對于“程序是做什么的？應達到怎樣一個目標？”這樣一些問題一般沒有從主觀上得到重視，更難談到從根本上把握。
之所以如此，就如同在規范化工程理論發展成熟的今天，我們仍以作坊式開發模式進行生產一樣，信息化建設到了一個如火如荼的時期，而大多用戶對其本質方面的認識還僅僅停留在“機器代替手工”這樣的理解上，他們對軟件產品應該具有的性能、適應性、安全性幾乎一無所知，甚至對一個自己所需要的應用系統的功能范圍都不是能夠很好地定義。這樣，用戶是很少會對開發企業提出實質性生產要求的。
用戶方往往將期望寄托于他們選定的開發企業，認為一切難題都會由開發方很好 地解決。在這種情形下，他們不會想到軟件開發的失敗可能（認為是開發方的事），當然也就不會去了解會導致開發失敗的風險因素，也就不會提倡以工程化的規范方法來約束過程了。孰不知，他們那“崇高的信任”很容易地被開發方強奸了，許多的用戶方在項目進行相當時間后才發現一些問題，在項目將完成時或試用階段才與開發方發生爭端，但最終認輸的往往是用戶，因為一個相對的軟件外行與“內行”的開發方對峙，顯然只能在大量的“事實”面前承認是自己的失誤導致功能的不完整、項目的延期……。
這樣“無知的”用戶群廣泛存在，是“作坊式開發”賴以生存的沃土，培育了“作坊”的勃勃生機。既然用戶要的是包括其規劃功能的、可以“跑得通”的應用程序，何必當什么工程來費時費力地勞作，敲出來不就得了！有那功夫還不如找些理由應對用戶的“挑剔”。
軟件企業在沒有形成規范化管理體系時，不可能建立起“全面為客戶信息化建設服務”的意識，企業沒有能力將工程化過程要求提到應用實施規劃內容當中，從這一層意義上說，其實是作坊式軟件企業自己斷送了自己的前程。
用戶對應用軟件以及開發過程的不理解，造成其對軟件產品成本和開發周期的過低估計，從而使軟件企業無力投入更多的人力和資金健全開發組織管理、規范整個工程過程。
第二，規范化管理理論不被軟件開發企業管理者所重視、風險意識淡漠，人員組織和資金投入不夠。
所謂規范化管理，是依據工程化理論，對項目實施的過程進行科學的、有條理的管理，這得有一整套的操作規范和監督機制。對于有一定規模的軟件企業，得有一整套技術管理體系，包括得力的管理機構、人員配備和完善的管理制度，管理體系中應嚴格制定生產過程的步驟、監管方法，必須有專人監督制度的有效實施；要有一個確定的發展方向，制定企業的遠景規劃；根據需要，建立一支具有各技術層次、各技術方向的技術隊伍；在整體上要形成一種團結、向上的具有凝聚力的企業文化。特別是對于軟件開發過程，一定要堅決地貫徹落實前人總結形成的工程化管理理論和方法，這決定著一個軟件企業的命運。
軟件業是一個高投入，高回報，高風險的成長性極強的行業。在想獲得高回報之前，首先應考慮如何規避風險、如何使自身得到成長和壯大。風險是伴隨著應用系統開發的整個過程的，一旦風險失控，其結果對軟件企業往往是致命的。作坊式的軟件企業在小的應用軟件的作坊式開發中嘗到了些甘甜頭，而對潛在的風險危機缺乏認識，為自己的“成型的”開發模式而沾沾自喜，這種模式實際上使企業的效率不能提高、市場適應能力低、企業內部危機四伏�？上У氖�，軟件企業的決策者們往往看不到這一點，短期利益的輕易獲得導致最終的企業倒閉，這是領導者的失敗。
按照工程化理論和規范化管理要求，企業須要投入更多的人力、財力于：客戶關系管理、分析設計結果審查、流程化的過程管理、質量管理等等，而遠非代碼實現的人力支持。與作坊式開發模式相比，企業的管理者們首先想到的是投入太多，卻看不到作坊式開發風險造成的虧損危機，反而不會積極支持以提高開發效率和系統可靠性的工程化開發；在沒有必要的人力保障和過程指導的情況下，項目組規范化開發的嘗試是弱不禁風的、沒有結果的。在這種情形下，不可能有積極的實踐活動，不可能建立起一個健全的機制來支持工程化規范開發的進行。
事實上，理論并不精確地指導實踐，對于工程化管理和規范化開發，盡管可以羅列許多所需的管理機構和過程任務，但規范化管理本質上并不是要求具體“人”的行為，并不一定要求人力規模，而是要求建立一個機制、體系，嚴格工程的過程管理，所以，如果我們的管理者做一些“職能轉變”、實施者多一份過程、質量管理意識，已是大的飛躍。理論是死的，人是活的，數以千計的軟件企業的興衰證明了管理的重要性，而軟件企業管理的根本是軟件工程化管理和技術管理。
第三，軟件開發技術人員對工程化理論的實踐有抵觸心理，認為增加了勞動量。
文章來源于領測軟件測試網 http://www.kjueaiud.com/