崗位決定視角

Eric Liu 2006年26日

從正式離開(kāi)雜志社到新公司上班也已經(jīng)1周多的時(shí)間，加上春節(jié)這個(gè)空隙的折騰，，離開(kāi)媒體也接近一個(gè)月，在此之前，很少去考慮過(guò)有關(guān)不同崗位之間考慮問(wèn)題的視角，在雜志社一年的時(shí)間也沒(méi)有真正靜心下來(lái)去寫(xiě)一些技術(shù)架構(gòu)或者管理方面的文章，我想更多的是因?yàn)槌恋聿粔虻脑颉?/SPAN>

有些主題注定會(huì)找罵，其實(shí)理由很簡(jiǎn)單，因?yàn)闊o(wú)知和觸碰一些本來(lái)不應(yīng)該屬于自己的視角。所以寫(xiě)本文的開(kāi)始我就做好了被打擊的準(zhǔn)備。從2002年大學(xué)畢業(yè)到現(xiàn)在也快接近上年，加上大學(xué)畢業(yè)之前2年多的工作經(jīng)驗(yàn)，在這個(gè)浮躁的IT也算不老不少的人了。從Coder到Technical Leader再到Architect到《MSDN開(kāi)發(fā)精選》的Editor，再到如今另外一個(gè)方向的工作，雖然層次始終不高，但是依舊覺(jué)得比較幸運(yùn)，因?yàn)閲L試了大多人希望的職位。

如果將我自己從事過(guò)的崗位簡(jiǎn)單的歸納，應(yīng)該可以描述成下面的崗位

Coder：完成Technical Leader指定的模塊功能，擁有良好的編碼風(fēng)格和一些細(xì)節(jié)實(shí)現(xiàn)技巧

Technical Leader：根據(jù)項(xiàng)目經(jīng)理或者產(chǎn)品經(jīng)理（國(guó)內(nèi)大多比較少區(qū)分這兩個(gè)角色）指定的任務(wù)，協(xié)助Architect或者Analyst實(shí)現(xiàn)系統(tǒng)設(shè)計(jì)，指導(dǎo)和監(jiān)督Coder完成開(kāi)發(fā)任務(wù)，同時(shí)承擔(dān)一些技術(shù)難題的解決。

Architect:從技術(shù)和業(yè)務(wù)的角度對(duì)應(yīng)用系統(tǒng)或者產(chǎn)品進(jìn)行抽象，進(jìn)而設(shè)計(jì)一個(gè)適用于解決方案的模式。簡(jiǎn)要地說(shuō)是抽象和分離軟件產(chǎn)品中的共性問(wèn)題，提供一個(gè)解決這些共性問(wèn)題的方法論（不是某一個(gè)方法）。從這個(gè)角度來(lái)講，系統(tǒng)架構(gòu)師可以分成兩種類(lèi)型：一是提供解決方案的技術(shù)實(shí)現(xiàn)，一個(gè)是提供業(yè)務(wù)的抽象（這是我個(gè)人的理解）。與此同時(shí)，可擴(kuò)展性、可伸縮性、安全性、性能等等這些東西成為Architect關(guān)注的重點(diǎn)，他們不再具體關(guān)注某一個(gè)業(yè)務(wù)功能的具體代碼實(shí)現(xiàn)，而是在一個(gè)更高層次上考慮系統(tǒng)的總體結(jié)構(gòu)，諸如子系統(tǒng)劃分、組件分布、消息通信等等方面的東西。

