艾伟也谈项目管理,关于项目管理的一点体会

  这段时间,一直在负责一个项目的管理与开发。在时间短、任务紧,而团队人员又大部分是没有经验的菜鸟的恶劣情况下,我带领接近40人的团队,终于在客户规定的时间范围内如期交付产品。这其中,经历了需求变更、人员变动(因为其它任务,先后有近10人离开团队)等诸多问题,项目仍然取得成功了,不能不说有几分侥幸,但此外也有一些经验与教训可以与大家分享。

  一、项目开发方面

  需求

  项目应以需求为核心。一个项目是否能够成功,对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功,如果需求出现偏差,仍然是南辕北辙。由于EAS项目的特殊性,项目开发过程中能够与客户建立有效快速的沟通渠道,是项目成功的关键。

  需求必须获得客户的确认。通过需求调研与分析后获得的用户需求说明书,以及软件需求规格说明书都必须得到客户的签字确认。确认的内容包括项目的目标、范围以及项目需求功能点(用例)。EAS项目在前期对需求不够重视,导致在需求理解上出现了一些偏差,从而影响了项目的进度。幸而得到了及时的纠正,在项目管理部的协助下,所有需求都得了客户或客户代表的签字确认。从而使得项目在客户验收时,有了充分的保证。

  项目应确立专门的需求分析师。公司没有专门的需求分析师,不能不说是人员配备上的一大弊端。从EAS项目的开发过程中,我们就充分地认识到这一问题的严重性。需求的不断更改,客户迟迟未签字确认,原因正是在于我们没有专门的具有丰富经验的需求分析师。普通开发人员在调研需求以及撰写需求规格说明书时,总是会出现偏差或理解错误的地方。软件需求分析是一项重要且负责的技术,没有经过专门训练的需求分析师,通常会给项目带来隐患。

  项目应指定各个模块的需求接口人。只有这样,才能有效地保证项目组与客户的及时沟通,快速响应客户的请求与反馈。EAS项目在开发早期及时地确立了需求接口人,在一定程度上规避了需求变更给项目带来的风险。但是,确立的需求接口人未经过系统培训,在需求调研以及与客户沟通的过程中,工作表现只能说是差强人意。

  注意维护需求调研记录以及需求跟踪表。这一工作做得不够好。由于需求调研人不够专业,而项目经理以及需求分析负责人对这一过程还欠缺足够的重视,同时没有好的工具或流程来监控这一过程,使得需求调研记录没有发挥更大的作用。此外,需求跟踪也非常重要,毕竟,任何项目的需求都不是固定不变的,需求随时会发生变更,而开发人员实现的需求也可能会与客户的要求偏差。

  注意维护需求矩阵。项目经理对这一内容缺乏足够的重视与理解,项目开发过程体系中也缺乏好的需求矩阵文档模板。但是在项目中后期,项目及时撰写了EAS项目需求功能列表,并结合交付版本与客户进行了沟通和协商,从而规避了需求偏差的风险。

  控制需求变更。重视CCB的作用,同时应建立需求变更的响应机制。EAS项目组对于需求变更的响应还不够及时,这一点项目经理与项目管理小组要担负一定的责任。

  设计

  重视架构设计。EAS项目的成功,一定程度是源于我们有个优秀的框架开发小组,我们在项目立项之初就基本确定了整个系统的架构。其中虽然发生了一些变化,但核心架构仍然没有发生大的变化。由于,我们建立了稳定、简单的系统框架,可以极大地提高开发效率,规避了对框架的重复编码。

  善于对设计作出取舍。项目开发的三要素是成本、质量与进度。在保证质量的前提下,为了项目进度不出现大的偏差,EAS项目组并没有过分强调技术,特别是在考虑进度的情况下,牺牲了系统的部分可扩展性。虽然这为系统的后期维护带来一定隐患,但却能够有效地保证项目的进度。从EAS最初的架构设计来看,我们引入了Castle与AOP,试图简化ORM以及横切关注点例如日志、异常、权限、事务等功能的实现。同时,希望采用WCF,利用SOA思想建立松散耦合的面向服务应用程序。但随着客户需求的变化,我们果断地放弃了采用WCF的构想,同时又克服了技术困难,坚持了对Castle与AOP的使用,并为此成立了框架开发小组。事实证明,在技术的抉择上我们作出了正确的决定。

  重视UI原型设计。系统的原型设计与需求分析相辅相成。如果有好的原型版本交付给客户,则客户更能够理解系统的实现,促进沟通的有效性与准确性。在EAS项目中,我们从一开始就确立了原型设计小组,并在分析需求阶段,就开始了原型设计。这一做法无疑在客户沟通、需求确认、UI设计等方面都发挥了很大的作用。但是,我们在这一点上,由于缺乏专门的UI设计人员,因此,这一工作还存在很大的缺陷,甚至于UI的设计为迭代版本的交付带来了很大的障碍。在项目后期,关于UI的bug是最多。因此,我们认为在开发类似的WEB应用程序时,应尽早确立UI设计规范,以约束所有的UI设计。同时,必须培养专门的UI设计师,在开始原型设计时,就尽快完成UI交互的设计。并且,必须成立专门的UI设计小组,在需求阶段与需求分析师合作,在编码阶段与开发人员合作。

  测试

  测试成员应了解需求。如果不了解需求,测试人员无法编写正确的测试用例,同时在测试过程中,也可能因为错误地理解需求,从而导致报告错误的bug,影响开发人员效率。

  加强开发人员与测试人员的合作。开发人员必须及时响应测试人员提交的bug。而测试人员也应跟踪开发人员对bug的修复情况。

  测试之初必须确定测试原则,对bug的严重程度进行分级。同时,必须确定修复bug的优先级别。


  二、项目管理

  进度管理

  保证项目进度不出现大的偏差的前提是制定一个好的项目计划。必须根据项目规模,成员情况,技术难度等多方面考虑整个项目计划。如果项目的deadline已经确定,则必须采用一些方法来保障项目计划的完成。首先是选择符合项目的软件开发生命周期。通常情况下,并不建议采用瀑布开发方式。最佳的办法,应该是RUP或者敏捷开发,然后结合原型法制订项目计划。这样可以规避因为需求变更产生的风险。

  其次,要每日跟踪项目的进展情况。可以通过晨会、周会以及项目日报、项目周报了解项目进展情况。同时,需要为各个小组指定进度跟踪人,根据各个小组长的日报,判断实际的进度是否与计划出现偏差。
