在互聯(lián)網(wǎng)項(xiàng)目當(dāng)中，相信每一個(gè)項(xiàng)目經(jīng)理或者制作人，最頭疼的就是技術(shù)部的管理。因?yàn)榧夹g(shù)工作看起來是那么的棘手，一般人難以理解，而且技術(shù)人員大多數(shù)都似乎情商不高。管理人員既不能輕易了解技術(shù)工作的內(nèi)涵，技術(shù)人員也覺得很難和管理人員溝通。特別是技術(shù)工作，難以在不同人之間交接，很多技術(shù)人員都聲稱無法繼續(xù)別人做過的項(xiàng)目。這讓管理者覺得技術(shù)人員特別喜歡耍大牌，而且他們要偷懶也非常容易。但正如軍事中的定理，對付坦克最好的武器就是坦克，對付航母最好的武器也是航母，這條理論是通用的。要管理好技術(shù)人員，就一定要懂技術(shù)。這是任何一種其他號稱完美的管理方法都無法替代的。

　　開發(fā)是一切——何時(shí)寫文檔

　　對于技術(shù)管理來說，很多公司會非常注重文檔。雖然開發(fā)的結(jié)果是代碼，但對于管理來說，代碼往往難以閱讀，也很少有人擅長接手別人的系統(tǒng)。為了讓代碼不至于被丟棄，公司管理人員就祭起文檔這個(gè)法寶。我認(rèn)為文檔是很重要的，但也發(fā)現(xiàn)這些文檔中很典型地存在幾個(gè)問題：文檔和代碼不同步;文檔的可讀性差，需要的文檔沒寫，不需要hr369.com的文檔寫了一大堆;文檔和代碼脫節(jié)，文檔很多，開發(fā)出來的成果很少。

　　我們應(yīng)該何時(shí)寫什么文檔，這是需要有嚴(yán)格定義，并且有檢查過程的，而不是任由大家自然發(fā)展就可以完善的。代碼的編寫需要按不同類型，定義好在各個(gè)階段中所需要完成的部分。

　　設(shè)計(jì)類文檔—— 這類文檔往往在項(xiàng)目、模塊啟動的時(shí)候，大家都會想到要去寫，作為討論和最后決議的成果，顯然是很自然的。然而在項(xiàng)目進(jìn)入開發(fā)之后，碰到實(shí)際問題時(shí)，往往就不能完全按照設(shè)計(jì)的初衷去做了，所以通常設(shè)計(jì)文檔就在這個(gè)時(shí)候和代碼脫離了聯(lián)系。但有一點(diǎn)是絕對可以做的，就是在重構(gòu)的時(shí)候，按照現(xiàn)有狀況，重新增加重構(gòu)前的系統(tǒng)狀況說明，然后再添加上重構(gòu)后的設(shè)計(jì)。這樣就把重構(gòu)的設(shè)計(jì)和文檔的更新結(jié)合到一起了。

　　API(應(yīng)用編程接口)文檔——現(xiàn)代軟件都希望能提高重用的程度，因此很多程序員都會自己構(gòu)造自己的業(yè)務(wù)API，以便在之后的開發(fā)中使用。而這種業(yè)務(wù)API，也是很多分工合作的基礎(chǔ)。這種代碼的說明，會直接影響日常的開發(fā)，因此非常有必要保證和代碼的高度一致性。

　　使用文檔—— 一般來說，一個(gè)軟件的使用文檔必須包含以下幾個(gè)：《產(chǎn)品版本說明》、《產(chǎn)品安裝和部署文檔》、《產(chǎn)品使用教程以及例程》、《產(chǎn)品FAQ文檔》。這里面的《產(chǎn)品版本說明》應(yīng)該在每次發(fā)版的時(shí)候，作為發(fā)布流程的一個(gè)固有環(huán)節(jié)來設(shè)計(jì)�！懂a(chǎn)品使用教程以及例程》是我認(rèn)為所有文檔中，最值得花大力氣去寫好的�！懂a(chǎn)品安裝和部署文檔》內(nèi)容越少越好，應(yīng)該讓安裝部署盡量智能化、自動化。

　　了解什么是軟件架構(gòu)

　　了解軟件架構(gòu)的范疇，才能有針對性地去把握軟件開發(fā)中的風(fēng)險(xiǎn)，從而管理好軟件開發(fā)的過程。簡單來說，軟件架構(gòu)就是應(yīng)對需求所產(chǎn)生的“一系列決定”。軟件會根據(jù)這些決定來開發(fā)。根據(jù)軟件需要應(yīng)對的需求，軟件架構(gòu)一般包含以下幾個(gè)部分。

　　邏輯架構(gòu) 主要是為了明確“功能性需求”而做的設(shè)計(jì)，針對需求以及需求變化作為架構(gòu)目標(biāo)所做出的關(guān)于代碼之間的劃分、耦合、關(guān)聯(lián)的決定。采用合理的邏輯架構(gòu)，將會大大降低需求變更對開發(fā)的延遲作用。邏輯架構(gòu)最直接指導(dǎo)代碼中互相耦合的情況，仔細(xì)設(shè)計(jì)好耦合的規(guī)則，會讓后續(xù)開發(fā)事半功倍。