Editor:恰當(dāng)?shù)恼f(shuō)是技術(shù)編輯，而不是純粹意義的編輯，所以它的第一要素是技術(shù)性，而非文字。這里我要感謝我在雜志社的搭檔孟巖先生，在短短的一年時(shí)間內(nèi)他教會(huì)了我許多東西，也知道了許多事情可以從Non-Technical ViewPoint去看待。很多大學(xué)同學(xué)和朋友問(wèn)過(guò)我做編輯和作程序有什么區(qū)別，我想最大的不同依舊是視角，作為一個(gè)合格的技術(shù)編輯，首先要求有比較扎實(shí)的技術(shù)功底，然后有開(kāi)拓的視角和接納新知識(shí)的能力，最后才是其文字表達(dá)功底（就我個(gè)人認(rèn)為，在這幾個(gè)方面孟巖和熊節(jié)先生做得非常出色，所以也就理所當(dāng)然地稱為國(guó)內(nèi)頂尖級(jí)的技術(shù)編輯）。作為一個(gè)編輯最重要的使命就是傳播，那么如何在這種信息爆炸的時(shí)代將最有用的信息通過(guò)最有效的途徑傳播給需要接受新知識(shí)的人，除了傳統(tǒng)的平面媒體和大家所熟知的論壇，Blog是一個(gè)非常有效的形式，它能夠讓讀者和身份為技術(shù)編輯的Bloger在第一時(shí)間得到最好的交流。所以技術(shù)編輯應(yīng)該更多的是能夠?qū)⒆约簩?duì)于技術(shù)的理解和對(duì)于說(shuō)了解的東西盡快地讓更多人了解，雖然很多IT雜志社比較傾向編輯不用寫(xiě)稿，而是掌握大量的作者資源，然后有效地利用這些作者資源。對(duì)，本身沒(méi)有錯(cuò)，但是在IT卻不是行的很通，所有做技術(shù)的都佩服Orielly的技術(shù)編輯，原因無(wú)它，因?yàn)槟菐腿藪侀_(kāi)編輯的生活，每個(gè)都是技術(shù)上的大佬。獨(dú)立技術(shù)評(píng)論或者產(chǎn)業(yè)評(píng)論在許多時(shí)候成為一個(gè)技術(shù)編輯可以和他人溝通的基本條件，“英雄惺惺相惜”的局面在開(kāi)發(fā)人員中出現(xiàn)的概率遠(yuǎn)遠(yuǎn)高于其他人群。因此在這個(gè)崗位上對(duì)于技術(shù)和文字的要求是并行的，或者前者重一點(diǎn)，只是相對(duì)于Coder,關(guān)注的層次和方向已經(jīng)截然不同。也正是因?yàn)槿绱?，在雜志社一年的時(shí)間雖然給朋友的公司做過(guò)一些技術(shù)咨詢，卻發(fā)現(xiàn)自己寫(xiě)代碼的能力正在退化（寫(xiě)代碼明顯比較慢）。

Manager：請(qǐng)記住永遠(yuǎn)不要用Business-Card上面的Title去看待一個(gè)人的崗位或者說(shuō)職位，這點(diǎn)在外企尤為明顯，做商務(wù)或者市場(chǎng)的沒(méi)有一個(gè)不是經(jīng)理:)，不過(guò)仔細(xì)的看他們英文的Title就能夠比較準(zhǔn)確的反映出這個(gè)人在公司的崗位。在我經(jīng)歷中，名片上很早就出現(xiàn)經(jīng)理的字樣，但是客觀的說(shuō)，那只是公司的商業(yè)因素決定的，大多時(shí)候所謂的項(xiàng)目經(jīng)理等等是等同于Team Leader，是一個(gè)工作過(guò)程的臨時(shí)角色，而不是在公司行政體系中的崗位劃分。在做Coder的時(shí)候，我更多的是關(guān)心某個(gè)API的使用，能夠?qū)懗鲆欢钨p心悅目的代碼是一件非常有成就感的事情，在做技術(shù)負(fù)責(zé)人的時(shí)候依舊關(guān)心的是技術(shù)，這個(gè)時(shí)候需要考慮針對(duì)人的分工，根據(jù)每個(gè)人不同的技術(shù)特點(diǎn)進(jìn)行分工，然后再上級(jí)領(lǐng)導(dǎo)指定的時(shí)間內(nèi)完成工作。而Architect從大多人來(lái)說(shuō)，應(yīng)該是相對(duì)不錯(cuò)的崗位，它更多的是關(guān)心技術(shù)或者特定領(lǐng)域行業(yè)業(yè)務(wù)的抽象，我們可以簡(jiǎn)單的認(rèn)為Architect和Consultant的工作和比較接近的，不同的是Architect給公司干，Consultant給別的公司干，當(dāng)然了，我這里提及的是技術(shù)顧問(wèn)，而非大多咨詢公司的泛意義上的顧問(wèn)。Architect總體上來(lái)說(shuō)是一個(gè)和事情打交道居多的職位，是Non-Leadership，因?yàn)闆](méi)有涉及到太多人的因素。

