TA的每日心情 | 无聊 3 天前 |
---|
签到天数: 77 天 连续签到: 1 天 [LV.6]测试旅长
|
项目管理与软件开发的质量、效率、最终成果息息相关,本文主要讲述软件项目的风险评估、成本预算、
客户沟通、需要分析、开发管理、成品交付等多个流程。
在现今国内的项目的管理形式十分零乱,对管理欠缺重视,以致很多项目因为失去管理而最终折腰。
很多的实战形人才只重视于开发环节,而对其他的流程欠缺认识(包括本人),因而导致项目欠缺有条
理的、阶段化的管理。
本人是一个典型的只重视开发的管理者,在多次的教训中深刻地体会到管理的重要性,因而以此文章对
项目管理作出一个总结,当中存在很多的不足之处,敬请各位点评!
文件下载:项目管理流程.docx
风险评估
成本预算
客户沟通的过程
需求分析
面向对象程序设计(略)
开发管理
产品交付
一、 风险评估
软件项目风险是指在整个项目周期中所涉及的成本预算、开发进度、技术难度、经济可行性、安全管理
等各方面的问题,以及由这些问题而对项目所产生的影响。项目的风险与其可行性成反比,其可行性越
高,风险越低。软件项目的可行性分为经济可行性、业务可行性、技术可行性、法律可行性等四个方面。
而软件项目风险则分为产品规模风险、需要风险、相关性风险、管理风险、安全风险等六个方面:
1. 产品规模风险
项目的风险是与产品的规模成正比的,一般产品规模越大,问题就越突出。尤其是估算产品规模的方法,
复用软件的多少,需求变更的多少等因素与产品风险息息相关:
(1) 估算产品规模的方法
(2) 产品规模估算的信任度
(3) 产品规模与以前产品规模平均值的偏差
(4) 产品的用户数
(5) 复用软件的多少
(6) 产品需求变更的多少
2. 需求风险
很多项目在确定需求时都面临着一些不确定性。当在项目早期容忍了这些不确定性,并且在项目进展过程
当中得不到解决,这些问题就会对项目的成功造成很大威胁。如果不控制与需求相关的风险因素,那么就
很有可能产生错误的产品或者拙劣地建造预期的产品。每一种情况对产品来讲都可能致命的,这些的风险
因素有:
(1) 对产品缺少清晰的认识
(2) 对产品需求缺少认同
(3) 在做需求分析过程中客户参与不够
(4) 没有优先需求
(5) 由于不确定的需要导致新的市场
(6) 不断变化需求
(7) 缺少有效的需求变化管理过程
(8) 对需求的变化缺少相关分析等
3. 相关性风险
许多风险都是因为项目的外部环境或因素的相关性产生的。控制外部的相关性风险, 能缓解策略应该包括
可能性计划,以便从第二资源或协同工作资源中取得必要的组成部分,并觉察潜在的问题,与外部环境相关
的因素有:
(1) 客户供应条目或信息
(2) 交互成员或交互团体依赖性
(3) 内部或外部转包商的关系
(4) 经验丰富人员的可得性
(5) 项目的复用性
4. 技术风险
软件技术的飞速发展和经验丰富员工的缺乏,意味着项目团队可能会因为技巧的原因影响项目的成功。
在早期,识别风险从而采取合适的预防措施是解决风险领域问题的关键,比如:培训、聘请顾问以及为
项目团队招聘合适的人才等。关于技术主要有下面这些风险因素:
(1) 缺乏培训
(2) 对方法、工具和技术理解的不够
(3) 应用领域的经验不足
(4) 对新的技术和开发方法应用不熟悉
5. 管理风险
尽管管理问题制约了很多项目的成功,但是不要因为风险管理计划中没有包括所有管理活动而感到惊奇。在
大部分项目里,项目经理经常是写项目风险管理计划的人,他们有先天性的不足——不能检查到自己的错误。
因而,使项目的成功变得更加困难。如果不正视这些棘手的问题,它们就很有可能在项目进行的某个阶段影
响项目本身。当我们定义了项目追踪过程并且明晰项目角色和责任,就能处理这些风险因素:
(1) 计划和任务定义不够充分
(2) 对实际项目状态不了解
(3) 项目所有者和决策者分不清
(4) 不切实际的承诺
(5) 不能与员工之间的进行充分地沟通
6. 安全风险
软件产品本身是属于创造性的产品,产品本身的核心技术保密非常重要。但一直以来,我们在软件这方 面的
安全意识比较淡薄,对软件产品的开发主要注重技术本身,而忽略了专利的保护。软件行业的技术人员流动
是很普遍的现象,随着技术人员的流失、变更,很能会导致产品和新技术的泄密,致使我们的软件产品被它
公司窃取,导致项目失败。而且在软件方面关于知识产权的认定目前还没有明确的一个行业规范,这也是我
们 软件项目潜在的风险。
7. 回避风险的方式
(1) 以开发方诱导能保证需求的完整,使需求与客户的真实期望高度一致。再以书面方便形成《用户需求》
这一重要的文档,避免疏漏造成的损失在软件系统的后续阶段被逐步地放大。
(2) 设立监督制度,项目开发中任何较大的决定都必须有客户参与进行的,在该项目中项目监督由项目开发
中的质量监督组来实施。
(3) 需求变更需要经过统一的负责人提出,并且要用户需求的审核领导认可,需求变更应该是定期而不是随时
的提出,而且开发方应该做好详细的记录,让客户了解需求变更的实际情况。
(4) 控制系统的复杂程度,过于简单的系统结构,对用户来使用比例会有明显的折扣,甚至造成软件寿命过
短。反之,软件结构的过于灵活和通用,必然引起软件实现的难度增加,系统的复杂度会上升,这又会在实
现和测试阶段带来风险。适当控制系统的复杂程度有利于降低开发的风险。
(5) 从软件工程的角度看,软件维护费用约占总费用的55%~70%,系统越大,该费用越高。对系统可维护
性的轻视是大型软件系统的最大风险。在软件漫长的运营期内,业务规则肯定会不断发展,科学的解决此问
题的做法是不断对软件系统进行版本升级,在确保可维护性的前提下逐步扩展系统。
(6) 设定应急计划,每个开发计划都至少应该设定一个应急预案去应对出现突发情况和不可遇知的风险。
回到目录
二、 成本预算
1. 成本预算方式
(1) 自上而下的预算方法
自上而下的预方法主要是依据上层、中层项目管理人员的管理经验进行判断,对构成项目整体成本的子项目
成本进行估计,并把这些判断估计的结果传递给低一层的管理人员,在此基础上由这一层的管理人员对组成
项目的子任务和子项目的成本进行估计,然后继续向下一层传递他们的成本估计,直到传递到最低一层。
使用此预算方式,在上层的管理人员根据他们的经验进行的费用估计分解到下层时,可能会出现下层人员认
为上层的估计不足以完成相应任务的情况。这时,下层人员不一定会表达出自己的真实观点,不一定会和上
层管理人员进行理智地讨论,从而得出更为合理的预算分配方案。在实际中,他们往往只能沉默地等待上层
管理者自行发现问题并予以纠正,这样往往会给项目带来诸多问题。
自上而下更适用于项目启动的前期,与真实费用相差在30% ~ 70%之间。
Scrum使用自上而下的成本预算方式,它不会立即精确地确定成本,而是以最大限度容纳客户对未来产品要
求所产生的变更。
(2) 自下而上的预算方法
自下而上方法要求运用WBS(Work Breakdown Structure,工作分解结构)对项目的所有工作任务的时间和预
算进行仔细考察。最初,预算是针对资源(团队成员的工作时间、硬件的配置)进行的,项目经理在此之上再
加上适当的间接费用(如培训费用、管理费用、不可预见费等)以及项目要达到的利润目标就形成了项目的总
预算。自下而上的预算方法要求全面考虑所有涉及到的工作任务,更适用于项目的初期与中期,它能准备地评
估项目的成本,与真实费用相差在5% ~ 10%之间。
注解:WBS
WBS是面向提交成果对项目的分解,从提交成果的列表可以确定每个提交成果需要执行的活动。Scrum会对WBS
进一步细化,把一个迭代分解为一个或多个的工作包,再把工作包分解为细小的开发任务(一般开发任务的开
发周期在15个工作小时以内)。
2. 确定项目支出
总体成本预算就是结合下列多个成本预算方式综合计算的开发成本:
(1) 零基数预算
在成本预算的初期应该使用零基数的计算原则,而不可以使用类似于:以上一年总体费用加上20% 这样粗略
的方式计算项目成本。
(2) 软硬件成本、物品成本
物品成本是指类似于:服务器(RAM 硬盘 CPU NIC卡 RAID簇)成本、维护成本、机房租金、光纤通讯成本、
软件成本等的成本。
计算成本时需要考虑组装硬盘需时的长短,技术人员需要具备的质素,产品供应商能否提供保证质量,管理
时是否需要额外的管理人员这些多方因素。
(3) 软件许可证成本
(4) 外包成本
当使用类似:视频、短信、移动电信类服务、门户网站等子项目时可以考虑以外包形式完成,以降低开发成本。
(5) 人力资源成本
计算人力资源成本时应该使用以最高和最低的工作效率估算平均效率的方式,计算出人力资源的平均成本。
(6) 维修保养成本
回到目录
三、 客户沟通的过程
从客户沟通的方向出发来看,软件项目可分为:需求识别、方案定制、项目实施、项目结束等4个不同的阶段,
各个阶段都具有不同的沟通重点。
1. 需求识别阶段
(1) 文本沟通
在需求识别的前期,应该通过问卷、原型展示、界面展示、逻辑处理展示、准化文档模板等方式进行全方位多
角度的分析,随时将不明确之处反馈给客户,以期待客户解答。并以文本记录的方式建立需要分析书,并要求客
户审核需求分析书,以达到需要分析与客户的真实期望高度一致的结果。
(2) 业务逻辑沟通
在进行业务沟通时,应该了解客户的行业语言,以促进业务分析的过程,越过应用需求和开发之间的鸿沟。沟
通过程提倡以草图或者可视信息化的方式进行, 针对不同层面的企业用户提供最适合的操作界面。以多角度的方
式思考问题,要抓住需求重点,尤其是客户方领导所关注的创新类和实用类需求。
(3) 需求变更的规范化管理
需求变更在软件开发类项目中是可以理解的,但必须对需求变更做好规范化的管理,以避免出现需求无止境变
更的风险。需求变更必须由统一的负责人提出,并且由用户需求的审核领导者认可。需求变更的提出应该是定
期而不是随时的,开发方应该做好详细的文本记录,让客户了解需求变更的实际情况和开发方为之所付出的成
本代价。
2. 方案定制阶段
该阶段项目的主要任务是与客户共同制定一个以前期明确的需求、双方的资源、项目开始的阶段、实施的时间
约定、项目费用限制等为基础的具有可操作性的项目计划,从本阶段开始争取客户全面参与项目的管理,并以
双方的共同利益考虑项目实施的具体计划与风险规避。
3. 项目实施阶段
在该阶段,软件项目团队应该与客户共同领导项目的实施。同时,项目团队应实时评估客户满意度,并通过持续改
进的方式提高客户满意度,还应要求客户参加必要的培训,以及在必要时检查项目产品。在出现客户的需求变更
前,应主动与客户沟通交流,使客户充分了解项目的每个环节,以及变更带来的影响,减少需求变更。如果出现客户
需求变更,应与客户一起共同解决由变更引起的成本、进度、质量变化。
4. 结束阶段
该阶段主要进行项目成果的移交,并把系统交付给维护人员,帮助客户实现商务目标,结清各种款项。完成这
些工作后应该进行项目评估,审核此项目的成果并总结项目经验。
5. 售前人员注意事项
在产品型项目作为开发成果时,相关销售人员应该注意:对产品的推销不应该过分承诺。如果过分承诺,会给
后续的项目实施带来困难;一旦承诺没有兑现,也会降低客户满意度,影响今后合作。如果有附加承诺,一定要以
文本形式记录,让实施项目经理知晓并传达给项目组成员。
注解:在软件项目中,需要明确以下四种客户角色
A. 要明确最终使用部门和用户,要去了解他们现有的工作方式,要让他们知道项目的目标框架,知道项目要解决
他们的哪些困难,但绝对不是全部困难,这样可以较好的控制项目范围。
|
|