關鍵字：崗位 決定 視角
從正式離開雜志社到新公司上班也已經1周多的時間，加上春節這個空隙的折騰，，離開媒體也接近一個月，在此之前，很少去考慮過有關不同崗位之間考慮問題的視角，在雜志社一年的時間也沒有真正靜心下來去寫一些技術架構或者管理方面的文章，我想更多的是因為沉淀不夠的原因。
有些主題注定會找罵，其實理由很簡單，因為無知和觸碰一些本來不應該屬于自己的視角。所以寫本文的開始我就做好了被打擊的準備。從2002年大學畢業到現在也快接近上年，加上大學畢業之前2年多的工作經驗，在這個浮躁的IT也算不老不少的人了。從Coder到Technical Leader再到Architect到《MSDN開發精選》的Editor，再到如今另外一個方向的工作，雖然層次始終不高，但是依舊覺得比較幸運，因為嘗試了大多人希望的職位。
如果將我自己從事過的崗位簡單的歸納，應該可以描述成下面的崗位
Coder：完成Technical Leader指定的模塊功能，擁有良好的編碼風格和一些細節實現技巧
Technical Leader：根據項目經理或者產品經理（國內大多比較少區分這兩個角色）指定的任務，協助Architect或者Analyst實現系統設計，指導和監督Coder完成開發任務，同時承擔一些技術難題的解決。
Architect:從技術和業務的角度對應用系統或者產品進行抽象，進而設計一個適用于解決方案的模式。簡要地說是抽象和分離軟件產品中的共性問題，提供一個解決這些共性問題的方法論（不是某一個方法）。從這個角度來講，系統架構師可以分成兩種類型：一是提供解決方案的技術實現，一個是提供業務的抽象（這是我個人的理解）。與此同時，可擴展性、可伸縮性、安全性、性能等等這些東西成為Architect關注的重點，他們不再具體關注某一個業務功能的具體代碼實現，而是在一個更高層次上考慮系統的總體結構，諸如子系統劃分、組件分布、消息通信等等方面的東西。
Editor:恰當的說是技術編輯，而不是純粹意義的編輯，所以它的第一要素是技術性，而非文字。這里我要感謝我在雜志社的搭檔孟巖先生，在短短的一年時間內他教會了我許多東西，也知道了許多事情可以從Non-Technical ViewPoint去看待。很多大學同學和朋友問過我做編輯和作程序有什么區別，我想最大的不同依舊是視角，作為一個合格的技術編輯，首先要求有比較扎實的技術功底，然后有開拓的視角和接納新知識的能力，最后才是其文字表達功底（就我個人認為，在這幾個方面孟巖和熊節先生做得非常出色，所以也就理所當然地稱為國內頂尖級的技術編輯）。作為一個編輯最重要的使命就是傳播，那么如何在這種信息爆炸的時代將最有用的信息通過最有效的途徑傳播給需要接受新知識的人，除了傳統的平面媒體和大家所熟知的論壇，Blog是一個非常有效的形式，它能夠讓讀者和身份為技術編輯的Bloger在第一時間得到最好的交流。所以技術編輯應該更多的是能夠將自己對于技術的理解和對于說了解的東西盡快地讓更多人了解，雖然很多IT雜志社比較傾向編輯不用寫稿，而是掌握大量的作者資源，然后有效地利用這些作者資源。對，本身沒有錯，但是在IT卻不是行的很通，所有做技術的都佩服Orielly的技術編輯，原因無它，因為那幫人拋開編輯的生活，每個都是技術上的大佬。獨立技術評論或者產業評論在許多時候成為一個技術編輯可以和他人溝通的基本條件，“英雄惺惺相惜”的局面在開發人員中出現的概率遠遠高于其他人群。因此在這個崗位上對于技術和文字的要求是并行的，或者前者重一點，只是相對于Coder,關注的層次和方向已經截然不同。也正是因為如此，在雜志社一年的時間雖然給朋友的公司做過一些技術咨詢，卻發現自己寫代碼的能力正在退化（寫代碼明顯比較慢）。
Manager：請記住永遠不要用Business-Card上面的Title去看待一個人的崗位或者說職位，這點在外企尤為明顯，做商務或者市場的沒有一個不是經理:)，不過仔細的看他們英文的Title就能夠比較準確的反映出這個人在公司的崗位。在我經歷中，名片上很早就出現經理的字樣，但是客觀的說，那只是公司的商業因素決定的，大多時候所謂的項目經理等等是等同于Team Leader，是一個工作過程的臨時角色，而不是在公司行政體系中的崗位劃分。在做Coder的時候，我更多的是關心某個API的使用，能夠寫出一段賞心悅目的代碼是一件非常有成就感的事情，在做技術負責人的時候依舊關心的是技術，這個時候需要考慮針對人的分工，根據每個人不同的技術特點進行分工，然后再上級領導指定的時間內完成工作。而Architect從大多人來說，應該是相對不錯的崗位，它更多的是關心技術或者特定領域行業業務的抽象，我們可以簡單的認為Architect和Consultant的工作和比較接近的，不同的是Architect給公司干，Consultant給別的公司干，當然了，我這里提及的是技術顧問，而非大多咨詢公司的泛意義上的顧問。Architect總體上來說是一個和事情打交道居多的職位，是Non-Leadership，因為沒有涉及到太多人的因素。
當我第一天上班，家里的老大就提醒我需要注意一個Technical Leader和Manager是兩個差距比較大的角色，前者更多的是對事情而言的，而后者更多的是針對人。比如團隊建設，人才組織結構，員工培養計劃，激勵和考評機制和資源調度安排等等。在此之前，對于工作大多考慮的是如何爭取資源，而作為一個管理人員，更多的是考慮利用將有限資源最大化（嘿嘿，資本家和資本家走狗的本質）。
我不是職業IT經理，也沒有太多的管理經驗，雖然之前做過或多或少的管理工作，但是和一個崗位本身真正所從事的事情差距甚遠，因為如下只是我個人的一些理解，也請各位看官原諒我的無知和賣弄。一個小型公司的開發部門負責人需要做以下事情（至少吧，雖然還有其他許多事情）
1） 規劃化軟件開發過程
我不是一個軟件工程專家，甚至對于目前的大多軟件工程方法學不是特別感冒，但是我從來不去拒絕規范化的軟件開發過程，就如許多人問過我是否要采用CMM/CMMI或者RUP進行軟件開發時，我首先會去確認他們的團隊規模，通常來說，不超過15個人的開發團隊采用這些軟件工程的方法學并不能夠帶來明顯的好處，因為CMM/CMMI或者RUP對于角色的定義太明晰，雖然提供了定制的可能，但是對于國內大多的軟件公司而言，15個人的開發團隊應對的不僅僅是一個項目，更多時候被分離成了3個孤立的團隊，這個時候5個人的開發團隊在項目實施過程中很多角色注定是重合的，相信大家應該知道太多角色重合的結果是帶來崗位職責的沖突，對于大多數人而言，處理好這些沖突不是那么容易的。
里程碑和迭代總是被忽視，因為大多小公司的開發人員沒有經歷過相對系統的培訓，也就不是特別理解軟件開發過程，他們更多的是按照上級分配的任務去完成工作，稍有經驗的開發人員都會知道，這些東西的欠缺是非常致命的。最直接的結果就是無法控制項目進度和成本核算，更多的是依賴于個人的感覺“大約、估計、差不多”在現有資源的情況下完成指定工作。于是加班就成為了家常便飯，大多是為了在指定的時間之前完成任務。
通過一些輔助工具能夠能夠幫助小型開發團隊明顯的提高工作效率和里程碑的界定。比如建模工具Visio，Rational XDE，數據庫建模工具Power Designer，代代碼生成工具如CodeSmith，文檔和測試工具（NDoc,NUnit/NMock）及其批處理工具（NAnt）等等，這些工具能夠很大程度的幫助開發人員完成一些枯燥無味的重復性開發工作，從而將精力集中在核心業務的實現。
我們可以簡單的描述一個軟件開發過程能夠使用到的工具，當然這里提到的沒有太多的軟件工程方法學，只是從實用的角度來看利用一些已有的工具能夠較少軟件開發中的重復，同時提供相對明晰的里程碑界定：
(1) 定義需求。對于小型軟件開發，建議不用引入太復雜的開發工具（不知道大家的感覺如何，使用UML來進行業務建模對于大多開發人員是存在困難的），因為大多人習慣用代碼去表述業務邏輯，諸如Use Case，時序圖、活動圖等等，對于非專業技術人員而言太抽象，UML的提出是為了建立一種統一標準的溝通語言，讓所與參與者能夠統一種符號去表達思想，可是在國內目前的實際情況而言，這些UML恰恰讓許多人無法理解。對于大多軟件開發而言，我們需要的僅僅是一份開發人員的文檔，簡單來說文檔必須包含業務要求和技術要求兩部分。業務部分包含核心的業務流程圖和列表形式的業務描述，技術要求具備一些基本的要求如整合現有IT系統、技術模型等等就足夠了，對于大多數開發出生的系統分析員而言，有這個文檔就可以開始做設計了，那么有了這個文檔是不是全部足夠了呢？顯然不是，如果我告訴你是又多了一次被鄙視的機會了。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/