问题描述:自己公司内部人员提出需求,但是需求提的很简单;系统做出来后,又不断的提要求,最好导致程序员非常郁闷;
摘自:http://fehly.iteye.com/blog/699278?page=1#comments
i2534 写道:
我帮楼上哥们补充下经验吧:如果他们把自己放在了客户的一方,也就是需求永远不能满足的情况,你就应该向你的老大反应,让他帮你和那个部门沟通,沟通一次,写一次类似需求书一样的,不一定那么详细,但是这次沟通要完成的功能写下来,尽量详细,特别是一些容易产生歧义的地方要详细,让他们的人观看后通过邮件发给你,如果可以,抄送你的老大和他们的老大.每次完成后,通过邮件往来告知他们完成这些,如果有变动,属于下次,依次类推.再简单也要写,避免产生一些陷阱把自己掉进去.
--------------------------------------------------------------------------
王者之剑 写道:
一件很容易的事被你搞成这样
一个问题你要么解决它要么给出一个让人信服的在规定的时间内解决不了的理由。
显然你没有做到
不知道你离开时,需求文档已经变成了什么样子,如果我所料不错,需求文档仍然是原来的样子,新的需求只存在于你的脑袋和代码里。
这可能和你对自己的定位有关,你就是把自己当成一个代码工人,而不是一个软件工程师或者其它。
不幸的是你领到了一个麻雀虽小但不是纯代码工的活儿,因此就杯具了。
引用fehly 写道
需求文档中什么都不写,就要添加和查询,做出来的时候,有要这个有要这个
王者之剑 写道:
就是一个代码工人,讲究的也是严密的逻辑,添加,要添加哪些项,没有不能做吧。
查询要按哪些项查询,如果添加的项里面没有,不能做吧。
查询的结果要排序,缺省情况下如何显示,还有哪些特别的排序方式
查询的结果要导出保存,要保存成什么文件形式
需要保存的报表有几种。
更新,是单个更新还是批量更新,在什么情况下需要更新,更新的频率,更新的记录数占总记录数的比率。
删除,是单个删除还是批量删除。删除以后要不要恢复。
等等。
其实,你只要花半天时间就可以将需求细化。
打印出来,和营业部的MM面对面讨论,将她想做的都列出来。
不需要做的都划掉。
想做的你认为本周内搞不定的,挑出来放到后面。
人家也说了,让你自己发挥,结果你拿起来就做,没有花一天的时间发挥一下。
-----------------------------------------------------------------------------
fehly 写道
yuwenchun 写道
是沟通问题
恩,沟通的有问题...每次她自己都不知道需要什么,然后就说我要方便..怎么方便怎么来...这个方便..这么模糊的概念...等我按照所谓的方便做出来的时候.她又觉得,还需要点其他的..才能更方法,...这些所谓的方法,需求文档一点都没有写...然后我他们领导最开始也给我说,你功能实现就好了.她要什么你加不就好了....就想楼下兄弟说的,这个不是我发挥,是她发挥....我感觉恨不得她把所有的工作都放在这个系统里,每个月点几下,自己的工作就完成了....
zhuyx808写道:
不是沟通的有问题,而是沟通问题。
沟通的有问题?沟通的什么有问题?
沟通问题就是说你和人打交道有问题。首先运营部 的小姑娘不是你经理不是架构师不是需求分析师,人家是最终用户,她没有受过软件方面的专业训练,页面不出来她当然讲不出东西南北,当你页面出来后她使用不方便当然会提各种意见。为什么你们沟通的时候你不把页面大概做成什么样子提前给她讲下那?既然你都能和最终用户直接沟通了那你就应该更理解他们需要的是什么样的东西。有什么不懂不理解直接问最终用户分清他们的最终要求,他们说的都是很具体的东西你要提炼成页面的样子画给他,不行的话先做一个demo,只是简单的html就可以,她同意后在去实现,不同意就继续改,所以说问题在你。当然我也是一个程序员,我理解需求变来变去导致我们很不爽,但是要清楚,正是有他们存在才有我们的价值。
---------------------------------------------------------
fehly 写道: 感觉恨不得她把所有的工作都放在这个系统里,每个月点几下,自己的工作就完成了....
-------------------------------------------------------------------
系统是为了方便工作,要不搞这个系统干什么?换句话说你要是她,你也这么想。如果我是LZ,我会改掉这个想法并端正自己的态度,说句比较BT的话,你应该做成让她点都不用点的、她只要打开页面就全部显示给她看的那种。。。。。。
我只是就事论事分析问题不针对LZ。
分享到:
相关推荐
**2.1 为何选择原型法** 1. **明确用户需求:** 软件开发初期,用户往往只能提供较为模糊的需求描述。通过构建原型系统,用户可以直观地了解软件的基本功能和界面,从而更好地表达自己的需求。 2. **降低后期变更...
- **风险控制**:讨论如何通过原型法来控制项目风险。 #### 十七、设定需求优先级 - **必要性**:阐述设定需求优先级的原因。 - **角色差异**:说明不同角色(如项目经理、开发人员等)在处理需求优先级上的不同...
- **原型法**:构建一个简单的系统模型供用户测试并提供反馈。 - **联合应用设计(JAD)**:邀请用户参与需求讨论会议,以达成共识。 #### 3. 需求分析工具 - **Rational Rose**:一款广泛使用的建模工具,支持UML...
- 原型法:快速构建演示系统以验证需求。 6. **需求文档化** - 用户需求规格说明书:详细记录所有需求,作为开发依据。 - 需求分析:将获取的需求进行结构化分析,如使用结构化分析方法或基于用例的分析方法。 ...
- **原型法的风险评价**:评估使用原型法可能带来的风险。 - **如何使原型法获得成功**:确保原型制作的质量和效果。 **3.7 产品边界的最后确定** - **最终确定产品的价值与范围**:根据需求获取的结果来定义产品...
### 需求分析二三话之获取需求的几种简单...总之,在需求分析过程中,通过综合运用以上提到的学习法、创造法和实践法,可以帮助我们更好地理解和具现化需求,而有效的沟通策略则是确保客户理解和接受这些需求的关键。
- **以商业利益为导向**:在多客户的情况下,优先考虑那些支付更多费用的客户的需求。 - **平衡开发者与用户的意见**:尽量遵循用户的意见,但也要警惕不合理的请求,并通过构建原型等方式来帮助双方更好地理解和...
- **市场需求**:来自市场的总体需求,通常由市场趋势、竞争对手分析以及客户需求调研得出。 - **产品需求**:具体到某一产品的特定需求,包括功能需求、性能需求等。 - **内部需求**:企业内部对产品的要求,例如...
- **无条件遵从客户需求**:需平衡客户需求与技术可行性,必要时引导客户理解限制。 - **需求验证的意义**:即使在系统未开发前,通过编写测试用例来验证需求的合理性和完整性。 #### 九、可行性研究与需求获取 - *...
2.2.1 软件客户需求权利书 13 2.2.2 软件客户需求义务书 15 2..3 “签约”意味着什么 17 第3章 需求工程的推荐方法 18 3.1 知识技能 19 3.2 需求获取 20 3.3 需求分析 21 3.4 需求规格说明 22 3.5 需求验证 23 3.6 ...
- 原型法:创建软件模型,快速迭代以满足用户需求。 - 使用案例分析:描述用户如何与系统交互以实现特定目标。 - 数据流图(DFD):图形化表示数据在系统中的流动和处理。 - 实体关系图(ERD):用于描述数据库...
2.2.1 软件客户需求权利书 13 2.2.2 软件客户需求义务书 15 2..3 “签约”意味着什么 17 第3章 需求工程的推荐方法 18 3.1 知识技能 19 3.2 需求获取 20 3.3 需求分析 21 3.4 需求规格说明 22 3.5 需求...
- **网页工程师**:制作需求原型。 - **客户经理**:协助项目经理协调需求开发,参与需求评审。 - **客户**:参与需求获取和评审,确认需求。 - **项目总监**:审批《需求规格说明书》,协调资源。 - **评审...
组织级需求收集的多种途径:原型法、客户访谈、现场观察、客户决策委员会、用户大会、客户简报、高层拜访、标杆学习、Beta测试、产品试用、现场支持、支持热线、行业会议、客户满意度调查…… 从竞争的角度看需求 ...
012 第12章 通过原型法减少项目风险 013 第13章 设定需求优先级 014 第14章 需求质量验证 015 第15章 需求开发向设计规划的转化 第三部分 软件需求管理 016 第16章 需求的管理的原则和实现 017 第17章 管理变更请求 ...
良好的需求开发管理流程能够确保项目团队准确理解客户需求,并据此制定合理的开发计划,从而提高产品的质量和用户的满意度。本文将详细介绍需求开发管理流程的关键步骤及其重要性,并通过流程图的形式直观展示这一...
2.2.1 软件客户需求权利书 13 2.2.2 软件客户需求义务书 15 2..3 “签约”意味着什么 17 第3章 需求工程的推荐方法 18 3.1 知识技能 19 3.2 需求获取 20 3.3 需求分析 21 3.4 需求规格说明 22 3.5 需求...
- 原型法:创建模型以帮助理解需求。 - **输出**: - 需求文件:记录了收集到的需求。 - 需求管理计划:描述如何规划、跟踪和报告需求的过程。 - 需求跟踪矩阵:用于追踪需求到最终产品的实现。 ##### 2. 定义...