技術(shù)背景的項目形式風格偏硬，喜歡擼起袖子自己干，往往不注意軟技能的修煉。而非技術(shù)背景的項目經(jīng)理往往行業(yè)技術(shù)知識不足，往往容易被技術(shù)專家忽悠，因此需要多修煉一些技術(shù)硬功夫。本文就談談非技術(shù)背景的項目經(jīng)理該如何提升自己的技術(shù)素養(yǎng)。
可能是因為自己是技術(shù)出身的項目經(jīng)理的原因，以往比較關(guān)注技術(shù)出身的項目經(jīng)理需要注意的思想行為的轉(zhuǎn)變。大概是因為技術(shù)背景的項目經(jīng)理往往風格偏硬，也就是比較喜歡擼起袖子親自干。其實，我身邊也有不少非技術(shù)背景的項目經(jīng)理，雖然不乏理科畢業(yè)的，但是畢業(yè)后基本沒有從事過具體的技術(shù)研發(fā)工作。因為缺乏技術(shù)一線的背景，他們往往天生硬不起來，只能靠軟技能來管理項目。我通過觀察發(fā)現(xiàn)，非技術(shù)背景的項目經(jīng)理在工作中存在偏軟的問題，當遇到技術(shù)人員用所謂的技術(shù)權(quán)威來耍賴的時候，這一類項目經(jīng)理往往無計可施，只能是啞巴吃黃連。
所以，要把項目管好，從項目經(jīng)理的個人能力上來講，軟硬兩手都要抓。技術(shù)背景的項目經(jīng)理要補軟的短板，非技術(shù)背景的項目經(jīng)理要補技術(shù)的短板。今天我們討論一下，非技術(shù)背景的項目經(jīng)理如何補上技術(shù)的短板。
首先要說明一點，所謂補技術(shù)的短板并不是要求項目經(jīng)理從事具體的技術(shù)研發(fā)工作，而是指項目經(jīng)理需要加強技術(shù)邏輯能力，也就是能用技術(shù)術(shù)語和概念，根據(jù)技術(shù)原理進行邏輯思維和推理的能力。
實際上，今天我要談的既是一種能力也是一種學習方法。我雖然是技術(shù)背景，但是在項目管理實踐中，我也不可能懂得項目中所有的技術(shù)。如果說討論軟件相關(guān)的技術(shù)，海哲基本上沒有怕過誰，但是機械結(jié)構(gòu)、電子相關(guān)的工作的確沒有從事過。但是我經(jīng)常處理一些棘手的“專業(yè)”之外的技術(shù)問題，很多問題還是多了幾個月解決不掉的。有幾位非技術(shù)背景的項目經(jīng)理就特別佩服我，對我說：“懂技術(shù)就是好，一通百通，什么結(jié)構(gòu)、電子的問題到你這都不是什么問題。” 我事后總結(jié)發(fā)現(xiàn)，其實我并沒有解決任何具體的技術(shù)問題，這些問題都是工程師解決的，我所做的就是，按照我的邏輯，讓工程師完成工作，試驗、反饋、修正，最終達成目標。
因為所解決的這些技術(shù)問題并非我專業(yè)特長，所以相對解決的問題而言，我就是非技術(shù)背景的項目經(jīng)理。我的方法對我有用，那么對其他非技術(shù)背景的項目經(jīng)理也一定有所幫助。那么該如何提升自己的技術(shù)素養(yǎng)，順利與各專業(yè)的工程師溝通，并解決問題呢？
首先，不能以自己非技術(shù)出身，就否定自己。
不懂技術(shù)的最大問題是，你無法和工程師交流和溝通。關(guān)于溝通我們都知道，你需要用對方能聽的懂的語言和對方溝通，才有可能達成有效的溝通。你不能苛求工程師能用你能聽得懂的語言和你溝通，如果是那樣的話，你除了贏得工程師的鄙視，什么也得不到。每個工程師的內(nèi)心，其實都很傲嬌的。
技術(shù)也好，管理也好，本質(zhì)上都是知識，能夠首尾相連，前后貫通的就是知識體系。知識體系都有一些共同的特點，掌握這些特點對于我們來講還是非常重要的。因為只有如此，你才會了解該學習哪些知識才是有意義的。
任何知識體系都是有層次的，這種體系不是上下關(guān)系，而是內(nèi)外關(guān)系，大致可以分為三層。
最里面的是核心概念，往往有一兩個核心的定義來支撐整個體系。掌握了這一層，你基本上可以用一兩句話把一種知識體系講清楚，但是你不一定能做出什么東西出來，甚至連數(shù)學公式未必能看得懂，但是別人會覺得你很高深，那么復雜的體系，兩句話搞定，不是一般人物。
第二層是由核心概念派生的邏輯原理層，有核心概念派生出一些術(shù)語，然后用邏輯把這些術(shù)語串聯(lián)起來就變成了原理。掌握了這一層，你基本上可以把這門知識的方法面都考慮到了，而且據(jù)此可以安排工作了，工作之間的相互關(guān)系和影響基本上了然于胸。在這個層次上，你基本上可以通過畫幾個方框（模塊）再加上幾根連線（邏輯）把該知識體系講清楚了。但是你不一定會計算，不一定能把東西做出來。但是掌握了這一層，你可以進行邏輯推理和思考，而且還能夠創(chuàng)新，很多創(chuàng)新是先要把原理邏輯想清楚，才能工程實踐做出來。先有概念，通過思維派生邏輯，邏輯清楚了再動手，方向就對了，最后才能做出來，即工程應用。
最外面一層是工程應用層，工程應用往往就會涉及到數(shù)學、工藝和流程步驟，也就是說你不一定懂原理，但是你照著做一定能做出來。現(xiàn)代社會知識爆炸，其實很多人只是掌握了工程應用的知識，對于原理未必清楚。
為了說明上述三層關(guān)系，我們舉個例子，牛頓力學定理。
核心層：是什么推動世界運動，是力，因此力是核心概念；
原理層：力有什么特性，牛頓三大定律；
工程應用層：加速度公式、萬有引力公式、沖量公式。
形而上謂之道，形而下謂之器。道是無形的，器是有形的。上面講的這三層，核心層是道、原理層是術(shù)、工程應用層是器。作為非技術(shù)出身的項目經(jīng)理，我們要掌握的是道和術(shù)的層次。這兩層次純粹是邏輯思維，而且一旦把這兩個層次掌握了，你就可以高屋建瓴的指導別人工作了，大部分工程師其實對原理層也不是很清楚，所以在進行邏輯PK的時候是占不到你什么便宜的。
其次，要注意學習方法，勤思考，多做思想實驗。
很多人特別喜歡讀書，讀完之后除了記住幾句聽起來很時髦、NB的話之外別的就沒有什么了，有時候書讀的越多越困惑。例如同樣一種情況有三十六種應對方法你該如何處理？你不可能把這三十六種方法記得滾瓜爛熟，即使你記住了，真碰到事情你還是不知道該如何應對，總不能把三十六種方法都試一遍吧。這種情況就是沒有掌握學習方法的緣故。我在讀書學習的過程中根據(jù)前人的經(jīng)驗和自己的摸索，總結(jié)出了一個模型，發(fā)現(xiàn)很好用，在這里分享給大家。
我稱這個模型為WWH模型，即What-Why-How模型。
第一先談What，這是讀書的過程種要做的事情，就是搞清楚這本書在講什么，這個“What”包括基本概念和基本邏輯。讀書的時候先不要懷疑作者的言論，先假設對方說的是合理的，此時的狀態(tài)是沒有不接受，也就是既不相信，也沒有不相信，且看作者做說什么，如何論證的。這個時候我會用作者的邏輯來試圖證明作者的觀點，如果發(fā)現(xiàn)作者邏輯能夠很好的證明其觀點，那么這本書是值得讀的。記住任何科學體系都必須滿足兩個特征，即自洽性（自己不能證明不了自己）和相容性（不能用自己的邏輯證明相互矛盾的結(jié)論）。
除了自洽性和相容性，好的知識體系應該一個核心的觀點，所有的派生的概念和邏輯最終都是為了證明這個核心的觀點。也就是我們以前上學的事后，老師讓我們總結(jié)的中心思想。如果一本書竟是一些觀點的羅列，作者自己沒有中心思想，這種書往往屬于毒雞湯，還是趁早扔掉的為好。
第二談Why，這是在讀過之后要做的事情。經(jīng)過What的過程之后，就書中一些關(guān)鍵的概念和邏輯提出“為什么”的問題。通過問自己為什么，可以把新學到的知識和自己既有的知識融會貫通。這其實就是在做歸一化的思想實驗。因為“為什么”之后還有更多的“為什么”，凡事都架不住多問幾個問什么。科學類的知識（無論自然科學還是社會科學）都是一家之言，也就是有其適用的特定條件，所有這些一家之言都是在說明世界的某一種真理的某一個方面，通過問問什么，可以把這些知識背后的知識挖掘出來，到最后往往就是一個適用性更廣泛的道理。那么也就實現(xiàn)了知識的歸一化，同時你對世界的認識也更加透徹，也就不需要記住三十六種處理方法了。
第三談一下How，所謂How，也就是知識如何應用的問題。作為以技術(shù)為職業(yè)的人來說就是把知識進行工程應用。而對于我們項目經(jīng)理來說，是不需要這么做的。我們這個時候要做的仍然是進行思想實驗，也就是結(jié)合工作和實踐來思考剛剛學到的知識應該如何應用。
記住，最關(guān)鍵的是要思考技術(shù)對于人的作用和影響，也就是該技術(shù)可以解決人的什么問題。知識是人創(chuàng)造和發(fā)現(xiàn)的，知識最終都是為人服務的。以人為中心來思考知識的應用，那么你看問題的層次就提高了，那么在論證技術(shù)方案的合理性的時候你就不會慌了。最重要的是，當工程師給出很多方案的時候，選擇合理方案就不會那么困難了。因為你已經(jīng)懂得了技術(shù)的價值是什么。
最后，不要試圖展現(xiàn)你比工程師更專業(yè)，而應展現(xiàn)你比他更有邏輯。
我認識的很多資深的非技術(shù)背景的項目經(jīng)理，自身的技術(shù)知識其實是很豐富的，邏輯思維能力也很強。但是往往還是無法和工程師處理好關(guān)系，其中非常重要的原因是：他們往往喜歡用工程師的專業(yè)知識來挑戰(zhàn)工程師的工作。并不是說發(fā)現(xiàn)工程師的問題不要指出，也不是說工程師耍技術(shù)權(quán)威的時候一味的放縱，而是要注意方式方法。要盡可能的用引導方式和問問題的方法，讓工程師自己的邏輯出現(xiàn)混亂，當他陷入困境的時候，你再出手，此時仍然以問問題的方式說“你看往這個方向是不是可行的？”，這個時候工程師對你是感激，而非不快。如果你太直接的指出對方技術(shù)上的問題，工程師往往面子上掛不住，反而不利于工作的開展。要知道，技術(shù)是工程師賴以獲得成就感的源泉，被你那么輕易戳破了，瞬間尊嚴會受到嚴重的挑戰(zhàn)。作為可以拯救銀河系的項目經(jīng)理，就不要跟工程師爭這個了。
還有當面臨錯綜復雜的跨專業(yè)技術(shù)問題時，清晰的技術(shù)邏輯和項目邏輯結(jié)合，會讓你更加淡定，能夠起到穩(wěn)定軍心的作用。這種表面時技術(shù)問題的項目問題，如果直接交給工程師來處理，往往處理不好，因為工程師往往只會看到他眼前的技術(shù)問題，跨專業(yè)的問題往往會被忽視，更不用提項目整體的問題了。這個時候，懂技術(shù)的項目經(jīng)理，運籌帷幄的能力才能真正解除項目的危機。
結(jié)束語
非技術(shù)背景的項目經(jīng)理不應該放棄對技術(shù)的學習，某種程度上你尤其需要把自己行業(yè)的知識體系掌握下來，這樣做的最大好處是讓你容易和技術(shù)人員溝通，而且讓你擁有了技術(shù)判斷能力。你需要掌握的是核心概念和原理，而非技術(shù)細節(jié)。知識的學習需要總結(jié)自己的方法，掌握方法才能快速有效的學習所需要的專業(yè)知識，通過思維實驗逐步實現(xiàn)知識體系的歸一化。
(本文于2017-02-02首次發(fā)布)
