1. 背景

軟件產(chǎn)品在經(jīng)歷前期一系列的設(shè)計岔激，研發(fā)萎攒，測試等流程遇八，進入到實際的部署使用環(huán)節(jié)，整體流程可以分為兩大塊：

1. 前期的大量成本投入階段耍休。這里就是上面提到的"設(shè)計刃永、研發(fā)、測試"羊精。
2. 后期的成本回收斯够，賺取利潤階段。比如這里提到的"部署使用"园匹。

對于賺取利潤階段的"部署使用"來說雳刺，如果這個軟件產(chǎn)品采取的是類似支付寶/12036這樣的集中部署方式，那么出現(xiàn)問題基本都是自己內(nèi)部維護裸违，影響相對可控掖桦；但是對于本文將要重點討論的"本地化部署"場景下，客戶現(xiàn)場環(huán)境的千差萬別供汛，以及涉及研發(fā)枪汪，測試/技術(shù)支持，實施怔昨，終端用戶多方參與人員等等雀久，對于可能遇到的問題種類和數(shù)量，稍有經(jīng)驗的都應(yīng)該會對此刻骨銘心趁舀。

針對"本地化部署"場景下的軟件產(chǎn)品在使用過程中所遇到的問題赖捌，我們可以將其解決方案以逐級遞進的方式劃分為：

1. 面對面溝通解決；
2. 解決方案文檔形式矮烹；
3. 提供簡單的可執(zhí)行修復(fù)程序越庇；最典型的如shell / bat腳本罩锐；
4. 提供界面化的修復(fù)程序。

針對以上四種方案卤唉，本文嘗試闡明一些基礎(chǔ)性的認知涩惑，并且對其進行邏輯上的論證。因為在實際的工作過程中桑驱，我發(fā)現(xiàn)不同的團隊竭恬，團隊內(nèi)部對其的理解千差萬別，出現(xiàn)"問題解決慢熬的，難以斷根痊硕，問題改進緩慢"等諸多問題，進而造成軟件產(chǎn)品在持續(xù)演進過程中質(zhì)量問題無法被遏制悦析，甚至隱約表現(xiàn)出下坡路的跡象寿桨。

2. 前置知識

正式開始介紹前，我們有必要先對幾條基本理念達成一致强戴，方便之后進一步的交流討論亭螟。

2.1 軟件產(chǎn)品賺的是規(guī)模效應(yīng)的錢

首先我們要明確的一個基本理念是"軟件是一個邊界成本低的特殊商品"，相較于初始巨量資源的投入骑歹，后期的分發(fā)成本基本可以忽略不計预烙。

2.2 雖然軟件是群體分工協(xié)作的產(chǎn)物，但各崗位利益訴求存在顯著差異

如果做出來的軟件產(chǎn)品始終局限在有限的用戶范圍內(nèi)道媚，除了極少數(shù)的場景外扁掸，這類軟件產(chǎn)品的生命周期肯定不會太長，那么依附于這個產(chǎn)品之上的從業(yè)人員最域，其職業(yè)生涯自然也會出現(xiàn)問題谴分。

因此，上至公司镀脂，中至領(lǐng)導牺蹄，下至一線從業(yè)人員，其實都是對于產(chǎn)品的規(guī)模效應(yīng)有著一致的利益訴求的薄翅。只是對于不同的視野下沙兰，各方的感受程度不太一致：

1. 對于公司和領(lǐng)導，明確直接的盈利要求被直接擺在面前翘魄，不由得你把腦袋埋進沙子里鼎天。
2. 但對于一線從業(yè)人群，當制度無法將利益進行顯著捆綁時暑竟，干多干少斋射，干好干壞都不影響我拿這一個月工資，那大多數(shù)人的選擇自然是順著人性一路滑下去。

3. 化學反應(yīng)

以下讓我們針對不同的組合绩鸣，探究下"四種方案"在不同環(huán)境下的表現(xiàn)：

3.1 "問題解決的四種方案" + “規(guī)模效應(yīng)"

以上四種方案還具有如下特點：

1. 四種方案至上而下乘综，對研發(fā)的要求逐級提高憎账。
   1.1 “面對面溝通”是最符合人性的 —— 想到什么直接上手干，有什么疑問直接開口問卡辰；突出一個即時滿足胞皱，解決眼前問題就好。
   1.2 相較于之下九妈，"文檔/腳本"等方案既要思考用戶操作習慣反砌，又要考慮各類系統(tǒng)的兼容性，更得時刻注意的文檔/腳本實時性萌朱，這對腦細胞實在是太不友好了宴树，累！
