程式設計師如何提升管理思維，從個人到團隊的轉變？

所謂權力越大責任越大，要想成為一個合格的專案管理人員，我認為最重要的首先是扭轉自己的思想。

正如老子說的“道為體，術為用。”我們的思維模式改變了，各種管理的方法和工具自然的就會去學習使用了。

正所謂“有道者術能長久，無道者術必落空。”所以在本文中，我就和大家聊一聊管理中的“道”，我們程式設計師如何修煉管理思維？我們要先懂得道理，再去學怎麼做。

你不是一個人在戰鬥

很多兄弟剛轉型管理的時候，更多的關注事，而不是關注人。不斷的把任務分派下去，到點驗收，期待得到一個好的結果。

遇到任務出問題，馬上跳出去指責。“你為什麼又沒完成！”，“怎麼這點東西都做不好！”。

這樣只能導致一遍又一遍的出問題。你想想，你可能是因為業務精湛才被提拔為專案經理，其他同事業務上沒有你那麼嫻熟，無可厚非。

而任務分派下去以後，你是否需要和同事聊聊難點，說說你的想法，有問題給予一些簡單的指導。

出問題的時候，首先應該引導而不是指責。

有的兄弟剛轉型管理的時候，一旦遇到同事完不成的任務，遇到的難點，馬上跳上去三下五除二一頓敲，解決問題後，不留下一片雲彩，揮袖而去。

這些兄弟總會替代同事做他們自己本應該做的事情導致同事得不到成長，而自己則搞的很疲憊。

我想有一點我們需要明白：專案經理是團隊中的指戰員，掌控著整個團隊前進的方向和打法。你不是一個人在戰鬥，你的行為影響著整個團隊的戰鬥力。

作為程式設計師，我們習慣了單兵作戰，不斷的鑽研打磨自己的技術，就能高效的完成任務，提高戰鬥力。而專案經理，是需要指揮一群人，去打贏一場又一場的戰鬥。

所以我想說的是：

• 你要給予團隊裡的同事包容，給予引導而不是指責。

• 給予每個人鍛鍊的機會。事無鉅細的幫助或者親手操刀，只會毀了團隊。

• 誇張點說，你決定了整個團隊的戰鬥力，請為同事負責也為自己負責。

• 培養人是你的職責，團隊的進步才是真的進步。

並行工作可以拯救你，也可以毀了你

做了管理以後，你會發現自己被各種事情同時纏身。你不僅僅要處理技術那點事了，你可能同時在處理多件事情。

你要維繫干係人、要做任務 WBS（工作分解結構）、要溝通需求、要專案演示、要協調團隊關係、要處理各種緊急情況、甚至於要填報材料、要寫合同、要解決客戶亂七八糟的問題等等。

總之剛開始的時候你會發現，你事情多的做不完，被各種事情纏的脫不開身。但這又是你的工作職責，必須要去處理。

我們程式設計師最擅長的就是抽絲剝繭，把一個複雜的需求逐漸理清，結構化後編寫成程式碼。同樣的，你也需要在這些紛亂的任務中抽絲剝繭，有章有法的去處理開來。

這些事情如果處理不好，你會發現自己一直處於忙碌之中，而不知道自己到底在忙些什麼。

長此以往，你會對自己失去信心，專案也會一塌糊塗。但從另一個角度來說，如果你能有條有理把這些雜亂的任務整理清楚，你一定會有質的飛越。

所以我想說的是：

• 擁抱混亂，但別陷入其中。

• 這是展示你真正技術的時刻，如何做好個人時間管理，是你最重要的一課。

碼程式碼很重要，但其他事情也同樣重要

我們程式設計師總認為：碼程式碼才是正事，其他事情都是扯淡。但你別忘了，你肯定也經歷過需求改來改去導致的痛苦、設計稿一改再改帶來的重複勞動、沒有設計就開發導致的各種問題。

既然我們身為程式設計師的時候，已經經歷過這些苦楚，那為什麼要讓我們的同事再經受一遍呢？

所以，請重視專案前期的階段。去搞定干係人、去敲定需求、去定稿設計、去指導程式碼設計。這些工作完成的越好，開發過程越順利，專案進度越有保障。

身為專案經理，你需要額外做很多事情，保障專案的進度。很多事情等到開發階段再介入，你會發現為時已晚。莫要坑了同事也坑了自己。

所以我想說的是：

• 先設計後開發。

• 防範於未然的能力，比救火能力更重要。

不斷挖掘，發現本質

我們程式設計師啊，總是亦或者是習慣了別人說什麼，我就做什麼。但其實我們也應該多問問為什麼。

而專案經理我認為需要有透過表象發現本質的能力：

需求來臨的時候，你能否透過現有的需求發現客戶更深層次的需要？

某同事任務完不成的時候，你能否透過日常點滴發現他完不成的原因？

測試團隊和開發團隊起衝突的時候，你是否能透過日常的交流發現矛盾的根源？

團隊士氣低落的時候，你能否透過大家的表現悉知團隊狀態低落的問題所在？

首先，要想做到一步到位透過表象發現本質我認為是很難的，需要大量的鍛鍊。

