很多人應該唸過 Internet 的概論與歷史，知道 Internet 是從 DAPR 發展為了想要降低以線路為主的通訊因為單點被攻擊而失能，而開發出以封包為主的通訊協定，但真的是這樣嗎？

很多人應該唸過 Internet 的概論與歷史，知道 Internet 是從 DAPR 發展為了想要降低以線路為主的通訊因為單點被攻擊而失能，而開發出以封包為主的通訊協定，但真的是這樣嗎？

的確當時 Internet 計劃是用這種理由去「圈錢」的，且最後這計劃獲得了很大的成果，不然就不會有現在的網際網路了，但過了 20 年後，裏面的工程師跳出來說話，說到當時裏面的開發者完全不是用這個角度出發，他們主要是為了降低成本提高效率而做的，這到底是誰對誰錯呢？

事實上這種狀況一直常發現在職場中，上面的決策者跟下面的執行者有很大的觀點落差，常常最後因為各種角力與因素做出四不像的產品，雖然有時是可以運作與實用，但也有很大的機會是失敗告終的，雖然有時也是雙方經過調整與互相妥協，做出意外的作品更是有的。

當然在「軟體工程」教科書中有一些開發生命週期的說法：

1. 分析與計畫 ( Analysis and Planning )
2. 提出需求 ( Requirements )
3. 設計和製造產品原型 ( Design and Prototyping )
4. 軟體開發 ( Software Development )
5. 測試 ( Testing )
6. 實施 ( Implementation )
7. 維運和更新 ( Maintenance and Updates )

但事實上這些在很多場合已經知道是很有問題的，現今的開發中反而較主流的是隕石式開發方式（笑），只是因為現在的系統已經過於複雜，在很多以社群或不特定對象為基礎的開發方式，單單要定義需求與目的就很困難了，更不要是實作細節的掌控。

在職場最常遇到的不是上面的人說出讓下面三條線的想法，不然就是下面說出讓上面三條線的原因，這問題想靠上面的瀑布流式的開發模型是相當困難的，因此之後就有了敏捷、MVP、螺旋式、……等等的方式來解決，只是真正的問題還是發生在「需求與實作」的落差。

這個落差就是發生在企劃者或是經營管理的人，認為這計劃是為甚麼要做，或者是做得好的話會有多少的效益，但這些「上位者」對於實作的細節差很遠，不只不知道那些事做得到做不到，或者是在實作所需要的資源與困難，在無法做可行性評估時，就只能無限制的要求計劃能夠完成。

而實作的人有時無法知道這計劃是為甚麼做，有時遇到問題時無法判斷是否有資源與需求的必要性，往往不是花太多資源在不需要的事情上面，或者是因為跳過的部份細節是重要的，而經營者也不願去了解細節時就做了過份要求或是忽略很重要的問題。

這問題的發生往往在於幾種可能性：

1. 在過於認定「專業經理人」的價值時，忽略經營決策者所需要的實務經驗。
2. 能夠成為上位者或是不斷創業家的人，有時出生與關係是主因，而不是能力。
3. 換了位子就換了腦袋的人，更常遇到的是對於原本的技能不夠紮實或這早已淘汰。
4. 當溝通流程過於冗長，或是容易失焦時就無法獲得相互了解。

這問題事實上除了「金湯匙」的狀況無法解決外，大部份是有機會改善的，例如對於管理者實務經驗的要求，或是改善溝通方法，更重要的是身為一個管理者需要對「細節」的掌控度要夠，或者是更願意聽實作者的想法。

但若你是下面的員工時該怎解決這問題呢？可能最好的方式是獲得「向上管理」的技能，讓上面的人了解細節的重要性，也要更主動的釋出需求與困難點，讓主管能夠理解或是幫忙，只是若最後也是失敗的話，那就「塊陶吧～～～～」。

延伸閱讀：
流星轟落開發/隕石開發(英文: Meteo fall)

這篇文章 當你覺得主管讓你三條線時，他也是這樣看你的｜專家論點【黑貘】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。