从程序员到项目组

发表于:2007-05-26来源:作者:点击数: 标签:
从 程序员 到项目组 作者:9pts 本文选自:WP MI 在互联网的时代,软件项目的成功更大程度上取决于项目小组中那个体的成熟度和能力,而非个别程序员的个人魅力。所以,如何从程序员准确定位到项目组就是一个非常重要的转折点。 微软的 Windows 彻底改变了用

程序员到项目组 

作者:9pts 本文选自:WPMI 

在互联网的时代,软件项目的成功更大程度上取决于项目小组中那个体的成熟度和能力,而非个别程序员的个人魅力。所以,如何从程序员准确定位到项目组就是一个非常重要的转折点。

微软的Windows彻底改变了用户使用计算机的方式,此后,软件业便进入了快速发展的黄金时期,并因此成为推动计算机网络应用的最重要源动力。如今,在.com公司纷纷凋零之际,软件业更加逆流而上,以致各发达国家竞相将软件工程提升到重点产业的战略高度。作为软件行业的最基本细胞,程序员也成为了当今最热门的一种职业。

但最初的程序员,就像一个个斗士,更多的包含了个人英雄主义的色彩。他们在数字和字符中挣扎,在激流中顺应变化,在曲折迂回中寻找出路,面对着太多的困苦与压力:首先要耐得住个人奋斗的寂寞;其次,还要承受得住压力,有查不完杀不净的BUG在等待,有日新月异的技术在更新;再其次,更要承担得起挫折。因为或许费尽心血开发出的产品一朝便成了垃圾,更或许走过多年才发现必须回到起点重新开始。这种种的困难全都渡过去,才能成就一个优秀的程序员。但整体而言,仅仅凭借几个、几十个,甚至几百个数字英雄却很难铸造出一个强劲的产业。

实际中,大多数人都把软件开发人员想当然地默认为程序员。的确,程序员这个原本默默无闻地在后台辛勤耕耘的角色随着计算机的发展空前重要起来。微软的比尔·盖茨成了无数程序员的梦想,但程序员并不代表软件开发的全部,甚至可以说编写代码仅仅是软件开发中相对简单的一小部分。众知周知,在近乎已成流水线的软件产业发展中,依靠简单的密集劳动或几个数字英雄绝对不可能从真正意义上解决企业经营和管理上的问题,所以,要开发出成熟有效的产品,就必须要有一个强有力的团队共同协作,在一个成熟严密的项目体制中,需要很多角色担任不同的分工和责任。项目的成功系数更大程度上取决于团队整体的成熟度和能力,而非个别程序员的个人魅力。

再看看国内市场,我国虽然在网络门户、电子商务的模仿、借鉴和推动方面丝毫不亚于西方发达国家,但是在软件项目管理和专业人才的培养方面却大大滞后。所以如何将一个个自由英雄更好、更有效地团结起来,组建出高效的开发小组,已成为越来越多管理者思考的重点。 本文将对程序员的个人定位与项目团队的组成与发展进行简要的分析,希望与大家共同探讨。

软件项目小组的角色分工

  软件项目小组大多是为实现一个特定目标而成立的团队,规模大小根据目标而定,从2个人到十几人甚至几十人、几百人不等,但通常都在20人以下。这样的小组集合了不同方面的专业人员,几乎每个做过开发的人员都会遇到以下的问题:

  项目无法按期完成,完成以后还要不断修补完善,象一场噩梦遥遥无期;

项目进行当中人员流失,产品夭折; 客户需求不断改变,永远对开发完成的产品不满意;

开发成员之间矛盾不断,互相抱怨,工程进展缓慢;

小组成员分工不均,工作分配失去平衡等等; ……

为了避免噩梦的再次发生,也许下面的建议对您会有所启发和帮助: 在项目小组成立的时候,一定要有个项目负责人,我们称之为组长或项目经理。一个项目的成功与否,项目经理是最关键的因素,古人云:一将无能,累死千军。可谓一针见血。

项目经理根据需求制定出开发的目标,并选择最合适的人员组成项目小组。一个比较完整的项目小组可能由以下表1所列的角色组成,当然,有些角色是在项目小组成员比较少的情况下完全可能由一个人兼任,但并不意味着这些角色可以轻易地忽略:

clearcase/" target="_blank" >cccccc" height="30">

角色性质

角色分工

项目管理人员

  • 项目经理
  • 产品经理
  • 技术经理

系统分析人员

  • 框架设计
  • 系统分析员
  • 软件设计师

