成爲軟件諮詢師的關鍵

翻譯 ：劉昕

歡迎訪問網易雲社區，瞭解更多網易技術產品運營經驗。  

 

最近，我在Twitter上發佈了一條狀態(以下圖所示)——我在考慮寫一些東西，是關於如何從一個軟件開發人員到一個軟件諮詢師。不少人老是問我這個問題，這確實是一個有趣的話題。你們對這條推特的熱情迴應也讓我受寵若驚，深受鼓舞。

                                              

（這周我又在爲寫書而癢癢——軟件開發人員如何成爲軟件諮詢師的一本指南書）

 

我在考慮這些內容的最佳載體。我能夠再寫一本書，或者作一些視頻課程或者一些列的小課程。可是不管我用什麼方式，我都須要在作這些事情前先把關鍵內容列出來。我將在這方面進行深刻的研究。但我想說，成爲一名軟件諮詢師有基礎的、哲學上的關鍵點。今天我想談談這個問題。

 

軟件諮詢師，和軟件開發是有區別的

 

這裏沒有導語（直接開始）。我爲你們提供的建議是基於我（給你們看的）全部內容基礎上。你可能不會喜歡它。或者，你至少會認爲它應該讓位於其餘建議，好比「更多同理心」或「問不少問題」之類的。可是,沒有。

不要讓潛在的諮詢客戶爲你編寫的代碼付錢。

認真講，這是你從軟件開發人員到軟件諮詢師的過程當中最基本的部分。其緣由在於，成功的諮詢顧問都會慢慢明白的一個點:定位。目前人們談論定位都是談在市場營銷中，經過定位把本身與競爭者區分開來。在這裏我想說的是，將你本身與你習慣作的事情區分開來(所以，與你應該中止把軟件開發人員當成你的競爭對手)。

讓我像往常同樣用敘述的方式來給你們解釋一下這個觀點。

（譯者注：這段意思是，若是你想成爲一個軟件諮詢師，就要明白本身的定位。不要讓你的潛在客戶爲你的代碼買單而不是你的諮詢服務買單，不要總想着和軟件開發人員競爭）

 

達芬奇:文藝復興時期的水管工

 

不管怎麼看，列奧納多·達·芬奇都是世界上最偉大的人物之一。在他不一樣的成就中，他畫了《蒙娜麗莎》，設計了一輛坦克，在人體解剖學方面取得了重要的貢獻。但讓咱們這樣假設吧，在一個相似於「比爾和泰德歷險記」的特別劇情中，他穿越到500年後的將來，也就是現代世界。

即便是像達·芬奇這樣偉大的人，無疑也須要一點時間來適應現代社會。因此咱們假設，當他學習現代語言、技術和文化時，他找了一份水管工的工做。

 

假設你碰巧有一個水槽漏水的水龍頭，你打電話給達芬奇的管道公司尋求幫助。他們馬上派達芬奇到你這裏來看一下，幫你一把。

這樣達芬奇來了，由於他是達芬奇，他立刻就發現你的供給線有點鬆了。他把它收緊，你對這個結果很滿意。

 

被忽視的達芬奇

 

在你的鼓勵下，達芬奇的眼睛閃閃發亮。他作了一些心算，告訴你若是你採用一種反直覺的飯後清洗餐具的方法，你的水費會減小15%。他接着告訴你水費減小的原理。同時，他還指出，你廚房牆上的畫和房間裏的畫不太匹配。

面對天才達芬奇教你如何更好洗碗的方法並幫助你的藝術，你會怎麼作?你微微一笑，應和着，而後心裏想:「把水槽修好，趕忙離開這裏。」你這樣作是絕對正常的反應。

爲何?由於你並不知道他是達芬奇。你只知道你僱了一我的來修水槽，可是如今有人主動給你洗碗、還提供裝修房子的建議。你僱傭他來執行勞動，而你卻獲得了他對你生活的建議。

 

被忽視的軟件開發人員

 

若是在讀文章的你是一個專業的軟件開發人員，均可能像達芬奇同樣。你懂的若是你的公司減小科技債務將會運轉的更好。您能夠很容易地發現，管理的瀑布式「方法」是無效的和使人痛苦的。並且，雖然你不是專家，你甚至知道公司的品牌和銷售策略是無效的。

你提出建設性的反饋，但沒人聽。你是達·芬奇，可是被忽視了。我不是在討好你。您必須聰明地以編寫軟件爲生，在我採訪的每一站中，軟件開發人員都有很好的想法，這些想法遠遠超出了IDE的範圍。一般，管理層要麼隨便應和，要麼乾脆無視他們。你能夠把這歸結爲「親近感滋生輕蔑」，但這實際上是我以前提到的「定位」理論。

