在IT公司中，管理層和“自命清高”的技術人員之間的溝通和協(xié)調永遠是一個值得討論的話題，在互聯網項目當中，相信每一個項目經理或者制作人，最頭疼的就是技術部的管理。因為技術工作看起來是那么的棘手，一般人難以理解，而且技術人員大多數都似乎情商不高。管理人員既不能輕易了解技術工作的內涵，技術人員也覺得很難和管理人員溝通。特別是技術工作，難以在不同人之間交接，很多技術人員都聲稱無法繼續(xù)別人做過的項目……要管理好技術人員，就一定要懂技術。這是任何一種其他號稱完美的管理方法都無法替代的。本文分析了技術人員的管理之道，包括何時以及如何評審、分層開發(fā)、盡快運行、追求代碼質量等。
首先，了解軟件架構的范疇，才能有針對性地去把握軟件開發(fā)中的風險，從而管理好軟件開發(fā)的過程。根據軟件需要應對的需求，軟件架構一般包含以下幾個部分：
邏輯架構：主要是為了明確“功能性需求”而做的設計，針對需求以及需求變化作為架構目標所做出的關于代碼之間的劃分、耦合、關聯的決定。采用合理的邏輯架構，將會大大降低需求變更對開發(fā)的延遲作用。邏輯架構最直接指導代碼中互相耦合的情況，仔細設計好耦合的規(guī)則，會讓后續(xù)開發(fā)事半功倍。
運行時架構：運行時架構是為了滿足運行期的質量需求，所做出的關于對象行文、進程結構、通信協(xié)議、數據結構等方面的決定。運行架構一旦確定，等于大部分的“實現”代碼都確定了，設計有足夠擴展性和可用性的運行架構，可以為后續(xù)工作節(jié)省時間，也降低了系統(tǒng)在運行期對開發(fā)工作的干擾。
其次，開發(fā)文檔的問題是一個老問題，根據文檔的不同類型：
設計類文檔：這類文檔往往在項目、模塊啟動的時候，大家都會想到要去寫，作為討論和最后決議的成果，顯然是很自然的。然而在項目進入開發(fā)之后，碰到實際問題時，往往就不能完全按照設計的初衷去做了，所以通常設計文檔就在這個時候和代碼脫離了聯系。但有一點是絕對可以做的，就是在重構的時候，按照現有狀況，重新增加重構前的系統(tǒng)狀況說明，然后再添加上重構后的設計。這樣就把重構的設計和文檔的更新結合到一起了。
API(應用編程接口)文檔：現代軟件都希望能提高重用的程度，因此很多程序員都會自己構造自己的業(yè)務API，以便在之后的開發(fā)中使用。而這種業(yè)務API，也是很多分工合作的基礎。這種代碼的說明，會直接影響日常的開發(fā)，因此非常有必要保證和代碼的高度一致性。
使用文檔：一般來說，一個軟件的使用文檔必須包含以下幾個：《產品版本說明》、《產品安裝和部署文檔》、《產品使用教程以及例程》、《產品FAQ文檔》。這里面的《產品版本說明》應該在每次發(fā)版的時候，作為發(fā)布流程的一個固有環(huán)節(jié)來設計?！懂a品使用教程以及例程》是我認為所有文檔中，最值得花大力氣去寫好的?！懂a品安裝和部署文檔》內容越少越好，應該讓安裝部署盡量智能化、自動化。