在製造業供應鏈中有所謂「長鞭效應」：「下游的訂單產生變異時，訂單資訊因為某些因素而被逐級放大的現象」。
其實在軟體業，也有製造業供應鏈「長鞭效應」的現象，但其負面結果及解法不同。
Photo from wikipedia
長鞭效應(Bullwhip Effect)
「長鞭效應」（Bullwhip Effect）是把整個產業供應鏈比做一條鞭子，而鞭子的一頭是握在最終端的客戶手中。
隨著客戶購買需求的改變，就像搖動鞭子，於是整條鞭子的各環節也跟著不停地擺動。當鞭子越長時，鞭梢擺動的幅度就越大，於是整個產業供應鏈就向上遊影響而變得非常不穩定。
在製造業的解決方法，利用資訊科技將供應鍊的庫存串連，使資訊透明。另一個方式，就是利用電子商務的方式，直接跨過中間的批發商和零售商，由製造商（網站）直接賣給最終的消費者。
我知道這個例子大家可能聽了不是很懂，沒關係，我拿一個在軍中看到的實例。
「長鞭效應」在軍中的實例
我在部隊服役時，每個月的辦伙軍官會計算由各連執星官彙報的開伙人數，以此來決定採買的主副食及每日的菜量，假設一營有4個連，每連120人。
改善前：各連執星官彙報的開伙人數，在考量不確定的差勤、臨時公差、請假、或其他因素，會多報一些人。如果每個連隊都多報5人，四個連就多報了20人。再加上辦伙軍官不知道各連隊已經多報了人數，所以又會再加上營級的彈性人數15人，多報的人數加總就有35人。
以一個人一餐的副食30元計算，光是一餐最多可能浪費了1050元，一個月扣掉放假後剩23天來計算，一個月最多可能浪費24150元（30元*35人*23天=24150元）。
改善後：營長要求各連的值星官改採精準的計算人數方式，統一由辦伙軍官計算彈性人數15人。這樣一個月最多只會浪費了10350元（30元*15人*23天=10350元）。
和改善前相比，精算開伙人數的效應是省下了13800元，這筆錢在月底的慶生會就能發揮用處了！
長鞭效應的差異
其實在軟體業也會有類似製造業供應鍊長鞭效應的問題，但情況稍有差異：
| 產業供應鏈 | 差異處 | 軟體開發 |
| 下游訂單 | 發生點 | 上游需求 |
| 逐級預防缺貨 | 發生原因 | 逐級延遲/延後 |
| 過度生產和存貨 | 結果 | 軟體品質不佳、時程延後、增加人力成本 |
以我們公司目前的軟體的開發過程：
- 上游「硬體部門」 member 負責開發硬體，並依照硬體的開發進度，告訴中游的同事需要在模擬器內模擬的功能（提出需求）。
- 中游「模擬器」 member ，在接收了需求後，會依照Spec文件，在模擬器內實作出這些功能，使得模擬器能模擬出與硬體的功能相符的結果；並告訴下游 member 這些功能的interface。
- 下游「前端IDE」
下游的 member 知道了interface後，要在IDE的前端作出這些interface的GUI，讓User可以透過GUI，將命令傳到後端的模擬器模擬出這些功能。
軟體開發長鞭效應的結果1-軟體品質不佳、時程延後
當我們把實際的情況套入軟體的開發過程後就發現問題了。
在前一版軟體 Release 後，我們就一直內部討論下一版軟體的內容。
但即使軟體內容確定，也確定下一版軟體 Release 的時間在六月底，但上游 member 並未凍結這個內容，反而隨著外在環境、與內部開發的情況，一直在改變軟體內容。
有時是為了某個客戶的要求，而必須新增客戶需要的功能；有的時候則是硬體上的限制、或缺陷，為了讓程式在硬體和模擬器上表現的行為一致，所以得用軟體修正硬體的Bug，以符合一致性的要求。
這些變動使得下游的 member 一直無法決定該版軟體實際的GUI介面，搞得在最下游負責V&V的我，為了避免重覆測試，得一直將測試時間向後遞延，以避免因為實際需求變更而重覆測試。
當這個軟體內容一直到 Release 前二十天才總算確定時，最大的影響是壓縮到最後面V&V的時程竟然得在一個星期內作完。
但實際上這有執行上的困難；即使我執行了，軟體品質就能提高嗎？
軟體開發長鞭效應的結果2-增加人力成本
我當然理解，在軟體開發的過程，需求本來就會隨著實際變化作修正，但這些修正理應要記錄在文件內。
但我們公司缺乏「文件版本控制」機制，上游的 member 始終沒有控管文件版本並發布，這才導致下游的 member 仍依照舊版文件實作軟體。一直要等到匹配後發現錯誤，一追查問題，才知道是上游的某些關鍵資訊已經修正或更新，卻未通知下游的 member 。
因為不斷地發生類似的錯誤，使得公司的人力配置，一直耗在這類非關鍵的地方。常見的情況是才剛花時間作完的東西，卻可能因為一句話、一次小修正，就導致下游的 member 得重作、甚至將完成的產品棄之不用，既浪費時間、也浪費人力。
軟體開發長鞭效應的解法
我一直思考「難道我們不能一次解決這類的問題嗎？」
後來，我發現長鞭效應的問題並不在揮動鞭子的動作，而在鞭子本身，也就是軟體開發的過程。原來是因為我們沒有做好軟體開發過程的某些關鍵活動，才讓小問題透過長鞭效應而逐級放大成更嚴重的問題。
所以我歸納了該做的事，能徹底解決一直困擾我們的問題：
- 需求管理
- 建立開發流程
- 文件版本控制
- 型態管理
需求管理
其實「需求管理」已經不只是軟體開發專案的範疇了，也是所有專案管理的重點。
在我遇到的情況中，已經不只是在軟體開發層面把描述清楚這樣簡單，還得考量商業機會與內部資源。有時，非得要在某個特定時間點完成特定的功能，才能達到商業目的，對公司產生實際的助益。
有時，也得砍在某個時間點（Feature Freeze Date），因為資源永遠有限！否則軟體永遠沒有完成的一天！
建立開發流程
在還沒導入 ISO 系統前，我們公司並沒有制定嚴謹的開發流程。但即使未來導入ISO系統，也因為我們的管理階層一直很擔心在執行了制定的開發流程後、會使我們的軟體開發效率降低、和人員反彈，甚至導致人員離職，所以一直在推行軟體建立開發流程上有所顧慮。
我曾經和同事討論這個問題，我們的結論是：一個錯誤的開發方式，即使效率再高，也只是很有效率的產出有問題的產品。
這句話說來殘酷，但一針見血的點出了目前軟體開發部門的情形。
我們的主管一直要求有效率的開發，結果卻導致我們不斷浪費時間用錯的方式作錯的產品，然後再不斷的花時間去修正，這個情況我已經在《軟體開發的遭遇戰》中已經說明。
文件版本控管
要做好「文件版本控管」，必須先有嚴謹的開發流程，才知道在開發流程的不同階段執行該完成的事，每個階段的作業才能依照上個階段的產物進行開發，這樣作「文件版本控制」才會有意義。
但是，我們公司的管理層一直輕忽建立開發流程，自然也無法要求 member 在何時必須產出那些必要文件。
因為我們的管理階層認為：寫文件是一件浪費時間、金錢的工作。影響上遊的開發人員並不會在規畫、構思階段就寫出必要的設計文件，並先想清楚自己的工作內容。最後導致上游的開發人員無法產出一份能對下游同事說明的文件。
當SQA要去Verify這些功能時，就只能依靠僅僅數頁在開發前期、為了討論設計內容而作的Power Point檔、和口述片斷資訊來制定Test Plan/Case，但這些片斷資訊卻不足以讓SQA去V&V這些實作出的功能。
但即使有了文件，也做好版本控管，事情也只完成了一半，另一半得靠文件的公告、發布，才能讓必要的相關人員，了解這些關鍵文件，不過，這已經是後話了。
型態管理
「型態管理」（CM, Configuration Management）是在CMMI Level 2就要執行的項目，可見這個工作是相當基本且重要的工作。
「型態管理」是系統生命週期內從頭到尾，針對硬體、軟體、韌體、以及文件所做的變更（包括其衍生出的紀錄）的管制。和「版本控制」不同的是，「型態管理」著重持續追蹤內容的變化過程記錄。
型態管理的過程，含括了一個變更管理的過程：提出的變動編號、內容、相應改變的評估（變動輻度、人力評估、時程的影響、可能的影響與風險、變動方式、方案評估）、變更的確認（客戶、執行單位）、相應所需的其他變更內容（如：相關文件、測試個案）。
不過，我們公司既然欠缺需求管理、尚未建立開發流程、也未完成文件版本控管，自然也無法達成「型態管理」。這導致我們根本無法追蹤每個版本的變化及其影響，最後當然無法了解每個版本實際的情況。
小結
以上這四類的問題在小公司、以及新公司特別常見。
小公司往往因為案子規模不大、金額不高、時程緊迫，導致無法落實這些看似無用的活動；新公司則因為未建立有效的開發流程，使得其他三項工作無法有效達成。
但如果真的以總成本（開發成本 + 維護成本），更應該得這麼做，只是管理階層始終不這麼認為！
大公司也是一樣常見,台灣軟體沒幾個像樣的
回覆刪除