職場中，你是否遇到過十分抗拒與其共事的人呢？通過對這類人的特性進行歸納分析后，我們又能找到什么思考點與改進點呢？

在我們的日常工作中，和其他人一起合作在所難免。

而與三觀未知的他人朝夕相處往往不啻于一場冒險——那些傳說中行云流水般流暢的合作似乎僅存在于書本中，現實世界中的合作則常常難以契合，大多互相掣肘，不得通暢。

毫無疑問，在眾多的項目中，與我合作過的很多同事（我把一起工作的人們都稱為同事，而并不特別區分內部外部，比如團隊上的其他合作方也可以視為同事）都令我大開眼界并深受啟發，并在或長或短的合作中受益良多。作為對比，同樣有很多同事則從相反的方向令我印象深刻。

我仔細回想，如果整理出一個“我最不希望與之合作的人之特質”的清單的話，一來或許可以警示自己不要成為這樣的人，二來潛在地也可以讓具備這些特質的人從中受益。

古語有云：有則改之，無則加勉，此之謂也。

一、不會劃分優先級

在一個團隊中，效率最低的當然是那些什么都不干的人。

不過可能與大部分人的直覺相反的是，什么都做的那個人效率是倒數第二低的（如果不是最低的話）。這樣的人被巨大的backlog支配，深陷其中而無法自拔，各個未完成的任務可能還會互相影響，直至崩潰。很多時候，這些人手頭的工作甚至都不是被分配的，而是他們自己攬上身的。

如果你認為所有任務都很重要，也就意味著所有任務都不重要。具體來說，這樣的做法有很多潛在的問題，對于個人和團隊都有很大壞處：

• 個人成為信息孤島
• 由于太多并行任務，無法真正完成某一項任務
• WIP（work in progress）隊列變的無限大
• 成為團隊的瓶頸

正如《鳳凰項目》中描述的場景，那個Superstar成員成為了團隊中最大的瓶頸。當那個Superstar的帶寬被完全占用之后，所有的在隊列中的工作都需要進入等待狀態，而這個曲線是呈指數態勢增長的。

一個優秀的團隊成員，需要在某種程度上遵循UNIX哲學中的一條原則：每次僅完成一件事，并將其做到最好。

當然，這并不妨礙一個團隊成員在很多方面都有優秀的技術專長，重點是：在每次任務中都專注地做好某一件事。

最有意思的是：在這種情況下，即使這位同事的主觀意愿是好的，個人能力是出色的，但是從外部來度量整個團隊的產出的話，其效率仍然會低于平均水平。也就是說，在策略上有缺陷的忙事實上是在幫倒忙。

二、祥林嫂式的抱怨

在我早年的一個項目上，在一個產品的研發進行到某一階段后，團隊進行了一次類似于Bug Bash的活動：收集產品中潛在的設計缺陷（包括可用性以及功能性的設計）。

有一位同事從各個方面提出了近30條發現的「問題」，但是幾乎沒有給出一條有用的建議。

基本上就是一副：這個產品是個徹頭徹尾的垃圾，而我也不知道怎么能把它變得更好的心態。后來團隊只好草草結束了這個有始無終的設計缺陷收集，而重新開始做一些Up Front Design。

在工作中這種人是非常容易招人厭惡的。一方面他們往往散發著濃郁的負能量，看著什么都充滿怨念，另一方面，他不愿意或者不能夠提出任何有效的改進方法。

應該注意到的是，提出問題——特別是不需要自己去費力解決的問題——是很容易的，而能想到可能的解決方案則相對困難。

更進一步，想到一個直觀的方案很容易，而給出多個選項，并對比各自的優劣則很困難。

最后，如果你想要真正解決問題，或者讓工作實際有所推進，那就需要嘗試多做一些困難的事情（比如羅列并對比可能的方案，并給出可行的計劃），并嘗試簡化他人的工作。

三、眼高手低

事實上，業界有很多坐而論道的大神，言必稱高內聚、低耦合，動輒S.O.L.I.D，對各種編程范式更是如數家珍。但是具體到動手的時候，要么顧左右而言他，要么勉強寫出幾行未必能通過編譯的代碼，而內容則不忍卒讀。