管理層僱傭你來執行代碼編寫工做。你不請自來的意見不是工做的一部分。由於你很受歡迎，人們會對你微笑、點頭和應和。但他們其實不在意你的見解。這就是軟件開發人員的現狀。把大家的建議歸檔到我辦公桌旁邊的小垃圾箱裏，只是用「建議」標籤取代「垃圾「標籤」」。

 

被忽視的將來軟件諮詢師

 

假設你厭倦了這種狀況。你喜歡這個行業和軟件，但你想要更多的影響力。管理不適合你，但「諮詢」適合你。也許你會出去作自由職業者，或者你會去一家軟件「諮詢」公司工做。如今，狀況就不同了。如今，人們會聽你的建議。

而後，讓你極度沮喪的是，狀況並不如意。即便你的頭銜和名片上寫着「諮詢師」，人們仍然會笑着地對你說，「不管如何，夥計，只要編寫規範就好了。」

怎麼回事呢?實際上，很大一部分問題在於咱們的工做領域中「諮詢師」一詞被用爛了。在你的客戶的網站上，不管他們是親自給CIO提建議的人，仍是把本身封閉在一個空間裏編寫存儲過程的人，沒有和客戶進行W2協議的人都叫作「諮詢師」。

更糟糕的是，每一家作定製應用程序開發並稱之諮詢的公司都以「諮詢」爲本身定位。「哦,個人天。咱們的顧問不只僅是程序員——他們編寫代碼，還提供領導力和建議。

這徹底是意料之中的事，以致於一些客戶可能會以爲聽到這樣的商店或人們說:「不，咱們只是把範式變成代碼。」「謝天謝地。我終於不用聽管道工談論我對牆壁裝飾的選擇了。

 

給本身一個真正諮詢師的定位

 

所以，讓咱們來審視軟件諮詢師的狀況。全部「諮詢師」對人們的實際含義是，你是在爲一個不會給你發W2的人工做。可是，若是他們勝券在握，就會發現，無論有沒有人想要，你代碼是爲一個不會給你發送W2可是會提供不少意見的人寫的。通常軟件諮詢師的角色和默認定位是「自覺得是的，高於通常開發者」。

如今對我將來的書或課程感興趣的人其實是想成爲諮詢師的人。公司不爲勞動力(或代碼)支付諮詢師費用;他們付錢給諮詢師徵求他們的意見。這就是問題所在。若是你以軟件諮詢師之類的身份介紹本身，你默認的定位是「編碼者」。可是，爲了實現你的目標，你須要把本身定位成一個真正的諮詢師，並從諮詢中得到報酬。

雖然有許多細節觀點能夠推進你朝着這個方向前進，但要注意一個基準點——不要讓你的客戶付錢讓你寫代碼。

在一個每個爲另外一家公司編寫代碼的軟件開發人員都是「諮詢師」的世界裏，你能夠經過不爲報酬編寫代碼來將本身定位爲真正的顧問。這樣沒有人會把你和專業程序員混淆。

 

隱喻醫學

 

《拋棄小時》和《自由職業者秀》的喬納森·斯塔克(Jonathan Stark)用一個很好的比喻來幫助你理解定位的概念。我將在這裏用它來講明諮詢和勞動(即編寫代碼)之間的主要區別。

他談到了爲公司解決問題的四個階段：包括診斷，開處方，應用治療，和從新應用治療。軟件開發人員和大多數所謂的軟件諮詢師幾乎只參與第三階段:應用。但這是一個槓桿率很低的階段。諮詢師幾乎只存在於第一和第二階段:診斷和處方。他們讓勞動者（即編碼的程序員）負責第三階段，甚至更低的地位勞動者負責第四階段。

從其餘知識工做者的角度來考慮。你帶着一種疾病去看醫生，醫生髮現了這種疾病並開了處方。可是若是須要天天用這種藥在你的腳底擦5次，這個醫生也不會處理這個事情（給你擦藥這個事情）——這低於他的工資標準。而是你本身擦藥，或者僱個按摩師什麼的幫你擦藥。

 

當你以軟件「諮詢師」的身份負責代碼時，你會告訴別人你從事的是診斷和處方的工做。但當具體實施的時候，你幾乎把全部的時間都花在人們的腳上，而且詳細地討論(「諮詢」)操做的最佳方法。【譯者注：這裏做者用了一個比喻「橡膠和路」，意思是和「藥膏」一個意思，表示不該該注重如何給患者上藥，而應該聚焦於第1、二階段的諮詢工做。這裏翻譯的時候直接去掉了這個一句話的隱喻】

