岗位决定视角

从正式离开杂志社到新公司上班也已经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.ltesting.net