技術項目的溝通藝術：講故事

如何說服企業的其他成員來批准我們在這些領域所需要的投資？雖然我們對面向客戶的應用進行了更新和重構，但是我們在三年內放慢了產品和服務創新速度。我們在市場上付出了代價，為了更現代化的更新產品平台，為了更加靈活的未來，我們做出了犧牲。

在過去三年中，我們已經更新了公司內的幾乎所有和技術相關的方面。我們已經將大量服務遷移到雲，更換了我們的電話和網路系統，並實施了CRM和聯絡中心軟體的軟體即服務版本。 我們將所有生產系統的機械硬碟替換為固態硬碟。

我們實施了超融合基礎設施，實現了SOC認證，並通過採用微服務架構，使我們面向客戶的遺留應用更現代化。我們在敏捷和DevOps 上也取得進展——我們已經為DevOps中應用級安全性的發明，申請了三項專利——我們已經利用這些專業知識和這些最新的技術開發了一系列的新應用和服務。

所有這一切都需要時間、金錢和人員。那麼問題是，我是如何說服企業的其他成員來批准我們在這些領域所需要的投資？這不是反問句。 雖然我們對面向客戶的應用進行了更新和重構，但是我們在三年內放慢了產品和服務創新速度。我們在市場上付出了代價，為了更現代化的更新產品平台，為了更加靈活的未來，我們做出了犧牲。

三年前，我強烈地認為這是一個有價值的投資，但企業的其他人員也會這樣認為嗎——特別是我的同事和老闆？

溝通藝術：「為什麼」的重要性

我並不是伶牙俐齒的人。如果我成為一個銷售，我肯定會餓死。我不會表達。我不是一個優秀的溝通者。然而，我的職位，讓我必須定期做出令人信服的業務案例。鑒於我缺乏銷售技能，我必須想辦法說服他人去做我認為應該做的事情。我被迫去思考技術項目的溝通藝術。

最初幾次，我試圖為一個項目做案例，我花了幾天收集數據和技術事實。我詳細介紹伺服器容量，生產量指標和周期時間的降低。我練習我的演講。我設想每個提問。一切都按照我計劃的進行。當我完成演講後，我覺得我能立即獲得批准。 但是，我收到的唯一提問是，「我們為什麼要這樣做？」 同樣的情況發生了好幾次，然後我意識到聽眾很容易在數據和技術事實之中迷失。既迷失又迷茫。

在我努力尋求如何讓我的案例獲得批準時，我讀了一本名為「Made to Stick: Why Some Ideas Survive and Others Die」的書。從Made to Stick中，我學到的最重要的教訓是人們關注並會記住故事。 我改變了我的方法，並努力掌握講故事的藝術。當我為我們的遺留ERP進行零定製重做案例時，我講述了我們創建新條目需要多長時間，添加新稅務地區需要多少人員，以及要獲得例如產品盈利能力這樣簡單的問題的答案，有多麼困難。 我的聽眾與這些故事產生共鳴，因為他們是條目創建，財務和盈利能力報告流程的所有人。當他們聽了這些故事，我只需要將我的項目與這些流程中的痛點的解決方案相關聯。

我沒有談到伺服器容量，生產量指標或周期時間的降低。為什麼沒有？因為這些技術指標，雖然對我的下屬有意義，對我的業務同行和老闆則沒有意義。 要成為一個講故事的人，我也發現，故事中最重要的元素是「為什麼」。事實上，我現在相信這個故事的「為什麼」比「什麼」要重要得多。而我幾乎從來不需要講到「如何」——「如何」是一個實施細節，不應該是業務案例中的一部分。

溝通藝術：如何收集故事

故事從何而來？

在我處理業務時，我收集那些會在某一時刻構建業務案例的微小故事。例如，對於我們的ERP的零定製重做，我必須克服一個基本的信念，即我們的流程是如此獨特，標準的ERP功能不僅對我們無效，而且實際上使我們面臨風險。

我如何克服呢？通過收集幾個月的例子，證明我們高度定製的ERP，比更換後，更有風險。例如，在一次會議中，我們的內控官要求我們將一個新項目列入我們的名單：他需要我們在供應商名單中添加一個新的供應商。

問題是，這個供應商位於印度一個尚未納入我們稅務結構的地區。在印度，每個地區的稅務都不同，所以需要兩個會計師和四個IT人員，花費六個星期的時間，將這個印度地區納入我們的稅務結構。如果我們使用的是標準賬目圖表和稅務結構（而不是我們古怪的，高度定製的版本），那麼這個工作只需要一個員工不到一天的時間就能完成。我將這些信息添加到我的「重做ERP」理由中，還有其他類似案例。當我們需要解釋為什麼要重做ERP時，我有幾十個故事來做為理由。

收集故事需要耐心。有了一些技術方案，需要幾個月的時間收集足夠的證據來證明我的案例，當我站在聽眾面前時，我希望能夠得到肯定的答案，他們不但批准項目，還會擁護項目。更好的是，由於他們可以與故事產生共鳴，並記住故事，我的聽眾還可以向企業的其他成員解釋項目的原因。 通過講故事來建立一個業務案例對我非常實用，我不再需要解釋單調的細節，比如投資回報率，伺服器速度和生產量。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！