组建高效快速研发团队必要角色.docVIP

组建高效快速研发团队的必要角色　　作者一直从事与网站开发有关的项目，本文所述的高效快速反应的研发团队组成元素并非放之四海而皆准，也与网站开发项目有关，并且只是理论求证阶段，作者尚未有实际的实践证明，如果有不足或者欠缺之处，请指教。 　　在三层架构风靡IT界的当今，仍然有不少的公司对三层架构置之不理，具体原因不得而知。下面列出的场景不全面，但是也可以说明冰山一角。 　　1. 时间紧张，任何一个项目的客户都非常着急，公司也可以理解，程序员作为服务的最终实现人也比较着急，交付不了产品，客户不满意，公司受损失，个人的奖金也有相关的级联。为了DeadLine，不管怎样，把产品交付验收之后，公司拿到钱就皆大欢喜了。在这种利益驱使下，没有办法不抓紧时间以最快的速度实现产品代码的编写。那好吧，不择手段、分层不清晰、野路子、有问题百度一下等八仙过海，各显神通，之后就去喝庆功酒了，留下一堆只有自己才能勉强理解的代码。 　　2.技术部组织结构不健全。公司为了节省成本，招聘过多的初级程序员，缺少高级职称的人带领指导项目的完成。初级程序员比较多这个问题基本上不是大的问题，公司在组建之初，都会考虑找一个信得过、技术比较好的人担任技术总监，掌控负责软件产品的技术方面。接到一个项目后，经过简单的需求调研，项目经理把项目划分为子项目按人头分配任务，要求按期完成任务交给QA部门就万事大吉了。 　　还有更多的场景有待大家共同研究，在IT的项目管理中，组建项目团队是技术总监或者项目经理必须要做的一件事情。诸多书籍中都讲过，组建项目团队需要考虑项目团队需要什么样的角色，根据角色挑选合适的人才，大多数书籍中也讲解了如何面试潜在的团队成员。其中关键的部分，也是每个技术总监或者项目经理都需要思考的问题却无法一一说明白，即团队需要什么样的角色，如何确定这些角色，这些角色之间存在什么样的关系，每个角色最终需要交付什么样的产品，以及如何确保交付产品的质量。这个问题在不同的行业，不同的团队中有不同的答案，没有统一的答案，因团队的性质和规模不同而有差异。因此任何一本IT项目管理书籍都不会描述这个问题，因其不可能找到一个普遍的答案。以下是作者在开发基于SSH框架的WEB应用程序中关于团队角色的一些思考。 　　1.需求调研角色。在中小企业项目应用中，一般在销售把项目谈下来之后，客户想尽快的看到项目的效果，因此需要尽快的出来一个原型。客户对原型确认之后，项目团队也许会根据这个原型进行继续开发，或者重新制作，原型可以用原型工具生成。因此，需要一个需求分析角色对项目的整体需求进行把关和确认。这个角色一般是项目经理或者由项目经理直接指派的队友，其主要的作用是对客户的需求进行整理和确认，把客户的需求用程序员可以读懂的语言描述出来，其提交的内容为用户需求文档，要求无二义性，准确，并能被程序员实现。 　　2. 美工，美工的作用显而易见，就是设计漂亮的UI界面，让用户看起来赏心悦目，从感性上能有一个好的印象，最好能让用户感觉这个特别为他设计的界面比别人的好，钱没有白花，或许能在上级面前邀功。 　　3.UI工程师，这个角色的主要任务是根据美工设计的界面制作出静态网页，提交的内容为HTML集和一些JS代码，由于一些效果的特殊性，因此必须借助于JS来实现。一般的美工设计人员对于编程不熟悉，他们的使用PS等工具切割生成的HTML代码也不精简，或者样式需要重构等，UI工程师必须对这些代码进行重新整理，并对循环的代码块进行注释，以便于界面开发人员使用。提交的产品应该代码简介，格式明确，方便阅读。 　　4. action工程师，根据业务的需求写Action类(兼配置文件)以控制用户数据交互，主要依据UI工程师的结果并调用Service工程师写的接口。在Action中不执行业务逻辑，只做一些简单的界面逻辑判断和数据封装。比如把页面提交的数据封装为类的实例，或者从会话中取得用户的状态。 　　5.service工程师，根据业务的需求写service接口和实现(兼配置文件)，供Action工程师调用，service的实现依赖于dao工程师的接口。在service层，把action的调用作为一个业务进行封装，并返回业务执行的结果，比如，在action层调用登陆验证，在service层进行验证，验证成功后填写用户登录日志。是否填写用户登录日志这样的业务对于action的调用者是未知的，action只调用service的接口并对返回结果进行判断。 　　6. dao工程师，顾名思义，dao工程师提供dao接口和实现(兼配置文件)，供service层使用，dao层只关注的数据的存取，并返回封装后的结果。在dao层不应该包含任何业务逻辑判断的代码。 　　7.db工程师，根据业务需求设计满足业务需求的数据库定义，并对数据库进行相应的优化