商务分析人员

  • 业务流程分析员
  • 业务功能设计员

交互设计人员

  • 界面工程师

  • 交互流程分析员

数据库工程师

  • 数据库设计员

程序开发人员

  • 软件实施员

质量控制人员



技术支持人员

  • 售前工程师
  • 售后工程师

系统管理人员

  • 系统管理员
辅助设计人员
  • 专业美工
  • VI设计师




(表1)

软件开发无疑是人的智力结晶,所以选择最适合的人员参与小组是项目经理最重要的工作。这里要注意的是选择最合适的,而不一定是最优秀的或代价最昂贵的。

当小组人员落实的时候,开发前整个小组成员应该对以下的问题进行充分的讨论,并形成一致的意见:

  是否已经很清晰的理解了开发的需求和目标,并使每个人员充满斗志地准备开始完成共同的目标?

  是否制定了一套规范的、经过评测的、可复用的技术框架;

  每个人的角色分工是不是都非常清楚地落实了;

  是不是已经制定了开发过程中的周期划分及评估办法?而不是冒险等项目期限快到的时候才发现补牢已晚;

  项目管理人员是否有随时把握开发进度的有效手段?

  小组人员是否都互相认识而且熟悉;

  每个人是否都明白和他关联的角色是谁,相互之间的工作流程?

  是否忘了布置文档撰写及管理的方法或标准?

  定义项目小组各种角色的工作流程

如果每个小组成员都对即将开始的开发心中有数并跃跃欲试的时候,那么这就是一个很好的开头。

现在我们通过以下一份基本的角色及分工示例表2,把开发任务进行拆分,并定义每个角色的获得、处理、输出来表示各个角色之间的关联:

角色

主要职责

工作流程

获得

处理



输出



系统分析员

软件设计
系统建模
流程分析



获得需求(来源:商务工程师、项目经理)
获得(提取)系统相关的角色
获得(提取)系统相关的用例

数据映射分析
系统分析
流程分析
类分析
部署情况分析

输出系统模型工件文档(UML



界面设计师



用户界面设计

得到项目流程描述工件文档(来源:商务工程师、项目经理、系统分析员)

理解项目界面控件类型及限制
理解项目受益人使用习惯
理解项目流程
设计通用界面规范
设计特定流程界面规范

输出界面描述工件文档



数据库设计师

数据库设计

得到项目数据对象工件文档(来源:商务工程师、项目经理、系统分析员)

理解数据库设计要求
理解选定数据库功能及限制
设计通用数据库采用标准
设计特定数据对象的结构

输出数据库定义工件文档

程序员

代码实现

获取界面描述工件文档HTML等)(来源:界面设计师)
获取数据库定义工件文档(UML)(来源:数据库设计师)
获取对象定义工件文档(UML)(来源:系统分析员)
获取项目开发进程计划(来源:项目经理)