如今，想象一下這樣一個行業，診斷醫生和奴隸販子都自稱醫生。因此當你須要診斷的時候，你會本能地去尋找那些手上沒有粘東西（沒有幫人擦藥）的人，這樣就能分辨出不一樣（沒有擦藥的就是醫生）。

 

警告

 

首先，讓我立馬理清一下。我實際上能夠本身寫評論。有人會讀這篇文章，而後說，「我是一個爲個人客戶編寫代碼的諮詢師，可是個人客戶實際上會諮詢我是否應該採用Scrum（敏捷開發），並採起個人意見。「是的，我相信，就像我相信管理層有時確實會聽取軟件開發人員的意見同樣。這種狀況會發生。可是，若是你只是告訴他們是否採用Scrum，那就徹底不一樣了。【譯者注：管理者偶爾會聽取程序員的意見，但偶爾聽取與只提供意見服務不一樣】

其次，你能夠以協助的角色去編寫代碼。教練和培訓師是很好的例子。記住，我說過不要讓別人爲你編寫的代碼付錢。公司不會爲了寫代碼而付錢給培訓師，而是爲了讓培訓師向他們的團隊展現如何編寫代碼。做爲區分的原則，能夠問問本身客戶是否依賴於你編寫的用於生產的代碼。若是答案是確定的，那你就是在塗足膠（也就是醫生擦藥），而不是在診斷。

最後，我不會質疑，有些人走這條路可能不只僅是曇花一現的成功。也許不管他們走到哪裏，他們都會挽起袖子，整個上午都在擺弄代碼，而後走進CIO（首席信息官）辦公室提供策略建議。我歷來沒見過這種狀況，也沒見過相似的狀況，但這是有可能發生的。或者，更有可能的是，有人爲一些客戶提供諮詢，爲另外一些客戶提供代碼。不管如何，有些人可能會成功地永遠走在諮詢編碼員這個方向，並對他們有益。但我能告訴你的是，這是例外，不能做爲參考。

 

諮詢的內容要多得多，但這是你的開始

 

正如我在文章開頭提到的，如何成爲一名成功的軟件諮詢師這個問題我能夠寫滿一本書或者作一整個課程。從軟件開發人員到軟件諮詢師彷佛很簡單，但這其實很表面（做者用了「fools’gold」表示不是真材實料的、表面上的）。你接受「諮詢」這個極其鬆散的定義是很容易的事情，但若是你真的想經過提供專家的意見、診斷和處方，而不是編寫代碼而得到報酬，那就不容易了。但你就有了一個很好的學習和技能學習的機會。

那麼，爲何在全部原則中，我選擇「避免編寫代碼」做爲基準原則呢?正如我一直說的，定位本身是關鍵，這是你擺正本身位置最好的地方。爲了獲得診斷費，你須要有人向你問診，而不是讓你在他們的腳上塗藥就叫診斷。

另外，還有一個更微妙的理由讓我強調不要編寫代碼。編寫代碼是使人滿意的，有趣的，並且很是有市場需求的。所以，找到付錢讓你寫代碼的人是很是容易的。他們很是須要你的編程技能。若是你想被稱爲「技術代碼的CEO」，他們甚至會叫你「技術代碼的CEO」。你有現成的柺杖（譯者注：相對諮詢，提供編碼你有現成的市場和基礎，會更容易）。

拒絕爲客戶編寫代碼意味着強行移除柺杖。這樣作，你就像一個飛到國外的非母語人士，只有經過沉浸式學習來學習。你沒有柺杖，也沒有選擇，只能去解決它。您能夠在業餘時間爲興趣編寫代碼，並踐行您的想法。但若是你想認真考慮成爲諮詢師，那就須要中止這樣作（寫代碼），這樣你就能夠開始診斷了。別讓他們爲你的代碼付錢。

 

原文：https://daedtech.com/key-becoming-software-consultant/

 

免費領取驗證碼、內容安全、短信發送、直播點播體驗包及雲服務器等套餐

更多網易技術、產品、運營經驗分享請點擊。

 

相關文章：
【推薦】 論用戶體驗測試：牛逼的功能千篇一概，好的體驗萬里挑一
【推薦】 消息中間件客戶端消費控制實踐
【推薦】 【譯文】抽象漏洞法則