深度長文:技術管理者應該管些什麼?

在講清楚技術管理者需要做哪些工作之前,我們通過一個駕馬車的比喻類比描述下。
在駕駛馬車之前,我們首先要看看馬車的定位是什麼(拉人?運貨?等);其次,要看看目的地在哪裏,該走哪條路,朝哪個方向行進;再次是當前馬匹的情況怎麼樣(滿員?傷病?等)。這些對應到管理中,就是得弄清楚團隊的基本職能、工作目標、團隊情況及可選路徑,它們代表這方向性的東西,可簡稱爲“管理規劃”。
當我們開始駕駛馬車時,至少需要做兩件事:一邊抓住馬繮,關照好馬的狀態和組織分工;一邊揮舞馬鞭,協調好整個馬隊的前進方向和節奏,讓馬匹一起用力把車拉到一個個里程碑和目的地,完成一段一段的旅程。前者對應到管理中,很像是在做人和組織相關的工作,我們稱爲“帶人”,或者“團隊建設”;後者對應到管理中,很像是在完成一個個項目或一項項任務,我們稱爲“做事”,或者叫“任務管理”。
綜合上面的比喻示例,可抽象概括下技術管理者需完成的工作如下,下面將展開說明。
(以下內容部分來自果見-劉建國系列文章)。
深度長文:技術管理者究竟應該管些什麼?
一、管理規劃:“敢問路在何方?”
管理規劃對於技術管理者來說,非常之重要。在日常工作中,技術管理者往往需面對大量紛繁複雜的事情,特別是有很多救火類的工作。但在忙亂之餘,是不是有一個“全盤規劃”的指引,清不清楚把團隊帶往何方,這纔是不同leader領導水平的差距所在。出現問題就解決問題,是一種“問題驅動型思維”。而今天我們所談論的"管理規劃",就是要回答"把團隊帶往何方"的這個方向性問題。通過理清未來的發展來理順當前問題的帶團隊思路,稱之爲“規劃驅動型思維”。
1、職能
在我們開始管理規劃之初,首先要弄清楚就是“這是一支揹負着什麼樣職責和使命的團隊”。在明確之後,才能決定了你需要設定什麼樣的工作目標,並通過哪些要素來衡量你的目標;決定了你需要什麼樣的人加入你的團隊,以及需要多少;還決定了你選擇什麼樣手段,投入什麼樣的資源來完成工作。這個問題是如此重要,可將其作爲管理規劃的第一個要素,稱之爲團隊“職能”;這是管理工作的起點。
1)職能層次
團隊職能可分爲兩個層次:基本的職責和昇華的使命。前者解決的是團隊生存問題,後者解決的是團隊發展問題。
職責。是團隊職能的下限,即至少要完成的工作。如果這些職責都搞不定,意味着團隊的基本價值都不能體現。一般來說,團隊的基本職責,是由上級給定的,上級在把這個團隊交給你負責的時候,已經給你提了期待,只不過有的上級會明確交代,而有的上級默認你很清楚。所以,你無論如何都需要弄清楚團隊的基本職責,否則肯定會失職。
使命。是團隊職能的上限,即,如果我們團隊做得好,就能承擔更大的職責,體現出更大的價值。使命達成後的願景,常常是令人期待和憧憬的。使命願景常常是團隊leader自己的規劃和設想。上級一般不會作出這樣的要求,最多就是提一下期待,團隊做不到也不會認爲是團隊失職。
2)設定職能方法
①收集信息。可從多角度收集方方面面的信息,包括上級、同級和下級。對上級而言,需關注上級對團隊的期待和要求,特別是用什麼維度來衡量團隊工作。團隊的初始定位和基本職責,一般都是上級直接給定的。同級,則需關注與兄弟部門的職能邊界,做好無縫銜接、共同發展。下級則可與大家討論對團隊工作的看法,以及對未來發展的期待。這也可爲後續的溝通做好鋪墊。當然最爲重要的是管理者本身對工作的理解、期許。
②提煉和昇華。團隊的職責和使命,不能只停留在leader的腦海中,爲了方便記憶和傳播,則必須從上述信息中進行提煉和昇華。提煉和昇華有三個要點:
職責的提煉。基於上級的期待和要求,以及你對業務核心價值的理解,最好用上級和團隊成員、兄弟部門都易於理解的語言,對職責進行簡短化提煉,並儘可能長時間穩定下來。
使命的昇華。基於基本職責,尋找團隊對於部門和公司的獨特價值,並和行業發展趨勢結合,設定自己的期待。要注意使用基於“結果”的描述,而非基於“過程”的描述,基於結果的描述會更有使命感。
確定衡量維度。一般來說,團隊的職責和使命決定了衡量的維度,但是如果有明確的關於衡量維度的說法,會讓員工對職責和使命有更深刻的理解。需要根據自己團隊的職能,向員工明確傳遞,什麼指標維度對團隊是最重要的。
③確認和主張。提煉完成之後,接下來就是確認和主張。確認主要是和自己的上級確認,得到上級的認同和支持後,就可以向團隊內外進行主張了。主張的過程,就是一個長期宣貫的過程,不可能一蹴而就。這也是團隊的文化建設的重要組成部分。
2、目標
在明確了團隊職能後,下一步就是確定目標。類別前面的比喻,就是需要明確要去的目的地在哪裏,才能評估需要什麼樣的馬、多少匹,以及有哪些路線可以選擇。這個關於"目的地在哪裏"的問題,是管理規劃的第二個要素,稱爲“目標”。
1)設定目標意義
問題明確的目標,對於技術團隊管理非常具有意義。
目標設定,可以實現資源的有效配置。明確的目標可以讓你把資源投注在有效的方向上,從“該做什麼”去調配資源,而不是“能幹什麼”。
清晰明確的目標可以凝聚團隊成員的力量,讓大家勁往一處使,提升團隊凝聚力。大家因爲相同的目標而並肩作戰,在一起取得成就的過程中建立起深厚的“革命友情”,這對凝聚力有莫大幫助。
清晰的目標,還是執行力的必要要素。回想一下,有多少工作是因爲目標不夠清晰,而最終有始無終。
清晰的目標還能提升判斷力。當面對某個突發狀況快速決策,你非常清晰想要的是什麼。
清晰的目標本身就是激勵,當員工很清楚自己的工作目標,方向感很清晰的時候,他們更容易進入一種投入度非常高,沉浸其中、物我兩忘的工作狀態。
2)目標設定原則
目標的設定,可遵從SMART原則。
Specific - 明確性。把目標設定到可以衡量的程度,就叫做明確了。常見的誤區是,只做過程化描述,而沒有結果。因此,面對這類問題和挑戰的鑰匙叫做“結果導向的描述”。
Measurable - 可衡量性。跟明確性緊密相關。在具體實施上,可參考有量化指標的KPI,或者目標導向的OKR形式。
Attainable - 可達性。標準上,不能定一個完全實現不了的很高的目標,也不能定一個不需要努力就能實現的很低的目標。定義一個有挑戰且努力能達到的目標,纔是恰當的。
Relevant - 相關性。對於技術團隊來說很難跑偏,因爲技術這個角色決定了其工作內容必定是和上、下游及上級目標相關聯的。
Time-bound - 時限性。所有的目標都是基於一定時限的,缺少時間限制的目標沒有意義。
誤區:以資源定目標
常見的一類問題是基於現有資源做目標,而不是基於遠方的目標往前推。常見的說法就是,“我們團隊只能做到個程度”、“這些項目能做完就不錯了”等。其實,更爲合理的做法是,從上級的角度來講,你的團隊需要保證哪幾項重要的結果,然後再看看如何調配和補充資源。簡言之,破解之道就是“以終爲始”。
誤區:目標變來變去
定義的目標,有時不得不面臨一些調整。有些是因爲業務的原因,有些是因爲上級領導變更的緣故等等。應對此類問題的方法就是“設定專業目標”,用專業目標來增強團隊的內在定力。簡言之,就是“做正確的事”。
誤區:事情太多忙不過來
這是一個優先級的問題,可遵循“重要/緊急象限法”進行分析。具體可參考下圖,原則就是將“重要緊急”轉換爲“重要不緊急”,儘量減少“不重要緊急”類工作;以上措施就可以減少上述問題。
深度長文:技術管理者究竟應該管些什麼?
3、團隊
針對團隊,可以從多個視角來看待。
1)根據團隊目標去梳理團隊
作爲管理規劃的一部分,團隊規劃是管理者必須重點考量問題。這裏需要去設定”團隊目標”,即在某個時間點,團隊發展成什麼狀態。有如下衡量指標:
團隊的規模。也就是你團隊有多少人,這其中要理清楚有多少人是現有的,有多少人是接下來要新增的,即實際人數和預算人數,加起來就是你規劃的團隊總規模。
團隊的分工。即,你的團隊都負責哪些業務,每個業務配置了多少人力,以及這些人員都如何分工,人力分佈和業務目標是否匹配等。
團隊的梯隊。一個團隊的梯隊情況代表了團隊的成熟度和復原力。梯隊成熟的團隊,不會因爲一些偶然的因素(例如核心人員離職)就隨便垮掉。復原力強的團隊只是短暫影響部分業務進展,但是不會傷筋動骨、元氣大傷,很快就會恢復正常。
2)從資源角度來審視團隊
在很多互聯網公司裏,技術團隊往往是最昂貴的資源和成本。作爲一個管理者,在盤點自己當前人力和預算人力的時候,需要有成本意識,要考慮投入這麼多資源和成本是否值得,是否合理。其實,即便你不考慮這個問題,你的上級也會考慮,所以,你預算人力的時候,最好能給出十分充分的理由。
3)從人才培養角度看梯隊規劃
對團隊的盤點,還需要從人才培養角度來看。即,到下一個時間節點,你需要重點培養出哪些人,給他們什麼樣的平臺和空間,以及你有能力提供給他們什麼指導和支持,期待他們能夠勝任什麼職能和角色。
4、路徑
在選擇路徑之前,需先考慮一個重要因素-資源。脫離資源評估的路徑選擇是沒有意義的。
1)資源評估
這裏所提到的資源,不僅僅包括通常意義上的“人、才、物”,還包括其他一些容易忽略的因素。
人。最爲常見的資源,爲參與到項目的人員。
財/物。一般也是圍繞着團隊的人員來說的。
時間。最容易忽視的一類資源,時間長短直接影響人的投入。這裏需要參考上級的預期,及你個人的客觀分析,需要綜合你對緊急重要程度的理解做出判斷。
信息。是另外一個常被忽視的資源。有的時候,你需要更多的公司內外的信息,你的工作如果需要特殊的信息和數據,需要提前和上級溝通,尋求必要的支持。
權限。是否需要獲得某些權限,作爲資源投入。比如獲得績效評估的權限,以此來掌握人員激勵的手段等。
2)路徑評估
站在管理者視角上,就需要評估一段時間內的產出效率。完成一項工作,原來還有很多的手段可以選擇。對於你來說,不同的方案意味着着多大程度的成本呢,可以嘗試使用如下評估表。把你認爲的“大”“中”“小”填入下表中。這個表格最大的意義不在於讓你去評估每一種方案的成本大小,而在於擴展你的管理思路,看到解決問題手段的多樣性,避免思路過於單一,就達到目的了。在不同的公司、不同的期待之下,不同的管理者會做出不同的選擇。這不同的選擇會帶來不同的效果,同時也意味着不同的成本。
深度長文:技術管理者究竟應該管些什麼?
對於自研來說,由於靠自己團隊的力量,資金開銷比較低,維護成本也可控;而由於需要邊學邊做,時間成本會比較高。
對於招聘來說,不確定性比較高,招聘順利固然好,但招聘不順則時間完全不可預期,整體上時間成本比較高。
對於借調來說,如果能借調到合適的人,各方面的成本是最低的,但是需要這個事情足夠重要才能獲得支持。
對於跨部門合作來說,項目推進的可控性取決於合作情況,這裏最大的風險就是合作成本能否控制住。
對於外包來說,時間和資金成本一般都可控,用來做嘗試性項目或者demo是比較合理的。但如果是長期的任務,你會發現外包的解決方案可維護性比較差,遷移和替換的成本會比較高。
採購雲服務,對於中小公司來說,其實是很好的解決方案,對人才成本、維護成本、時間成本,都可以降得很低,特別適合初創公司,所以你看業內的雲服務層出不窮,確實有價值。
商業方案,是時間成本很低,資金成本略高的一種方案。在應急的情況下,或者是公司非核心業務的場景下,這倒不失爲一種好的解決方案。
二、團隊建設:“衆人拾柴火焰高”
團隊建設的核心,在於提高“效率”。參照之前的”工作目標達成分解圖”,可將其劃分爲個體、個體間和團隊三個層次。
深度長文:技術管理者究竟應該管些什麼?
針對個體而言,重點在於提升能力和個人意願。
針對個體間而言,在於加強分工和協作。
針對團隊,在於構建梯隊和文化認同。
1、能力
1)能力分層
員工的工作能力是由三個方面共同決定的,下圖可見。
深度長文:技術管理者究竟應該管些什麼?
人格力量。通常是指一個人在面對某一情形時穩定的態度和表現,比如迎難而上、堅持不懈、積極正向、主動擔當等等。這些人格力量對於個人能否搞定一件事情有時至關重要,但是培養起來卻不是一朝一夕的,關鍵在於平時。
通用能力。沒有一個統一的標準,比如我會把溝通表達能力、團隊協作能力、快速學習能力等作爲重要的通用能力,並和我的團隊達成共識。這些能力是可以遷移的,會伴隨員工受益終身。
專業能力。對於技術人來說,一般是指技術能力。很多公司都有技術能力衡量標準和體系,用於評估工程師的技術水平。所以,工程師專業能力的評價維度和標準相對於通用能力更加有據可循。
2)鼓勵學習
可以組織多種形式,鼓勵員工學習。
第一類:幫助員工自學。可組織內外部培訓、購買書籍等形式。
第二類:相互交流討論。可通過定期覆盤、技術交流、代碼審覈等手段進行。
第三類:工作實踐。給員工獨立負責重要工作的機會,並給予輔導和反饋。
對於提升員工個人能力來說,最關鍵的往往不是學習的方法,而是學習的意願。對於很多團隊來說,並不缺少學習的機制,而是沒有能夠有效激發員工的學習動力。主動學習的員工總會是少數派,不只是公司的員工如此,社會生活中的人們亦是如此,所以有人說,“學習是反人性的事情!”。可通過下面多種手段,激發很多員工的學習動力了,你甚至可以把學習和成長放入團隊文化建設當中。當然,如果你要把學習作爲團隊文化的一部分,那就需要你自己首先有學習的“基因”。
推 - 給予壓力,推動他們學。比如提出明確的學習機制、工作要求,必要時與績效、晉升機會、調薪掛鉤。
拉 - 指明方向,引導他們學。通過樹立榜樣、配備導師、輔導方式,引導大家學習。
放 - 給予空間,讓他們自主學。在可控情況下,給予員工空間、機會及耐心,讓員工充分施展。
2、激勵
1)理論 - 馬斯洛的需求層次模型
深度長文:技術管理者究竟應該管些什麼?
最原始的驅動力主要來源於對生存和安全的渴望,需求層次處於“馬斯洛需求模型”的最底層。這類驅動力是人們爲了尋求生存下去的基本要素而努力。
第二類驅動,就是“獎勵好的行爲、懲罰壞的行爲”,也就是人們經常唸叨的“胡蘿蔔加大棒”。這是被廣泛認同的激勵方式,也是當前大部分管理者最常用的激勵手段。
第三類驅動,更加強調自驅力。隨着中國經濟和文化發展,物質獎懲和別人的評價變得不如從前那麼令人關注。很多 90 後職場人有着自己篤定的價值觀。此外,在這樣一個信息時代,員工的創造力更能爲公司創造價值,而創造力需要更多的自主和差異。
2)如何激勵
第一,激勵要立體。你需要從單一的激勵維度,升級爲更加立體的激勵體系,從而適應新職場環境的要求。
第二,激勵在平時。不能指望一些臨時性刺激方案來做好激勵,激勵體系的搭建應在平時。當員工跟你提離職的時候,它就已經不再是一個激勵問題了。
第三,激勵要設計。由於每個人的業務特點不同、團隊性質不同、管理風格不同、員工特徵不同、問題挑戰不同,所以不要迷信別人給你的激勵建議,我更建議你充分考慮自己面臨的實際情況,結合自己的特質和激勵框架,來設計適用於自己的激勵體系。
3、分工
不能簡單地認爲分工一定是件好事。分工是不是好事取決於協作水平,協作水平又受限於管理者的管理水平。通常分工的目的是爲了實現規模化(多人幹大事)或實現專業化分工(用人之長、避人之短)。
組織結構
從一個業務所涉及的各個角色的分工情況來看,互聯網領域最常見的組織結構有兩類,一類是矩陣式的,一類是BU式的。
矩陣式結構。員工按照角色被劃分到不同的團隊,每個團隊都有自己的負責人。要做項目的時候,會有專門的項目經理來向各個角色的leader協調人力,然後把申請到的各個角色的人組織在一起去完成這個特定項目。一旦項目完成之後,人員將回歸各自團隊去迎接新的項目。人力資源是按照角色“橫向”來組織的,而項目執行是按照任務“縱向”來推動的,就形成了一個縱橫交錯的矩陣式結構,所以叫矩陣式組織結構。這類組織架構的好處是各個角色團隊的專業度都會很高,而且角色歸屬感比較強,資源調配靈活;但不足之處是項目執行起來較爲低效,因爲每次都要重新申請人力,而且每次的項目團隊都需要重新磨合。
BU式結構。就是“業務單元”式,也叫事業部制,是指做某項業務所有的人員和資源都統一調配,無論這個事業部是大是小,都角色齊全。這樣做的好處是團隊長期合作磨合充分,協作效率高,執行速度快;不足是各種角色自己都要有,資源冗餘和浪費比較多。另外,由於某些角色不在業務主幹上,團隊規模比較小,能力要求也不高,所以其角色專業度很難提升。
4、協作
“就是隻要一句話,甚至是一個動作、一個眼神,對方就知道是什麼意思。”顯然,協作水平很高的團隊,就好像一部良好運轉的機器一樣,既有分工,又彼此緊密連接,形成一個有機整體。其核心在於:
一是建立協作機制,通過機制來約定協作的動作,以此來保證大家“動作協調”;
二是提升團隊凝聚力,通過提升團隊成員間的信任度、認同度和默契度來降低協作成本,提高協作效率。
可以說,“硬件”靠機制,而“軟件”靠凝聚力。
1)提升凝聚力
設立共同願景。想提升團隊凝聚力的時候,總是希望大家“心往一處想,勁往一處使。這就要求團隊首先要有一個使命和願景,有一個共同的長遠目標,供大家“往一處想”。如果團隊有着自己的使命,又能得到團隊成員的普遍認同,大家會更容易朝着一個方向共同努力,也更容易肩並肩地一起迎接挑戰,即所謂的“志同道合”。
提升員工歸屬,讓員工從心裏就認爲自己是團隊的一份子。你要分給他一份職責,人的內心深處是渴望承擔適當的責任的。有當員工清楚自己能爲團隊做出什麼貢獻的時候,纔會心安,纔會感受到自己是團隊的一份子。要讓員工清楚他肩負的職責對於團隊的意義,讓他覺得自己做的事有價值,這就是所謂的“事對”。
要營造良好的團隊人際關係,讓彼此間形成緊密的連接。團隊成員間良好的關係,和團隊凝聚力的提升是互爲因果的,所以不要小看能促進員工間關係的一些小事,恰恰是這些小事,能夠促使員工間的合作關係走上正向循環的軌道,員工會因爲喜歡和團隊的人相處而覺得有歸屬感。這就是所謂的“人對”。
明確亮出團隊的文化價值觀。團隊的文化和價值觀是否是員工認同和欣賞的,決定了他能否長期留在團隊。價值觀方面的衝突是很難調和的,好的團隊文化本身就是一個篩選器,最終留在團隊發揮核心作用的都會是認同團隊價值觀的人。因喜歡一個團隊的文化和氛圍而產生歸屬感,這就是所謂的“味對”。
加強相互瞭解。團隊成員間需要不斷深入地相互瞭解和認同。可以通過一些方式增加員工間瞭解,例如團建活動。這裏是需要花點心思去設計的,對增進大家的瞭解和信任做必要的設計。
共同面對挑戰。一起面對挑戰的時候,特別能夠讓大家擰成一股繩。顯然一起扛過槍的兄弟,感情是很鐵的,畢竟是經歷過不離不棄的並肩作戰。可以通過攻關項目、緊急故障等,甚至是一些組隊的對抗性遊戲,都可以得到提升。
5、梯隊
一個團隊的梯隊,就好像一個團隊的“骨架子”,這“骨架子”是否健康良好,決定了團隊是否健壯。其重點在於梯隊的規劃和建設方面。規劃在前文已談到,建設就是需要選撥人,並培養成核心骨幹的過程。
1)選拔人才
對骨幹人員的選擇要遵從你團隊建設的理念。除了基本的個體能力要強,有成長潛質之外。更重要的是強調其協作能力,因爲這些骨幹未來不是一個人工作,而是要帶領團隊的。要強調其行爲風格和價值觀與團隊整體文化相匹配。例如團隊強調“勇於創新”,那麼一個墨守成規的人員顯然不適合成爲骨幹去培養。
2)培養人才
對齊期待,達成共識。常用方式是IDP,即個人發展計劃。可以將IDP與績效結合起來,就是說培養人才也是要以做出績效爲依託,而不只是爲了培養而培養。通過IDP可以對齊你和培養對象彼此的期待,讓他清楚你關注的是什麼,在這個事情上形成共識,從而形成良好的互動和有效的反饋。但在這過程中需要注意,不要以晉升等作爲承諾。一方面,晉升等是需要靠員工表現來獲得,而不是靠承諾;另一方面也要留有培養失敗的退路,避免不必要的人才流失。
提供機會,做好授權。培養的過程是需要在做事上體現的,你需要給培養對象足夠的發揮空間,也就不可避免地要做工作授權。
工作授權三段法
深度長文:技術管理者究竟應該管些什麼?
授權整個過程可劃分爲事前、事中、事後三個階段。其重點在於事前的安排和事後的反饋。因爲既然是授權,事中最好不要干涉太多,只做約定好的check和支持就好。
事前階段。管理者首先要明確此次授權的初衷是什麼。如果是有多重目標,那麼主次關係如何。進而讓培養對象明確你的期待是什麼。此處可沿用目標管理的SMART原則,雙方需要明確要求、口徑等。在完成授權任務後,需聽取其對工作的看法和思路,進而大致判斷是否可行,規避風險。最後約定一個溝通機制,爲事中做鋪墊。
事中階段。需要管理者定期瞭解工作進度、評估風險,必要時給予支持,而不是放任自流。在支持方面可遵循“授人以漁”的原則。
事後階段。對於授權後的工作結果進行評估,並與培養對象充分溝通反饋。注意你的授權目標本身不僅僅只有事情,還有培養目標的。對於培養對象在工作中好的表現,要給予充分肯定,特別是要其優勢所在;針對不足之處提供1~2條修改建議,以利後續改進。
6、文化
團隊文化就好像是團隊的氣質和調性,它會吸引“氣味相投”的人持續加入,而把不符合團隊氣質的人篩選出去,越來越鮮明的團隊價值觀讓大家緊密地聚攏在一起,從而讓團隊越來越“結實”,越來越“經得起折騰”,不斷增強團隊的耐力和韌勁。關於團隊文化部分,我之前有文章專門說明,這裏就不展開了。
三、任務管理:“不以規矩,不成方圓”
我們研究任務管理,就是爲了把事情做出來,產出實實在在的業績和成果。作爲結果導向的管理者,這纔是管理工作的落腳點。同時,也是驗證管理規劃是否合理、團隊建設是否有效的最重要的標準和依據。對任務執行,可劃分爲三個階段:
在做事之前,我們需要回答的問題是:要做哪些事?先做哪件,後做哪件?也就是分清楚輕重緩急,也叫優先級梳理。
在做事過程中,我們要確保事情的進展按照計劃推進,盡在掌握之中,也就是有效執行。
在做事之後,我們要覆盤做事的整個過程,並從過去的經驗之中抽取一些流程機制,以便以後在類似的場景下也可以做得更好、更順暢。
1、輕重緩急
對於每個團隊來說,當下能做的工作是有限的,增加併發並不會讓大家的產出更高效,所以,多任務並行問題歸根結底還是優先級問題,即,你要優先保證哪項工作的順利進行。
1)重要緊急四象限
深度長文:技術管理者究竟應該管些什麼?
2)判斷標準
如果做,收益是否很大?收益越大,這個事情就越重要。
如果不做,損失是否很大?損失越大,這個事情就越緊急。
3)應對策略
對於“計劃內的工作”,關注它在一個規劃週期內的價值和收益有多大。收益越大就越重要,也就越需要給予相匹配的優先級、資源和關注度;收益相對不大,就放入“To do list”,作爲待辦任務處理。
對於“計劃外的工作”,看損失是否足夠大,這裏包括自身損失和因中斷正常工作帶來的損失。損失夠大,就按照緊急任務安排,以止損爲核心目的;如果損失可控,就放入“計劃內工作”列表。
4)持續改進
原則上,管理者的中心應該在那些“重要不緊急”的工作上,這些是對團隊長期受益的,應該作爲主要目標。
“重要且緊急”的工作,要分析其緊急原因,將其流程化、自動化,逐步過渡到不緊急的狀態。
“不重要緊急”的工作,往往是事務類的,可交由下屬處理,長期可通過自動化改進其緊急狀態。
“不重要不緊急”的工作,要反思其價值,是否仍然作爲核心工作之一。
2、有效執行
在項目執行中,是否能有效執行,取決於多個因素。
深度長文:技術管理者究竟應該管些什麼?
目標清晰。在執行之初,就需要對目標有明確且具體的定義,具體到可執行層面;而且要確保上下級對其理解是一致,沒有偏差。當目標出現變化時,要做到及時同步。如果目標不清晰,必然會引起員工在緊急程度、質量水平和效果取捨上的偏差,最後也就引發了執行上的偏離預期。
責任明確。明確工作的“唯一”負責人,避免出現無人負責、多人負責等情況。負責人要起到對應的責任,有關項目中所有涉及項目執行和協調的問題都要負責。
機制健全。不要沉迷於依靠個人完成項目,需要有完善的流程和機制,讓員工做事有依據。同時對應還需要必要的監督機制,不要將“流程機制”束之高閣。
溝通到位。在執行中,強調主動溝通意識,要做到溝通閉環,而不要想當然。
3、流程機制
在任務執行之後,針對任務中可抽象出來的部分,可制訂必要的流程機制。在指定過程中,可明確幾個原則:明確目標、責任到人、檢查複覈、降低成本、全員共識。避免出現爲了流程而制定流程的情況,要做到儘量簡化,能解決具體問題。
觀點:人靠譜 OR 機制靠譜?
人的靠譜度的方差比機制大,即,人靠譜的時候比機制靠譜,人不靠譜的時候會比機制更加不靠譜。即便是最靠譜的員工,也會由於身體狀態、精神狀態、情緒狀態以及外部干擾變得偶爾不靠譜;而機制的意義就在於,當人不靠譜時,事情也不至於變得很差。所以,機制是爲了保證做事的“下限”的。同時,機制有很好的遷移性和傳承性,不會隨着某個人的缺位而產生大的影響。因此,必要的機制是不可或缺的。
番外篇:“如何做好技術判斷?”
作爲技術管理者,和普通管理者最大的區別,就是"技術"二字,這也是技術管理者最鮮明的標籤和最大的競爭力。從技術工程師到技術管理者的轉型,有很多做事的思路和方法都需要轉變,其中一個重要的轉變就是你和技術的關係。其核心在於從技術實現者到技術應用者的轉變,不斷提升的是技術的使用能力,而技術實現能力由於投入的時間越來越少,會逐漸減弱。從技術管理者自身來說,既然你選擇了做更大的事情,就不得不適當放棄一些細節,放棄一些技術實現能力,不斷提升你的技術判斷力,讓團隊行走在正確的方向上。
1、角色轉換
技術管理者,對待技術與技術人員會有所區別,是有個角色的轉換。
技術實現者:程序設計能力、編碼實現能力、技術攻堅能力和技術評估能力,都是需要具備的,主要關心的是"怎麼做",屬於"how"的範疇。
技術應用者:技術評估能力變得尤其重要,因爲技術管理者主要關心的是"要不要做"、"做什麼",屬於"why"和"what"的範疇,是要在綜合評估之後,做出決策和判斷的
2、評估維度
1)結果評估
要回答"要不要做",希望拿到什麼結果,你要從哪幾個維度去衡量結果,從哪幾個技術指標去驗收成果。事關每項工作的效果和業績,對結果的評估能力最爲關鍵。雖然結果驗收都是放在項目完成後,但是在事先就要明確如何驗收,這樣才能讓大家有的放矢,以終爲始。
2)可行性評估
可行性有兩層含義:一是"能不能做",二是"值不值得"。作爲技術管理者需要做好角色轉換,更多從"值不值得"着手,就是成本收益問題。收益,往往是顯而易見的;而成本,就有很多方面需要考慮了,這正是體現技術判斷力的地方。
資源成本 — "人財物時"。需要投入多少人、多少時間,甚至是多少資金和物資在該項目上,這項成本相對容易評估。
維護成本。這是評估技術方案時要重點考慮的。考慮維護成本是技術管理者和架構師視野寬闊、能力成熟的體現。這裏麪包括:技術選型成本、升級成本、問題排查成本、代碼維護成本等。
協作成本。多人協作所增加的時間精力開銷。一個方案的協作方越多,需要溝通協調的成本也就越高,可控度越低。如果可能的話,儘量減少不同團隊和人員之間的耦合,這樣會大大降低協作成本。
機會成本。這是技術管理者做決策時要意識到的。即當你把人力、時間花在這件事上,同時就等於放棄了另外一件事,而沒有做另外這件事將帶來什麼樣的影響呢?就是你要考慮的機會成本。
3)技術風險評估
也叫技術風險判斷力。即,有哪些技術風險需要未雨綢繆,考慮該技術方案帶來最大損失的可能性和邊界,以及在什麼情形下會發生。這項評估工作很考驗技術管理者的技術經驗和風險意識,而且需要藉助全團隊的技術力量來做出準確判斷。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章