當(dāng)我第一天上班，家里的老大就提醒我需要注意一個(gè)Technical Leader和Manager是兩個(gè)差距比較大的角色，前者更多的是對(duì)事情而言的，而后者更多的是針對(duì)人。比如團(tuán)隊(duì)建設(shè)，人才組織結(jié)構(gòu)，員工培養(yǎng)計(jì)劃，激勵(lì)和考評(píng)機(jī)制和資源調(diào)度安排等等。在此之前，對(duì)于工作大多考慮的是如何爭(zhēng)取資源，而作為一個(gè)管理人員，更多的是考慮利用將有限資源最大化（嘿嘿，資本家和資本家走狗的本質(zhì)）。

我不是職業(yè)IT經(jīng)理，也沒(méi)有太多的管理經(jīng)驗(yàn)，雖然之前做過(guò)或多或少的管理工作，但是和一個(gè)崗位本身真正所從事的事情差距甚遠(yuǎn)，因?yàn)槿缦轮皇俏覀€(gè)人的一些理解，也請(qǐng)各位看官原諒我的無(wú)知和賣(mài)弄。一個(gè)小型公司的開(kāi)發(fā)部門(mén)負(fù)責(zé)人需要做以下事情（至少吧，雖然還有其他許多事情）

1）  規(guī)劃化軟件開(kāi)發(fā)過(guò)程

我不是一個(gè)軟件工程專(zhuān)家，甚至對(duì)于目前的大多軟件工程方法學(xué)不是特別感冒，但是我從來(lái)不去拒絕規(guī)范化的軟件開(kāi)發(fā)過(guò)程，就如許多人問(wèn)過(guò)我是否要采用CMM/CMMI或者RUP進(jìn)行軟件開(kāi)發(fā)時(shí)，我首先會(huì)去確認(rèn)他們的團(tuán)隊(duì)規(guī)模，通常來(lái)說(shuō)，不超過(guò)15個(gè)人的開(kāi)發(fā)團(tuán)隊(duì)采用這些軟件工程的方法學(xué)并不能夠帶來(lái)明顯的好處，因?yàn)?/SPAN>CMM/CMMI或者RUP對(duì)于角色的定義太明晰，雖然提供了定制的可能，但是對(duì)于國(guó)內(nèi)大多的軟件公司而言，15個(gè)人的開(kāi)發(fā)團(tuán)隊(duì)?wèi)?yīng)對(duì)的不僅僅是一個(gè)項(xiàng)目，更多時(shí)候被分離成了3個(gè)孤立的團(tuán)隊(duì)，這個(gè)時(shí)候5個(gè)人的開(kāi)發(fā)團(tuán)隊(duì)在項(xiàng)目實(shí)施過(guò)程中很多角色注定是重合的，相信大家應(yīng)該知道太多角色重合的結(jié)果是帶來(lái)崗位職責(zé)的沖突，對(duì)于大多數(shù)人而言，處理好這些沖突不是那么容易的。

        里程碑和迭代總是被忽視，因?yàn)榇蠖嘈」镜拈_(kāi)發(fā)人員沒(méi)有經(jīng)歷過(guò)相對(duì)系統(tǒng)的培訓(xùn)，也就不是特別理解軟件開(kāi)發(fā)過(guò)程，他們更多的是按照上級(jí)分配的任務(wù)去完成工作，稍有經(jīng)驗(yàn)的開(kāi)發(fā)人員都會(huì)知道，這些東西的欠缺是非常致命的。最直接的結(jié)果就是無(wú)法控制項(xiàng)目進(jìn)度和成本核算，更多的是依賴于個(gè)人的感覺(jué)“大約、估計(jì)、差不多”在現(xiàn)有資源的情況下完成指定工作。于是加班就成為了家常便飯，大多是為了在指定的時(shí)間之前完成任務(wù)。

        通過(guò)一些輔助工具能夠能夠幫助小型開(kāi)發(fā)團(tuán)隊(duì)明顯的提高工作效率和里程碑的界定。比如建模工具Visio，Rational XDE，數(shù)據(jù)庫(kù)建模工具Power Designer，代代碼生成工具如CodeSmith，文檔和測(cè)試工具（NDoc,NUnit/NMock）及其批處理工具（NAnt）等等，這些工具能夠很大程度的幫助開(kāi)發(fā)人員完成一些枯燥無(wú)味的重復(fù)性開(kāi)發(fā)工作，從而將精力集中在核心業(yè)務(wù)的實(shí)現(xiàn)。

        我們可以簡(jiǎn)單的描述一個(gè)軟件開(kāi)發(fā)過(guò)程能夠使用到的工具，當(dāng)然這里提到的沒(méi)有太多的軟件工程方法學(xué)，只是從實(shí)用的角度來(lái)看利用一些已有的工具能夠較少軟件開(kāi)發(fā)中的重復(fù)，同時(shí)提供相對(duì)明晰的里程碑界定：

