程序員如何修煉管理思惟

來源：首發自——51CTO

一個技術精湛的程序員，只要有機會，就有可能被公司提拔爲項目管理人員，掌控項目中的一切。但所謂權力越大責任越大，要想成爲一個合格的項目管理人員，我認爲最重要的首先是扭轉本身的思想。

正如老子說的「道爲體，術爲用。」咱們的思惟模式改變了，各類管理的方法和工具天然的就會去學習使用了。正所謂「有道者術能長久，無道者術必落空。」

因此在本文中，我就要和你們聊一聊管理中的道。聊一聊咱們程序員如何修煉管理思惟。咱們先懂得了道理，再去學怎麼作。

你不是一我的在戰鬥

不少兄弟剛轉型管理的時候，更多的關注事，而不是關注人。不斷的把任務分派下去，到點驗收，期待獲得一個好的結果。遇到任務出問題，立刻跳出去指責。「你爲何又沒完成！」，「怎麼這點東西都作很差！」。這樣只能致使一遍又一遍的出問題。你想一想，你多是由於業務精湛才被提拔爲項目經理，其餘同事業務上沒有你那麼嫺熟，無可厚非。而任務分派下去之後，你是否須要和同事聊聊難點，說說你的想法，有問題給予一些簡單的指導。

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

有的兄弟剛轉型管理的時候，一旦遇到同事完不成的任務，遇到的難點。立刻跳上去三下五除二一頓敲，解決問題後，不留下一片雲彩，揮袖而去。這些兄弟總會替代同事作他們本身本應該作的事情。致使同事得不到成長，而本身則搞的很疲憊。

我想有一點咱們須要明白：項目經理是團隊中的指戰員，掌控着整個團隊前進的方向和打法。你不是一我的在戰鬥，你的行爲影響着整個團隊的戰鬥力。

做爲程序員，咱們習慣了單兵做戰，不斷的鑽研打磨本身的技術，就能高效的完成任務，提升戰鬥力。而項目經理，是須要指揮一羣人，去打贏一場又一場的戰鬥。

因此我想說的是：

1. 你要給予團隊的同事包容，給予引導而不是指責
2. 給予每一個人鍛鍊的機會。事無鉅細的幫助或者親手操刀，只會毀了團隊
3. 誇張點說，你決定了整個團隊的戰鬥力，請爲同事負責也爲本身負責
4. 培養人是你的職責，團隊的進步纔是真的進步

並行工做能夠拯救你，也能夠毀了你

作了管理之後，你會發現本身被各類事情同時纏身。你不只僅是要處理技術那點事了，你可能同時在處理多件事情。你要維繫干係人、要作任務WBS（工做分解結構）、要溝通需求、要項目演示、要協調團隊關係、要處理各類緊急狀況、甚至於要填報材料、要寫合同、要解決客戶亂七八糟的問題等等。總之剛開始的時候你會發現，你事情多的作不完，被各類事情纏的脫不開身，但這又是你的工做職責，必需要去處理。

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

這些事情若是處理很差，你會發現本身的一直處於忙碌之中，而不知道本身到底在忙些什麼。久而久之，你會對本身失去信心，項目也會一塌糊塗。但從另外一個角度來講，若是你能有條有理把這些雜亂的任務整理清楚，你必定會有質的飛越。

因此我想說的是：

1. 擁抱混亂，但別陷入其中
2. 這是展現你真正技術的時刻，如何作好我的時間管理，是你最重要的一課

碼代碼很重要，但其餘事情也一樣重要

咱們程序員總認爲：碼代碼纔是正事，其餘事情都是扯淡。但你別忘了，你確定也經歷過需求改來改去致使的痛苦、設計稿一改再改帶來的重複勞動、沒有設計就開發致使的各類問題。

既然咱們身爲程序員的時候，已經經歷過這些苦楚，那爲何要讓咱們的同事再經受一遍呢？因此，請重視項目前期的階段。去搞定干係人、去敲定需求、去定稿設計、去指導代碼設計。這些工做完成的越好，開發過程越順利，項目進度越有保障。

身爲項目經理，你須要額外作不少事情，保障項目的進度。不少事情等到開發階段再介入，你會發現爲時已晚。莫要坑了同事也坑了本身。

因此我想說的是：

1. 先設計後開發
2. 防範於未然的能力，比救火能力更重要

不斷挖掘，發現本質

咱們程序員啊，老是亦或者是習慣了別人說什麼，我就作什麼。但其實咱們也應該多問問爲何。

而項目經理我認爲
透過表象發現本質的能力

需求來臨的時候，你可否透過現有的需求發現客戶更深層次的須要？
某同事任務完不成的時候，你可否透過平常點滴發現他完不成的緣由？
測試團隊和開發團隊起衝突的時候，你是否能透過平常的交流發現矛盾的根源？
團隊士氣低落的時候，你可否透過你們的表現悉知團隊狀態低落的問題所在？

