项目管理者联盟 | 中国工程管理网 | 中国研发管理网   会员中心 资料库 博客 圈子

PMI-ACP®认证

适合敏捷开发项目
敏捷项目管理最佳实践

网络课程

PMI-PBA®认证

重视项目商业分析
商业价值与需求分析能力

网络课程

NPDP®认证

产品管理国际认证
全球产品管理最佳实践

网络课

PMP®认证

单项目管理经典指南
年轻项目经理首选

北京 | 直播 | 录播

PgMP®认证

大型复杂项目全球标准
定位高级项目管理层

网络班

PfMP®认证

链接战略与项目
实现组织资源投资回报

全球直播

软考项目管理

信息系统项目管理师
系统集成项目管理工程师

计划 | 报名 | 经验

论坛
价值源于交流与分享
会员区:
登陆ID 密  码
功能区: 公告建议 | 帖子搜索 | 管理团队 | 荣誉版主 | 帮助手册






 项目型组织  项目管理  工程项目  科技项目  项目化管理  管理软件  资格认证  职业休闲
EPM体系与流程 综合集成管理 总承包管理 IT软件开发 项目型制造 P3E/P6 PMP | PgMP 职业发展探讨
组织与人力资源 进度,范围,成本 国际工程 生物制药 专业服务 微软PROJECT IPMP | PRINCE2 管理学堂
项目管理信息化 团队建设与沟通 房地产 汽车设计开发 生活项目 PowerOn专版 软考项目管理 英语角|读书版
多项目与大项目 质量与风险 监理与咨询 手机数码 文体娱乐 注册建造师 房车吃游
PMO建设与管理 采购与合同 工程设计 项目管理硕士 闲聊版|商务版
俱乐部北京 | 大连 | 福州 | 广州 | 杭州 | 南京 | 山东 | 上海 | 深圳 | 四川 | 天津 | 武汉 | 西安 | 郑州 | 申请成立 TOP榜精华 | 最新 | 最热 | 会员

版面信息

说明:手机数码,客户与市场驱动研发,做好项目管理与产品管理是核心

本版版主

andyplay
登录:2015/1/6
次数:464
注册:2004/7/19
发帖:674

俱乐部导航

北京大连福州广州杭州
南京山东上海深圳四川
天津武汉西安郑州 

联盟·近期活动

社区热点

开放讲座|项目组合管理与PfMP认证
开放讲座|PgMP:项目管理思维与方法
开放讲座|《项目组合管理与PfMP认证
网络讲座|《项目组合管理与个人职业
开放讲座|《项目组合管理与PfMP认证
网络直播|产品经理的四大核心技能提
如何轻松拿下PgMP?免费学习机会--.
国际项目组合经理PfMP访谈:张富贵
由PMO评论主办的第十二届中国PMO大.
如果不参加这次直播你会痛失一次学.

精彩专题

如何做好项目沟通计划

软件项目质量管理

国际工程索赔与反索赔

更多:

推荐信息

·项目经理沙龙俱乐部
·推荐项目管理公开课程
·联盟VIP会员服务
·联盟99元大课堂
·建造师课程辅导免费试听

社区圈子

集团企业生态体.
圈主:ETPPM
行业:综合应用

深圳IT项目管理
圈主:lshcom
行业:综合应用

项目管理知识宝.
圈主:wenyu2010
行业:工程设计安装

项目经理职业生.
圈主:zhenjm
行业:综合应用

生态系统体系下.
圈主:ETPPM
行业:综合应用

联系社区管理员

咨询电话 010-82273401/11
斑竹申请 admin@mypm.net