(1)    定義需求。對(duì)于小型軟件開(kāi)發(fā)，建議不用引入太復(fù)雜的開(kāi)發(fā)工具（不知道大家的感覺(jué)如何，使用UML來(lái)進(jìn)行業(yè)務(wù)建模對(duì)于大多開(kāi)發(fā)人員是存在困難的），因?yàn)榇蠖嗳肆?xí)慣用代碼去表述業(yè)務(wù)邏輯，諸如Use Case，時(shí)序圖、活動(dòng)圖等等，對(duì)于非專(zhuān)業(yè)技術(shù)人員而言太抽象，UML的提出是為了建立一種統(tǒng)一標(biāo)準(zhǔn)的溝通語(yǔ)言，讓所與參與者能夠統(tǒng)一種符號(hào)去表達(dá)思想，可是在國(guó)內(nèi)目前的實(shí)際情況而言，這些UML恰恰讓許多人無(wú)法理解。對(duì)于大多軟件開(kāi)發(fā)而言，我們需要的僅僅是一份開(kāi)發(fā)人員的文檔，簡(jiǎn)單來(lái)說(shuō)文檔必須包含業(yè)務(wù)要求和技術(shù)要求兩部分。業(yè)務(wù)部分包含核心的業(yè)務(wù)流程圖和列表形式的業(yè)務(wù)描述，技術(shù)要求具備一些基本的要求如整合現(xiàn)有IT系統(tǒng)、技術(shù)模型等等就足夠了，對(duì)于大多數(shù)開(kāi)發(fā)出生的系統(tǒng)分析員而言，有這個(gè)文檔就可以開(kāi)始做設(shè)計(jì)了，那么有了這個(gè)文檔是不是全部足夠了呢？顯然不是，如果我告訴你是又多了一次被鄙視的機(jī)會(huì)了。

