一個IT人的非典型職場十年 (6)

話說我當年從研發跳到諮詢部門，其實思路很簡單，就是但願能夠更加的靠近一個公司賺錢的部門，追着公司的發展戰略走。這種選擇工做的策略，是不會有錯誤的。但實際上換了工做後才發現，諮詢工做遠沒有我想象中那麼容易。每個衣着光鮮職位的背後，都有一個個苦逼的IT人。 

首當其衝的是工做性質和內容。研發的工做相對單純， 基本上日出而起日落而息，固然有時候免不得要晚上跟阿三啊老美啊搞個conference call啥的。但基本上須要作的事兒是相對獨立，以我的爲單位完成，悶到屋子裏面搞定。並且項目的週期是跟隨產品的週期走，相對來講比較長，怎麼一個大版本的發佈也須要半年時間。有時候會有些跟客戶打交道，也是通過了若干層技術支持的篩選，基本都是很專一的技術問題。 而IT Consulting則徹底不一樣，純諮詢出報告項目、項目羣管理、客戶關係維繫、測試管理等等，各類類型、各類金額規模的項目五花八門， 基本上不重樣的。一切說所謂解決方案重用，都是在說謊。覺得客戶具體需求差異很大，客戶本身的想法也很不同。

其次是技術路線。即使你灘上一個技術類系統實施項目，那在諮詢部門的技術實施和在產品部門也徹底不一樣。IBM的產品部門基本是專一在產品技術自己， 每一個工程師對產品的某一個模塊很熟悉，很專一，技術實現強調產品完備性和重用性；而諮詢部門則徹底是另一個路數。 他們強調的是項目範圍內風險可控，所以更多采用相對來講不那麼高級的技術細節。好比一個數據庫訪問模塊的實現，產品部門可能用了一堆的設計模式，全部能外部參數化的都參數化，搞了一堆的支持模型，可以支持Oracle, MySQL, DB2.....外加zOS, AS400, AIX, Soloris, HP UX.....巴不得全部的平臺都通通的搞定。而諮詢項目則是特定平臺的，一樣模塊諮詢項目可能就是用簡單的Java 可持久化框架分分鐘搞定了，什麼多平臺多產品支持一律不予考慮。反卻是更加關心在系統性能上去後的各類處理，例如使用不少緩存啊、memcache啊..等等。不然系統垮了架構師是要坐牢的。所以，很負責的講，產品架構師和系統架構師是徹底不一樣的兩個工做。

我比較幸運，來到諮詢部門第一個項目就是當年全國最大的信息化項目，具體客戶名我就不提了，不管是行業仍是客戶提了就很快知道是誰了。總之這個項目是十幾億的大型項目，並且最奇葩的是IBM是諮詢，HP是實施，下包給埃森哲，用的是SAP ERP和ORACLE DB. 顯然，這是一個足夠熱鬧的項目。各大IT供應商所有到場落座，基本上各類利益牽扯在一塊兒，打的不亦樂乎。這個項目咱們是項目羣管理和需求分析，也就是一個甲B方的角色，表明客戶來管理各類跟咱們沒有合同關係的「友商」。項目大到最高峯時期有巴不得200+的人駐場工做，而各方面的利益牽扯，使得項目羣管理顯得尤其困難。 這個項目讓我明白的最大道理，不是什麼技術和項目管理自己。而是如何在項目中溝通與分析各方的立場。這點在大項目中尤其關鍵，每一方每一個人都有他本身的立場，都源自他的利益。所謂屁股決定腦殼，腦殼副作用於屁股就是這個道理。如何製做到溝通有效，說服有理？就須要明確你的溝通目的，明確對方的立場和底線。我以爲這確實是IT人，尤爲是工程師比較欠缺的一點。固然我也不是一下就學會的，都是必須繳足了學費。常常有時候開會，一句話說錯可能就上了全套，而後被對方拉出來使勁打，你還話說。工程師相對單純，但作諮詢顧問不只僅是要作好技術，而是要將技術運用在客戶的特定場合。說服對方，既要靠技術，更加劇要的是要靠溝通。

IT技術人員必定要學着面對客戶，面的那些非IT的人員。 尤爲是在作客戶項目時，不能老是用IT的語言或者思路來和客戶溝通。要學着用業務的思路，想一想看客戶爲何這麼作，這麼想。他的痛點在哪裏？如何經過IT來解決問題。歸根結底，IT是爲業務服務的。銀行核心系統自己不賺錢，只有銀行的存貸款業務才賺錢啊～

待續。。。