1. 程式人生 > >成為軟體諮詢師的關鍵

成為軟體諮詢師的關鍵

翻譯 :劉昕

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


最近,我在Twitter上釋出了一條狀態(如下圖所示)——我在考慮寫一些東西,是關於如何從一個軟體開發人員到一個軟體諮詢師。很多人總是問我這個問題,這確實是一個有趣的話題。大家對這條推特的熱情迴應也讓我受寵若驚,深受鼓舞。

20181206093509159a23c2-2307-450a-8a4d-f2edffce191c.png                                              

(這周我又在為寫書而癢癢——軟體開發人員如何成為軟體諮詢師的一本指南書)

 

我在考慮這些內容的最佳載體。我可以再寫一本書,或者做一些視訊課程或者一些列的小課程。但是無論我用什麼方式,我都需要在做這些事情前先把關鍵內容列出來。我將在這方面進行深入的研究。但我想說,成為一名軟體諮詢師有基礎的、哲學上的關鍵點。今天我想談談這個問題。

 

軟體諮詢師,和軟體開發是有區別的


這裡沒有導語(直接開始)。我為大家提供的建議是基於我(給大家看的)所有內容基礎上。你可能不會喜歡它。或者,你至少會認為它應該讓位於其他建議,比如“更多同理心”或“問很多問題”之類的。但是,沒有。

不要讓潛在的諮詢客戶為你編寫的程式碼付錢。

認真講,這是你從軟體開發人員到軟體諮詢師的過程中最基本的部分。其原因在於,成功的諮詢顧問都會慢慢明白的一個點:定位。目前人們談論定位都是談在市場營銷中,通過定位把自己與競爭者區分開來。在這裡我想說的是,將你自己與你習慣做的事情區分開來(因此,與你應該停止把軟體開發人員當成你的競爭對手)。

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

(譯者注:這段意思是,如果你想成為一個軟體諮詢師,就要明白自己的定位。不要讓你的潛在客戶為你的程式碼買單而不是你的諮詢服務買單,不要總想著和軟體開發人員競爭)

 

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


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

即使是像達·芬奇這樣偉大的人,無疑也需要一點時間來適應現代社會。所以我們假設,當他學習現代語言、技術和文化時,他找了一份水管工的工作。

2018120609353907749353-349e-4a65-b57f-5c6216abc075.png


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

這樣達芬奇來了,因為他是達芬奇,他馬上就發現你的供給線有點鬆了。他把它收緊,你對這個結果很滿意。

 

被忽視的達芬奇


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

面對天才達芬奇教你如何更好洗碗的方法並幫助你的藝術,你會怎麼做?你微微一笑,應和著,然後內心想:“把水槽修好,趕緊離開這裡。”你這樣做是絕對正常的反應。

為什麼?因為你並不知道他是達芬奇。你只知道你僱了一個人來修水槽,但是現在有人主動給你洗碗、還提供裝修房子的建議。你僱傭他來執行勞動,而你卻得到了他對你生活的建議。

 

被忽視的軟體開發人員


如果在讀文章的你是一個專業的軟體開發人員,都可能像達芬奇一樣。你懂的如果你的公司減少科技債務將會運轉的更好。您可以很容易地發現,管理的瀑布式“方法”是無效的和令人痛苦的。而且,雖然你不是專家,你甚至知道公司的品牌和銷售策略是無效的。

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

管理層僱傭你來執行程式碼編寫工作。你不請自來的意見不是工作的一部分。因為你很受歡迎,人們會對你微笑、點頭和應和。但他們其實不在乎你的看法。這就是軟體開發人員的現狀。把你們的建議歸檔到我辦公桌旁邊的小垃圾箱裡,只是用“建議”標籤取代“垃圾“標籤””。

 

被忽視的未來軟體諮詢師


假設你厭倦了這種情況。你喜歡這個行業和軟體,但你想要更多的影響力。管理不適合你,但“諮詢”適合你。也許你會出去做自由職業者,或者你會去一家軟體“諮詢”公司工作。現在,情況就不一樣了。現在,人們會聽你的建議。

然後,讓你極度沮喪的是,情況並不如意。即使你的頭銜和名片上寫著“諮詢師”,人們仍然會笑著地對你說,“無論如何,夥計,只要編寫規範就行了。”

怎麼回事呢?實際上,很大一部分問題在於我們的工作領域中“諮詢師”一詞被用爛了。在你的客戶的網站上,無論他們是親自給CIO提建議的人,還是把自己封閉在一個空間裡編寫儲存過程的人,沒有和客戶進行W2協議的人都叫做“諮詢師”。

更糟糕的是,每一家做定製應用程式開發並稱之諮詢的公司都以“諮詢”為自己定位。“哦,我的天。我們的顧問不僅僅是程式設計師——他們編寫程式碼,還提供領導力和建議。

這完全是意料之中的事,以至於一些客戶可能會覺得聽到這樣的商店或人們說:“不,我們只是把正規化變成程式碼。”“謝天謝地。我終於不用聽管道工談論我對牆壁裝飾的選擇了。

 

給自己一個真正諮詢師的定位


因此,讓我們來審視軟體諮詢師的情況。所有“諮詢師”對人們的實際含義是,你是在為一個不會給你發W2的人工作。但是,如果他們勝券在握,就會發現,不管有沒有人想要,你程式碼是為一個不會給你傳送W2但是會提供很多意見的人寫的。一般軟體諮詢師的角色和預設定位是“自以為是的,高於一般開發者”。