遇到這種情況，我會在他用鼠標哆哆嗦嗦的在文件列表里逐個找文件的時候把鍵盤搶過來，然后確保不讓他碰鍵盤。如果心情好的話，我會規勸他多動手寫一些代碼。

要解決這個問題，方式其實并不復雜。

胡適說：多研究些問題，少談些“主義”。

要我說，應該多寫寫業務代碼，少談些理論。我們都知道，在實踐中，用TDD寫個FizzBuzz是一回事兒；用相同的方法和原則把復雜的業務邏輯抽象并歸類，則完全是另一件事兒。

這些人往往會混淆了知道和能做到間的界限，知與行并不統一。正如那個著名的畫馬的漫畫所要表達的那樣:

大部分情況下，我們缺少的不是用簡筆畫畫出幾個圓圈，而正是那些被輕視的細節。無論如何，我們的各種理論最終還是要體現在可以真正執行的軟件代碼上。

Talk is cheap, show me the code.

——Linus Torvalds

一些可供參考的常見的技巧是：

• Code?kata
• 用腳本來自動化一些常見任務
• 重構復雜的業務代碼

簡而言之，坐而論道，不如作而行之。

四、致命的舒適區

這種人痛恨變化，這種情感可能來自于過往項目中引入新技術之后的負面的體驗，或者純粹的對新鮮事物興趣的缺失，又或者二者兼而有之。

總之你從他們口中經常聽到的是諸如：“為什么不用redux”（因為redux我比較熟），或者為什么要用“Material-UI”（因為我不會）。事實上，這種情況甚至會發生在那些曾經熱切而激進的技術人員身上。

大多數情況下，是他們沒有勇氣走出“舒適區”。他們誤以為目前已經熟練掌握的技術永不過期，且是解決手頭問題的最佳方案。然后現實是，沒有什么是不變的。技術很快會過期，通常比我們想象的要快很多。

在我入職ThoughtWorks的時候，RoR是西安辦公室的主流，前端的Backbone+Jasmine算是新的技術，而兩年后一些團隊開始零星的試點Angular1.2，bower，PhantomJS等，而如今這些技術都去哪兒了呢？

React+Redux，GraphQL在很多場景下確實可以簡化前端的工作，不過誰又知道下一個breaking change正在何處默默醞釀呢？

與固步自封相對的另一個極端是追逐一切新奇的事物，這樣的做法亦不足取 — 它會浪費你大量的時間和精力在那些可能永遠不會涉及的技術上。

盡管如此，我覺得作為開發者至少可以做的是：對新技術保持好奇和新鮮的態度，同時與其保持一定的距離。你未必需要在下一個項目中就采取Github Trending上的明星框架，但是花一些時間來保證自己了解其與同類產品的優劣對比，以及主要的應用場景等可以使你不至于在做技術決策時過于盲目和偏頗。

五、后端返回的數據不對

在有明確的前后端分工的團隊中，前端開發負責界面的實現，同時消費后臺API返回的數據，并可能做一些可能的數據格式化等；后端則負責與下游服務的交互，并組織數據供前端呈現。

這種工作模式下的一個極端的情況是前后端僅僅通過契約來協作，一端對于另一端完全忽略并視之為黑盒。表面上來看，這種隔離可以帶來一些益處：前后兩端的進度相對獨立，互不影響。不過我始終懷疑這種機械的割裂真的可以帶來它所承諾的好處。

不過其帶來的問題往往非常顯著：由于延遲的集成導致延遲的價值交付。更嚴重的是后果是人們會對于團隊作為整體為結果負責這一根本問題的忽視，當出現問題時則往往互相指責。我聽到太多次前端開發抱怨：“這個是后端API的問題”，或者“這個問題是后端沒有處理網絡超時所致”，而理所當然地將問題簡化為“別人的問題”。

“這是后端API的問題”這個描述本身是沒有問題的，但是它不應該作為一個問題的結論，恰恰相反，它應該是進一步探索的開端：一個更系統的，更端到端的解決問題的方案的開端。這個描述可以指導物理上分離的兩組同事一起面對問題，并找出適合當前架構的方案。

