岗位决定视角

从正式离开杂志社到新公司上班也已经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系统、技术模型等等就足够了，对于大多数开发出生的系统分析员而言，有这个文档就可以开始做设计了，那么有了这个文档是不是全部足够了呢？显然不是，如果我告诉你是又多了一次被鄙视的机会了。

(2)    数据建模。你可以简单的理解成数据库设计，在这个过程中建议使用Power Designer或者Microsoft Visio(最好是.NET自带的那个版本，而非2002或者2003的Professional)，使用数据库建模工具而非直接进行数据库设计的理由有很多，我不想去夸夸其谈的说可以提高……那样的空话。最直接一点的好处就是可以图形化的设计你的数据模型，同时这些建模工具都提供了很好的文档生成。数据建模一个最基本的原则就是能够满足你在需求文档定义的所有业务数据描述，你整个业务流程中的所有数据都能够找到直接或者间接的存储，同时数据之间的关系必须满足业务的种种约束（比如生日不可以比当前时间大，员工数不可以是负值等等一些要求），这些业务约束可以通过触发器和约束来表达，同时根据你业务的需要，可以适当的编写一些存储过程用来实现你的业务逻辑。最重要的一点，请记住记得为所有设计元素写注释，因为这些注释正式用来描述你设计的最重要依据，也是你日后沟通的依据。

(3)    业务建模。可以理解为设计，按照推荐的做法，一个系统应该是分层设计的。比如微软的Petshop就分离了Model、DAL、BLL和UI这样的几个层次。如果是基于.NET开发的，我建议使用Rational XDE Plus for VS.NET，从数据库到商务对象的映射目前有两种推荐的做法。一个是使用或者自行开发ORM框架用来完成数据到对象之间的映射，Java中可以使用Hibernate、JDO、EJB（Entity  Bean似乎不是推荐的做法等等，.NET也有一些ORM工具如NHibernate,ORMapper、OPF.NET等一些开源项目，但是总体不算特别成熟。另外一种做法就是一个一个的编写你的Business Object了，但是你可以通过一些CodeGeneration工具让简化你的重复工作，如果熟悉ASP.NET，建议使用CodeSmith。生成基本的代码骨架之后，可以将这些代码通过反向工程生成你的模型图，然后再通过对象建模反复的校验你的设计，当然设计过程中良好的注释是必要的，通过对象模型图，你可以和团队成员很好的交流，在出现问题的时候也能够及时修正你的设计。TDD（测试驱动开发）也得到越来越多的人接受，如果问我什么时候开始写单元测试，那么我就建议从这个时候开始写，原则也很简单，就是你所有的测试用例合起来能够完整覆盖你的业务要求，一旦发现测试用例无法继续编写下去，那么存在问题的可能是你的业务建模部分（大多情况下，不应该回溯到数据建模阶段），这个时候去修正你的设计。反复之后就能够得到一个比较好初步设计框架。在此基础上可以进行部分的设计调整，使其更具扩展性和灵活性，当然在一些特殊要求（如性能）的情况下可以在设计完毕的时候降解你的设计，虽然会破坏一些设计原则，但是在必要的时候还是可以接受的。

(4)    业务实现。好了，这个时候是开始编码的阶段了，这个时候开发人员需要一些文档，如需求文档（可能是Word形式）、数据库设计文档（Power Designer或者Visio的，也可以通过文档工具直接生成相关文档），设计文档，单元测试用例，通过上述的迭代，这些文档都是非常完整的。此时Team Leader对于开发人员的要求可以算比较简单了，按照设计文档提供的接口要求实现，工作完成得第一原则是通过单元测试，因为代码的骨架在设计阶段已经完成，同时对于各个接口提供了很好的文档说明，就能够在很大程度上去约束开发人员的散漫和随意性，从而保证代码的规范和可阅读性。而规范的设计也保证了工作量的细化，从而能够用相对量化的指标去衡量一个开发人员的具体工作量。开发过程中有三方面工具推荐使用：NAnt实现编译、测试、部署的自动化；版本控制工具如（Visual SourceSafe）实现代码的版本管理；利用BugTrack工具，从而有效地跟踪和解决问题。

(5)    测试和部署。大多软件出现问题的原因是没有测试和模拟部署，要求开发人员自行完成测试之后就开始投入应用，这样带来的问题是显而易见的，因为大多人对于自己的问题是一种逃避心理，而百盒(White Box)的测试如果没有通过一些工具有效地保障，让开发人员通过Code Review的方式是不切合实际的，对于目标环境的模拟部署也是非常必要的，为了减少不必要的麻烦，建议大家可以使用VMWare或者微软的Virtual Server 2005来进行目标应用环境的模拟。