版权所有 © 2003-2004
京ICP证070584号 
BBS业务许可2007第353号 
最佳显示模式:1024*768像素
项目管理与PMP认证
[原创] 令人迷惑的软件外包--软件外包项目需要注意的问题 [发表于 2007/2/20]
状态 开放帖 浏览量 3926   
令人迷惑的软件外包--软件外包项目需要注意的问题
笔者有幸参与了公司与世界某知名软件外包开发商之间的一个大型软件外包开发项目,为了保密起见,将该项目命名为P项目,外包供应商为W公司。P项目合作从06年5月15日正式启动到06年12月15日W公司 VP与我司进行继续推进项目的模式谈判失败,历经了7个月时间,期间我司三次派出工程师与W印度进行需求沟通,印度方面一次派出工程师到深圳与我司进行系统设计文档讨论。双方都为推动这个项目付出了巨大的努力,现在虽然与W公司之间的合作失败,但是回头来看看项目的整个推进过程,W公司作为世界上第三大独立软件外包开发公司,从运作体制上一定存在比我们更多的经验,所以将W公司方面存在的问题比如沟通意识不强、客户服务意识不强、针对推进项目的具体模式选择上灵活性不强、太注重于项目推进的进度指标而忽视质量和效果、前期需求和开发工作量估计不足等问题撇开不谈,主要来看看我们在整个项目推进过程中存在的问题、有什么经验可以获取、未来我们在继续进行软件外包开发过程中需要注意哪些细节。笔者将分部分进行总结。期望这些经验能够为成功推动软件外包开发项目的工程带来有益的参考。
一、 项目范围管理方面
我司在与W公司外包开发启动伊始,就没有一个完整的、详细的基于自己分析的系统需求报告。在06年3月份,开发部组织各个部门进行系统需求收集,当时所有人员将我们认为有必要的需求全部放入系统需求中。在软件开发项目中,首先是要具有客户需求,将客户需求转化为系统软件需求,将软件需求细化为具体的功能需求,从而形成软件系统需求规格书和软件细化功能需求规格书。但是这一步我们没有扎实推进,提交给W公司用于参考的文档还是以前与I公司合作时I公司提交的文档,至于在Carlibor中我们的需求与I公司提交的需求没有进行一致性检查,同时我们也没有再次对需求的详细内容进行细化,没有形成一个基线化的系统需求和系统功能需求,导致在后期我们的部分需求我们自己都无法描述清楚或者项目组没有统一的意见,给W公司形成的印象就是我们的需求在不断变化,范围在蔓延。对于P项目这种大系统开发,需求内容庞大,无论是自主开发还是外包开发,对于范围和需求的管理都是一个难题。前期我们没有将需求进行有效分级,认为是外包,所以能够放入的需求全部放入,希望实现的需求全部列入文件,需求内容庞杂,不能区分核心的业务需求和外围的完善需求,导致外围需求的不满足影响到核心业务需求的实现。
根据以上对项目范围的回顾,针对未来推进软件外包项目,需要注意以下细节:
1、 项目的范围必须严格基线化,形成一个统一的版本,在该版本固化之后,任何新的需求需要进入都必须经过严格评审,原则上不允许新需求进入已经固化的系统范围和需求版本。
2、 项目的需求存在不同的重要等级。核心业务需求是实现整个系统的基础和关键,外围需求作为对系统的有效补充和完善,会对系统的架构产生影响。但是不能因为外围需求的实现困难,导致能够实现的核心需求也因此被拖延或者不能实现。对需求必须进行严格分级并进行有效评审,形成在同一基线化需求基础上的需求分类,系统设计以整体基线化需求为基础,实现以核心需求实现为重点,在实现对核心需求的有效细化、分析的基础上,进行外围需求的处理。在必要条件下,可以先首先核心需求,将外围需求的功能接口预留,完成核心需求后,进行外围需求挂接。
3、 基线化范围和需求的内容必须明确、清晰。基于软件文档的体系,以系统客户需求为基础,形成系统软件需求,系统软件功能需求以及系统具体业务实现需求,并形成系统设计方案,系统概要设计和系统详细设计文档。文档形成后经过评审形成该文档的基线化版本,对基线化版本文档的修改必须经过评审、可追索。
4、 在外包之前,必须将系统的整体解决方案、主要技术基础、实现方式、技术与具体需求的结合进行详细分析、研究,形成可以对外包方提供的技术方案进行技术评审和基础。没有这个基础,在对外包方的技术方案进行审核时,很容易限于被动,无法确认技术可行性、技术实现的复杂性,仔细研究会导致项目周期的延长,不分析会受到外包方简单化处理导致的系统不可用或不易用,同时无法对外包方提出的一些技术上无法实现的环节的确认,导致系统实际功能的缩减或者简单化。
5、 整体系统的需求在实现方面的不同版本划分。对于P项目这类的大型软件开发项目,将所有需求划分到一个版本中进行整体开发的成功机会相对小一些,这种成功的基础包括双方顺畅的合作关系、互相的信任、技术基础上的严肃探讨、双方公开的问题沟通机制、合理的费用和控制机制等。一次将所有需求放在一个版本中实现会因为规模庞大而对双方的要求增加,一方达不到要求就可能导致项目的失败。所以必须进行实现版本划分,实现版本以需求的版本为基础,不同实现版本的具体系统必须是一个包含了部分需求的完整系统,可以承载独立的业务,而不应该是将一套独立的业务放置在不同版本中实现,那样前期实现的版本测试难度太大。前期版本在设计中同样需要预留后期实现本版所包含内容的接口,整体应该是一个迭代的过程。
二、 项目进度管理方面
从项目签订伊始,就明确了项目的具体交付时间,这对于推进项目按照这个目标实现具有良好的指引作用。在这个时间的确认上,却是没有经过双方合理的沟通和研究。我们的时间确认是因为我们已经有了路标规划、我们已经在市场进行了宣布,而W公司方面同意这样一个时间是在没有完全理解需求、没有清晰实际的具体需求的基础上进行了。在这样一个现实情况下,W公司按照既定的计划进行项目计划排定,就不得不投入较多的资源同时开展工作,同时压缩双方交流和文档审核的时间,这是为什么W公司提交的进度计划我们一再提出反对意见并要求增加给我们的审核时间的原因之一,这也同样导致了W公司团队受到计划的压力非常大,经常以计划为要挟要求我们加快进度或者抱怨我们进度慢。
合理的进度计划是基于对需求和工作量的合理评估的基础上,结合投入资源的数量和质量以及既定的完成时间来排定的,没有合理和良好的工作量评估为基础的计划,从制定完成就注定该计划必须被不断修改,项目组成员会因为计划的一次次修改而不能确认究竟什么时候才能固定计划、才能按照计划开展工作,同时会对工作的推进产生不良影响。所以未来在外包项目进度管理方面,需要注意以下几点:
1、 包项目的进度计划是基于工作量的合理分析和评估的基础上作出的,制定进度计划之前,必须对工作量进行估算。这个估算不仅仅包括具体开发的工作量,同样需要估算双方在需求交流、澄清、沟通,技术方案讨论、技术问题确认、技术实现等多方面的估算。
2、 进度计划在完成工作量评估之后,需要根据资源的情况进行时间调整。比如我们在前期系统需求阶段只有三名项目组成员,在短期内完成需求分析根本不现实,要么增加资源,要么延长工作时间。否则压缩时间带了的结果就是文档质量不高。
3、 进度计划在完成编制之后需要与外包方一起进行沟通,确认其中存在的问题并进行必要调整,同时对执行计划的资源安排提出意见,确认双方必须投入的资源数量及其质量,在整个项目组内达成共识之后,进行签订并形成基线化的进度计划。
4、 在项目执行过程中,可能需要对进度计划进行调整。调整必须作为输入,具有合理的解释并对调整内容进行充分说明后,经过双方认可方可进行调整,尤其是对于项目延期方面,必须在调整之前确认双方出现延期的责任划分,并对未来还会出现的延期进行评估,确定进度计划具有良好的可执行性。
三、 项目质量管理方面
项目的质量需要在设定项目标准之后,通过实际项目文档等的数据与质量标准对照来确认项目的质量。在P项目中,我们从伊始没有对文档、技术方案、评估标准、度量数据等设定清晰的标准,尤其是技术文档,该如何对其中存在的问题进行分类和分级,针对不同的问题应该采取什么样的控制措施等都没有明确下来,这些就导致了我们在后期推进过程中,对于文档是否达到我司要求出现分歧,W公司也投诉我们总是提出各种问题。在外包项目中,需要注意以下几点:
1、 在项目计划文件中,必须明确项目的质量体系需求以及双方在质量控制方面的有效机制。这是从体制上保证双方都会在质量管理方面投入资源。
2、 在合同附件中,必须明确对于技术、文档、代码、测试问题等具体的质量要求,例如什么问题属于严重问题、致命问题、一般问题,具有多少数量的问题后,文档属于不合格,需要完善后才能提交,代码缺陷率、代码测试问题数,达到多少测试问题以及不同类型的测试问题后提交的文档或者代码不可接受,必须完善后才可以提交客户进行测试。
3、 双方必须对文档、代码等发现的问题建立统一的问题跟踪机制,保证所有发现的问题必须经过有效解决、关闭或者达成一致的放弃更改意见。
4、 在问题发现后,双方必须对问题的解决制定可行的解决计划并进行资源保证。
5、 对质量不能达标或者长期质量不能满足双方已经确定的要求的情况下,必须说明对双方需要承担的责任的罚责,通过惩罚来保证及时、有效的投入和质量的保证。
四、 项目人力资源方面
在P项目立项期间,我们在整体把握上的要求是仅仅对需求负责,具体的开发和测试都应该由外包方负责。因而项目配备的资源较少,前期只有三人参与。而在实际的操作过程中,由于我们的资源不足,导致我们无法对系统需求进行细化以及详细的讨论,确定可以用于交流和支持开发的细节内容,提交给外包方的需求文档也只能保留在框架需求的规模下,对框架需求的具体解释却没有能够在前期进行详细交流,导致后期合作过程中冲突不断,对于同一框架需求的理解双方不一致,需要投入人力对外包方进行需求讲解和澄清,同时抽调其他资源加入审核团队,对外包方提交的文档进行详细审核。外包方提出我们的框架需求在审核之后不断扩大和蔓延,导致他们的工作量增加。我们的团队成员同样需要付出巨大努力来帮助承包方进行完善。整个过程控制难度很大,沟通的障碍逐渐增加,双方互信减少,最终导致我们对W公司提交的方案不信任,需要改变项目操作模式,在没有达成一致意见的情况下,项目合作陷于终止。
软件外包项目的目的是减少发包方在具体项目的详细规格编写、技术实现以及代码开发方面的人力投入,但是前期的需求收集、分析、系统设计方案以及详细规格的编写工作却是不能外包的。因为承包方可能根本就没有发包方的行业背景,对于如何将用户需求转换位系统需求以及详细需求和功能需求并没有多少可以参考的经验。而这些正好是项目成功的最基础的工作――即需求。同样这些也是需要大量发包方进行人力投入的环节。所以,未来在软件外包项目中,针对人力资源管理,需要注意以下几点:
1、 发包方必须建立一个强大的外包管理团队,该团队不但要覆盖项目具体需求以及技术的背景,同样要具有强大的商务谈判、沟通、项目管理等方面的能力。
2、 发包方的工作主要在前期需求收集、分析、方案确定、详细功能分析等工作,后期在开发过程中则资源需求数量会降低,所以在项目前期需要投入大量资源和较长时间,形成自己的系统设计、系统详细功能规格、系统详细设计要求文档,否则在合作过程中,需求将在一开始就为项目的成功留下严重隐患。
3、 在项目合作开始,必须对承包方的人力情况进行调查、最好能够面试保证人力质量满足该项目的要求,尤其是核心的技术、架构以及管理接口等人员。
4、 双方必须建立有效的、基于不同层级体系的沟通渠道,双方管理体系需要对项目投入足够的关注并及时解决项目组面临的问题。高层的态度是不得不在前期就要考虑的问题,最好获得双方高层在项目承诺方面的书面材料。
5、 确定一个双方人员交流的记录和保存体系,并及时将双方在重要谈判、重要问题、重要冲突、重要文档提交等方面的详细交流进行记录,作为跟踪项目推进的重要跟踪工具以及未来出现问题后双方进行沟通的证据基础。
6、 双方在合作过程中,存在不同文化背景、不同地域、公司等冲突,在人力配置过程中,需要注意在小组中具有协调者、推进者、意见提出者、强力反对者等不同性格特质的人员。在选择承包方时,应该重点考虑双方人员在沟通方面能否顺畅、合作意愿是否强烈、外包经验是否充分等问题。从PowerNet项目外包可以看出,大型项目的外包首先在语言上应该具有较好的基础,人员应该从小项目外包开始培养,并及时进行培训,增加团队人员能力,应对承包方提出的各类问题。
以上是对P外包项目的不同方面进行回顾,并提出针对外包项目应该注意的一些问题,作为未来在进行外包项目操作中的参看。
金小云--共同推进研发能力提升

>>> 由论坛统一发布的广告:
楼主 帅哥约,不在线,有人找我吗?xiaoyunjin


职务 无
军衔 三等兵
来自 广东
发帖 1篇
注册 2007/2/20
PM币 20
经验 16点

Re:[原创] 令人迷惑的软件外包--软件外包项目需要注意的问题 [回复于 2010/6/9]
学习了
1楼 帅哥约,不在线,有人找我吗?qjx456


职务 无
军衔 无军衔
来自 广东省
发帖 3篇
注册 2010/6/9
PM币 1
经验 6点

共1页  97 [ 第1页 ] 8:
  
!  您尚未登录,不能回复主题。    现在 登录  注册
关于联盟 | VIP会员 | 培训服务 | PMP认证 | PgMP认证 | 刊物出版 | 沙龙会议 | 人才服务 | 广告投放 | 联系我们 | 友情链接
建设运营:共创时网络
版权所有 京ICP证070584号 BBS业务许可2007第353号