(2)    數(shù)據(jù)建模。你可以簡(jiǎn)單的理解成數(shù)據(jù)庫(kù)設(shè)計(jì)，在這個(gè)過(guò)程中建議使用Power Designer或者Microsoft Visio(最好是.NET自帶的那個(gè)版本，而非2002或者2003的Professional)，使用數(shù)據(jù)庫(kù)建模工具而非直接進(jìn)行數(shù)據(jù)庫(kù)設(shè)計(jì)的理由有很多，我不想去夸夸其談的說(shuō)可以提高……那樣的空話。最直接一點(diǎn)的好處就是可以圖形化的設(shè)計(jì)你的數(shù)據(jù)模型，同時(shí)這些建模工具都提供了很好的文檔生成。數(shù)據(jù)建模一個(gè)最基本的原則就是能夠滿足你在需求文檔定義的所有業(yè)務(wù)數(shù)據(jù)描述，你整個(gè)業(yè)務(wù)流程中的所有數(shù)據(jù)都能夠找到直接或者間接的存儲(chǔ)，同時(shí)數(shù)據(jù)之間的關(guān)系必須滿足業(yè)務(wù)的種種約束（比如生日不可以比當(dāng)前時(shí)間大，員工數(shù)不可以是負(fù)值等等一些要求），這些業(yè)務(wù)約束可以通過(guò)觸發(fā)器和約束來(lái)表達(dá)，同時(shí)根據(jù)你業(yè)務(wù)的需要，可以適當(dāng)?shù)木帉?xiě)一些存儲(chǔ)過(guò)程用來(lái)實(shí)現(xiàn)你的業(yè)務(wù)邏輯。最重要的一點(diǎn)，請(qǐng)記住記得為所有設(shè)計(jì)元素寫(xiě)注釋?zhuān)驗(yàn)檫@些注釋正式用來(lái)描述你設(shè)計(jì)的最重要依據(jù)，也是你日后溝通的依據(jù)。

(3)    業(yè)務(wù)建模?？梢岳斫鉃樵O(shè)計(jì)，按照推薦的做法，一個(gè)系統(tǒng)應(yīng)該是分層設(shè)計(jì)的。比如微軟的Petshop就分離了Model、DAL、BLL和UI這樣的幾個(gè)層次。如果是基于.NET開(kāi)發(fā)的，我建議使用Rational XDE Plus for VS.NET，從數(shù)據(jù)庫(kù)到商務(wù)對(duì)象的映射目前有兩種推薦的做法。一個(gè)是使用或者自行開(kāi)發(fā)ORM框架用來(lái)完成數(shù)據(jù)到對(duì)象之間的映射，Java中可以使用Hibernate、JDO、EJB（Entity  Bean似乎不是推薦的做法等等，.NET也有一些ORM工具如NHibernate,ORMapper、OPF.NET等一些開(kāi)源項(xiàng)目，但是總體不算特別成熟。另外一種做法就是一個(gè)一個(gè)的編寫(xiě)你的Business Object了，但是你可以通過(guò)一些CodeGeneration工具讓簡(jiǎn)化你的重復(fù)工作，如果熟悉ASP.NET，建議使用CodeSmith。生成基本的代碼骨架之后，可以將這些代碼通過(guò)反向工程生成你的模型圖，然后再通過(guò)對(duì)象建模反復(fù)的校驗(yàn)?zāi)愕脑O(shè)計(jì)，當(dāng)然設(shè)計(jì)過(guò)程中良好的注釋是必要的，通過(guò)對(duì)象模型圖，你可以和團(tuán)隊(duì)成員很好的交流，在出現(xiàn)問(wèn)題的時(shí)候也能夠及時(shí)修正你的設(shè)計(jì)。TDD（測(cè)試驅(qū)動(dòng)開(kāi)發(fā)）也得到越來(lái)越多的人接受，如果問(wèn)我什么時(shí)候開(kāi)始寫(xiě)單元測(cè)試，那么我就建議從這個(gè)時(shí)候開(kāi)始寫(xiě)，原則也很簡(jiǎn)單，就是你所有的測(cè)試用例合起來(lái)能夠完整覆蓋你的業(yè)務(wù)要求，一旦發(fā)現(xiàn)測(cè)試用例無(wú)法繼續(xù)編寫(xiě)下去，那么存在問(wèn)題的可能是你的業(yè)務(wù)建模部分（大多情況下，不應(yīng)該回溯到數(shù)據(jù)建模階段），這個(gè)時(shí)候去修正你的設(shè)計(jì)。反復(fù)之后就能夠得到一個(gè)比較好初步設(shè)計(jì)框架。在此基礎(chǔ)上可以進(jìn)行部分的設(shè)計(jì)調(diào)整，使其更具擴(kuò)展性和靈活性，當(dāng)然在一些特殊要求（如性能）的情況下可以在設(shè)計(jì)完畢的時(shí)候降解你的設(shè)計(jì)，雖然會(huì)破壞一些設(shè)計(jì)原則，但是在必要的時(shí)候還是可以接受的。