六、歷史遺留問題

我常?？吹接腥吮г棺约汗ぷ鞯倪z留代碼如何如何糟糕，添加新功能如何如何困難等。當你嘗試challenge他為何對這些問題不做出行動的時候，他會告訴你這些都是歷史原因 – 這段代碼本來就是這樣寫的。

在實踐中，這種情況往往和其他一些癥狀并行發作：

• 不了解業務（沒有意愿理解業務）
• 不了解技術決策（可能由于系統中缺乏諸如ADR的記錄等）
• 重構能力欠缺
• 高層次的自動化測試缺失

這種情況和“這是后端的問題”本質上可以算作同一類，都是嘗試將自己置身事外，并將問題歸因到另一些人（即使所謂的歷史遺留代碼就是他們自己寫的）。如果說在某些情況下，比如后端是另一個團隊，甚至是另一家公司提供的代碼，“這是后端的問題”尚可作為一個借口的話，那么“歷史遺留問題”的說法則是完全是無稽之談。

這樣的說法刻意的將自己描述成對糟糕現狀無能為力的受害者，就好像是說，假如有一個理想的起點 — 比如讓我從新開始寫 — 他就一定可以做的比現在好。

但是我們都知道，這種假設是未必成立的。事實上，當你決定要寫點代碼出來的那個時刻起，代碼和架構就已經在準備腐壞了，除非你花費足夠多的時間和精力去將其不斷完善和修葺。

而這正是事物的本性，并不隨著人的客觀意志為轉移。

因此，壓根不存在歷史遺留問題這回事兒，它們只是普通問題。解決問題的第一步，永遠是直面問題，認識到所謂的歷史遺留問題是和我們將要開發的新需求，或者要修復的線上defect，以及剛剛sign off的卡上的一個微小的需求變更并無二致。

簡單來說，我們可以像故事墻那樣維護一個技術債務板，并定期維護，按照工作量和價值來劃分優先級，然后按部就班的將其消除。

我在很多遺留項目上工作過，有一些是接手時就已經存在了很長時間的老代碼，另一些則是從頭開始寫但是隨著需求的增加和改變而逐步腐化的。

我發現行之有效的方法就是用對待老舊代碼那樣對待自己新寫的代碼——建立測試以形成安全網，做適度的重構（小到重命名一個變量，大到刪除一個模塊），并讓代碼比之前變好一點點。

當然，這需要整個團隊每個成員都對代碼質量有相類似的理解和足夠的動手能力，同時也需要持續的投入心血和精力來維系。

七、小結

本文列舉了一些我在各個項目中遇到的各種不靠譜的同事，包括 ThoughtWorks 內部和外部的一起工作的人們。甚至我自己在不同階段也可能展現出這里列舉的某些類型的特質。

1. 無法根據事情的重要/緊急程度劃分優先級而導致自己疲于奔命的
2. 只知道抱怨而不著手解決問題
3. 沒有足夠動手能力只尚空談
4. 固步自封，不思進取
5. 急于撇清責任，將自己置身事外
6. 缺乏責任感，將問題歸類到自己無法控制的外部力量

正如上面討論過的，解決問題的第一步永遠是承認并正視問題。唯有有勇氣和魄力做到這一點，才可以接著討論如何解決它們。如果僅僅列出問題而不討論解決方案，那么我自己就變成了上述的“祥林嫂”式了。好在這些問題都可以通過技術手段消除（和上述問題依次對應）。

1. 按照價值決定優先級
2. 通過刻意訓練保持動手能力
3. 抱怨之外，要順帶提出自己的觀點（有備選方案更佳）
4. 保持好奇心
5. 通力合作而非互相指責
6. 正視問題，并逐步解決

其他參考

• Lead Time vs Utilization
• Refactoring 2nd edition
• Code Kata
• 鳳凰項目

作者：ThoughtWorks邱俊濤，微信公眾號：ThoughtWorks洞見

本文由@思特沃克 原創發布于人人都是產品經理，未經允許，禁止轉載。

題圖來自Unsplash, 基于CC0協議