第一次看見這句話，來自于『二爺鑒書』，也就是之前 工程師與產品經理相處之道 提到的邱岳的公眾號。
這句話還是讓我挺受啟發的，因為遇到過相似的場景。
與客戶端同事
記得有次在與客戶端同時討論技術方案的時候，我當場發脾氣了。
當時與客戶端討論的是如何實現我們產品中的某項多客戶端數據同步的進一步需求。這種數據的同步在以前的實現很簡單，我們是按數據項的對比方案來實現的，即：
- 客戶端請求服務端，拉取列表，對比本地存在的列表，主要對比 ID 以及更新時間戳；
- 然后將本地不存在的數據添加進本地存儲，而將遠程不存在的發送給服務器；
- 最后根據時間戳，將早于服務端時間的數據項重新拉取詳細數據；
而現在的需求，變成了需要增加列表的分組，并且分組信息也要同步，于是情況就開始變復雜了，如果只是在當前的基礎上繼續添加同步的對比項，那么情況就會變得難以處理，并且在多設備同步時也會很容易出現數據不一致情況。
因此，我提出了一種改動比較大的方案，即基于操作日志的同步方案（具體的情況不多說，如果有興趣另寫一篇，這里只是說說主題相關的）。而就在我說出這個方案后，聽到卻是：『這要增加多少請求啊』、『開發難了點，不好做』、『要改動很大，不行』。
這讓我聽了后就很受不了，情緒當場失控：『不要說做不了，這種方案能解決當前的問題，不要跟我說做不了，要不你們提自己的方案！』
這句話把客戶端同事也激怒了，之后的情況可想而知，雖然我之后克制了情緒，開始問他們為什么做不了、能說說具體做不了的原因之類的試圖拉回討論，但最終還是讓這次需求會議不歡而散。
會后我想了想，我生氣的點在于：我當時認為客戶端同時只是由于想偷懶，難度有點高而不考慮這個方案，顯得不靠譜。
所以，這次會議，是我讓同事『失敗了』。
后來還是做了些補救，包括給客戶端同事發去了完整的實現文檔，找客戶端領導溝通，打聽客戶端同事最近的任務安排是不是有點緊張等等，讓我欣慰的是，客戶端同事沒有計較我的情緒失控。
這次的結果，讓我想到，我不能讓客戶端同事失敗，那么我就需要讓他們對這個方案心里有底，信任我，那么我就應該做好提前溝通，而不是在會議上臨時提出這個解決方案，另外在他們提出質疑的時候，也不要馬上認為他們就是偷懶或者不想做事；而最后即使會議上沒有解決，我也可以另外約時間，而這個緩沖的時間內，我可以找他們了解真正的想法。
與運維同事
長期以來，我在團隊內部長期以來都是在推廣 DevOps 的，有一段時間里我們與運維同事的關系一般，畢竟很多情況下，應用部署，維護以及事故處理都用不到跟他們過多溝通，但是，打交道總避免不了的。
比如一旦我們出了線上事故，影響的都是雙方，這時候就會需要通力配合，配合得好，事故就處理得快。另外就是我在推廣新工具的時候，就會覺得他們水平不行，不會告訴他們細節，讓他們參與的只是機器的系統維護，但是其它方面都是我們自己在維護，這在我看來，是一種效率非常高的方式。
只是，事實告訴我，我讓他們『失敗了』，因為我只顧著自己團隊內部推廣工作的維護與使用方式，而沒有給運維同事提供相同的培訓，而導致兩方會有一些信息差，于是我們不知道他們在干什么，他們也不知道我們在干什么，我不讓他們接觸到應用級別的維護，他們也不給我系統級別的維護權限。
這種情況造成了我們合作層面的問題，甚至直接影響到了事故的恢復時間。
后來，意識到了這一點后，我就開始主動讓運維同事參與到我們線上運維的過程中去，教他們使用 Git 管理線上的配置，以及自動化部署，開放團隊文檔與他們共享：讓他們知道我們干了什么，內部技術分享的時候，也會拉上他們一起；同時他們也會積極學習新工具，新知識，并開始積極配合維護：我們也能得到他們的快速響應，合作起來變得很順利。
最后
這句話很值得琢磨，因為這讓我提醒自己，身邊的同事都是一個戰壕里的戰友，而不是互相對立的敵人，我們需要共同解決問題為團隊創造價值，而不是制造隔閡與不信任。
首發于 Github issues: https://github.com/xizhibei/blog/issues/87 ，歡迎 Star 以及 Watch
本文采用 署名-非商業性使用-相同方式共享（BY-NC-SA）進行許可
作者：習之北 (@xizhibei)
原鏈接：https://blog.xizhibei.me/2018/09/23/donot-let-your-teammates-fail/