2. 單項目模式下嚷兔，四種方案至上而下成本是逐步增加的森渐；但規(guī)模效應(yīng)下卻是反過來。
3. 單項目模式下冒晰，位于前面的方案對于研發(fā)更為省力同衣，尤其是當研發(fā)的職責中不包含文檔這一項時 —— 研發(fā)只負責口訴問題解決方案，由專門的技術(shù)支持人員來進行文檔編寫壶运。
4. 由團隊最終的選擇來逆向推導耐齐，可以很清晰地分析出：絕大部分團隊成員的認知里就是一個個項目這么干下去，規(guī)模效應(yīng)壓根不在其考慮范圍內(nèi)；即使規(guī)模效應(yīng)出現(xiàn)埠况，那我就一個人你能拿我怎么滴 —— 我又沒閑著耸携，我只要表現(xiàn)得在忙就行，忙什么無所謂辕翰。雖然規(guī)模效應(yīng)是這些崗位存在的意義夺衍，但意義這玩意太長遠了，考慮著太累喜命。

3.2 "問題解決的四種方案" + “不同的利益訴求"

隨著軟件體量的擴展沟沙，以及規(guī)模效應(yīng)之下，相應(yīng)的團隊里勢必會產(chǎn)生更為細化的分工壁榕，例如一開始可能是由研發(fā)直面用戶矛紫，然后慢慢分工出來測試，技術(shù)支持牌里，實施等等崗位颊咬。

在本文探討主題"四種解決方案"之下，以上的細分崗位可以進行歸納總結(jié)為兩大類：研發(fā)和其他牡辽。

是的喳篇，此類場景下測試/技術(shù)支持人員/實施可以近似看作產(chǎn)品的最終用戶，他們是有著相似的利益訴求 —— 產(chǎn)品最好沒問題催享，如果出現(xiàn)問題希望能夠盡快得到修復(fù)杭隙，越快越好。

對于以上這個對比表格需要做一些解釋：

1. 對于各方而言因妙，尤其是對于軟件產(chǎn)品服務(wù)的提供方（研發(fā)/測試/技術(shù)支持等）痰憎，基于眼前的短期利益而言，他們是和最終用戶有著一樣的利益訴求的 —— 直接面對面溝通方式解決掉眼前問題攀涵，方便快捷铣耘。
2. 但是在規(guī)模效應(yīng)的加持之下，解決方案的選擇就開始產(chǎn)生分歧：
   2.1 終端用戶的訴求"盡快解決問題"造成其依然偏向選擇"面對面溝通"方式解決問題 —— 有專人服務(wù)以故，不用承擔導致問題可能進一步惡化的責任蜗细；而且我是掏了錢的，理應(yīng)享受這樣的待遇怒详。
   2.2 但是對于諸如研發(fā)/測試/技術(shù)支持這類的服務(wù)提供者炉媒，這個時候就不再是"面對面溝通是最優(yōu)解"了，大量的用戶解決問題的訴求昆烁，相較之下非常有限的支持團隊吊骤，如果采用"面對面溝通"方式去解決，那公司商務(wù)的工作就只剩下跟客戶道歉了静尼。

4. 如何應(yīng)對

"四種問題解決方案"在"規(guī)模效應(yīng)"白粉，"不同的利益訴求"的組合加持之下传泊，團隊需要形成一個健康的基礎(chǔ)思想認知，以及相應(yīng)的成熟處理流程體系鸭巴。

4.1 基礎(chǔ)思想認知

1. 工作量不會消失眷细，而只會轉(zhuǎn)移。作為研發(fā)-測試-技術(shù)支持-實施這樣鏈條體系而言鹃祖，問題存在時間越長溪椎，離起始點越遠，問題解決的成本也就越高惯豆，團隊為此需要付出的代價也就越大池磁。
2. 行文至此，其實我們一直嘗試將研發(fā)這個崗位從整個處理流程中單獨摘出來進行討論楷兽。如此操作的根本原因一來是我自身就是一個研發(fā)，擁有著相關(guān)切身感受华临；二來則是最根本的 —— 研發(fā)是最有希望改變這個"老鼠跑圈"死循環(huán)的芯杀，他們有這樣的能力，現(xiàn)在是需要補齊這個認知和意愿雅潭。不能將應(yīng)對單個具體實際項目這種低工作壓力狀態(tài)的思維揭厚，一成不變地應(yīng)用到規(guī)模效應(yīng)下的軟件產(chǎn)品維護中。
3. 四種解決方案扶供，所體現(xiàn)的其實就是"個人利益和團隊利益"筛圆，"短期利益和長期利益"，"過程負責還是結(jié)果負責"的抉擇椿浓。
4. 在"單項目"這種符合人性（目標明確太援，反饋迅速等）的低工作壓力模式下，問題解決效率和成本要求勢必不會太高扳碍；但是一旦規(guī)模效應(yīng)開始發(fā)揮威力提岔，效率和成本問題將不斷直接拷問團隊的極限，這個時候團隊是選擇迎難而上笋敞，銳志進燃蠲伞；還是抱著原有解決問題方式夯巷，"咱就這個效率了"赛惩；這必然導向兩條截然相反的結(jié)局。

4.2 處理流程體系

針對以上"四種解決方案"在規(guī)模效應(yīng)下的選擇問題趁餐，這里我們跳過諸如"分析問題是否具備普遍性"等前置操作喷兼；直接進入"如果屬于普遍性問題"時，四種方案的推薦選擇如下：

