(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/