但我認為我們保持一顆好奇之心，就能把問題的本質掌握的八九不離十。不斷給提出問題，同時去挖掘問題的答案。

舉個例子：

客戶：“我想造一架飛機。”

專案經理：“您為什麼想造一架飛機呢？造完飛機還需要建飛機場才能飛呢。您是要去什麼地方嗎？”

客戶：“我是想去西班牙，覺得有架飛機比較方便。”

專案經理：“您去西班牙做什麼呢？是旅遊嗎？去西班牙的話，可以搭乘現有航班和渡輪也可以。”

客戶：“我這不是想去巴薩羅那看看比賽嗎。”

專案經理：“我們中央五臺不是有直播嗎，也可以看的。去巴薩羅那成本比較高。”

客戶：“我覺得去現場看比較有氣氛，這點成本我能負擔。”

專案經理：“好的，那我們搭乘國際航班去可以吧？”

客戶：“好的，沒問題。”

以上，客戶的最根本需求是要到巴薩羅那現場去看球賽。而他的想法大概是要過去得有飛機，所以提出了造飛機的需求。

而專案經理在不斷的交談過程中，一次次的給出新方案，以探尋客戶最需要的東西和摸索客戶的想法（例子中為價效比和體驗，客戶更想要體驗）。

假設交談過程中發現客戶就是想要造架飛機，你也要告訴他飛機造出來了還要建飛機場。讓他權衡成本是否可以接受。

不要飛機造出來了沒地方起飛，這不光是客戶的問題，是你沒給客戶提供完整的方案。這就叫做發現本質。

以人為中心，而不是機器

我們程式設計師天天和機器打交道，習慣了非 0 即 1 的二進位制生活。

但專案經理是需要和人溝通的，與人打交道。所以面對我們的同事，面對整個團隊。應該多考慮人，以人為中心。

所以我想說的是：

-減少應激反應，多聽取別人的說法，不要急於反駁。

-保持同理心，多從同事的角度想想，出錯前做好預防工作。

-不要輕易給同事下結論，貼標籤。人都是會改變的，這次不行不代表下次也不行。

-不能為兄弟們擋刀並引領兄弟們前進的老大是不值得追隨的，弟兄們在你手下做事受盡委屈，爭不了一口氣，那這個老大也做不長。

放棄完美，是走向完美的路

我相信大多數程式設計師都有個毛病，追求完美。程式碼格式要最舒服，程式碼邏輯要最簡潔，細節一摳再摳。就像強迫症一樣，追求自己程式碼的完美。作為程式設計師來說，這是一個非常棒的習慣。

但作為專案經理來說，我們最需要的是平衡。一味的追求完美，會導致專案成員壓力大增，成本不可控制。

作為專案經理來說，我們都希望自己帶的專案細節無可挑剔，功能一應俱全，程式碼質量無懈可擊，團隊氛圍融洽得體，專案質量高的無以復加，專案週期如約達成。

但其實專案裡，所有事情都是互相平衡的。工期和細節打磨之間的平衡、成本與需求開發的平衡、批評與讚揚之間的平衡等等。

平衡是一方面，另一方面是迭代。保持迭代，一步一個腳印的把專案逐步推進。

所以我想說的是：

-把握平衡的尺度，是專案逐步趨於完美的路。

-不要追求一步到位，完美是迭代出來的。

少寫程式碼可以，脫離技術不行

以上都是針對專案管理說的，而這最後一條，是為了引起各位的警惕。

我們上面說會有很多瑣事纏身，可能導致你幾乎沒有寫程式碼的時間了。這是正常的也是正確的，你的工作不是去當機槍-手，你的工作是指揮大家戰鬥。

但這就代表我們要脫離技術了嗎？我認為不是這樣的。我們可以少寫程式碼，但我們不能拋棄技術。

我有個朋友告訴我說：不要過早涉足“純管理崗位”。我想他的意思，就是告訴我技術乃是一個軟體開發的專案經理安身立命的根本。

我們程式設計師做專案管理，最大的好處就是，不會出現外行指導內行的情況。所以我們即便轉型了，也要時刻保持對技術的敬畏和對技術的關注。

你可能不需要對各種技術的細節瞭解的特別透徹，但要心裡有底，知道各種技術的適用範圍、使用條件、優勢劣勢等等。保證在專案需要的時候，能夠快速選型。

而作為一個專案經理，最大的一個好處在於可以讓團隊同事去學習，讓他學習整理後來教你，以達到快速學習的目的。

所以我想說的是：

• 不要拋棄技術，它總有一天會拯救你。

• 學如逆水行舟，不進則退。

後記

程式設計師的管理思維修煉就寫到這裡。明白了道理之後，大家再去練習工具，練習方法，才會卓有成效。

總結下來，我們要鍛鍊的管理思維如下：

• 從個人到團隊的轉變。

• 從專心做一件事到同時處理多個任務的轉變。

• 從只關注點到關注面的轉變。

• 從說什麼是什麼到為什麼的轉變。

• 從追求完美到掌握平衡的轉變。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69901074/viewspace-2639306/，如需轉載，請註明出處，否則將追究法律責任。