1. 面對面解決第一次
2. 解決完問題之后開始編寫注意事項說明文檔澎怒，并且開始思考將文檔進行腳本化褒搔。
3. 隨著相同問題的繼續(xù)出現(xiàn)阶牍，持續(xù)優(yōu)化文檔和腳本，逐步將修復(fù)操作從文檔過渡到以腳本執(zhí)行為主 —— 注意這一步切換采取小步快跑的方式實現(xiàn)（內(nèi)部以最快速度普及驗證）星瘾，以實現(xiàn)盡量快的切換走孽。
4. 待腳本穩(wěn)定之后，視問題解決的ROI琳状，考慮進行最后的“界面化的修復(fù)程序”選項磕瓷。

演進過程中，研發(fā)負責持續(xù)跟進腳本/界面修復(fù)程序的正確運行念逞，進行解決方案沉淀困食，實現(xiàn)腳本/界面修復(fù)程序的逐步智能化。其他崗位人員只負責執(zhí)行程序并確認問題被修復(fù)翎承，其他事情都不應(yīng)該關(guān)心硕盹。如此來減少其他崗位人員對于該類方案的抵觸，提升其使用意愿叨咖。

4.3 組織結(jié)構(gòu)

這一步就比較務(wù)虛瘩例，而且本人這方面并沒有多少經(jīng)驗，所以只做簡單的總結(jié)甸各。

1. 組織結(jié)構(gòu)調(diào)整垛贤。對于設(shè)計為規(guī)模效應(yīng)的軟件產(chǎn)品而言，其人員選擇是一定存在比較高要求的趣倾，如果人員能力和職業(yè)素養(yǎng)存在較大的差異聘惦，建議直接進行替換。與其花時間培養(yǎng)儒恋，不如花時間尋找善绎。
2. 利益綁定。將軟件產(chǎn)品的收益與團隊成員的直接利益綁定碧浊，從制度上將"結(jié)果導向"和"職業(yè)素養(yǎng)"思維倒逼出來涂邀。
3. 以固定的頻率置換產(chǎn)品研發(fā)人員去參與實際項目。感受實際的項目壓力箱锐，避免躲在溫室里自嗨比勉。

5. 一些"刺耳"的話

其實這篇行文完全不在我的計劃里，而且在過往職業(yè)生涯里驹止，我也一直都是按照"規(guī)模效應(yīng)"場景來要求自己面對問題時候的思考浩聋；因此以上文字并沒有進行長期的顯性思考和總結(jié)。

不過最近一年多新的工作環(huán)境下的觀察臊恋，使得我見證了另外的選擇衣洁，這個選擇讓筆者難受，但細致思考分析卻有著其合理性抖仅。

所以以下只是一些并不針對任何人的吐槽（將它們從大腦有限的內(nèi)容里倒騰出來坊夫，留出空間給寶貴的邏輯思考）：

1. 上面說的"問題解決慢整個處理鏈條上都跑不了"砖第，這個其實就屬于"結(jié)果負責"，但往往鏈條上的各崗位所秉承的卻是"過程負責" —— "死道友不死貧道"环凿，只要火不燒到我這里怎么都行的心態(tài)梧兼。至于全鏈條上的成本，嗯智听，只要不是我來承擔就行唄羽杰。
2. 對于當前由"實施-技術(shù)支持-測試-研發(fā)"所構(gòu)造出來的問題解決層次體系，動不動就被輕易擊穿前三者到推，而將問題露到研發(fā)這里來考赛，研發(fā)自身覺得這種情況好受嗎？
3. 以上的問題我在不同的場合隱含地表露過莉测，對方的第一反應(yīng)是"又不是我的問題"颜骤，“你是不是在責怪我”？反應(yīng)那是相當之強烈捣卤，遠比"怎么快點解決這個問題"要急切得多复哆。
4. 對于研發(fā)，“不斷抱怨實施/技術(shù)支持/測試人員不靠譜”這說明你并不信任他們腌零；但在實際操作上采取的“文檔大于腳本”解決途徑似乎表面你又是信任他們的；這兩個看著矛盾的操作底下其實是有著統(tǒng)一自洽邏輯的 — 盡快把包袱甩出去唆阿，出問題大家一起扛益涧，實在沒辦法/甩不出去了再說。
5. 文檔之所以成為腳本/界面化修復(fù)程序/面對面溝通之外的首選：
   5.1 規(guī)模效應(yīng)下面對面溝通實在忙不過來驯鳖，我又不能不解決闲询，自然得找個方式。
   5.2 腳本/考慮的因素太多浅辙，不如寫個文檔教材把責任甩出去扭弧，況且文檔還不是由我來寫，我只要出張嘴就行记舆，還能顯示優(yōu)越感 —— 你們測試怎么連這個命令都不知道啊鸽捻。

6. 相關(guān)

1. 傳統(tǒng)軟件行業(yè)技術(shù)團隊中如何做好知識沉淀
2. 做技術(shù)決策時候的基本指導思想 - 簡書 (jianshu.com)