程式員如何修煉管理思維

來源：首發自——51CTO

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

正如老子說的“道為體，術為用。”我們的思維模式改變了，各種管理的方法和工具自然的就會去學習使用了。正所謂“有道者術能長久，無道者術必落空。”

是以在本文中，我就要和大家聊一聊管理中的<code>道</code>。聊一聊我們程式員如何修煉管理思維。我們先懂得了道理，再去學怎麼做。

很多兄弟剛轉型管理的時候，更多的關注事，而不是關注人。不斷的把任務分派下去，到點驗收，期待得到一個好的結果。遇到任務出問題，馬上跳出去指責。“你為什麼又沒完成！”，“怎麼這點東西都做不好！”。這樣隻能導緻一遍又一遍的出問題。你想想，你可能是因為業務精湛才被提拔為項目經理，其他同僚業務上沒有你那麼娴熟，無可厚非。而任務分派下去以後，你是否需要和同僚聊聊難點，說說你的想法，有問題給予一些簡單的指導。

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

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

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

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

是以我想說的是：

你要給予團隊的同僚包容，給予引導而不是指責

給予每個人鍛煉的機會。事無巨細的幫助或者親手操刀，隻會毀了團隊

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

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

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

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

這些事情如果處理不好，你會發現自己的一直處于忙碌之中，而不知道自己到底在忙些什麼。長此以往，你會對自己失去信心，項目也會一塌糊塗。但從另一個角度來說，如果你能有條有理把這些雜亂的任務整理清楚，你一定會有質的飛越。

擁抱混亂，但别陷入其中

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

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

既然我們身為程式員的時候，已經經曆過這些苦楚，那為什麼要讓我們的同僚再經受一遍呢？是以，請重視項目前期的階段。去搞定幹系人、去敲定需求、去定稿設計、去指導代碼設計。這些工作完成的越好，開發過程越順利，項目進度越有保障。

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

先設計後開發

防範于未然的能力，比救火能力更重要

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

而項目經理我認為

<code>透過表象發現本質的能力</code>

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

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

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

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

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

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

舉個例子：

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

這就叫做發現本質。

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

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

減少應激反應，多聽取别人的說法，不要急于反駁

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

不要輕易給同僚下結論，貼标簽。人都是會改變的，這次不行不代表下次也不行

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

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

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

作為項目經理來說，我們都希望自己帶的項目細節無可挑剔，功能一應俱全，代碼品質無懈可擊，團隊氛圍融洽得體，項目品質高的無以複加，項目周期如約達成。但其實項目裡，所有事情都是互相平衡的。工期和細節打磨之間的平衡、成本與需求開發的平衡、批評與贊揚之間的平衡等等。

平衡是一方面，另一方面是疊代。保持疊代，一步一個腳印的把項目逐漸推進。

把握平衡的尺度，是項目逐漸趨于完美的路

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

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

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

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

我們程式員做項目管理，最大的好處就是，不會出現外行指導内行的情況。是以我們即便轉型了，也要時刻保持對技術的敬畏和對技術的關注。你可能不需要對各種技術的細節了解的特别透徹，但要心理有底，知道各種技術的适用範圍、使用條件、優勢劣勢等等。保證在項目需要的時候，能夠快速選型。

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

不要抛棄技術，他總有一天會拯救你

學如逆水行舟,不進則退

我們的項目經理道理我都懂就寫到這裡。明白了道理之後，大家再去練習工具練習方法，才會著有成效。

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

從個人到團隊的轉變

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

從隻關注點到關注面的轉變

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

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

以上，就是我想和大家分享的内容，希望越來越多志在管理的程式員，能夠順利走上管理崗位。