要制定项目进度偏差的应对方法。一旦项目进度出现了偏差,必须采取相应错误解决问题。或者通过加班、增加人手、申请项目进度等方法及时作出响应。

  及时向项目成员汇报项目进度情况。只有让各个项目成员了解到项目现状,才能够给每个成员增加压力,不至于松懈。同时,也能够使得每个成员能有一个目标,而不至于茫然失措。

  制定项目计划时,必须考虑阶段评审与同行评审的时间。这一点在EAS项目中做得不够好。其中原因也是由于项目进度本身较紧的缘故。

  注意维护项目进度跟踪表与项目进度偏差跟踪表。让项目管理部以及QA及时掌握项目进度,有利于对项目进度的管理。

  变更管理

  变更包括需求变更、人员变更。如果不控制好,两者对项目的进展都会带来灾难性的后果。需求变更在前面已经叙述,而EAS项目中发现人员变更的情况也非常严重,因此这里重点介绍关于人员变更的管理。

  如果发生人员进入的情况,那么对项目带来的通常都会是好的影响。但我们也必须注意如何让新成员更快地融入团队。整体上讲,如果需要新成员加入,发生变更的最佳时机是项目前期。如果在项目中后期加入新成员,无疑则意味着项目出现了灾难性的后果。而新增加的成员,由于不熟悉项目,所能带来好的影响也是有限的。如果不处理好新成员与老成员之间的合作关系,反而会带来负面影响。

  人员的退出很多时候是不可控的,同时对项目带来的影响也是不可估计的。为了将这些影响降到最低,就必须在项目开始之初就要确立编码规范。同时,还应该重视对文档的维护与更新。而在人员退出时,必须做好交接工作。同时,还应对这种变更进行合理的评估,并及时报告项目管理部,并与客户及时沟通。如果对项目进度有严重影响,应争取最大的努力取得客户的理解,提出项目延期的申请。

  风险管理

  要在项目开始之初就考虑到项目过程中可能出现的所有风险,是不现实的。但是,我们必须考虑对风险的管理,尤其是在制订项目计划以及创建团队的时候,考虑这一因素。风险有很多,包括需求的风险、进度的风险、质量的风险以及技术风险等。必须制定一套完整的风险管理计划,而一旦发生了风险,则必须及时响应,组织相关人员解决风险。不能忽略任何一个小的风险,否则一个小的风险到最后会造成大的灾难。风险的把握必须要有项目经理与系统架构师把关。

  成员管理

  不团结的项目组是无法保证项目的成功地。项目经理与项目组长在管理团队成员时,必须时刻注意成员状况,即使处理工作出现的矛盾与摩擦,随时保证团队合作精神得到最大程度的执行。

  持续地保证项目成员的士气非常重要。项目每取得一个阶段性的进展,必须告知全体成员,如此才能收获成功的信心。项目开发过程需要注意劳逸结合。一味地强制性加班,只能降低项目成员的工作效率。项目过程中,如能适当地开展一些活动,无疑能够让团队成员感受到项目组的集体气氛。在阶段实现的重要时刻,项目经理必须注意通过文字、语言等激励项目组成员。而项目经理的自信也是保证成员士气的一个关键。

  必须注意了解团队成员的心理状态与工作状态。项目成员的战斗力除了是个人的能力发挥之外,一个好的领导也是至关重要的。因此,必须选择合适的项目组长,通过他们掌握整个项目团队成员的工作进展。同时,还要了解每个成员的能力,以安排合适的角色与岗位。

  重视开发组与测试组以及项目管理小组的合作。项目组是一个整体,每个成员的角色不同,但大家都是团队的重要一员。

