幾乎每種行業都有基層主管（或基層管理人員），而軟件行業的基層主管一般是項目經理、技術經理、開發經理、組長等。其職責是資源協調、風險預估、項目管控、團隊建設，說白一點大多數的企業現狀就是項目負責人帶領團隊攻下一個又一個項目的過程。很多公司以項目成敗作為項目負責人考核的唯一標準，因為項目規模、成本、客戶滿意度等容易量化，并且是直接跟公司的利潤有很大關系；而相反團隊建設卻難以衡量，如何衡量一個普通技工晉升成高級技工到底是基層主管的培養還是原員工本身就具備高級技工的技能。因此，難免出現以項目額度論英雄的局面，這樣往往造成一將功成萬骨枯的悲壯場面，并不利于團隊的發展。卡耐基曾經說過，帶走我的員工，把我的工廠留下，不久后工廠就會長滿雜草；拿走我的工廠，把我的員工留下，不久后我們還會有個更好的工廠。我的觀點是，從短期目標來看，項目成功是解決溫飽問題的指標，如果溫飽問題未解決，還如何談吃得好，如團隊經常瘋狂加班趕項目就是溫飽尚未解決的一種表現；從長遠角度來看，團隊建設是邁向“吃得好”的改進過程，或著說是一種手段。

　　一只獅子帶領一群綿羊的團隊會戰勝由一只綿羊帶領一群獅子的團隊

　　如果你是一只綿羊，配備一群獅子般的團隊也是枉然。說到這里，我曾經從一個電視節目看到十多只年輕獅子攻擊一頭河馬，由于缺乏領隊，結果導致河馬成功逃過一劫并且一頭獅子犧牲這樣難以置信的場面。后來，同樣這群獅子在一只經驗豐富的獅子帶領下，戰勝比河馬更強壯更兇猛的對手。

　　基層主管往往來自基層的優秀員工，在成功轉型之前必須先把自己的寶劍磨利。

　　在NBA賽場上，5個科比組成的球隊可能會輸給聯盟任何一只球隊

　　一個項目一般需要若干個成員組成團隊——售前、需求、設計、開發、測試、部署等。而現實情況往往是，要么項目急、要么人員未到位，或者兩種情況都有，那么開發人員由于在公司所占比例大，可能會兼做需求和測試。這樣造成的后果是，需求把握不明確，測試不到位導致軟件質量差，客戶不斷投訴。

　　正如下象棋一樣，必須了解各種棋子的角色和作用，以及它們應該擺放的位置。否則拿車當兵使，后果可想而知。

　　當項目出現危機，基層主管的第一反應是？

　　如果第一反應是“這個問題是哪個兔崽子造成的”，意味著該主管的思維是先追究責任。有一次，需要向客戶演示現有的開發成果，由于各種原因導致離演示的前一天發現很多功能都未完善，如果照這樣演示給客戶看的話簡直是演猴戲。當時，基層主管唯有向上匯報，而高級主管的第一反應是，評估完善這些功能需要多少時間？現在增加資源是否能夠縮短工期？需要哪些資源才能完成？并且在該項目所有成員目前表示，他不想追究任何一個人的錯誤，首要任務是先分析如何能夠解決問題。事后，他再向基層主管了解如何改進才能避免同類問題的發生，通過這種方式相當于給基層主管上了一次深刻的管理課程。

　　聆聽團隊的意見

　　善于聆聽是良好溝通的鋪墊。如果你的團隊成員在他的崗位上老老實實的干了幾個月，突然他有一天告訴你（或者從其他成員了解到），他覺得自己的工作沒意思。這其實不完全是分工的問題，很大程度上是溝通出現問題。試問，他是覺得沒意思，而不是不合適，即他勝任這份工作，可惜覺得缺少了什么，可能是缺少鍛煉機會、想換個項目等等。主動去了解團隊成員的意向，因為把他們放在感興趣的崗位會發揮他們潛在的能力。當然并不是每個人都能找到適合自己的崗位，恰當的給予激勵會鼓舞士氣，保持工作的熱情。某些基層主管把開空頭支票當激勵，結果失信于團隊。

　　最大限度地發揮團隊的力量是每個基層主管的職責

　　最大限度地發揮團隊的力量的前提是得深入了解每個團隊成員的技能和喜好。特別是軟件工程師，很多不善于語言表達也不會表現自己，更多的需要基層主管去觀察。如A君喜歡鉆研技術但是缺乏經驗，如果有技術難度較高地先分配給他，幫他分析解決方案，更重要的是給他信心。

　　不要說我以為

　　基層主管不同于普通員工，一旦犯錯就勇于承擔。如果說“我以為…，想不到會…，結果造成…”，是一種借口，是不成熟的表現。

　　讓團隊主動反饋

　　基層主管要了解他管理的不是一群機器，是一支優秀的隊伍。如果把團隊訓練成機器，最終會累死基層主管。例如，你需要挨個挨個的去問他們工作進展的怎么樣，或者索性讓他們寫日報周報來反饋。這樣得到的結果就是一切看起來很美好，而實際情況就可能隱藏一個個定時炸彈。如果并非團隊成員的主動反饋，“被反饋”往往是走走形式，例如某某說“A功能完成了，B功能差不多了”。到了第二天、第三天還是“B功能差不多了”。主動反饋是簡要說說工作的問題和解決方法，如某某說“A功能解決方案是…，B功能遇到…問題，C功能預計明天可完成”，并且更重要的是，不是等到你去問他才反饋。

　　總結

　　以上純粹是自己對基層管理的個人看法，也是自己一些微薄經驗的一個小結，思維有點混亂。這里拋磚引玉，希望聽到更多的建議。