理解工件意图
解读原型prototype(UML)
理解开发规范
编码
版本控制
建立版本控制环境(CVS
获得项目初始工程文件(Java RAD工程,如Jbuilder)
获得最新工程源码(CVS update)
编码
保存工作结果(CVS commit)
模块调试
理解测试要点
  测试
  工作检查

输出程序源代码



美工

辅助VI企划设计


产品界面美工设计
美工设计

获取整体风格需求。(来源:项目经理)
获取特定流程风格需求。(来源:界面工程师)



美工设计
按要求做后期处理



输出界面模板

文档员

技术白皮书
使用手册
培训教材
演示文档

获得产品计划及功能描述。(来源:项目经理、界面工程师)
获得系统分析文档(来源:技术经理、系统分析员)

检测系统可操作性
编写技术白皮书
编写使用手册
编写培训教材
编写演示文档

输出各种文档



在小组中,每个人的工作都是与其他相关联的,因此,小组成员除了保证自己担负的任务的质量的同时,还需要关注其他关联角色的任务,假使界面工程师迟迟无法定义产品流程,美工人员也许只能望纸生叹,而美工人员不能将产品界面文件及早完成而任由程序员随意定义界面的话,后期重新美化的工作量可能大到重写一遍代码的地步。

因此,项目经理需要时时掌握小组每个成员的工作进度,并进行监督和协调。有经验的管理人员都知道,项目的计划和进度在实施中必不可少地会进行调整,这种调整可能来自于:

  客户的需求进行了补充或修改;

  工作量估算不准,造成进度不平衡;

  某个技术环节出现障碍,需要另外需求人员或帮助;

  有人不遵从开发规范,导致产品缺陷

在面对意料中的意外时,项目管理人员需要有应急解决的办法,从而保障开发持续稳定地向目标前进。

避免走向开发陷阱

一个成功的软件项目小组,需要时刻提防无时不在的陷阱,走出泥潭。

技术陷阱:技术是无止境的,开发人员往往热衷于追求新的技术而放弃了最擅长或最适用的技术,把项目当做练习新技术的试验田,造成产品的不成熟。

解决办法:想清楚是为技术而技术,还是为产品而技术?这不是个难以回答的问题。

需求陷阱:软件的功能的确越来越强大,虽然在开发前期制定了开发计划,但是开发过程中经常激发更多想象,从而试图不断增加新的功能,这种追求完美的心理可能导致的后果就是产品始终出不来,永远处于开发期。

解决办法:锁定需求,限制功能,需要的话,利用版本升级的原理,把功能分阶段实现,既保障产品的及时完成,又使小组产生成就感。

从程序员到项目小组

程序员除了坚持努力成为高级程序员以外,可以根据自身的性格、爱好和特长,并学习相关的技能,实现个人的提升,根据笔者个人的经验,对以上可能转换的角色做一些简要阐述:

===如何成为项目经理?

资深的开发经验并不一定能成为好的项目经理,项目经理对人员的管理、进度的掌握、质量的控制、成本的核算等等所做的工作已经远远超过代码本身,作为项目领导人,应随时能掌握先进的技术和方法并在适当的时机采用,管理整个项目小组往既定的目标前进。项目经理的角色不等于技术经理,也许项目经理实战开发能力并不是最优秀的,但却是小组的灵魂,所谓千军易得,一将难求。选择正确的人员、组织人员有效的工作是项目经理无法取代的价值。

===如何成为系统分析员?

从获得需求分析开始建立合理健壮的系统模型将决定项目开发的成败与否,也可以说系统分析员做的是项目最基础的工作。系统分析员需要掌握科学的分析方法和工具,具有优秀的大局观和前瞻能力,对系统的稳定性、安全性、适应性和扩展升级的能力进行控制。

===如何成为系统管理员?

从五月的红黑大战和种种报道来看,已经越来越多的人意识到了系统管理及网络安全的重要性,一个成熟的产品或项目只要是于网络相连就无法逃避安全的问题。系统管理员需要考虑服务器端的各种技术问题解决,管理不同的操作系统、数据库及服务,进行网络环境的架设和安全保障,系统管理员象卫士一样保障整个项目的顺利进行。

===如何成为质量控制工程师?

质量控制工程师负责指定项目的测试计划与管理、编写测试方案测试用例、执行测试计划;还需要负责与开发部门进行沟通与协调,确保软件测试的顺利进行;并对所测试的软件进行质量评估,并完成测试报告。随着项目的进行,质量控制工程师同时输出程序文档、课程文档和使用手册,因此需要更强的文字表达能力,同时为用户提供友好清晰的文档记录,使开发的质量得到有效的提高和保障。

===如何成为数据库工程师?

数据库技术的不断提高和越来越多大型数据库的应用,使数据库工程师的角色日显重要,掌握数据库结构和建立数据库的方法,进行合理的安全性设置,数据备份和恢复,数据传输和数据复制,对很多程序员来说是个新的挑战,如果说今后是网络的社会,也可以大胆地说网络就是数据库,数据库工程师的重要性毋庸置疑。动态数据仓库、智能数据库等先进技术的深入研究和应用,在数据库领域的工作将越发重要。

===如何成为商务工程师和技术支持工程师?

也许你已经厌倦了开发部门相对封闭的环境和紧张的工作,又不愿意放弃辛苦积累的经验,那么走出开发部,和市场部门一起从事售前售后的技术工作也许能让程序员重新焕发激情,利用自身的经验和技术实现客户的需求是件很美妙的感受。学会倾听和分析,准确把握重点和需求能使开发的工作事半功倍,有效提高用户的满意度,又何尝不是件快事?!

在互联网的时代,程序员是令人尊敬的,但是只有更多的程序员团结起来,组成高效的软件小组。才能最大地发挥潜力。所以,个人程序员一定要结合自已的兴趣和所长,看清方向,尽快融入团队和产业大潮,那一定会加快个人的成功。

附注:本文示例参照了北京朗川软件有限公司的软件小组管理模式


原文转自:http://www.ltesting.net