时间: 2024-07-28 22:06:29

艾伟也谈项目管理,关于项目管理的一点体会的相关文章

艾伟也谈项目管理,对项目管理的几点认识

自2007年参加工作以来,参与的项目也有好几个了,但都是以项目成员的角色参与,从来没有以项目经理的角色参与项目.中国有句古话叫"旁观者清",同一个问题站的角度不同,可能会形成不同的结论.下面我就以一个普通项目成员的角度谈一下对项目管理的几个看法,希望大家给予指正. 1. 团队成员选择 人员选择要谨慎,要尽量选择合适的人员,在选择团队成员时要重点考虑其团队合作能力.编码可读性.能力和项目的匹配度等因素. 2. 项目远景的确定 项目初期项目经理需要和高层以及客户协商,定下项目的远景目标(即

关于项目管理的一点体会

"1人100个月完成的项目,不是100个人1个月就可以完成." 项目管理是让项目活动中相互竞争的各类制约因素:质量.进度.资源.风险等取得平衡的艺术,同时也是平衡项目干系人的各种需要.关注和期望,带领不同的人朝着相同目标迈进的领导艺术. 成功的项目管理可以简单理解为:按时.在预算内+满足产品需求+满足质量需求 地完成项目. 以下是我对项目管理的一点体会记录. 需求等级 视觉 A:图片没有分享功能吗? 技术 K:图片有链接转发分享.微博或邮件形式分享等多种分享,全部开发的话需要推延时间表

【原创】C#玩高频数字彩快3的一点体会

购彩风险非常高,本人纯属很久以前对数字高频彩的一点研究.目前已经远离数字彩,重点研究足球篮球比赛资料库和赛果预测. 这是一篇在草稿箱保存了1年多的文章,一直没发现,顺便修改修改分享给大家.以后会有更多关于足球和篮球体育彩票的玩法分析,希望大家关注. 本人不算专业程序员,但经常敲代码玩玩.上学时研究的是伪随机数这个东东,因此对彩票就情有独钟,从10年开始,就开始研究双色球,其中软件版本改了又改,但一直没有实际操作过,原因就是双色球的投注量太大.所以这1年多就没研究了.最近一次偶然的机会,发现了"高

关于建设行业技术论坛的一点体会

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 行业技术论坛不同于一般的娱乐性.地方性生活论坛,它的特点是: 1. 会员大部分都来自同一个行业. 2. 论坛的主要功能是提供技术交流的平台. 我们几个志通道和的朋友在业余的时间创办了橡塑与弹性体论坛,从2007年到现在,尽管论坛发展的还不是很大,但这几年在建论坛的过程中,还是有不少的收获,其中关于建设行业技术论坛的一点体会,现在拿出来和大家分

艾伟也谈项目管理,我是如何带领团队开发项目的

最近有不少朋友写信问我一些关于团队开发的问题,由于这段时间有些忙,没有回复.今天写一篇这方面的文章向大家介绍一下我是如何带领团队开发工作流项目的 关于团队建设,项目管理的文章网上已经有很多了,在这里我就不谈这些理论了,直接给大家展示一个我在 项目开发方,后台服务开发方式,前台UI开发方式,后台服务与前台UI对接方式,代码文档,页面的开发文档,源码管理,单元测试,以及单元测试文档,实现思路设计文档,数据库文档,数据库设计规范,编码规范,操做数据的方法命名规则 方面的一些片断,这是一个为期6个月的工

艾伟也谈项目管理,编程习惯

文/Alexey Radul 译/程显峰 原文地址:http://web.mit.edu/~axch/www/programming_habits.html 近年来,我对编程艺术有很多体会.过后,我发现有些体会是错的:有些体会我遗忘了但又重新感受到:而另外有些则是必然会发现的.我还完善了一套项目管理的好习惯,这些习惯包括我自己的,或者小组的,抑或是更大的,公司内部的.一方面,这些习惯对软件的成功开发是至关重要的(太小或者纯粹巧合的不算),另一方面,这些习惯也不是什么高深莫测的东西,较小的篇幅就可

艾伟也谈项目管理,我也发软件开发团队的思考(侧重点是人员)

//上个月给我们老板的mail.洋洋洒洒6000多字. //为了方便公开,改了一下.以致可能有些地方前言不搭后语. //不管他同意不同意,先在我们组实行了再说. //请多大家多提提意见,日后看有没有机会找老板当面交流 经历的几个项目,项目的进度老是不尽如人意.更重要的是市场的开拓因为这些项目拖住了后退而无所作为. 我们现有的情况是:项目期限和最开始的保守估计都相去甚远,最后提交给客户的产品60%都是最后一个多月开发出来的,还有20%左右是以前就固有的固定模块.这几个项目我参与了编码,我对整个系统

艾伟也谈项目管理,我的项目管理观点

    公司要我给项目经理做一个培训,关于项目经理的做事情的方法和观点方面.我就采用了Workshop的方式,Workshop不是会议模式,而是侧重于交流会谈的一种模式,毕竟大家都是项目经理,并非说我的做法就是对的,所有的一切都是自己的经验之谈,所以我只是说大家彼此分享经验,交流心得.我把我所要分析的内容大概做了一个讲义,也希望更多人能够参与到这个Workshop中.项目经理好做吗?      项目经理好做吗?好做!项目经理好做吗?不好做.不同的人.不同的态度.不同的方法,其结果也就存在有极大的

艾伟也谈项目管理,软件架构引言之项目管理的问题

软件架构引言之项目管理的问题   很多朋友都有过或者正在管理一个或者多个软件项目,那么我的文章就从这个问题开始:如果单纯从表象来说,软件项目管理过程中暴露的最大问题是什么?   不同的人的会有不同的答案,但是大致这样的答案我想大部分人都是会认可的,那就是"进度拖延".进度拖延当然是表象之一了,其他诸如质量不过关.功能不完整等等,我觉得都是和进度拖延密切相关的.很多项目经理都想去做那些认为是十分必要的事情,比如计划.测试等,但是"没有时间".为什么会没有时间?等到项目