//转自csdn liuruhong
我不是职业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个不同的岗位也决定了看待问题的不同方式，作为一个小公司的部门负责人，要做的事情很多很多，但是如何将最重要的事情做好呢，也希望和各位探讨。