　　運(yùn)行時(shí)架構(gòu) 運(yùn)行時(shí)架構(gòu)是為了滿足運(yùn)行期的質(zhì)量需求，所做出的關(guān)于對象行文、進(jìn)程結(jié)構(gòu)、通信協(xié)議、數(shù)據(jù)結(jié)構(gòu)等方面的決定。運(yùn)行架構(gòu)一旦確定，等于大部分的“實(shí)現(xiàn)”代碼都確定了，設(shè)計(jì)有足夠擴(kuò)展性和可用性的運(yùn)行架構(gòu)，可以為后續(xù)工作節(jié)省時(shí)間，也降低了系統(tǒng)在運(yùn)行期對開發(fā)工作的干擾。

　　開發(fā)架構(gòu) 為了滿足開發(fā)時(shí)的需求所做的決定，主要是軟件根據(jù)分工開發(fā)、測試驗(yàn)證流程等需求劃分的軟件層次和區(qū)域以及各種接口設(shè)計(jì)，也包含使用的軟件包、組件庫、開發(fā)工具，以及編譯構(gòu)建的方法。一個(gè)好的開發(fā)架構(gòu)，可以讓溝通成本降低，開發(fā)速度提高。

　　部署架構(gòu) 現(xiàn)代軟件系統(tǒng)，基本上都包括了客戶端和服務(wù)端程序，如何快速、高效、穩(wěn)定地部署和發(fā)布這些程序，如網(wǎng)絡(luò)機(jī)房的分布、服務(wù)器硬件的搭配、監(jiān)控和維護(hù)工具軟件的安裝、開發(fā)測試網(wǎng)絡(luò)和運(yùn)營網(wǎng)絡(luò)的設(shè)置�？梢垣@得安全性的配置，良好的部署能力，能推動軟件進(jìn)行更頻繁、更全面的測試，從而提高軟件質(zhì)量和開發(fā)效率。

　　數(shù)據(jù)架構(gòu) 數(shù)據(jù)是軟件項(xiàng)目的核心財(cái)富，關(guān)于數(shù)據(jù)的結(jié)構(gòu)，數(shù)據(jù)的存放、備份、傳輸會直接影響到運(yùn)行性能、業(yè)務(wù)功能、部署、安全等需求。在面向?qū)ο蟮拈_發(fā)模式下，數(shù)據(jù)到對象的ORM架構(gòu)也是很重要的設(shè)計(jì)。一個(gè)完整的數(shù)據(jù)架構(gòu)包括了數(shù)據(jù)流圖、數(shù)據(jù)字典、ORM結(jié)構(gòu)(如果需要的話)、數(shù)據(jù)索引和備份機(jī)制等幾個(gè)方面。

　　何時(shí)以及如何評審

　　相信大部分公司都有評審這個(gè)環(huán)節(jié)，評審可以包括方案評審、代碼評審、項(xiàng)目專項(xiàng)議題的評審，比如對存留Bug的處理評審等。而這些評審，常常會變成一個(gè)挑毛病的會議。要解決評審給產(chǎn)品帶來的負(fù)面影響，同時(shí)發(fā)揮這個(gè)活動的優(yōu)點(diǎn)，我們需要關(guān)注以下幾個(gè)方面。

　　評審由誰發(fā)起 相對比較好的是，由負(fù)責(zé)此項(xiàng)目的“領(lǐng)導(dǎo)”來召集人員評審，并且一定要有負(fù)責(zé)開發(fā)的人員參加評審。參與評審的受邀請人員可能會與方案提交者就一些問題有分歧，但提交者有最終決定權(quán)。要把權(quán)力給有能力承擔(dān)它的人。這樣做可以讓“防止風(fēng)險(xiǎn)”的一部分人和“注重效率”的開發(fā)人員形成平等的意見交換。

　　什么時(shí)候做評審 應(yīng)該在每個(gè)迭代、每個(gè)較大的版本開工前，或者僅僅是某個(gè)認(rèn)為比較重要的決定做出前，都來一次簡短的評審。如果開始時(shí)只是做一個(gè)DEMO，那么需要評審的東西也比較少，而隨著不斷的開發(fā)，評審也能遍歷所有的開發(fā)。

　　做評審的方法 真正對項(xiàng)目有幫助的，是了解項(xiàng)目的需求，分析面臨的難點(diǎn)，思考方案為何這樣做，提出自己的解決方案，給項(xiàng)目開發(fā)者以建議和啟發(fā)。多說“我建議這樣解決這個(gè)問題”，而不要僅僅去說“這樣做可能有問題，應(yīng)該添補(bǔ)這樣的功能”。以建設(shè)性的心態(tài)和思路去做評審，而不是以找問題的思路去做，這就是兩種做法的最大區(qū)別。