用作坊式來比喻我們的軟件開發，這與高新技術的軟件開發工作似乎很不切合，但不幸的是，我們大多數定製化應用軟件的開發過程很形象的展示了“作坊式開發”特點。我沒寫過代碼，但從事過長期的IT管理工作，程序員朋友可以從本文感受一個管理者眼中的作坊式軟件開發及其出路。
20世紀60年代，計算機的應用範圍得到較大擴展，對軟件系統的需求和軟件自身的複雜度急劇上升，傳統的開發方法無法適應用戶在質量、效率等方面對軟件的需求，這就是所謂的“軟件危機”。為解決這個問題，1968年NATO會議上首次提出“軟件工程”(Sotfwrae Engineeirng)的概念，提出把軟件開發從“藝術”和“個體行為”向“工程”和“群體協同工作”轉化。其基本思想是應用計算機科學理論和技術以及工程管理原則和方法，按照預算和進度，實現滿用戶要求的軟件產品的定義、開發、發佈和維護的工程，從此也誕生了一門新的學科——軟件工程。
50年過去了，我們今天環顧四周，作坊式的軟件開發依然比比皆是。今天的定製軟件開發普遍受制於老師傅的手藝，基本都是一個師傅帶幾個夥計的小作坊，可能大一點的企業為了統一各個小團隊的工作，會有一些“規程、制度”，在管理上也要求一些“計劃和方案”，不過只是一個個不同的很多小作坊罷了，因為其運作管理和今天其它行業的精細化管理比起來可以說是天壤之別，軟件工程的管理體系和措施落地執行的普遍不好。
一、說你是作坊還別不服氣，看看以下是不是招招致命
我摘錄了網上一個程序員寫的幾條表現，主要包括無合理開發計劃、需求不明確成為常態、無任何文檔和評審一般都事後湊數、領導不瞭解技術和業務、版本管理混亂、鄙視管理科學推崇關係幫派，其實日常開發工作中可能普遍或多或少的存在這些問題，我認為作坊式開發的集中體現是有組織的管理難以落地，有以下幾個主要問題：
（一）對“師傅”的依賴嚴重
師傅就是骨幹工程師，很多東西都是裝在開發人員的腦子裡面的，往往會因為一兩個開發骨幹走了，就造成整個團隊的癱瘓，如果研發骨幹一個人另謀高就，公司投資就將全部付之流水。我們看到很多團隊裡的“技術權威”使得老闆也不敢對其“指手畫腳”，否則他會“撂挑子”，事情成敗取決於師傅的能力，實際上說明工作缺乏組織的有效管理，在這樣的情形下，生產過程基本上是無序的、無約束的，老闆作為“管理者”角色的職能幾乎談不到，甚至受師傅的擺佈，除非老闆是一個非常高水平的技術大牛。
（二）老闆對軟件開發的過程無法介入，各層級之間也是以人為紐帶的弱管理
老闆大概知道要開發個什麼東西，需要什麼時候交付，但具體開發過程、產品工期、產品質量老闆只能問技術總監，有趣的是技術總監也是個大概齊，更多的只能問項目的負責人，雖然越接近開發工程師，越瞭解實際情況，但項目負責人甚至都不知道手下的工程師今天倒底是寫代碼了還是打遊戲了，這種粗放的管理水平在今天的其他行業是很難想像的。
（三）無文檔式開發，設計都在師傅的大腦裡，開發項目可持續的風險很大
作坊式開發過程中的技術負責人員一般是個“英雄”，應用系統的“設計”是在其腦子裡完成的，在其意識裡工作結果就只是一堆可執行的程序，既然能直接敲得出來，自然沒必要再做寫文檔的“重複工作”，各種文檔的不健全現象普遍，可以形象的比喻為“大樓有了，圖紙滯後”，現實就這麼可笑，更要命的是很多後補的開發規範的技術文檔與軟件產品本身並不能對應。
缺乏必要的設計和文檔，導致由於設計思路和實現細節在項目組內的交流困難，大部分的系統開發過程由於大量嘗試性、重複性工作而變得緩慢，後期調試會出現許多意想不到的大大小小的問題，狼煙四起之時大多數技術人員特別是技術負責人主要工作是“救火”。這樣的項目，工程延期往往是普遍現象，“火勢太大”情況下的人力再投入常常被“情非得己”地採用，工程越大越是如此。軟件開發的特殊性決定了其工程效率與編程人員的數量並不成正比，沒有過程文檔支持下的項目到了後期，人員的投入反而有可能使工程進度減慢，甚至失控。
在作坊式的軟件企業和開發團隊裡，會“救火”的技術人員就是掌握命運的英雄。可想而知，如果這樣一個英雄半途離開，那沒有文檔支持的項目的中間結果對其他人來說基本上就是“一堆垃圾”而已，也就是說，前期投入的資金只是造了“一堆垃圾”。
二、作坊式軟件開發的主要原因
（一）軟件開發的特殊性
這要從Fred Brooks在1987年所發表的《沒有銀彈》說起，“No Silver Bullet”寫道：“沒有任何技術或管理上的進展，能夠獨立地許諾十年內使生產率、可靠性或簡潔性獲得數量級上的進步。”因為軟件的根本困難（Essence，包括複雜度、一致性、可變性、不可見性）導致每一個軟件開發過程都具有其與眾不同的特殊之處，不同的軟件要解決的實際問題通常都具有相當大程度的複雜性，既不需要廠房也不需要機器，是工程師大腦裡的生產，優秀的工程師“作坊師傅”自然非常重要，軟件開發從誕生起就很作坊，一些大牛程序員憑藉一己之力創造了眾多偉大的軟件技術產品，所以軟件開發天然有著作坊的基因。
關於“No Silver Bullet”多扯幾句，其實也沒有那麼悲觀。第一，所謂“沒有銀彈”，只是說不能將生產率提高一個數量級，但並不妨礙我們繼續尋找“銅彈”、“鉛彈”，即有效解決次要問題的辦法；第二，“沒有銀彈”只是一個經驗論斷，並且是從軟件工程的角度來作出的論斷，在未來、在軟件工程之外的領域，或者就可以找到解決根本問題的“銀彈”。
實際上呢，Brooks更多地是站在當時的時點歷史的看問題，1987年以後的十年，軟件開發的確沒有出現十倍效能的進步。但是進入21世紀後，當軟件開發迎來了互聯網的廣泛應用之後，網絡提供了更大範圍的知識共享和技術學習，在部分行業和領域的軟件開發效能取得了快速的進步，可以說互聯網是軟件開發的第一顆銀彈恰如其份。我們看到的是互聯網促進了工程師的學習和共享，但並沒有改變軟件開發的日常管理和組織形態，只能說變成了效率更高一些的作坊，作坊的效率有了十倍以上的提高。
（二）軟件工程化開發的成本太高和“無知的用戶”廣泛存在
定製軟件開發幾十年來面對的多是“無知的用戶”。他們並不知道軟件開發應該有計劃、調研分析、方案、設計、質量監督、測試、培訓、系統說明文檔等等內容，他們對軟件產品應該具有的性能、適應性、安全性幾乎一無所知，他們甚至對一個自己所需要的應用系統的功能範圍都不是能夠很好地定義，這樣的不成熟的用戶是很少會對開發企業和開發團隊提出實質性生產要求的。他們往往將期望寄託於他們選定的開發企業，認為一切難題都會由開發方很好地解決，他們不會想到軟件開發的失敗可能（失敗了也是開發方的事），當然也就不會去了解會導致開發失敗的風險因素，也就不會提倡以工程化的規範方法來約束過程了。
“無知的用戶”廣泛存在，是“作坊式開發”賴以生存的沃土，培育了“作坊”的勃勃生機。道理很簡單，既然用戶要的是包括其規劃功能的、可以“跑得通”的應用程序，何必當什麼工程來費時費力地勞作，直接敲出來不就得了！有那功夫還不如找些理由應對用戶的“挑剔”。
（三）軟件開發的運營管理缺乏有效的IT支撐，很奇葩的燈下黑
管理信息系統在各行各業的應用，極大的提升了管理效能，今天不少優秀企業的運營管理很牛叉，主要的功勞是信息系統對核心業務支撐的好，從人的角度看企業的管理力和領導力或者說管理團隊的運營管理能力並不起主要作用，都是沾了信息系統應用的光。軟件開發行業則是燈下黑，核心業務並沒有得到信息系統的有力支撐，很奇葩的現實，變革已經進入進行時。
我們今天看到各行各業都在實施信息化的深度應用，不論製造業還是服務業，做的好的企業基本都實現了核心業務流程的信息化，通過海量數據和豐富的應用軟件創新，為企業面向顧客的服務、內部管理和決策提供了全方位的支持，各種ERP、各種信息系統，搞的好點的企業都可以說處於高度可控的運營狀態。軟件開發行業相比起來就是小農經濟手工作坊的感覺，開發工作不能基於對其核心業務的產物（每一行代碼）形成實時數據流的全程無縫管理，數據基本都是粗線條的、割裂分段分塊的，信息系統的應用只能是分段分塊的工具級應用，上升不到支撐業務全流程的精細管理，實踐中更多需要依賴人對人的粗放管理來實現的，很多時候還需要靠吼，這種燈下黑是不是很不可思議、很超級奇葩呢？
只要是軟件公司的老闆都希望能實現其核心業務的信息化，讓信息系統支撐程序員的工作，讓程序員依靠信息系統工作，最終實現信息系統助力企業管理運營效能的提升，這才是商業企業的必由之路。今天來看，符合時代特徵的軟件開發管理的基礎是基於每一行代碼的信息化管理，需要讓軟件開發全程透明，讓老闆很容易知道誰幹的好乾的多，讓項目工期控制和質量控制上有明顯提升，讓程序員能比較容易的進入和退出……
老闆們都知道，想要做好軟件開發的管理工作，軟件開發核心業務的信息化支撐是核心，怎麼把一行一行代碼管起來是關鍵，但是有心無力做不到啊！
聽起來也很不可思議，開發軟件的人沒有辦法用軟件把軟件開發工作精細化的管理起來，現實就是這麼搞笑，因為太難。
為什麼太難？我們看到不論是製造業還是服務業，支撐其核心業務的信息系統的根子是實現了所有細節信息的全流程管理，但是請注意，所有的信息之間都是線性流程化的，邏輯和先後都是普通人腦可以形象思考的，所以開發個信息系統來支持對業務的運營管理可以越做越細，數據可以越分析越有用，這個只要花錢是不難的。
軟件開發工作則不然，它的核心產品其實就是一行一行代碼，核心業務信息系統要處理的也是一行一行代碼，代碼之間的流程順序和邏輯關係是非常複雜的，不是線性流程的，用傳統信息處理中的增刪改查是沒有辦法來實現對代碼（信息）的有效管理利用，所以到今天我們依然沒有看到一款能支持軟件開發企業精細化管理的信息系統。
我只能大概作個比喻，其他行業的信息系統處理的信息是“死”的，它本身只是數值，可以通過線性流程來處理，以支撐這些信息表達的核心業務運營管理；而軟件的代碼，它是“活”的，軟件開發的核心業務要實現用信息系統有力支撐，一定要實現對這些活的信息（代碼）進行有效處理，傳統的信息處理技術估計就沒有辦法了。所以，軟件開發行業這麼多年除了互聯網這顆銀彈外，一直沒有一顆在運營管理上有突破的銀彈，因為開發不出來一套能支撐軟件開發工作的核心業務的信息系統，沒有辦法對軟件開發工作實現精細化的信息化管理。
三、目前幾個方向的努力
（一）提升軟件工程管理能力
這一點就不多說了，執行起來成本太大，大企業、大項目落地是可行的。
（二）行業、領域的低代碼開發
低代碼開發平臺是目前看到的一種脫離作坊式的實踐，由於軟件開發工作是依託低代碼開發平臺來開發的，平臺本身形成了完整的閉環管理，可以認為使用低代碼開發平臺的軟件開發企業隨著平臺功能的完善，逐步能實現對軟件開發工作的精細化管理。
既然是低代碼開發平臺，肯定就有封閉性，在新技術、新體驗的應用方面可能會顯現出支持能力不足不及時的缺陷，對程序員的個人自由發展也有一定限制，對企業的自由度也是非常大的約束和限制，總體來看，低代碼開發平臺可能會侷限於一定的範圍和場景內使用，很難從根本上改變軟件開發行業的運營管理能力不足的問題。
（三）人工智能在軟件開發中的應用
針對軟件開發中代碼信息的獨特性質，傳統的針對線性數值類“死”信息的處理看來走不通，只能從非傳統的數據處理技術來尋找解決方案，估計只能是人工智能了。曾總的猿開開雲開發平臺開創性的提出了用人工智能的方式來解決對這些代碼信息的有效管理，實現軟件開發的每一行代碼都能被信息系統有效管理起來，使得開發全過程的每一行代碼都置於信息系統的有效管理之中，在軟件開發中實現類似於我們今天在各行業看到的精細化管理，從而全面提升軟件開發的效能。
我估計很多學軟件編程的人沒有考慮過軟件開發核心業務的信息化支撐問題，怎麼用信息系統把每一行代碼精細化的管起來？當你深度瞭解猿開開的技術原理後，就能理解其精妙所在，為了能有效處理這些軟件開發中最具體的代碼數據，你首先要在“猿開開”系統裡定製自己的各種開發規範，這就形成了像下圍棋的規則體系，程序員開發的每一行代碼可以比如為你下的棋子，除了互相之間發生關係影響外，還要與這個規則體系發生關係影響，通過系統自動的智能化的根據每一行代碼的寫入來做出各種處理，否則就只能像現在這樣，主要依靠程序員本身的能力和分段式的粗放管理。
猿開開是不是能改變作坊式軟件開發的銀彈呢？
下面簡單介紹一下猿開開，它是基於人工智能在軟件開發領域的突破應用推出的，是一款革命性的雲開發平臺。猿開開實現了哪些業內首創？
猿開開的應用讓軟件開發企業一把手能夠全面掌控軟件開發工作，在不改變程序員原有工作方式、幾乎沒有學習成本的條件下，讓開發工期、員工效能、代碼質量全程被掌控，並且大幅提高開發效能。以下均是業界首創：
1.首次實現了開發規範的強制、無感、智能化的落地，通過桌面探針和雲端處理的連接，讓開發規範真正得到遵守並且發揮巨大作用。
2.首次實現了代碼實時在線提交、智能集成，極大的提高了開發協同能力，強化了對開發全過程的監管。
3.首次實現了將軟件開發的核心價值集中到詳設階段，通過細化到小時的任務拆分，其它的具體開發任務完全可以通過在線的虛擬團隊實現雲化的高可控開發，常備的技術員工隊伍可以大幅度減少。
4.首次實現了開發項目大部分代碼的規範化自動生成、自動更新，讓自動生成代碼變得有顯著價值，大概主要包括框架、路由、協議和接口類的代碼。
5.首次實現了開發人員所需要的各種文檔百分之百自動生成，而且跟每次開發的變更都是實時同步的，代碼和文檔高度一致，對系統的持續性有極大的好處。
猿開開的核心技術創新是什麼？
軟件工程的根本困難在於：都是概念上的結構，而不是對概念進行表達和實現逼真程度進行驗證，和建築工程比起來，在複雜度上、一致性上、可變性上、不可見性上、可持續性上都要超出很多，讓人腦在實際駕馭過程中很困難。
猿開開認為軟件工程中所有問題的根本在於開發規範不能得到實時、自動、低成本的落地和維護，猿開開基於面向過程的模式驅動技術是開發規範高效落地的核心，該技術是人工智能歸納領域的一次突破性應用，通過尋找最大化共性，自動形成作用於系統的規律和規範，並且能不斷的自動跟蹤調整。
面向過程的模式驅動技術，通過自動化從多個事務中抽取、建立、配置、驅動、運行來建立共同的規範，這種人工智能的應用，使得規範建立和持續維護的成本非常低，是無感而強制的，從而巧妙的在根本上解決了規範落地的難題。
結尾：猿開開的技術大牛曾總提出的模式化理論，讓人工智能在軟件開發的運營管理過程中有了開創性應用，並第一次在實踐中實現了軟件開發工作全程在線、智能化自驅動，使得最基本的運營管理訴求在軟件開發行業第一次被滿足，讓每一行代碼被置於系統的管控之下，通過信息系統讓軟件開發企業和團隊的管理工作得到落地加強，開發效能顯著提升。