以上提到的只是开发过程中的典型环节，通过一些工具来规划化和加速软件开发过程是必要的，我上述提到的一些软件是商业产品，在实际使用过程中建议购买商业软件或者寻找替代的解决方案。但是这些过程对于小型开发团队是行之有效的，我没有大型团队的应用开发，也许是另外一种场景，也不敢班门弄斧了。

2）  完善开发团队的梯度建设

这个也是小公司存在的非常严重问题，整个开发团队的成员结构是不合理，甚至是畸形的。不知道大家是否同意我这样的说法，大多公司都是一个所谓的技术牛人带领一帮资历比较浅的开发人员进行开发的，一些最核心的工作都是由1-2个人来完成的，其他人实际上来说只是辅助性的工作。不可否认，高水平的开发人员对于一个团队的效果是明显的，但是同时带来一个问题，如果对于开发人员脱控，就会形成“老板怕员工”的现象，这样的管理弊病导致的结果就是内部斗争严重。设计、编码、测试、管理等等各个环节人员的平衡是一个相对良好的组织架构，同时尽量不要让团队的梯度出现脱节，比如高水平的开发人员和其他员工出现无法沟通的障碍（两者完全不是在一个水平线上），低、中、高金字塔式的人才结构对于团队的稳定是至关重要的。这段最直接的是反映在人员招聘上，不是找便宜的或者找牛的，而是选择合适公司自己定位的。

3）  注重技术资源的基础积累

生存对于小公司是第一目标，但是很多时候就以为如此，忽略了团队的基础积累，在一些公共模块的应用上，在不同项目之间很多开发人员采用的是Copy/Paste来做的。在日常的开发过程中，应该逐渐形成自己的代码和组件甚至业务的积累。这些工作可以成为高级开发人员日常工作的一部分。

4）  并行开发

如果你不是一家贸易公司，那么请记得“人无我有，人有我优，人优我绝”，至于“人绝我偷”就免了阿，要让自己的公司保持长久的生命力，应该永远保持比竞争对手领先半步，那么这半步来自何处呢？除了保证为生存奋斗的商务开发之外，前瞻性的开发也是必要的，最好的做法就是根据公司实际情况，抽出部分人力并行下一代产品的开发，在下一代的开发过程中产生的一些比较好的产品可以直接利用与现行系统，因为时间周期相对允许的缘故，在下一个版本设计的时候来自时间的压力会明显比较少，这样子带来的好处是能够设计更好的系统。因此研发和开发并行对于一个小公司也是必要的，至于多少权重，那就根据实际情况去衡量了。

5）  加强内部外部的沟通

在社区和其它途径总是可以看到一些开发人员在抱怨公司没有给他们提供更好的交流技术，他们不知道市场，不知道需求，总是和客户存在非常大的沟通障碍，那么作为一个管理人员，尽量创造这种沟通的机会也是非常必要的。

6）  坚持员工培训

小公司员工跳槽的概率是远远大于规范的公司的，一个方面是待遇和福利跟不上，一个方面是无休止的加班，另外一个方面就是感觉公司没有什么前景，学不到多少东西。第一个问题只有随着公司业务的不断发展才能够根本性的得到解决，第二个问题通过规划化的软件开发过程能够减少不必要的重复和错误，也能够适度的得到解决（当然了，碰见真的资本家，赶紧走人吧）。最后一个问题在小公司是普遍存在的，那么给员工创造一个积极向上的发展空间，拥有更多的学习机会，对于管理人员是一个很大的挑战，这些东西可以归结为企业文化建设。对于小公司，因为资源方面的限制，很多管理人员会忽略这个环节。

目前所在的公司就坚持每周一次的技术培训和2周一次的职业规划培训。我的做法比较简单，相对于其他开发人员，我比较熟悉软件开发过程多一点，所以在开始阶段告诉他们在一个小型团队中怎样有效的进行协作开发，如何定义软件开发的各个过程，各个环节中有哪些工具可以提高开发效率，而这些工具具体是怎样使用的。等到员工熟悉了大致的软件开发过程，可以每周探讨一个技术点如.NET Remoting、Enterprise Services、Web Services、Http管道化等等，通过交流的方式让团队成员了解更多开发技术的具体细节，在适当的时候个人邀请一些技术上的朋友帮忙来公司做定期的交流。在职业规划培训方面，则是由公司的两位老大提供一些来自McKensin、Accenture这样公司的培训经验。

7）  明晰的岗位责任制

坦白说，这个方面我目前还是没有非常清晰的思路，希望得到各位的指点

岗位决定视角，从编码人员、技术负责人、系统架构师、技术编辑到部门管理人员，这5个不同的岗位也决定了看待问题的不同方式，作为一个小公司的部门负责人，要做的事情很多很多，但是如何将最重要的事情做好呢，也希望和各位探讨。

文章来源于领测软件测试网 https://www.ltesting.net/