筆者以前在小公司任職時，屬於帶領後進同事的角色，經常是由我設計後，同事就按圖索驥進行實作，換到大公司後，分工精細，經常需要和其他同事甚至跨單位合作，常有機會需要設計資料格式傳輸資料，人多意見多，你認為合理的，其他人有不同看法，如何和平地達成共識，也是職場生存的一門學問。

大綱

1. 列舉雙方優缺點
2. 說明自己的設計目的
3. 適時地「見風轉舵」
4. 僵持不下時，做個人情吧

列舉雙方優缺點

在職場上，應盡量避免情緒性發言，試著去了解對方為什麼這樣設計，有什麼利弊，不論何種技術、設計，都有它適用的場景，所以我通常會先把雙方的設計優缺點都陳述一次，一方面可以讓對方明白，我有好好的思考過他的方案，而不是為反對而反對，雙方都可以藉此重新評估一次。陳述的當下，可能發現之前沒考慮到的問題或者意料之外的好處等等。

舉個例子，一個server和多個client以Wifi進行socket連線的系統，client端有硬體在運作，需要即時回報狀態，server端會依據各client狀況下指令控制特定client硬體動作，有兩種通訊方式

1. server主控，所有控制都由server發起，client回應和執行
2. client主控，由client發起要做某動作，server回應可不可行

這兩種方式都可以達到相同的功能，前者比較直覺，先綜觀整理狀況後再決定控制，可是如果考慮到運算時間較長或無線網路延遲，client可能收到指令後已經來不及執行，還需要特別處理這一塊。後者由client發起，雖然該client不清楚其他client的狀態，但最清楚自己的狀態，可以在最合適的時機發出，若其他client發出的動作有所衝突，server還是會作管控，一次只允許一個client動作。最後只能比較兩邊的缺點，可以接受哪一種，依據場景決定，應該很快就有結論了。

說明自己的設計目的

當提出我們的做法時，若只是提出做法，然後堅持這樣比較好，是很沒有說服力的，最好可以一併說明這樣設計的目的，以及可以避免哪一些情況發生，某次討論為了明確說明目的，我甚至馬上畫架構圖來說明，不僅可以讓對方明白整個思路，若提出的目的切合場景需求，甚至可以直接取得共識，又或者我們的目的其實有其他更好的做法，也可以促進雙方進一步討論找出更好的做法。

//原做法
[{"A": "1", "B": "2"}];

//改良作法
{
  "DataList": [{"A": "1", "B": "2"}],
  "Timestamp":"2022/01/01 00:00:00"//未來可擴充其他屬性
};

舉例: 這個API回傳格式，雖然目前需求是回傳陣列資料，但直接使用陣列未來可能會遇到擴充問題，進而導致無法向前相容，若是改用物件內的屬性存放陣列，未來擴充只是增加屬性，後端就可以先上線，前端之後再增加即可，不會發生不相容的問題。這種通常馬上就被接受了，畢竟沒人可以保證未來不會擴充，而且這種只是格式差異，跟開發時間無關。

適時地「見風轉舵」

人難免都會覺得自己提出的方式是最好的，但過度堅持反而會局限自己，要盡量保持開放的心態，遇到更好的做法反而要高興，又學到一種看待問題的方式。有時我在和同事討論時，說著說著，同事提出的作法簡直神來一筆，找不出什麼缺點，當下立馬見風轉舵，表示贊同，雖然人多意味著意見多，需要統合，但運作的好，反而可以互相切磋，教學相長。

僵持不下時，做個人情吧

在雙方都是理性的前提下，如果僵持了許久，還是無法取得共識的話，應該屬於以下情形之一

1. 兩種做法都沒有太懸殊的差異，或者說沒有很嚴重的缺陷
2. 兩種做法的差異點跟這次場景沒有太大的關係或影響

換句話說，只是不同的做法或習慣，實際的影響不大，不會嚴重影響到後續的擴充或是彈性，既然這樣，何不放下堅持，做個順水人情吧，也許下一次相同情況，對方也會回個禮也說不定。我也遇過一種情況，之前已討論過做法沒共識，是由對方實作，後來討論就直接開門見山跟我說，他希望能用他的方式來做，後續真的有什麼狀況再修改，這種時候，沒有太大問題的話，我也是會成全，有理不一定能走遍天下XD，畢竟還是要尊重一下動手實作的人，對士氣也是有很大的幫助。