(4)    業(yè)務(wù)實(shí)現(xiàn)。好了，這個(gè)時(shí)候是開(kāi)始編碼的階段了，這個(gè)時(shí)候開(kāi)發(fā)人員需要一些文檔，如需求文檔（可能是Word形式）、數(shù)據(jù)庫(kù)設(shè)計(jì)文檔（Power Designer或者Visio的，也可以通過(guò)文檔工具直接生成相關(guān)文檔），設(shè)計(jì)文檔，單元測(cè)試用例，通過(guò)上述的迭代，這些文檔都是非常完整的。此時(shí)Team Leader對(duì)于開(kāi)發(fā)人員的要求可以算比較簡(jiǎn)單了，按照設(shè)計(jì)文檔提供的接口要求實(shí)現(xiàn)，工作完成得第一原則是通過(guò)單元測(cè)試，因?yàn)榇a的骨架在設(shè)計(jì)階段已經(jīng)完成，同時(shí)對(duì)于各個(gè)接口提供了很好的文檔說(shuō)明，就能夠在很大程度上去約束開(kāi)發(fā)人員的散漫和隨意性，從而保證代碼的規(guī)范和可閱讀性。而規(guī)范的設(shè)計(jì)也保證了工作量的細(xì)化，從而能夠用相對(duì)量化的指標(biāo)去衡量一個(gè)開(kāi)發(fā)人員的具體工作量。開(kāi)發(fā)過(guò)程中有三方面工具推薦使用：NAnt實(shí)現(xiàn)編譯、測(cè)試、部署的自動(dòng)化；版本控制工具如（Visual SourceSafe）實(shí)現(xiàn)代碼的版本管理；利用BugTrack工具，從而有效地跟蹤和解決問(wèn)題。

(5)    測(cè)試和部署。大多軟件出現(xiàn)問(wèn)題的原因是沒(méi)有測(cè)試和模擬部署，要求開(kāi)發(fā)人員自行完成測(cè)試之后就開(kāi)始投入應(yīng)用，這樣帶來(lái)的問(wèn)題是顯而易見(jiàn)的，因?yàn)榇蠖嗳藢?duì)于自己的問(wèn)題是一種逃避心理，而百盒(White Box)的測(cè)試如果沒(méi)有通過(guò)一些工具有效地保障，讓開(kāi)發(fā)人員通過(guò)Code Review的方式是不切合實(shí)際的，對(duì)于目標(biāo)環(huán)境的模擬部署也是非常必要的，為了減少不必要的麻煩，建議大家可以使用VMWare或者微軟的Virtual Server 2005來(lái)進(jìn)行目標(biāo)應(yīng)用環(huán)境的模擬。

以上提到的只是開(kāi)發(fā)過(guò)程中的典型環(huán)節(jié)，通過(guò)一些工具來(lái)規(guī)劃化和加速軟件開(kāi)發(fā)過(guò)程是必要的，我上述提到的一些軟件是商業(yè)產(chǎn)品，在實(shí)際使用過(guò)程中建議購(gòu)買(mǎi)商業(yè)軟件或者尋找替代的解決方案。但是這些過(guò)程對(duì)于小型開(kāi)發(fā)團(tuán)隊(duì)是行之有效的，我沒(méi)有大型團(tuán)隊(duì)的應(yīng)用開(kāi)發(fā)，也許是另外一種場(chǎng)景，也不敢班門(mén)弄斧了。