現在對我未來的書或課程感興趣的人實際上是想成為諮詢師的人。公司不為勞動力(或程式碼)支付諮詢師費用;他們付錢給諮詢師徵求他們的意見。這就是問題所在。如果你以軟體諮詢師之類的身份介紹自己,你預設的定位是“編碼者”。但是,為了實現你的目標,你需要把自己定位成一個真正的諮詢師,並從諮詢中獲得報酬。

雖然有許多細節觀點可以推動你朝著這個方向前進,但要注意一個基準點——不要讓你的客戶付錢讓你寫程式碼。

在一個每一個為另一家公司編寫程式碼的軟體開發人員都是“諮詢師”的世界裡,你可以通過不為報酬編寫程式碼來將自己定位為真正的顧問。這樣沒有人會把你和專業程式設計師混淆。

 

隱喻醫學


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

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

從其他知識工作者的角度來考慮。你帶著一種疾病去看醫生,醫生髮現了這種疾病並開了處方。但是如果需要每天用這種藥在你的腳底擦5次,這個醫生也不會處理這個事情(給你擦藥這個事情)——這低於他的工資標準。而是你自己擦藥,或者僱個按摩師什麼的幫你擦藥。
2018120609362121a59b0d-d4aa-43a8-b539-cb284b9ac659.png


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

現在,想象一下這樣一個行業,診斷醫生和奴隸販子都自稱醫生。所以當你需要診斷的時候,你會本能地去尋找那些手上沒有粘東西(沒有幫人擦藥)的人,這樣就能分辨出不同(沒有擦藥的就是醫生)。

 

警告


首先,讓我立馬理清一下。我實際上可以自己寫評論。有人會讀這篇文章,然後說,“我是一個為我的客戶編寫程式碼的諮詢師,但是我的客戶實際上會諮詢我是否應該採用Scrum(敏捷開發),並採取我的意見。“是的,我相信,就像我相信管理層有時確實會聽取軟體開發人員的意見一樣。這種情況會發生。但是,如果你只是告訴他們是否採用Scrum,那就完全不同了。【譯者注:管理者偶爾會聽取程式設計師的意見,但偶爾聽取與只提供意見服務不同】

其次,你可以以協助的角色去編寫程式碼。教練和培訓師是很好的例子。記住,我說過不要讓別人為你編寫的程式碼付錢。公司不會為了寫程式碼而付錢給培訓師,而是為了讓培訓師向他們的團隊展示如何編寫程式碼。作為區分的原則,可以問問自己客戶是否依賴於你編寫的用於生產的程式碼。如果答案是肯定的,那你就是在塗足膠(也就是醫生擦藥),而不是在診斷。

最後,我不會質疑,有些人走這條路可能不僅僅是曇花一現的成功。也許無論他們走到哪裡,他們都會挽起袖子,整個上午都在擺弄程式碼,然後走進CIO(資訊長)辦公室提供策略建議。我從來沒見過這種情況,也沒見過類似的情況,但這是有可能發生的。或者,更有可能的是,有人為一些客戶提供諮詢,為另一些客戶提供程式碼。無論如何,有些人可能會成功地永遠走在諮詢編碼員這個方向,並對他們有益。但我能告訴你的是,這是例外,不能作為參考。


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


正如我在文章開頭提到的,如何成為一名成功的軟體諮詢師這個問題我可以寫滿一本書或者做一整個課程。從軟體開發人員到軟體諮詢師似乎很簡單,但這其實很表面(作者用了“fools’gold”表示不是真材實料的、表面上的)。你接受“諮詢”這個極其鬆散的定義是很容易的事情,但如果你真的想通過提供專家的意見、診斷和處方,而不是編寫程式碼而獲得報酬,那就不容易了。但你就有了一個很好的學習和技能學習的機會。

那麼,為什麼在所有原則中,我選擇“避免編寫程式碼”作為基準原則呢?正如我一直說的,定位自己是關鍵,這是你擺正自己位置最好的地方。為了得到診斷費,你需要有人向你問診,而不是讓你在他們的腳上塗藥就叫診斷。

另外,還有一個更微妙的理由讓我強調不要編寫程式碼。編寫程式碼是令人滿意的,有趣的,而且非常有市場需求的。因此,找到付錢讓你寫程式碼的人是非常容易的。他們非常需要你的程式設計技能。如果你想被稱為“技術程式碼的CEO”,他們甚至會叫你“技術程式碼的CEO”。你有現成的柺杖(譯者注:相對諮詢,提供編碼你有現成的市場和基礎,會更容易)。

拒絕為客戶編寫程式碼意味著強行移除柺杖。這樣做,你就像一個飛到國外的非母語人士,只有通過沉浸式學習來學習。你沒有柺杖,也沒有選擇,只能去解決它。您可以在業餘時間為興趣編寫程式碼,並踐行您的想法。但如果你想認真考慮成為諮詢師,那就需要停止這樣做(寫程式碼),這樣你就可以開始診斷了。別讓他們為你的程式碼付錢。


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

 

免費領取驗證碼、內容安全、簡訊傳送、直播點播體驗包及雲伺服器等套餐

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


相關文章:
【推薦】 == vs === in Javascript