最近與同事聊天，從軟體質量保證的方**談論到了技術管理，那技術管理的內涵到底是什麼？在此通過這篇文章做乙個小小的總結和適當的外延。
技術管理給人的感覺更多是工作量評估、專案計畫、專案進度跟蹤等，但這只是技術管理的一部分。大體上，可以將技術管理分為兩個緯度，如圖1所示。
圖1
緯度之一就是專案管理，其中包括專案計畫、風險管理、預算管理等。對於基層技術管理者，更多涉及的內容是工作量評估、專案計畫、專案進度管理等等。這一緯度的可見性很強，一項做不好就很容易讓上級「緊張」，因此每一項內容都有專門的培訓課程。
相信在不少企業，將技術管理更多地理解為專案管理，在管理活動中似乎只有風險、計畫和時間表，而忽視了培養團隊。在圖2中存在兩個點和一條射線，其中點a代表團隊a對於技術管理在兩個緯度所採取的權重，同理，b點則代表b團隊。從圖中可以直觀地看出，a團隊更加側重於團隊管理，而b團隊則更加側重於專案管理。另外，圖中的射線代表如果團隊權重是分布在這條線上或附近，則說明這個團隊在技術管理中很好地掌控了團隊管理與專案管理的平衡。
圖2
乙個團隊的技術管理，其兩個緯度的權重在圖2中的分布或許不是一成不變的，應當根據不同的時期調整其側重點，但是，無論如何團隊管理應當是技術管理的核心內容，或者更進一步地說，提高團隊技能是技術管理的核心課程。
團隊管理不能只是出去吃吃飯做一做team building什麼的，更為重要的是要提高團隊的技能，且是實實在在地提高團隊的技能。專案管理中的很多問題，都可以通過提高團隊的技能從而緩解，乃至**。舉乙個例子，為什麼我們對於風險管理（專案管理中的內容）那麼的執著？那是因為團隊的能力不足以應對所面臨的挑戰！當然，作者並不是要說團隊的技能上去了就不需要風險管理，而是指當技能增強了以後，對於風險的掌握自然就強了，而對於風險管理的要求就會有所弱化。團隊技能上不去，專案管理工作只會是越做越累，且只是工作在問題的表面。
提高團隊的技能是乙個很不輕鬆的話題，因為它在理但卻很難操作。但無論如何，技術管理者首先應當具備這種意識，因為只有意識先行才會有所行動。現實中，存在不少現象，技術管理者說「我的老闆才不管團隊技能的培養呢，他只關心他自己，因為團隊能力的提高並不是他的首要職責，他只要求我將產品按計畫做出就行了。老闆不管，那我也就更管不了，也沒有給我時間去做啊。」對於這種藉口存在以下幾個問題：
1）產品按計畫完成意味著專案成功了，但它並不意味著產品成功。乙個技能不行的團隊是能進行產品開發，也能做到專案成功，但一定做不到產品成功。可能一發布產品，就「全員求火」了。
3）培養團隊不是有時間就能解決問題，而首先需要有意識。時間總會是有的，因為專案總是要做的。有了意識以後，同樣是做一件工作，所採用的策略將完全不同，而團隊所學得的知識也很有可能更多。
技術管理者除了需要有提高團隊技能的意識，更要注意方**的運用，打造適合團隊自身的方**也顯得尤為必要。另外，承擔一定的責任和適當的風險有助於為工程師們提高技能創造空間。
本文出自 「李雲」 部落格，請務必保留此出處
。
技術管理的核心內容 提高團隊技能
最近與同事聊天，從軟體質量保證的方 談論到了技術管理，那技術管理的內涵到底是什麼？在此通過這篇文章做乙個小小的總結和適當的外延。技術管理給人的感覺更多是 工作量評估 專案計畫 專案進度跟蹤 等，但這只是技術管理的一部分。大體上，可以將技術管理分為兩個緯度，如圖1所示。圖1 緯度之一就是 專案管理 其...
shell程式設計的核心內容
很多linux 的初學者以前可能用過很多 dos的命令，對 shell 這種命令式的程式語言略知一二，但並沒有接觸很多 shell 的用法，沒能真正抓住這種強大的程式語言的內涵，在這編文章裡，我們用簡短的篇幅使 linux 學習者掌握這門語言。在這篇文章裡，我們不會關注shell 每個命令的具體用法...
IT專案技術建議書核心內容
第一部分 概述部分 該部分的重點是理解標書，理解專案建設的背景，建設該項目的初衷究竟是什麼？需要解決的核心關鍵問題是什麼？基於對專案的理解然後明確專案建設的目標，項 目建設的原則，專案本事的定位，專案建設完成後期望達到的效果和解決的問題。專案目標本事又包括了業務目標和系統建設目標，業務目標驅動系統目...