2）  完善開(kāi)發(fā)團(tuán)隊(duì)的梯度建設(shè)

這個(gè)也是小公司存在的非常嚴(yán)重問(wèn)題，整個(gè)開(kāi)發(fā)團(tuán)隊(duì)的成員結(jié)構(gòu)是不合理，甚至是畸形的。不知道大家是否同意我這樣的說(shuō)法，大多公司都是一個(gè)所謂的技術(shù)牛人帶領(lǐng)一幫資歷比較淺的開(kāi)發(fā)人員進(jìn)行開(kāi)發(fā)的，一些最核心的工作都是由1-2個(gè)人來(lái)完成的，其他人實(shí)際上來(lái)說(shuō)只是輔助性的工作。不可否認(rèn)，高水平的開(kāi)發(fā)人員對(duì)于一個(gè)團(tuán)隊(duì)的效果是明顯的，但是同時(shí)帶來(lái)一個(gè)問(wèn)題，如果對(duì)于開(kāi)發(fā)人員脫控，就會(huì)形成“老板怕員工”的現(xiàn)象，這樣的管理弊病導(dǎo)致的結(jié)果就是內(nèi)部斗爭(zhēng)嚴(yán)重。設(shè)計(jì)、編碼、測(cè)試、管理等等各個(gè)環(huán)節(jié)人員的平衡是一個(gè)相對(duì)良好的組織架構(gòu)，同時(shí)盡量不要讓團(tuán)隊(duì)的梯度出現(xiàn)脫節(jié)，比如高水平的開(kāi)發(fā)人員和其他員工出現(xiàn)無(wú)法溝通的障礙（兩者完全不是在一個(gè)水平線上），低、中、高金字塔式的人才結(jié)構(gòu)對(duì)于團(tuán)隊(duì)的穩(wěn)定是至關(guān)重要的。這段最直接的是反映在人員招聘上，不是找便宜的或者找牛的，而是選擇合適公司自己定位的。

3）  注重技術(shù)資源的基礎(chǔ)積累

生存對(duì)于小公司是第一目標(biāo)，但是很多時(shí)候就以為如此，忽略了團(tuán)隊(duì)的基礎(chǔ)積累，在一些公共模塊的應(yīng)用上，在不同項(xiàng)目之間很多開(kāi)發(fā)人員采用的是Copy/Paste來(lái)做的。在日常的開(kāi)發(fā)過(guò)程中，應(yīng)該逐漸形成自己的代碼和組件甚至業(yè)務(wù)的積累。這些工作可以成為高級(jí)開(kāi)發(fā)人員日常工作的一部分。

4）  并行開(kāi)發(fā)

如果你不是一家貿(mào)易公司，那么請(qǐng)記得“人無(wú)我有，人有我優(yōu)，人優(yōu)我絕”，至于“人絕我偷”就免了阿，要讓自己的公司保持長(zhǎng)久的生命力，應(yīng)該永遠(yuǎn)保持比競(jìng)爭(zhēng)對(duì)手領(lǐng)先半步，那么這半步來(lái)自何處呢？除了保證為生存奮斗的商務(wù)開(kāi)發(fā)之外，前瞻性的開(kāi)發(fā)也是必要的，最好的做法就是根據(jù)公司實(shí)際情況，抽出部分人力并行下一代產(chǎn)品的開(kāi)發(fā)，在下一代的開(kāi)發(fā)過(guò)程中產(chǎn)生的一些比較好的產(chǎn)品可以直接利用與現(xiàn)行系統(tǒng)，因?yàn)闀r(shí)間周期相對(duì)允許的緣故，在下一個(gè)版本設(shè)計(jì)的時(shí)候來(lái)自時(shí)間的壓力會(huì)明顯比較少，這樣子帶來(lái)的好處是能夠設(shè)計(jì)更好的系統(tǒng)。因此研發(fā)和開(kāi)發(fā)并行對(duì)于一個(gè)小公司也是必要的，至于多少權(quán)重，那就根據(jù)實(shí)際情況去衡量了。

