ThoughtWorks 的諮詢師技術水平到底怎麼樣？

12-26

他們平時做開發嗎？還是僅僅提供口頭諮詢？一般都是什麼人去做諮詢師？一年的待遇是什麼情況？

ThoughtWorks的諮詢師的技術到底如何？

如果對技術做一個粗淺的劃分，我覺得可以分為：計算機科學和軟體工程。

像亞馬遜提供的各種雲服務的底層平台；谷歌（以及一些實驗室）啟動的各種人工智慧，機器學習項目；淘寶這種量級地處理高並發，分散式計算，分散式存儲等，其核心部分屬於計算機科學（需要很多科學研究來支撐）。

而另一方面，對於將這些已有的成果，實施在軟體工程領域，比如如何多快好省的實現新的軟體產品，如何消除軟體項目中的浪費（比如由於defect引起的返工，耗時的集成測試，容易出錯的手工部署等），建立順暢的工作流，高效的將客戶的需求變為高質量的交付件，則屬於軟體工程。

ThoughtWorks的諮詢師更聚焦在後者上。所以如果你問得是「軟體工程」相關的技術的話，我覺得ThoughtWorks還是很牛逼的（有點王婆賣瓜的意思啦，哈哈）。

諮詢師寫不寫代碼

ThoughtWorks的諮詢師基本上沒有不寫代碼的（除了一些做主要做流程，管理方面諮詢的同事之外）。很多時候，客戶甚至會「抱怨」ThoughtWorks的諮詢師太愛寫代碼，而沒有時間解決哪些更高層次的問題（比如流程改進，軟體架構方向等）。有時候確實挺難的，特別是你在客戶現場，會遇到一些很有挑戰，但是又不能實際上手寫代碼的情況。因為作為諮詢師/顧問/教練，你的職責更多的是幫助客戶團隊解決他們的問題，而不是自己悶頭寫代碼。

所以會出現這樣的情況：諮詢師在現場被憋的實在不行，下班後自己加班寫代碼，當然不是為了趕進度，純粹為了體驗那種解決難題的快樂（我知道，這聽起來是有點變態，但是在我們看來還挺正常的）。

中國區的MD胡凱同學有次自嘲說，一旦脫離的代碼，智商就會急劇下降（當時他自己已經被迫不寫代碼，轉向一個管理崗位了）。不寫代碼在工程師文化濃郁的辦公室說話時都會有點底氣不足。

所謂口頭諮詢

和很多提供行業解決方案、行業洞見的諮詢公司相比，ThoughtWorks是一個偏重於工程實踐方面的諮詢公司（當然，也有一部分諮詢師再向行業/方案等方向努力）。也就是說，ThoughtWorks很少提供純「口頭」的諮詢服務。其實在商業社會裡，所有的客戶都會以結果為導向。簡單來說，就是別管你說的多麼天花亂墜，客戶都需要你明確的告訴他，方案究竟如何落地！！！

什麼人去做諮詢

諮詢本質上是一種專業服務，客戶購買的是諮詢師的專業知識。根據這個定義，所有具備專業技能的人都可以去做諮詢。但事實上這是一個很難的問題，即使是對我們自己來說也是一樣：選擇什麼樣的人去做諮詢呢？

我前不久寫過一篇博客，講一個開發如何做諮詢師，你可以參考一下：

不想當UX的開發不是好諮詢師

裡面提到了我們對諮詢師的一些基本要求。如果具體到技術細節，我還寫過另一篇博客來討論：

技術的執念 - I code it

當然，並不是說所有諮詢師在各個方面都很強（那也不現實），但是基本上都會有非常堅實的「一技之長」。比如我們有持續交付方面的專家，有Scala方面的專家，有專精前端的，有主攻mobile相關的等等。

關於待遇

這個我就不說了，有興趣的話可以找HR打聽一下，:)

看到題主的這個問題好久沒人回答，感覺不合適呀（PS. 諮詢師在諮詢現場一般很忙）。

1. 首先諮詢師分很多類型（敏捷轉型，持續交付，純技術指導等等），做技術類的諮詢師肯定是有深厚的相關技術開發基礎/經驗的。
2. 是不是僅僅做口頭諮詢，我個人覺得這個問題的答案是不僅僅，有很多諮詢師過去會幫忙刪代碼的，哈哈，非技術層面的諮詢（比如敏捷轉型），一般也是深入了解客戶的痛點，儘可能全方位的幫助客戶解決，或者說幫助客戶學會解決問題。
3. 什麼樣的人，這是個好問題。公司內大部分人覺得你有資格，有能力做這方面諮詢的人。也就是任何人都有機會，只要你這方面我們／客戶需要，有價值，別人不知道，或者知道但是和你差距很大。
4. 這個我個人不是特別了解，但即便知道，確實也不是很方便透露。:)

另外，題主其實問的是TW諮詢師的水平，這個我感覺做為那些親身經歷過TW諮詢項目（不是那種旁觀者，「我感覺」，「我覺得」，「我聽別人說」那種的）的「外人」口中的描述可能更加準確，給兩個舊的鏈接吧：
騰訊與敏捷開發
博客推薦系列第二篇：thoughtworks顧問們的BLOG
這些都比較久遠了，感興趣的話，可以看官網的各種技術博客（英文為主的）：
Blogs | ThoughtWorks
和一些個人博客（國內）：
I code it
透明思考 | Transparent Thoughts

