筆者以前在小公司任職時,屬於帶領後進同事的角色,經常是由我設計後,同事就按圖索驥進行實作,換到大公司後,分工精細,經常需要和其他同事甚至跨單位合作,常有機會需要設計資料格式傳輸資料,人多意見多,你認為合理的,其他人有不同看法,如何和平地達成共識,也是職場生存的一門學問。
大綱
- 列舉雙方優缺點
- 說明自己的設計目的
- 適時地「見風轉舵」
- 僵持不下時,做個人情吧
列舉雙方優缺點
在職場上,應盡量避免情緒性發言,試著去了解對方為什麼這樣設計,有什麼利弊,不論何種技術、設計,都有它適用的場景,所以我通常會先把雙方的設計優缺點都陳述一次,一方面可以讓對方明白,我有好好的思考過他的方案,而不是為反對而反對,雙方都可以藉此重新評估一次。陳述的當下,可能發現之前沒考慮到的問題或者意料之外的好處等等。
舉個例子,一個server和多個client以Wifi進行socket連線的系統,client端有硬體在運作,需要即時回報狀態,server端會依據各client狀況下指令控制特定client硬體動作,有兩種通訊方式
- server主控,所有控制都由server發起,client回應和執行
- 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回傳格式,雖然目前需求是回傳陣列資料,但直接使用陣列未來可能會遇到擴充問題,進而導致無法向前相容,若是改用物件內的屬性存放陣列,未來擴充只是增加屬性,後端就可以先上線,前端之後再增加即可,不會發生不相容的問題。這種通常馬上就被接受了,畢竟沒人可以保證未來不會擴充,而且這種只是格式差異,跟開發時間無關。
適時地「見風轉舵」
人難免都會覺得自己提出的方式是最好的,但過度堅持反而會局限自己,要盡量保持開放的心態,遇到更好的做法反而要高興,又學到一種看待問題的方式。有時我在和同事討論時,說著說著,同事提出的作法簡直神來一筆,找不出什麼缺點,當下立馬見風轉舵,表示贊同,雖然人多意味著意見多,需要統合,但運作的好,反而可以互相切磋,教學相長。
僵持不下時,做個人情吧
在雙方都是理性的前提下,如果僵持了許久,還是無法取得共識的話,應該屬於以下情形之一
- 兩種做法都沒有太懸殊的差異,或者說沒有很嚴重的缺陷
- 兩種做法的差異點跟這次場景沒有太大的關係或影響
換句話說,只是不同的做法或習慣,實際的影響不大,不會嚴重影響到後續的擴充或是彈性,既然這樣,何不放下堅持,做個順水人情吧,也許下一次相同情況,對方也會回個禮也說不定。我也遇過一種情況,之前已討論過做法沒共識,是由對方實作,後來討論就直接開門見山跟我說,他希望能用他的方式來做,後續真的有什麼狀況再修改,這種時候,沒有太大問題的話,我也是會成全,有理不一定能走遍天下XD,畢竟還是要尊重一下動手實作的人,對士氣也是有很大的幫助。
發表迴響