5）  加強(qiáng)內(nèi)部外部的溝通

在社區(qū)和其它途徑總是可以看到一些開(kāi)發(fā)人員在抱怨公司沒(méi)有給他們提供更好的交流技術(shù)，他們不知道市場(chǎng)，不知道需求，總是和客戶存在非常大的溝通障礙，那么作為一個(gè)管理人員，盡量創(chuàng)造這種溝通的機(jī)會(huì)也是非常必要的。

6）  堅(jiān)持員工培訓(xùn)

小公司員工跳槽的概率是遠(yuǎn)遠(yuǎn)大于規(guī)范的公司的，一個(gè)方面是待遇和福利跟不上，一個(gè)方面是無(wú)休止的加班，另外一個(gè)方面就是感覺(jué)公司沒(méi)有什么前景，學(xué)不到多少東西。第一個(gè)問(wèn)題只有隨著公司業(yè)務(wù)的不斷發(fā)展才能夠根本性的得到解決，第二個(gè)問(wèn)題通過(guò)規(guī)劃化的軟件開(kāi)發(fā)過(guò)程能夠減少不必要的重復(fù)和錯(cuò)誤，也能夠適度的得到解決（當(dāng)然了，碰見(jiàn)真的資本家，趕緊走人吧）。最后一個(gè)問(wèn)題在小公司是普遍存在的，那么給員工創(chuàng)造一個(gè)積極向上的發(fā)展空間，擁有更多的學(xué)習(xí)機(jī)會(huì)，對(duì)于管理人員是一個(gè)很大的挑戰(zhàn)，這些東西可以歸結(jié)為企業(yè)文化建設(shè)。對(duì)于小公司，因?yàn)橘Y源方面的限制，很多管理人員會(huì)忽略這個(gè)環(huán)節(jié)。

目前所在的公司就堅(jiān)持每周一次的技術(shù)培訓(xùn)和2周一次的職業(yè)規(guī)劃培訓(xùn)。我的做法比較簡(jiǎn)單，相對(duì)于其他開(kāi)發(fā)人員，我比較熟悉軟件開(kāi)發(fā)過(guò)程多一點(diǎn)，所以在開(kāi)始階段告訴他們?cè)谝粋€(gè)小型團(tuán)隊(duì)中怎樣有效的進(jìn)行協(xié)作開(kāi)發(fā)，如何定義軟件開(kāi)發(fā)的各個(gè)過(guò)程，各個(gè)環(huán)節(jié)中有哪些工具可以提高開(kāi)發(fā)效率，而這些工具具體是怎樣使用的。等到員工熟悉了大致的軟件開(kāi)發(fā)過(guò)程，可以每周探討一個(gè)技術(shù)點(diǎn)如.NET Remoting、Enterprise Services、Web Services、Http管道化等等，通過(guò)交流的方式讓團(tuán)隊(duì)成員了解更多開(kāi)發(fā)技術(shù)的具體細(xì)節(jié)，在適當(dāng)?shù)臅r(shí)候個(gè)人邀請(qǐng)一些技術(shù)上的朋友幫忙來(lái)公司做定期的交流。在職業(yè)規(guī)劃培訓(xùn)方面，則是由公司的兩位老大提供一些來(lái)自McKensin、Accenture這樣公司的培訓(xùn)經(jīng)驗(yàn)。

7）  明晰的崗位責(zé)任制

坦白說(shuō)，這個(gè)方面我目前還是沒(méi)有非常清晰的思路，希望得到各位的指點(diǎn)

崗位決定視角，從編碼人員、技術(shù)負(fù)責(zé)人、系統(tǒng)架構(gòu)師、技術(shù)編輯到部門(mén)管理人員，這5個(gè)不同的崗位也決定了看待問(wèn)題的不同方式，作為一個(gè)小公司的部門(mén)負(fù)責(zé)人，要做的事情很多很多，但是如何將最重要的事情做好呢，也希望和各位探討。