我個人見識有限，還有好多內容沒拔出來，感興趣的話，題主可以探究一番。

這個問題來的太恰如其時了，剛好跟我司諮詢師伍斌有過這樣一番交流，以下是他的原文：

可能有讀者不大清楚什麼是諮詢工作。ThoughtWorks中國區所提供的專業服務大致分為兩種，一種是交付，另一種是諮詢。前者是指ThoughtWorks開發團隊直接為客戶開發軟體，後者則是ThoughtWorks諮詢師輔導客戶的團隊來更好地開發軟體。

ThoughtWorks諮詢團隊，有三種諮詢師。

第一種是管理諮詢師。這些諮詢師有些會深入到客戶基層開發團隊，來輔導客戶團隊進行Scrum迭代開發和看板實踐；有些會輔導客戶的業務分析人員做設計思維工作坊、拆分用戶故事、編寫驗收條件；有些會運用ThoughtWorks的精益企業理念和EDGE投資組合管理框架，來輔導客戶公司總裁制定組織級敏捷轉型的決策。

第二種是技術諮詢師。他們中有些會評估客戶現有軟體系統的架構，並提出改進建議；有些會輔導客戶程序員編寫測試代碼和進行代碼重構；有些會輔導客戶的持續集成工程師搭建部署流水線；有些會輔導客戶構建微服務架構的系統；有些會開始探索VR/AR（虛擬現實／增強現實）、區塊鏈技術、AI（人工智慧）、自動駕駛汽車和無伺服器架構等前沿「黑科技」。

第三種是全棧諮詢師。這些諮詢師能一人兼作上述兩種工作，這也是筆者所嚮往的。換句話說，這種諮詢師：既能和總裁聊天，又能輔導Scrum和看板；既能引入極限編程，又能指導需求管理；既能改進持續集成，又能和程序員結對寫單元測試；既能編製諮詢項目計劃，又能給團隊做培訓；既會設計思維，又能幹點售前。要想修鍊成全棧諮詢師，用同事大魔頭（楊雲）的話說，需要「膽子大，學得快，講得棒。」其中，「學得快」是核心。

這三種諮詢師在輔導團隊做敏捷轉型時，常用的套路大概有四步：

第一步：評估。根據客戶團隊情況，使用ThoughtWorks所總結的各種成熟度模型（比如敏捷成熟度模型和持續交付成熟度模型），來對客戶團隊的技術和管理實踐進行評估，找出痛點和改進點。

第二步：培訓。給客戶團隊進行Scrum和看板、用戶故事、持續交付等轉型相關內容的培訓，熟悉客戶團隊成員，發現客戶團隊中做敏捷轉型的忠實粉絲，並讓團隊對轉型中要做的工作獲得統一認識。

第三步：輔導。與客戶團隊成員結對工作，來一對一或一對多地輔導Scrum迭代開發和看板實踐、用戶故事拆分及其驗收條件編寫、編寫自動化測試、搭建部署流水線等等。

第四步：回顧。一段時間後，讓團隊回顧轉型取得的成績，並找出下一步持續改進的目標。

優勢

如果你讀到這裡，相信這支團隊在你面前已經不再那麼神秘了。筆者掐指一算，到今天已經加入ThoughtWorks快兩年半了。以前神秘的團隊，如今已成為筆者在深夜提筆撰寫此文的動力。那麼這支ThoughtWorks諮詢團隊，與其他競爭對手相比究竟有何優勢呢？筆者覺得至少有兩點優勢：

第一，技術能落地。ThoughtWorks最大的優勢就是工程技術實踐及分享的能力，比如代碼重構和首席科學家Martin Folwer的《重構》一書、持續交付和Jez Humble及Dave Farley的同名書、微服務及Martin Folwer的同名博客等等。而那些來自工程實踐一線的諮詢師們，能令諮詢方案落到實處。這一點，是很多競爭對手難以做到的。

第二，錦囊妙計多。ThoughtWorks中國區總經理張松曾經對筆者說過，ThoughtWorks與其他競爭對手最大的不同，就是公司人數眾多。而這支神秘團隊的領袖孔雀然（肖然）曾經說，在ThoughtWorks最大的好處，就是能利用上面所提到的Hivemind。綜合起來，這些通過了最難面試的ThoughtWorkers聚集了為數眾多的力量，又形成的強大的Hivemind，能讓你在遇事不決時，助你擁有足夠多的錦囊妙計。相比筆者曾經從事過的只有一人的自由諮詢師或僅有幾人的小諮詢公司來說，你能從幾千位ThoughtWorkers那裡獲得更多的智慧，讓你進步得更快。

至於薪資，還是得問HR妹紙。。。其實你可以去拉勾、獵聘等網站看看ThoughtWorks的招聘需求嘛。

謝邀,不過我沒請過tw的諮詢師.只是同事吃飯的時候聊到過.有些有水平.但也有水平很差的.

截圖自Logan CIJ Symposium，很抱歉，我們不止做技術諮詢

我覺得TW就是個二流技術公司，但他們給三流甚至不入流的公司做技術指導還是蠻不錯的。

問題是，他們總想把自己表現為一流。