軟體專案 困難
我們經常將軟體開發視為基於邏輯和清晰度的追求。 有一些定型的軟體開發人員是虔誠的邏輯追隨者，他們對二進位制數字的興趣遠大於對同伴的興趣。 從這個角度來看，令人震驚的是發現軟體專案的故障率很高 ，而有些專案的失敗率高達數十億。 在乙個邏輯學科中，由科學家領導的這種混亂狀態怎麼可能？
如果我們能更好地了解專案如何遭受失敗的影響，那麼我們可以學會將來更安全地處理專案。 最危險的風險是我們看不到的風險，尤其是如果我們的思維方式使我們對它們視而不見。
關於軟體開發的刻板印象
我們作為邏輯追求的軟體開發形象體現在由程式語言和由它們構成的應用程式的精確而嚴格的句法規則中。 這遍及了大眾的理解以及技術思想。 使用時，某些應用程式的規則對於應用程式的使用者可能很清楚-像太空入侵者這樣的簡單遊戲通常沒有頁面來解釋規則，因為我們只是看到它們。 在其他時候，可能很清楚應用程式具有規則，但是它們卻是晦澀難懂的，從而導致了熟悉的「計算機說不」的現象。 無論哪種方式，都傾向於感覺到規則的嚴格性，這會影響我們對軟體開發的假設。
計算問題的著名示例在我們的軟體中也佔很大一部分，並且這些定義往往非常嚴格。 教科書中的旅行推銷員比現實生活中受到更多的限制（他們很少乘電梯或與同事分擔工作或下床喝酒）。 我們傾向於將軟體工程與有關破解密碼的示例緊密聯絡在一起，而不是與有助於評估保險索賠的軟體聯絡在一起。
但是軟體開發人員並非全是學者，也不是全部都致力於解決明確的問題。 專業軟體開發涉及將規則編纂成乙個能夠滿足一系列業務目標的系統。 它旨在產生邏輯產物，以在混亂的世界中發揮作用。
因此，儘管普遍存在嚴格意義上的軟體開發邏輯，但世界的混亂在軟體製作過程中的確發揮了重要作用-使軟體在世界上發揮作用。 通過對世界做出錯誤的假設或對他們嘗試做的事情感到困惑，專案可能會出錯。
即使這樣，這僅是部分解釋。 軟體專案如此危險且如此頻繁地失敗怎麼辦？ 我們該如何編寫軟體？
軟體開發
軟體專案可能會發生巨大變化，專案實施方式的生命週期也會發生很大變化。 在製作軟體的過程中形成清晰的畫面並保持頭腦清晰是非常棘手的。 它變化如此之大，以至於在某種程度上人們僅需從經驗中學習。 但是，擁有更清晰的軟體開發圖景將有助於我們更好地理解軟體開發中的風險**。
考慮到抽象軟體開發的程度，可能會傾向於依賴更具體的學科。 尤其是，誘人可以比作建築或物理工程。 因此，這種模擬吸引人，以至於它在歷史上影響了很多軟體專案管理方法（特別是在瀑布模型上）。 但是我們應該對此謹慎：
我非常懷疑使用其他專業的隱喻來推理軟體開發。正如福勒指出的那樣，危險的是認為我們事先知道問題是什麼。特別是，我認為工程隱喻損害了我們的職業，因為它鼓勵了將設計與建築分離的想法。
馬丁·福勒
認為我們事先知道工具是什麼也是危險的。 容易想到程式設計師編寫**，因此主要工具是程式語言。 但是，當代的商業發展在很大程度上取決於現有的工具和庫，這些工具和庫必須選擇並應用於手頭的任務。 程式設計師不僅編寫**來解決問題，而且程式設計師大量編寫**來將其他人的部分解決方案組合在一起。 根據選擇，可能很難使工具用於特定目的（需要大量思考和拼接**）或例行程式，或者實際上是不可能的。
施工還涉及工具選擇的問題。 例如，為了承重和耐用性，必須選擇磚或材料的型別。 與軟體的不同之處在於，工具本身是概念性的，因此，至少在不花費大量時間的情況下，很難清楚地看到其工作範圍。 經常發現所選工具不支援我們想要的特定資料格式或通訊協議，這是很正常的。
毫無疑問，有關工具的早期假設無疑會導致超支和成本增加，從而導致故障。 但是，在業務目標空間中，更具破壞性的假設往往是不容質疑的假設。 這裡的構造隱喻再次沒有反映風險。 關於建築物設計是否為將使用該建築物的人數提供足夠的空間以及是否有足夠的電梯，肯定存在錯誤假設的範圍。 但是視覺計畫有助於提出假設，而實現越具體，就越容易找到假設。 由於軟體本質上是抽象的，因此很難在不完全構建解決方案的情況下將其具體化到足以消除假設的程度（屆時將產生所有成本）。
完善問題規範以消除假設可能比科學還重要。 完善規範並選擇解決這些問題的工具對於軟體開發人員而言都是至關重要的。 風險是兩者固有的。 讓我們嘗試表達比構造隱喻更好地表達這一隱喻的隱喻。
更好的隱喻
軟體開發既具有邏輯性又具有創造力 （其中存在混亂）。 一類特殊的問題既有創造力又是邏輯上的，一類問題可能被認為屬於「謎語」（儘管我並不認為所有被稱為「謎語」的東西都一定很合適）。 通過考慮拉格納·羅德布魯克（ragnar lodbrok）的古老北歐故事中的解謎故事，我們可以探索這種創造性的解決問題的方式如何充當軟體開發的隱喻。
隨著故事的發展，拉格納爾的男人向他報告說，他們見過每乙個美麗的女人克拉卡。 拉格納（ragnar）引起了他的興趣，他派遣了她，但他決定考驗她的智慧型。 他命令她既不穿衣服也不穿衣服，不餓也不飽，也不要乙個人陪伴。 面對挑戰，克拉卡（kraka）披上了網，扎著長長的頭髮，咬著洋蔥，只帶著狗作為伴。 拉格納留下深刻的印象並與她結婚。
ragnar的要求在至少乙個關鍵方面與軟體專案的規範沒有不同。 拉格納（ragnar）在看到請求之前並不完全知道什麼會滿足他的請求。 他知道某些需要滿足的約束條件，但他不知道kraka發現的解決方案是可能的解決方案，直到他看到為止。
為了更清楚地了解這種聯絡，讓我們想象一下拉格納爾不會立即嫁給克拉卡。 取而代之的是，他接下來規定，克拉卡（kraka）首先應通過更加英勇的鍛鍊證明自己的價值。 他要求她生產乙個系統，該系統將處理他目前雇用整個團隊的檔案批准和拒絕。 就規範而言，ragnar幾乎不需要團隊就可以完成任務的概念，就像以前的謎一樣，ragnar不知道沒有團隊就可以處理文件的批准和拒絕。 需要向他展示解決方案，然後才能知道它是否正在執行他目前所謂的「文件批准和拒絕」。
在這兩種情況下，kraka都必須將ragnar帶入乙個未知領域，這一點很重要。 拉格納（ragnar）不確定他會稱之為「既不穿衣服也不**服」的事情。 同樣，如果沒有團隊執行批准/拒絕，ragnar不確定他將如何稱呼「文件批准和拒絕」，並且kraka必須充分理解這些表達方式才能提出ragnar稱之為解決方案的內容。
因此，與軟體專案一起出現的基本不確定性是，直到我們有了完整的解決方案，我們才能完全了解解決問題的方法。 如果一切順利，那麼隨著專案的進行，人們會看到解決方案的形式越來越清晰。這是軟體專案與製造專案之間的關鍵區別–對於製造專案，乙個人可以在產品的早期階段就形成相對清晰的畫面進行生產，然後可以精確地繪製和物理構造。 在製造專案中，由於要生產的產品是物理物品，因此有可能盡早形成清晰的。 軟體產品是抽象的，軟體問題的解決方案是概念性的。 （軟體程式可以在物理上例項化，但這並不能脫離其概念性質。）
如果要為物理產品或結構起草需求，那麼從一開始就比軟體專案更容易理解這些需求。 例如，如果要建造一座橋，那麼從一開始就很清楚地說要承受x的負載，每輛都要重這麼多的汽車。 由於軟體需求是抽象的，因此很可能難以理解，有時看起來似乎很清晰，但根據後來的發展卻變得不清楚。
讓我們回到克拉卡和拉格納爾，想象一下，克拉卡是在兔子而不是狗的陪伴下到達的。 拉格納爾可能會說他不會接受這個解決方案–他認為與兔子同行並不算是陪伴。 如果這看起來不可行或不公平，那麼可以想象一下，克拉卡（kraka）帶著一條金魚來了。 我們可以找到情況，使克拉卡和拉格納爾對被視為「陪伴」的人持不同看法，這似乎是有道理的。 但自從拉格納提出問題以來，拉格納爾的觀點就很重要。
kraka和ragnar之間在軟體專案上存在類似的爭議-開發人員有時可以對問題的解決方案和終端使用者認為可以接受的問題有不同的看法。 kraka可能從一開始就通過進一步**該問題來試圖避免此類問題的發生-她可能已經進行了等效的需求分析。 我們可以想象kraka戴上商務分析師的帽子，然後問諸如「您的意思是有人陪伴嗎？ 那寵物呢？ 但是即使經過大量需求分析，這些型別的歧義仍然會保留。 即使確實很清楚ragnar會接受寵物，也可能不清楚（直到他看到他之前才對他）他不會接受金魚。
隱喻的用途
當我試圖尋找一種確定的答案，即某個特定的設計將「起作用」還是所選的工具將滿足特定的需求時，我個人發現邏輯解決問題的隱喻是乙個有用的後備。 有時我們無法確定是否提供解決方案。 我們可能非常希望獲得前期確定性，但我們卻無法實現。
當專案中正在進行很多任務作時，我還發現這個比喻很有用，我需要更好地了解專案動態-專案的運作方式以及嘗試達到的目標。 通過對邏輯問題解決方案進行開放式比較來思考乙個專案，可以幫助我了解那些本來可以忽略的方面的重要性。 它可以為我提供乙個更好地理解專案動態的原理，而不是檢視一組消耗圖表。 如果我們將軟體專案視為解決集體問題的練習，那麼我們會將思維重心從計畫的圖形上轉移到驅動專案的人員和動機上。
本文基於我的「為什麼製作軟體如此困難」，acm sigsoft軟體工程說明39
翻譯自:軟體專案 困難
為什麼製作軟體如此困難？
我們經常將軟體開發視為基於邏輯和清晰度的追求。有一些定型的軟體開發人員是虔誠的邏輯追隨者，他們對二進位制數字的興趣遠勝於對他們的同胞。從這個角度來看，令人震驚的是發現軟體專案的故障率很高 而有些專案的失敗率高達數十億。在乙個邏輯學科中，由科學家領導的這種混亂狀態怎麼可能？如果我們可以更好地了解專案如...
vco為什麼低頻下起振困難 為什麼協作如此困難？
vco為什麼低頻下起振困難 許多關於 協作 的當代定義將其簡單地定義為 一起工作 並且在某種程度上，它是一起工作。但是通常，我們傾向於將術語 協作 與諸如 合作 和 協調 之類的同類術語互換使用。這些術語還指 一起工作 的某種方式，但是它們之間存在細微但重要的區別。合作與協調或合作有何不同？協作到底...
vco為什麼低頻下起振困難 為什麼開放如此困難？
vco為什麼低頻下起振困難 如果開放是如此之好，那麼為什麼所有人都不擁抱它呢？要回答這個問題，還需要問幾個問題 大型組織中的大多數領導者都具有執行成功的開放系統的能力，那麼為什麼他們不這樣做呢？我認為這裡有幾個問題。為了提出關於為什麼 開放 如此困難的假設，我想 其中三個問題。幾年前，當我開始寫關於...