惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

宝玉的分享
宝玉的分享
NISL@THU
NISL@THU
E
Exploit-DB.com RSS Feed
L
LINUX DO - 热门话题
L
Lohrmann on Cybersecurity
K
Kaspersky official blog
Project Zero
Project Zero
Cisco Talos Blog
Cisco Talos Blog
T
The Exploit Database - CXSecurity.com
P
Palo Alto Networks Blog
C
CXSECURITY Database RSS Feed - CXSecurity.com
T
Threatpost
S
Schneier on Security
G
GRAHAM CLULEY
The Hacker News
The Hacker News
T
Threat Research - Cisco Blogs
Scott Helme
Scott Helme
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
P
Privacy & Cybersecurity Law Blog
C
Cyber Attacks, Cyber Crime and Cyber Security
Cyberwarzone
Cyberwarzone
C
CERT Recently Published Vulnerability Notes
T
Tor Project blog
AWS News Blog
AWS News Blog
Simon Willison's Weblog
Simon Willison's Weblog
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
爱范儿
爱范儿
P
Privacy International News Feed
云风的 BLOG
云风的 BLOG
P
Proofpoint News Feed
S
Securelist
G
Google Developers Blog
The Last Watchdog
The Last Watchdog
Google Online Security Blog
Google Online Security Blog
美团技术团队
F
Fortinet All Blogs
小众软件
小众软件
Recorded Future
Recorded Future
V
Visual Studio Blog
B
Blog RSS Feed
H
Help Net Security
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
Google DeepMind News
Google DeepMind News
Blog — PlanetScale
Blog — PlanetScale
博客园 - 聂微东
Stack Overflow Blog
Stack Overflow Blog
Martin Fowler
Martin Fowler
Latest news
Latest news
Spread Privacy
Spread Privacy
H
Heimdal Security Blog

博客园 - caidehui

软件开发的特点总结之二-----软件产品 软件开发的特点总结之三---软件开发过程 软件开发的特点总结之一------人 软件开发的主要要素 一个典型的软件项目的WBS评析 为什么我们的WBS元素多是活动 关于好的WBS 制订好的WBS的步骤 重构还是结构,开创还是竞争--面对战略的难题 合同范围与需求分析范围不符的一个原因 技术与外语在外包中的地位问题 外包的定义及其特点 客户、员工、投资者、社会等对外包服务提供商的要求 服务商对外包方的期望 外包的进一步研究 外包的原因与目的 上网本打开的那扇门 Windows7跳动的心 Borland哀歌
合同范围与需求分析后范围严重不符问题与分析
caidehui · 2010-01-20 · via 博客园 - caidehui

做为软件开发商,每到需求分析结束的时候,我们就会有感叹,这个需求怎么和合同上的完全不一样呢?做为客户却不能理解,我们不是还是做1-2-3-4这四个事情嘛,有啥不一样的?

    为什么会出现这个问题,我想首先的问题就是,客户的需求是解决其业务问题,从大的方面来说假设分成1-2-3-4,这个一般没有问题,如果出了问题客户也能够同意进行调整。而做需求分析的时候除了业务问题以外,最主要加入进来的确实操作习惯,那么我们可以大致这样来进行划分:

    决策层(花钱的):我们遇到这样几个问题,需要解决,花多少钱

    管理层(操作层的上级):为了解决这个问题,我们应该分成这些步骤,并且还有哪些问题

    操作层(用户):要做这个事情,我希望********

    在签合同的时候,我们往往会做到第一层和第二层,并且第一层应该弄的比较清楚,第二层往往是开发商带一些猜测,而客户的管理层也不重视,认为反正后面还有需求分析呢。这就埋下了祸根,而操作层一般是完全不会涉及的。时间、成本等也不允许进行涉及。

    等到需求分析的时候,我们要从决策层开始,分析其需要解决的问题,进入到管理层,由于每个企业都存在管理层意见不太统一的情况,因此如何把持住成了一个很难的问题,进入操作层以后,我们就会迷失在巨大的操作需求中。

    另外,客户往往有一种我已经花钱了,所以什么你都的替我解决。又给你增加了一大堆不在决策层考虑的范围之内的事情,操作层有的时候也会给你一大堆的难题进行解决。如果碰上客户之见有一些矛盾,你就会更加痛苦。

    再次,软件开发商的一些现场人员,对项目的目标(决策层的要求)把握不准,不能通过合适的沟通方法将客户领导的意图不断的强化到管理层和操作层,导致理解偏差。

    第四,软件开发商的现场人员不能有效的、清晰的表达出合同范围和需求范围变化的情况、趋势,这些被淹没在大量的、繁琐的文档之内。到需求分析结束的时候,又急于开展进一步的工作,导致双方都匆忙确认。

    这几个问题是非常严重的。我不想都展开讲解决方案,只讲2个方面情况,1,从行业发展的角度讲,如有可能应该鼓励客户将需求与实施分开成两个项目,独立完成。这需要行业人士的不断呼吁,客户的认识提高等。

    第二个方面,只涉及如何使客户和开发商都对项目的范围有非常清晰的认识并且在需求分析过程中进行强化、比对。开发商必须要建立2个工具,一是决策层提出的问题,要精炼好,制作成宣传标语贴在进行需求分析的会议室或者随时带着,作为检验我们是否脱离目标的工具,随时使用。二是开发商一定要在开始进行需求分析时,制作好项目的合同WBS,并且获得客户的认可,以此为基础进行需求分析与调研。保证不偏离WBS,如果发生偏离,随时进行检讨与纠正。在需求分析结束以后,制作新的项目的WBS,二者进行比较分析,将其对工作量、工期、成本、质量等的影响与客户交代清楚,并达成一致以后,方进行后续的工作。

    由于我们的需求工程师天生就喜欢将事情做的完美,因此自己也会加入一些范围外的东西,并且他们不太在意对项目的影响,有时候会在现场对客户进行一些承诺,导致项目范围扩大。因此每个企业都必须对需求工程师做出资质的要求,进行培训,并考核合同工作量与需求工作量的变化,并且明确告诉需求工程师,他没有获得有关授权,不能对客户进行承诺。以此来约束需求工程师。

    当然我们应该针对上面所讲的问题,拟定相应的解决方案,这里就不一一探讨,先谈谈上面这一点。