首先，要想作到一步到位透過表象發現本質我認爲是很難的，須要大量的鍛鍊。但我認爲咱們保持一顆好奇之心，就能把問題的本質掌握的八九不離十。

不斷的給用戶提出新方法，同時挖掘他更深層次的想法。

舉個例子：

客戶：「我想造一架飛機」
項目經理：「您爲何想造一架飛機呢？造完飛機還須要建飛機場才能飛呢。您是要去什麼地方嗎？」
客戶：「我是想去西班牙，以爲有架飛機比較方便。」
項目經理：「您去西班牙作什麼呢？是旅遊嗎？去西班牙的話，能夠搭乘現有航班和渡輪也能夠。」
客戶：「我這不是想去巴薩羅那看看比賽嗎。」
項目經理：「咱中央五臺不是有直播嗎，也能夠看的。去巴薩羅那成本比較高。」
客戶：「我以爲去現場看比較有氣氛，這點成本我能負擔。」
項目經理：「好的，那咱搭乘國際航班去能夠把？」
客戶：「好的，沒問題。」

以上，客戶的最根本需求是要到巴薩羅那現場去看球賽。而他的想法大概是要過去得有飛機，因此提出了造飛機的需求。而項目經理在不斷的交談過程當中，一次次的給出新方案，以探尋客戶最須要的東西和摸索客戶的想法（例子中爲性價比和體驗，客戶更想要體驗）。

這就叫作發現本質。

以人爲中心，而不是機器

咱們程序員每天和機器打交道，習慣了非0即1的二進制生活。

但項目經理是須要和人溝通的，與人打交道。因此面對咱們的同事，面對整個團隊。應該多考慮人，以人爲中心。

因此我想說的是：

1. 減小應激反應，多聽取別人的說法，不要急於反駁
2. 保持同理心，多從同事的角度想一想，出錯前作好預防工做
3. 不要輕易給同事下結論，貼標籤。人都是會改變的，此次不行不表明下次也不行
4. 不能爲兄弟們擋刀並引領兄弟們前進的老大是不值得追隨的，弟兄們在你手下作事受盡委屈，爭不了一口氣，那這個老大也作不長。

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

我相信大多數程序員都有個毛病，追求完美。代碼格式要最舒服，代碼邏輯要最簡潔，細節一扣再扣。就想強迫症同樣，追求本身代碼的完美。做爲程序員來講，這是一個很是棒的習慣。

但做爲項目經理來講，咱們最須要的是平衡。一味的追求完美，會致使項目成員壓力大增，成本不可控制。

做爲項目經理來講，咱們都但願本身帶的項目細節無可挑剔，功能包羅萬象，代碼質量無懈可擊，團隊氛圍融洽得體，項目質量高的無以復加，項目週期如約達成。但其實項目裏，全部事情都是互相平衡的。工期和細節打磨之間的平衡、成本與需求開發的平衡、批評與讚賞之間的平衡等等。

平衡是一方面，另外一方面是迭代。保持迭代，一步一個腳印的把項目逐步推動。

因此我想說的是：

1. 把握平衡的尺度，是項目逐步趨於完美的路
2. 不要追求一步到位，完美是迭代出來的

少寫代碼能夠，脫離技術不行

以上都是針對項目管理說的，而這最後一條，是爲了引發各位的警戒。

咱們上面說會有不少雜事纏身，可能致使你幾乎沒有寫代碼的時間了。這是正常的也是正確的，你的工做不是去當機槍手，你的工做是指揮你們戰鬥。

但這就表明咱們要脫離技術了嗎？我認爲不是這樣的。咱們能夠少寫代碼，但咱們不能拋棄技術。我有個朋友告訴我說：不要過早涉足「純管理崗位」。我想他的意思，就是告訴我技術乃是一個軟件開發的項目經理安身立命的根本。

咱們程序員作項目管理，最大的好處就是，不會出現外行指導內行的狀況。因此咱們即使轉型了，也要時刻保持對技術的敬畏和對技術的關注。你可能不須要對各類技術的細節瞭解的特別透徹，但要心理有底，知道各類技術的適用範圍、使用條件、優點劣勢等等。保證在項目須要的時候，可以快速選型。

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

因此我想說的是：

1. 不要拋棄技術，他總有一天會拯救你
2. 學如逆水行舟,不進則退

後記

咱們的項目經理道理我都懂就寫到這裏。明白了道理以後，你們再去練習工具練習方法，纔會著有成效。

總結下來，咱們要鍛鍊的管理思惟以下：

1. 從我的到團隊的轉變
2. 從專心作一件事到同時處理多個任務的轉變
3. 從只關注點到關注面的轉變
4. 從說什麼是什麼到爲何的轉變
5. 從追求完美到掌握平衡的轉變

以上，就是我想和你們分享的內容，但願愈來愈多志在管理的程序員，可以順利走上管理崗位。