Belief System 分析 · 釋出於 .
說什麼還能進化
令人信服的演示並不能取代影響專案的可能性。在組織會議之前，專案所有者必須能夠說出已決定的內容、尚未確定的內容以及由誰來決定。如果所有選項都已關閉，則以共建方式呈現會議會產生系統無法滿足的期望。問題在於對話的授權，而不是動畫的質量。
全國保衛人民大會特別區分了資訊、辯論和對貢獻的考慮。這個框架提醒我們，參與涉及決策過程。必須與相關團隊建立適用於特定專案的程式。自願溝通方法不應被視為正式程式的自動等同物。 [1]
從領土用途出發
受影響的人可以從出行、噪音、服務獲取、經濟活動或環境的角度審視該專案。技術檔案並不總是足以使這些效果易於理解。溝通必須能夠將假設轉化為具體情況：在工作過程中會發生什麼變化，然後在操作過程中會發生什麼變化，以及還有什麼需要研究。
我們建議對問題進行對映，而不是簡單地列出有利或不利的參與者。同一個人可以支援總體目標並反對特定的模式。將一個人的立場降為一個標籤不必要地結束了討論。該檔案還必須為平時會議中不太引人注目的受眾提供服務，以免混淆參與的便利性和需求的代表性。
顯示替代方案及其侷限性
有用的比較解釋了為什麼要檢查幾個選項以及哪些標準導致它們被保留或拒絕。成本、對使用的影響、技術限制和影響可以以其不確定性來呈現。不應為了使主要專案更具吸引力而對替代方案進行諷刺。分歧點若能被明確地識別出來，就會受益匪淺。
在給管理委員會的說明中，溝通可能會提出專案團隊尚不知道如何回答的問題。有些需要研究，有些則需要決定或更容易理解的解釋。這項工作使得區分資訊問題和目標分歧成為可能。增加支撐數量並不一定能解決第二個問題。
製作對話歸還證明
我們提供跟蹤日誌，表明收到的問題、答案、處理責任以及對專案可能產生的影響。貢獻可能會導致修改、接受額外研究或不被接受。在後一種情況下，推理必須是可以解釋的。恢復原狀並不意味著宣佈所有期望均已得到滿足。
在高度關注期之後，承諾也應該保持可訪問性。如果時間表發生變化或計劃的開發不再可行，相關公眾必須能夠確定新的決定及其原因。這種連續性可以防止對話被視為對專案的實際進行沒有影響的啟動事件。
示例：傳輸鏈路及其訪問
考慮一個虛構的交通連線專案。專案業主介紹了區域範圍內連線的好處，而居民則詢問如何從他們的社群訪問車站。這兩個問題並不矛盾。第二個可能揭示設計點、與社群的協調或仍然不足的資訊。
一個有用的答案會檢查訪問許可權、使用條件和所涉及的責任。如果無法立即決定解決方案，系統必須指定誰正在處理該問題以及如何公開結果。挑戰不僅在於更好地解釋區域效益。它是為了讓當地海關做出決定的方式變得可見。
六個問題的準備
| Before the dialogue | What needs to be clarified |
|---|---|
| 授權 | 哪些決定仍然懸而未決？ |
| 周長 | 涉及哪些領域和用途？ |
| 證據 | 可以檢查哪些要素？ |
| 替代方案 | 研究了哪些選項以及為什麼？ |
| 參與 | 如何允許多樣化的貢獻？ |
| 套房 | 如何報告所採取的決定？ |
這些問題必須由專案團隊、溝通、公共事務和相關職能部門共同解決。做出回應的承諾需要一個有能力兌現承諾的組織。因此，溝通時間表必須包括審查貢獻所需的時間。
對於Belief System來說，不能將可接受性承諾為競選結果。建議可以提高資訊的質量、選擇的可讀性和對話的連續性。分歧可能會持續存在；它必須能夠被理解和認真對待，而不會從專案的敘述中被刪除。