前陣子看到團隊在討論某個新專案打算採取何種技術架構，最後有兩種提案，每個提案都有其優缺點。這時有人提議用投票，結果是兩種提案的支持者各佔一半人數，這下尷尬了。

在外面常聽類似情境的故事，通常是雙方各持己見，花了很多時間爭論、嘗試說服對方，最後還是沒有一個結論，不歡而散。

但在這次的故事裡，採取的作法是不再問支持哪個方案，而是詢問對哪個方案有強烈反對的念頭，此時仍各有一個夥伴表達自己的反對，說明理由時也連結起過去選類似方案的不愉快或痛苦經驗。

但在進一步釐清、探詢，才了解到對方只是想表達顧慮，希望這些事情是能在選擇該方案後得到重視的，並不是真的強烈反對，兩位原本提出反對的人，在經過對話後都將其認定為顧慮與擔心，最後就由主要開發的幾位夥伴，先決定採取了某方案，結束了這次的討論。

這個過程後來決議的方式，其實就是認可覺得概念。這邊借用敝公司官網工具技的圖示來進一步說明，請參見下圖。

鈦坦科技・敏捷工具技・溝通・認可決

通常我們在選擇贊同哪一個方案時，其實都是在表達個人偏好，在這種情況，本來就很難達到所有人都一致的看法，如果這時候硬要用投票去決議，就會有人認為自己的聲音是沒被聽到的，進而造成雙方或多方不愉快、甚至對立的局面。

而在認可決裡面，我們選擇的是有異議的，確切來說是持反對意見的，而會讓我們提出反對的情況，不是在於這個方案不符合自己偏好就反對，而在於我完全無法容忍這個方案，這個方案選下去會對我造成傷害、不舒服，或是讓我喪失動力想離開現在的環境，這時才會提出反對。

在這樣的情況之前，其實都還屬於容忍範圍，而從個人偏好到可以忍受邊界內，都屬於認可的範圍。

有時候提出反對，並不代表真的是不可退讓，可能只是像這次案例一樣，當事人有些顧慮，希望透過反對提出來。如果有人提出更多的資訊與觀點能消除他的顧慮，那他就可以撤銷反對。但要注意的是，這邊是揭露更多資訊去消除顧慮，而不是靠強硬的言語去說服對方，後者可能會導致對方表面上接受，但心裡其實仍不買單。

另一種反對的情況，可能只是當事人對這件事的理解有認知落差，那藉由反對的選項揭露出來，透過釐清後，也可能就撤銷反對，也讓我們離建立共同理解又更進一步。

其實在敏捷軟體開發的情境中，很適合使用這樣的決策方式。畢竟提到支持與個人偏好，很容易就往完美的方向去鑽，但是這樣可能就會導致事情難以發展下去，也有可能讓開發停滯不前，這就有點本末倒置。透過選擇大家都認可的其中一個方案，先實驗與嘗試看看，再根據收到的回饋去調整，最後可能也會有另一種更適合的解決方案出現也說不定呢！