`
fantasy
  • 浏览: 516116 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论

如何应付项目中的细节需求?

 
阅读更多

  在项目开发中,有时候遇到非常细心的用户,经常在看到界面成品的时候,不断的提出细节需求,如这个地方应该有图有列表(原先是有图的),这个地方应该做成可编辑的。当然这些需求按道理是没有偏离需求范围,但是如此反复提出细节需求(多的达到8次),势必会增加项目中的成本,请问下大家对这样的事情有什么看法?

  另外做项目的时候有两个出发点,第一控制项目的成本,第二将项目做好,我认为把项目做好,但是把项目做好势必会增加项目的成本,两者如何平衡呢?

分享到:
评论
30 楼 miaow 2010-03-27  
jcs7575 写道
开发之前需求确认,确认后不允许需求变更。

也许我孤陋寡闻,我从来没见过不改的。
就08年有个项目差点做到,也没熬到最后,破了功。
29 楼 fsxxl 2010-03-26  
象这样的细节修改可以说非常之多,大部份情况下,都是拍脑袋想出来的,站在自己的角度利益,并且有可能破坏整个软件的流程,千万不能被用户迁着走,所有提出的需求由用户书写明细的文档说明如何改进,并且审批确认,这样的话,他对自己提出的需求就会进行深思考虑是否真的需要。

由经验评判需求的分类,合理的要求,真正可以帮助用户的,就尽可能满足。不合理的、可有可无的、十年不用一次的,就进行解释,或者说,先这样用着看看,用户其实就会慢慢的适应了,否则单在一个地方就转到你出不来。

最可怕的需求就是,用户本身素质不高,用过其他别的软件,然后将其他软件的功能作为需求提出。有些时候,完全不懂的还好过。
28 楼 beckrabbit 2010-03-04  
jcs7575 写道
开发之前需求确认,确认后不允许需求变更。


“不允许”恐怕难以实现。
27 楼 jcs7575 2010-03-04  
开发之前需求确认,确认后不允许需求变更。
26 楼 tangshd 2010-03-03  
androider 写道
seeckt 写道
1、细节是实现方式,需求是用户真的想要什么。这两个要分清楚,能够让他使用,并且好用就行,并不是他坚持图在表下面1CM你就不能挪到下面1.5CM。
2、让提问题的人和付钱的人是同一个人,否则随便找个谁到处提问题又不必掏钱那提点啥的还不容易么?
CCB的意思就是虽然需求是到各个用户那去采集的,
但是能做客户方确认的人只有一个,而那个人需要知道提范围外的需求需要付出一定的代价.
2其实比1更重要


这是没办法的事情,拥抱变化吗,嘿嘿,这是正常的,重要的是,得帮客户分析,在你真正开始做之前,跟客户分析清楚他需要什么,最起码再大的方向确定下来,否则这些东西要是在后期变更还是很恐怖的。对于项目进程中的细节问题还是应该修改,只要是客户需要的,不管什么,但是有些问题是可以跟客户沟通的,比如某个地方需要编辑功能,问问他是不是确实需要,用这个干什么的,如果他确定需要,那就给他一个评估时间,这里面沟通能力就极其重要了,你要让客户时刻都感觉到你是在为他着想,在这种长期的环境影响下,你否决他的一个请求(当然否决的方式也是出于为他考虑的方式)概率就很高了,而且还能得到客户的赞赏:)

其实跟掏钱的人谈是没用的,因为项目基本上在开始动手之前,钱就谈好了,最好就是从时间上来搞定,如果时间无所谓,就帮他做吧,这些成本还是得付出的,所以开始谈钱的时候,多少钱很关键。


同意您的观点, 说的很不错~~
25 楼 nijian 2010-03-03  
需求不是成本增加的根源,细节需求是软件开发的一部分
24 楼 pochonlee 2010-03-03  
页面画出来,按照页面来
23 楼 seeckt 2010-03-03  
引用
一般出现用户死磕界面的情况,要么你把界面做得震撼能满足客户,要么商务解决。


有种可能是每个客户的领导背后都有一家有关系的供应商
如果在换过客户方领导的时候被死磕界面其实是他想换自己有关系的那个供应商
要么联系他的上级领导给他施压
如果搞不定最好保证项目盈利,自己识相点乘早退出,别人也不折腾你了
22 楼 seeckt 2010-03-03  
关心界面的领导是你的领导还是客户的领导?
如果是客户的领导
很清楚最后合同的价格应该在双方底线内
如果因为折腾了很长时间界面,造成成本突破软件公司能够承受的底线
结果不是终止这次或下次合作关系就是想办法从别的功能点上捞回来
只要暗示对方这个潜规则就行

如果是开发方的领导
想把产品做精应该是好事,因为成本是领导出,
项目经理应该提醒进度和成本
项目组倒霉纯粹是项目经理未够班啊
乱承诺别人的要求又不提出对方应该额外付出的代价
一将无能累死三军
21 楼 fantasy 2010-03-03  
beckrabbit 写道
seeckt 写道
引用
当对界面斤斤计较的人不是客户,而是公司的领导怎么办?现在功能完成的不多,界面倒是快做到元素px级别了

是公司领导最好,马上拉销售一起拜访一次
既然大家都是生意人,当然知道所有的成本必须被覆盖
不需要明说,只要销售暗示反复折腾界面会造成乙方成本增加,
然后搞开发的说重要需求的处理资源被占用就行了


我们现在是在做产品,领导只关心界面好看就行了,精雕细琢,还请了外包美工,用了相当多的时间在界面,基本不怎么关心功能的实现,还定死了最后的工期,功能还有大块没做或者没和界面联调,最后倒霉只能是项目组了。

只所以领导只关心界面是因为客户在向领导邀功的时候,能让领导看懂的也只有界面,当然界面是用户的第一感觉,功能缺点,用户都能接受,界面不好看,用户绝对不能接受。
一般出现用户死磕界面的情况,要么你把界面做得震撼能满足客户,要么商务解决。
20 楼 beckrabbit 2010-03-03  
seeckt 写道
引用
当对界面斤斤计较的人不是客户,而是公司的领导怎么办?现在功能完成的不多,界面倒是快做到元素px级别了

是公司领导最好,马上拉销售一起拜访一次
既然大家都是生意人,当然知道所有的成本必须被覆盖
不需要明说,只要销售暗示反复折腾界面会造成乙方成本增加,
然后搞开发的说重要需求的处理资源被占用就行了


我们现在是在做产品,领导只关心界面好看就行了,精雕细琢,还请了外包美工,用了相当多的时间在界面,基本不怎么关心功能的实现,还定死了最后的工期,功能还有大块没做或者没和界面联调,最后倒霉只能是项目组了。
19 楼 seeckt 2010-03-03  
引用
当对界面斤斤计较的人不是客户,而是公司的领导怎么办?现在功能完成的不多,界面倒是快做到元素px级别了

是公司领导最好,马上拉销售一起拜访一次
既然大家都是生意人,当然知道所有的成本必须被覆盖
不需要明说,只要销售暗示反复折腾界面会造成乙方成本增加,
然后搞开发的说重要需求的处理资源被占用就行了
18 楼 beckrabbit 2010-03-02  
当对界面斤斤计较的人不是客户,而是公司的领导怎么办?现在功能完成的不多,界面倒是快做到元素px级别了
17 楼 fantasy 2010-03-02  
<div class="quote_title">karisen 写道</div>
<div class="quote_div">
<div class="quote_title">fantasy 写道</div>
<div class="quote_div">
<p>  在项目开发中,有时候遇到非常细心的用户,经常在看到界面成品的时候,不断的提出细节需求,如这个地方应该有图有列表(原先是有图的),这个地方应该做成可编辑的。当然这些需求按道理是没有偏离需求范围,但是如此反复提出细节需求(多的达到8次),势必会增加项目中的成本,请问下大家对这样的事情有什么看法?</p>
<p>  另外做项目的时候有两个出发点,第一控制项目的成本,第二将项目做好,我认为把项目做好,但是把项目做好势必会增加项目的成本,两者如何平衡呢?</p>
</div>
<p> </p>
<p>不知LZ 的项目用什么模型?瀑布?迭代?……</p>
<p>采用什么方法挖掘客户需求的?</p>
<p> </p>
<p> </p>
</div>
<p>迭代,但很多时候迭代期不是预先计划的,而是用户临时提出需求,我们被迫再迭代一次开发周期。</p>
<p>挖掘用户需求会根据项目的大小和时间而不一样,有原型法,截图+人工讨论法。</p>
16 楼 karisen 2010-03-01  
<div class="quote_title">fantasy 写道</div>
<div class="quote_div">
<p>  在项目开发中,有时候遇到非常细心的用户,经常在看到界面成品的时候,不断的提出细节需求,如这个地方应该有图有列表(原先是有图的),这个地方应该做成可编辑的。当然这些需求按道理是没有偏离需求范围,但是如此反复提出细节需求(多的达到8次),势必会增加项目中的成本,请问下大家对这样的事情有什么看法?</p>
<p>  另外做项目的时候有两个出发点,第一控制项目的成本,第二将项目做好,我认为把项目做好,但是把项目做好势必会增加项目的成本,两者如何平衡呢?</p>
</div>
<p> </p>
<p>不知LZ 的项目用什么模型?瀑布?迭代?……</p>
<p>采用什么方法挖掘客户需求的?</p>
<p> </p>
<p> </p>
15 楼 一蓑烟雨任平生 2010-02-25  
细节的需求可以分成两种:业务规则的细化,另一种是界面展现和操作风格的。

前者没有什么好的办法,看业务顾问的经验,用户提出来就应该做评估和修正,我的经验是最后还是要改的,只是看客户关系怎样,能不能走变更流程。

而后一种,就非常复杂,我的意见是在项目的技术协议阶段就最好能明确界面的展现和操作风格,原则上不允许对这块做大的修改,如果因为修改导致工时的增加则要求额外付费。

反过来也对我们自己的能力要有要求,一块是业务,一块是基础的标准,业务能力靠经验的积累和外部资源的帮助,基础标准则要提前做好准备。

项目中可以变化的是业务规则,基于这个概念考虑问题。
14 楼 yschen 2010-02-25  
任何的需求变更都需要客户签单,就算再小也好,我也试过这样的项目,今天他说这样,明天他又说那样,后来就直接签单的方式,就少了这样的要求了。
13 楼 fantasy 2010-02-23  
seeckt 写道
引用
“把项目做好会增加成本的问题”


这个观点很奇怪

做好了对甲乙双方都是增值,怎么会增加成本?

这个问题源于项目目标不明确
有两种可能:
1、甲乙双方对“好”的定义不一致,甲的目标如果是“打造世界一流的XX系统”,那么乙方基本上怎么做都是失败的
甲方想让乙方达到他心中的“好”,对乙方必然是增加了成本
2、对项目计划范围外的变更价值严重低估

特别是1、2并存的时候,通常乙方很吃力的做完很多功能,被甲方认为是本就应该做的,收不到钱还挨批

您说的很有道理。
在我们公司,做好会增加成本的问题,主要来源于需求不是我们产品的有意义功能。
如我们是做安管的,但是用户非常关心把安全论坛做好,提出很多这个模块的需求,而这个模块又恰好不是我们产品的重心和核心模块,不断的开发只会不断的增加成本,做一些对我们产品没有很高意义的需求。
12 楼 tuzipp 2010-02-11  
感觉项目开始时,首先敲定一个DOME,用HTML做出一个轮廓,有链接,JS功能倒是其次,然后给客户演示一下大体的操作步骤,比如“从哪个页面进去,进行什么操作,然后转到哪个页面”之类的。就算页面时空的,写几个字表示一下也可以。
项目中的二八原则,20%的功能解决了80%的需求。80%的时间用于解决那20%的需求。先把那些“大功能”、“主要的”完成,估计没有那么多的人那么较真……
11 楼 seeckt 2010-02-11  
引用
“把项目做好会增加成本的问题”


这个观点很奇怪

做好了对甲乙双方都是增值,怎么会增加成本?

这个问题源于项目目标不明确
有两种可能:
1、甲乙双方对“好”的定义不一致,甲的目标如果是“打造世界一流的XX系统”,那么乙方基本上怎么做都是失败的
甲方想让乙方达到他心中的“好”,对乙方必然是增加了成本
2、对项目计划范围外的变更价值严重低估

特别是1、2并存的时候,通常乙方很吃力的做完很多功能,被甲方认为是本就应该做的,收不到钱还挨批

相关推荐

    项目中的需求分析管理

    ### 项目中的需求分析管理 #### 一、需求分析的重要性 需求分析作为项目开发的基石,其质量直接决定了后续工作的开展以及项目的成功与否。在实际操作过程中,虽然很多团队已经意识到了需求分析的重要性并采取了...

    项目需求规格说明书范例.doc

    3. 降低项目的风险:项目需求规格说明书提供了一个明确的项目风险评估和应对计划,降低项目的风险。 四、市反走私信息交换平台项目需求规格说明书 市反走私信息交换平台项目需求规格说明书是根据项目的需求和目标...

    项目需求实例

    【标题】"项目需求实例"通常指的是在软件开发过程中,针对某一特定项目,明确并记录下来的需求集合。这些需求可能包括功能性的、非功能性的、业务规则以及用户期望等方面的内容,是项目开发的起点和基石。在实际操作...

    需求变更申请表需求变更过程中,需求变更表

    它通常包含了项目的基本信息,如项目名称,以及提出变更的人、时间等关键细节。 2. **变更内容**:在申请表中,需求提出人需详细描述变更或新增的具体内容,包括模块名称、所属子系统、菜单位置,以及变更的原因和...

    需求文档.zip(租车系统项目计划书+理财需求分析说明书+金融项目需求分析)

    通过租车系统项目计划书,我们可以了解项目实施的细节和预期目标;理财需求分析说明书则让我们理解如何打造符合用户需求的理财产品;而金融项目需求分析则是确保项目在技术和法规层面的可行性。这三者相互关联,共同...

    软件项目文档(项目开发计划,需求说明书,设计概要,详细设计,安装计划,软件合同,....)

    在软件开发过程中,文档起着至关重要的作用,它们记录了项目的各个方面,确保团队成员、管理者以及利益相关者之间有清晰的沟通。以下是标题和描述中提及的一些关键文档及其详细解释: 1. **项目开发计划**:这是...

    pycsafe项目需求规格说明书

    《pycsafe项目需求规格说明书》是对一个名为pycsafe的项目进行详尽阐述的文档,旨在定义项目的核心功能和用户需求,以便于开发团队理解并实现。该项目的主要目标是为用户提供一个平台,能够对视频、电子书和文档等...

    一句话的需求怎么测?需求文档的三种现状及应对策略.doc

    对于详尽的需求文档,测试人员应深入阅读,理解每一个细节,并对潜在的不明确之处与项目负责人或产品经理沟通。基于用户使用场景和行业经验,评估需求的合理性,并据此制定测试计划。 在处理任何类型的需求文档时...

    项目需求怎么写

    ### 项目需求文档撰写指南 #### 一、引言 **1.1 编写目的** 在撰写项目需求文档时,首先需要明确文档的目的。这一步骤至关重要,它能够帮助团队成员理解文档的价值所在,同时也为后续的工作提供指导方向。在本...

    需求阶段项目如何监理?

    #### 四、需求分析过程中的难点及应对策略 1. **客户难以清晰表达需求** - 解决策略:采用访谈、问卷调查等多种方式,引导客户表达真实需求。 2. **需求频繁变更** - 解决策略:建立需求变更管理制度,确保变更的...

    第04章软件项目需求管理.ppt

    目中的每一个成员。【标题】第04章软件项目需求管理.ppt【描述】本章主要探讨软件项目的需求管理,包括需求的概述、管理方法、任务分解和变更...在实际操作中,需灵活运用这些知识,以应对复杂的项目环境和变化的需求。

    中式报表系列之二如何快速应对报表需求变化

    综上所述,报表开发中面临的最大挑战之一就是如何高效应对需求变更。通过选择合适的报表工具、采用关注点分离的设计思想以及建立快速响应机制等方法,可以显著提高报表开发的灵活性和效率。此外,结合实际案例的学习...

    02 软件项目需求管理.pptx

    软件项目需求管理旨在确保团队在整个开发过程中准确、有效地获取、组织、记录和管理需求。这一过程包括需求的获取、分析、规约、验证和管理,以确保所有相关活动的规划和控制。需求分析在项目启动和计划阶段占据重要...

    第04章软件项目需求管理.pptx

    【软件项目需求管理】是软件开发过程中的关键环节,它涉及到对用户需求的理解、系统需求的定义、需求规格说明书的撰写以及需求管理的全过程。以下是关于这个主题的详细阐述: 4.1 软件需求概述 软件需求是软件开发...

    项目开发文档规范(需求分析,软件开发步骤)

    在软件开发过程中,文档规范和项目执行是至关重要的环节,它们构成了项目成功的基础。下面将详细阐述这些知识点。...在实际操作中,每一个细节都需要细致入微的关注,以实现项目的高效、高质量交付。

    在线培训网站项目需求

    在线培训网站项目需求 在当前数字化时代,建立一个在线培训网站是满足用户远程学习和企业扩展服务的关键。本文将详细阐述这样一个项目的各项需求,旨在创建一个高效、用户友好的平台,提供全面的在线教育资源和优质...

    云平台数据管理项目需求说明书.pdf

    总体需求与具体需求的划分,强调了项目的核心目标和具体实施细节。总体需求可能包括数据的高可用性、可扩展性、性能等方面;具体需求可能涉及数据备份策略、访问控制机制、数据加密方法等具体实施细节。 1.1.4 项目...

    企业IT运营类项目管理平台需求规格说明书共36页.pdf

    综上所述,企业IT运营类项目管理平台需求规格说明书详细列出了平台的各项功能需求和技术标准,旨在构建一个高效、智能、安全的项目管理环境,助力企业在激烈的市场竞争中提升项目执行能力,实现可持续发展。...

    软件需求工程习题及知识要点.doc

    在软件开发过程中,需求工程是至关重要的第一步,它关乎项目的成功与否。本文件是一份针对软件需求工程的习题集及知识要点,涵盖了从需求理解的困难性到具体的需求捕获、分析、管理等多个方面。 1. **为什么软件...

    一份软件需求说明书,需求分析模板

    软件需求说明书是软件开发生命周期中不可或缺的一部分,它为项目提供了清晰的方向,确保团队按照用户的需求进行开发,减少误解和返工,提高项目成功的可能性。在编写需求说明书时,应确保详尽无遗,避免遗漏任何关键...

Global site tag (gtag.js) - Google Analytics