全文5000字，閱讀大約需要10分鐘。
世界第一名槍是哪一支？
AK47。
按單獨一款武器計算，它是有史以來產量最大的武器，問世70年來，原產於蘇聯和各國仿製的AK47（包括中國的56式衝鋒鎗）超過一億支。凡是有戰爭的地方，就有AK47的身影。
令人匪夷所思的是，這樣一款影響了全世界的武器，它的設計師卡拉什尼科夫，居然是一個業餘選手。
卡拉什尼科夫原本是蘇聯軍隊中的一名中士，作為坦克兵參加了蘇德戰爭，受傷住院後，無法再參加戰鬥，才轉行進入兵工廠。他自學槍械的製造知識，生生造出了一支樣槍。
當蘇聯徵集新突擊步槍的設計方案時，這位中士的樣槍居然一舉擊敗波波沙衝鋒鎗的設計者斯帕金、DP輕機槍的設計者捷格加廖夫等科班出身的設計大師，贏得了競爭，成為最大的一匹黑馬。
從此開啟了AK47和後續一系列AK槍械家族的傳奇。
AK47強在哪裡？
其實，直到今天，很多武器專家對於AK47仍然瞧不起。書生在一個電視節目上就看到一位專家說，AK47沒什麼，它就是各個零件設計的公差比較大，所以皮實抗造，技術上沒什麼先進性。
確實，即使是在1947年，AK47所採用的技術也並不先進，同時代比它先進的武器有的是。比如，早在1943年，德國就製造出了與AK47技術相近的StG44突擊步槍，很多人甚至認為AK47就是StG44的抄襲之作。二者從外形到原理都很相似。
60年代越南戰爭，美國有了斯通納設計的新一代小口徑突擊步槍M16，準確性大大超過AK47。可是一到戰場上，士兵們卻對M16非常抗拒，因為M16在亞熱帶叢林中故障不斷，經常打不響。在戰場上，武器失效就等於把命交到了敵人手上。傳說有很多美國大兵扔下自己的M16，撿起越共的AK47戰鬥。
這樣一款並不「先進」、也不被專家看好的武器，憑什麼贏得了士兵的歡迎呢？
卡拉什尼科夫自己給出了最好的答案：我的槍，永遠不會讓扣動扳機的士兵失望。
如果都打不響，再高的準確性、再遠的射程、再大的威力，有什麼用呢？
AK47不管進了沙子還是淋了雨水，不管在熱帶還是極地，永遠能打響。而且，AK47的零件很少，大量採用衝壓件，易維護，成本低，小作坊也能生產，沒文化的士兵都會使用。反觀StG44、M16、AUG等先進的步槍，作為一款決鬥武器可能是優秀的，但作為國家大量裝備、用於各種惡劣環境的武器，完敗給傻大黑粗的AK47。
當年美國為了告訴士兵如何對M16進行維護保養，緊急印刷了大量維護手冊散發給士兵。可是AK47根本用不著手冊，一個新手只要跟老兵學上五分鐘，就能使用。
當一款產品做到了連手冊都不用的程度，確實達到了產品的最高境界。
AK47的強，不強在技術，而是強在觀念。
卡拉什尼科夫作為一個戰場上滾出來的士兵，最理解士兵的需求。這種對需求的深入骨髓的理解，甚至超過了製造技術的重要性。
在武器史上，AK47這樣的情況並不少見。很多經典武器，都出自士兵或軍官之手。
比如，以色列著名的梅卡瓦坦克，還有全世界航母普遍採用的斜角式甲板，其發明者都是軍人，而非專業設計師。
梅卡瓦坦克是以色列根據自己的國情定製的主戰坦克，是世界坦克家族中的一個奇葩。它由以色列國防軍塔爾將軍主持設計，1979年交付部隊。在歷次中東戰爭中，梅卡瓦以微小的代價擊毀阿拉伯國家的大量蘇制坦克，聞名世界。
以色列對於坦克有特殊的要求，因為以色列處於阿拉伯國家包圍之中，戰爭不斷，人口很少，承受不起大量人員損失，所以對坦克的防護性能要求特別高。塔爾將軍是裝甲團長出身，深知戰爭的需要，所以在主持設計梅卡瓦時，採用了很多打破常規的方案。
比如，與大多數坦克不同，採用了發動機前置方案，為乘員增加了一重防護。坦克後艙可以容納十位步兵，使梅卡瓦能兼任步兵戰車。厚重裝甲、低矮炮塔、尾部車門等，都給乘員增加了保險係數，使梅卡瓦成了一款難以摧毀的坦克。
斜角甲板更是一個劃時代的發明，所有現代航母都採用了這個設計。但這個設計最早也不是出於工程師，而是由英國皇家海軍丹尼斯·坎貝爾上校提出的。
二戰後，戰鬥機進入噴氣時代，由於噴氣式飛機降落速度快，原來的直通式甲板無法滿足飛機降落的要求，也無法做到降落與起飛作業同時進行，必須尋找新辦法。一開始大家考慮的是「彈性甲板」方案，在著陸區鋪設柔性材料，讓飛機以機腹著艦。今天看起來這種方法簡直是玩兒命，但當時真的做了大量實驗，但總也達不到滿意效果。
1951年，曾任航母指揮官的丹尼斯·坎貝爾上校提出在甲板上設置一個斜角區域供飛機降落，等待起飛的飛機可以停在前半部甲板，不受降落作業的影響，降落與起飛作業可以同時進行，大大提高了出動率；飛機降落失敗時，也可以直接復飛。只是簡單地把甲板區域做了一次重新劃分，居然一下子解決了困擾所有專家的難題。
據說方案剛提出時，因為太奇特，無人響應。但是負責彈性甲板建造項目的工程專家伯丁頓卻慧眼識珠，看出了這個創新的價值。深諳作戰需求的指揮官坎貝爾與能將概念變成現實的工程師帕丁頓一起推銷，終於讓當局認識到了它的優勢，迅速在英國和美國的航母上採用，最終成了所有現代航母的標配。
這些劃時代的傑出作品，它們成功的共同秘訣，就是完美滿足了使用者的需求。
它們的成功，並非是採用了什麼超越時代的硬核科技，而是一種理念上的先進，是在客戶需求與實現方法之間找到了最佳的平衡點。
說回我們關注的軟體行業，道理是相通的。
一款優秀的軟體產品，不一定贏在天外飛仙的黑科技，而是具備更好的研發理念，充分契合使用者的需要，在客戶需求與技術方案之間找到了最優解。
道理不難懂，但真正做到滿足客戶需求，談何容易。
現實中，南轅北轍的情況普遍存在。
書生曾參與研發一個數位化手術室控制系統。
現代手術室充斥著高科技設備，包括手術燈、手術床、拾音器、攝像頭等等。我們做的軟體，目的是用一個界面控制所有設備，實現集中操控。
設備來自不同的廠商，有國產的也國外的，每種設備的控制接口不同，研發團隊克服困難，終於把所有設備搞定。再加上一個漂亮的界面，看起來很棒。
可是當我們把系統安裝到醫院，請醫生和護士試用的時候，他們一句話，就讓所有工程師涼了半截：
我們怎麼能背對設備控制設備呢？
原來，這個系統的觸控螢幕是安裝在牆上，人面對屏幕操控設備，可是它控制的手術床、手術燈等都在人的背後，操作人員無法直接看到操作的效果。尤其手術床，病人躺在上面，它的每次調整都得小心翼翼，背對著它怎麼做？還不如用手術床自帶的控制器呢。
研發團隊一拍大腿：怎麼光顧了接入設備，忘了這個最基本的問題呢！
後來，這個產品不了了之。
產品跑偏的根本原因，是使用者與製造者的分離。
自從世界從小農經濟進入機械化大生產時代，我們的生活就越來越依賴於「專業人士」的打理，無論衣食住行，我們都不會親手製造，而是購買專業廠商的產品。這樣一來，製造的人並非使用的人，製造的人不能直觀感受到使用者需要什麼，埋下了產品跑偏的隱患。
解決這個問題的流行辦法是：依靠流程，打通需求與技術。
可是，這件事卻非常非常難。客戶所需與所得之間，往往相距千山萬水。
軟體行業也像製造業一樣，把研發過程做成了流水線，專業化分工，需求分析、產品設計、程序開發、測試、交付，都變成了獨立崗位，鐵路警察各管一段兒。
打開招聘網站，軟體公司有很多職位，各有不同的技能要求：需求分析師、產品經理、架構師、程式設計師、測試工程師、實施工程師……
流水線的崗位之間，以文檔的形式傳遞信息，如需求分析方案、概要設計方案、詳細設計方案、測試方案等等。看似規範，但環節越多，信息越失真，每步謬之毫釐，最終差之千裡。
一張漫畫形象地描述了軟體研發是怎麼跑偏的。
而且最大的麻煩在於：客戶也說不清自己要什麼。
汽車大王福特曾經說過，在汽車出現之前，如果你去問大家需要什麼交通工具，他們會說自己需要一輛更快的馬車。
如果靠調研客戶就能創造出一款新產品，那產品研發就未免太容易了。
還好，客戶通常都知道自己不要什麼。所以，在產品研發過程中與客戶保持溝通，讓他們對產品提出修改意見，算是一種略好的方法，至少在出現跑偏時及時糾正。雖然並非最佳的方法。
書生在《中國的軟體項目為什麼失敗率這麼高？》中談到，中國的軟體項目有著奇高的開工率和奇高的報廢率，其中重要的原因，就是建設方與開發方在需求理解上的錯位，大量項目未能解決客戶的問題，只能棄之不用，造成驚人的浪費。
我們需要新思維。
靠流水線加文檔的方式，也許能做出過得去的產品。但想要做出最好的產品，遠遠不夠。
因為最重要的東西，常常無法靠文字傳達。
一位翻譯家說：詩就是那些在翻譯過程中丟失的東西。我們也可以說：需求就是那些在文檔中丟失的東西。
讓軟體研發像機器製造一樣，由設計師畫出圖紙，具體到每顆螺絲釘，交給流水線上的工人製造，這是烏託邦式的理想。因為軟體研發是複雜的智力活動，它需要的不是物理的拼裝，而是思維深處的化學反應，還需要在研發過程中不斷靈光閃現和靈活調整。需求一旦變成了冰冷的文字，就丟失了靈魂。
三個武器製造的例子，恰好揭示了可行的解決之道，而且恰好是三種不同的模式。
卡拉什尼科夫本人就是使用者與製造者的神合體。在打磨步槍的每個細節時，他都能融入自己的戰鬥經驗，反覆修正。如果他只是畫一摞圖紙，交給一個委員會去審核，再交給工廠去製造，恐怕只能得到一支平庸的步槍了。
梅卡瓦又是另一種模式。坦克比步槍複雜，塔爾不可能自己製造，但他直接領導設計團隊，工程師直接貫徹他的意志，造出他心目中理想的坦克。
斜角甲板的成功，得益於一位深入理解需求的航母軍官與一位技術專家的深度合作。一個產品的創意往往是模糊的，與實際的產品之間相距萬裡。這種難得的拍檔關係，彌合了這段距離。
第一流的產品，一定是使用者與製造者合體的產物。當製造者能用使用者的頭腦去思考時，就離好產品近了一步。
流水線的軟體研發模式，強調的是分，也就是分工。而上面三個例子展示的是合，也就是需求與開發的融合。
合與分，切割了優秀與平庸，決定了成功與失敗。
這啟發我們對視為當然的研發過程做出反思。
書生再舉一個建築業的例子，作為軟體業的參考。
美國建築大師C·亞歷山大在《住宅製造》一書中記錄了他在墨西哥的一次打破常規的建築實驗。他把住戶組織起來，讓他們在專業人士的指導下，自己為自己建造房屋。
不僅如此，他還把傳統上屬於兩個職業的建築設計師與建造師合而為一，讓建築師不只畫圖，還要現場指導住戶和工人，把圖上的房屋建造出來。
他的目標就是打破使用者與製造者分離，而且打破建造者中設計人員與實施人員的分離，讓他們合體。
他的新實驗給所有參與者帶來全新的體驗。住戶發現自己居然能完全按自己的家庭條件設計房子，而不是被動接受批量建造的住宅，都非常興奮。設計師也樂於參與到現場建造中，看著紙上的設計圖一天天變成現實。
這個實驗太離經叛道了，雖然住戶對建成的房屋很滿意，但政府總覺得這樣的房子不安全，叫停了實驗，未能大範圍推廣。
這次特別的實踐，對於軟體研發有著巨大的借鑑意義，揭示了另外一種可能性。
軟體比建築更複雜、更不可見，更需要使用者與製造者、製造者中的各個角色之間深度融合，而不是貌似專業化的分離與分化。
軟體業最需要的，正是卡拉什尼科夫這樣的跨界人才。
在中國IT行業，已經有一些公司默默採用了類似方式，儘可能拉近使用者與製造者的距離。
大部分網際網路公司都自己組織研發，讓研發最大程度貼近運營。很多有實力的大型企業也有自己的研發隊伍，負責研發重要的業務系統。但大多數客戶沒有研發能力，仍然需要採購軟體企業的產品。
很多軟體企業嘗試打破崗位的界限，甚至讓開發團隊直接對接客戶，以加快響應速度。但產品型公司一般都抗拒定製化開發，開發團隊與現場實施團隊嚴格分開，通過實施人員傳遞需求，似乎只有三流公司才會讓開發人員直接面對客戶，客戶讓改什麼就改什麼，最後弄出一堆亂七八糟的版本沒法統一。
事實上，直接面對客戶的開發，並不像看上去那麼落後，反而能以最快速度對需求做出反應，而不是讓客戶每天面對一個對開發沒有控制力的實施人員，一行代碼能解決的問題也要等到猴年馬月。而現場的鮮活需求，也能不斷反哺研發，讓產品持續滿足客戶的最新需求。
但大量軟體企業還是照搬外企模式，客戶提出的問題，先給項目經理，再給測試組，再給產品組，最後才傳遞到研發團隊，程式設計師看到的都是三四手需求。看著挺規範，但反應遲鈍，客戶不滿意，公司各部門也矛盾重重。
其實，那些面對客戶堅持「規範」的外企，在中國都走向衰亡了，反而是看似土鱉的本土企業，在「客戶永遠是對的」觀念下，在對產品看似無序的修修改改中發展了起來。
當然，如何保持對需求敏捷響應的同時，保證產品版本一致、質量穩定，如何控制成本，如何讓軟體架構更好地支持定製化開發，這些是軟體企業需要解決的難題，考驗著軟體企業的水平。
破解了這些難題的企業，必將創造第一流的產品。