一个关于需求管理的血的教训

kjrick 2003-05-30 06:43:02
需求管理是一个开发团队在2级应该建立起来的管理机制，没有这个机制往往对于团队造成的打击是很严重的！！
一个我自己故事
从项目一开始就觉得那里不对劲了，从客户方面传来的信息没有让人感到丝毫的轻松，没有任何肯定的信息恢复过来，直到最后一天我们接到了来自客户方面的确认，他们确信只有整个网站的Flash是他们需要的，根据我们的报价他只肯付3000块人民币......
不知道该怎么评价这个项目的进展，从最开始去开客户会议到团队开始制作相关网络系统部件，这个团队里没有特出来过要跟对方签署任何形式的协议，人们在用一个东西支撑着自己-对方的经理跟我很熟，而最后问题却就出在了协议上。
回顾全部项目过程，双方以供召开了3次项目需求会议，前两次是由对方总裁直接参与的。而作为与会的一方我感觉对方似乎在隐瞒什么，而且他们并不关心系统最后会有什么功能，他们在等待我们丢石头出来。风险，这个词一直在我脑子里回响，而风险还是如期变成了灾难。客户的结论是这个团队被动工作的方式不受人欣赏，所以Canncel了与我们的合作，此时我们能做的也许就只有从演示网站上Delete所有的演示稿件。
诚然我们确实能力有限，但是基于过去我们所能完成的案例来看，共同的特点就是客户在那需求时的合作，如果我们所拿到的需求只是客户所期望的需求的一部分，那么一切都会变得很危险。然而客观地说，这次的客户确实比我们大太多，在双方无法平等谈判的前提下我们就像航行在没有指南针和星光的海面。对方在看看我们能不能给他一个新鲜的东西，我们却只能给他一个他给我们的需求实现，这也许是一个矛盾吧。
软件过程一再地强调，只有在需求确定的情况下，才能进行详细的设计，我想这条原则是没有错误的，这次需求管理的失败在于没有能够主动启发客户的潜在需求。
这是一个项目的总结，也对与我合作的弟兄们表示歉意！
但是我会记住这个客户的名字，如果他有一天遇到他的客户，希望他会想起我们今天的遭遇，不至于因心理不平衡跳楼自杀！
...全文
39 14 打赏 收藏 转发到动态 举报
写回复
用AI写文章
14 条回复
切换为时间正序
请发表友善的回复…
发表回复
金庆 2003-06-09
  • 打赏
  • 举报
 回复
能拿3K就不错了!
说明还有一点工作成绩.
sxzz 2003-06-09
  • 打赏
  • 举报
 回复
结果---〉行动----〉决定---〉思考
结果：损失惨重的失败
行动：大量的行动导致惨重
决定：没有合法的决策决定导致失败
思考：决策决定前有没有周密的思考，详细地分析？
chen20000 2003-06-08
  • 打赏
  • 举报
 回复
8会连合同都没签吧？？那打落牙也得往肚子里咽了。。这样的客户素质实在是低啊，同情ing..
silkeen 2003-06-08
  • 打赏
  • 举报
 回复
kjrick (康诚) 兄的总结很是“一针见血”:
"这次需求管理的失败在于没有能够主动启发客户的潜在需求。"

甲方在初期洽谈时是不可能把所有需求都告诉你的，有两个原因：

1、甲方考察多个公司的方案，希望找一家已有可实现他们大部分需求的项目实例或技术的公司来做，以降低项目的风险。甲方的需求多少有其独特性，基于商业机密或是公平竞争的原则，即使公开招标，也不会公开所有具体需求。当然，关系打得好的公司可能拿到全面具体的需求，增强中标率。

2、甲方的需求很多情况下可能只是一个大概的想法，没有细化。这就需要公司的成熟产品或是新的建议和意见，来启发客户的潜在需求，分析清楚客户的实际需求。毕竟乙方是技术专家，能从技术的角度结合业务需求提出好的意见，这是很受甲方欢迎的。

可惜的是，有的乙方为了项目快点完成，总是限制甲方的思维，缩水甲方的需求。





stonespace 2003-06-06
  • 打赏
  • 举报
 回复
这个问题可以从两个方面看：

1.为什么客户多疑

商业社会中，要信任另外一个人是很困难的，在中国商业性的欺诈行为非常普遍，信任更加难获得，反过来信誉的价值就越大。如果商业合作伙伴不信任你，实际上也不是完全是他的错误，这里边有客观上的合理性。所以抱怨合作伙伴多疑恐怕不能解决问题，这里边可能存在沟通的问题，客户不信任说明沟通失败，可能分析一下客户为什么多疑更加有建设性。

2.人的因素也是一种风险

如果客户真的过于多疑，项目的失败应该由客户来负责。我认为这说明，在开发过程中，人的因素也是一种风险，有些人就不适合做客户，如果他们成为客户，必将导致项目的失败。既然是一种风险，那么类似XP和USDP之类的技术对付这个问题也是有效的，迭代的原理就是设法在早期获得知识，客户是否值得合作也是这样的知识，不要到项目快要结束的时候才知道客户是否值的合作。如果早期能够拿出可以运行的原型，拿原型和客户交流，也是有可能在早期了解客户的素质。
kjrick 2003-06-06
  • 打赏
  • 举报
 回复
在这个项目我看还是要学会看人，方法是次要的，知道在跟什么样的人合作才是重要的。
kjrick 2003-06-06
  • 打赏
  • 举报
 回复
其实我们做软件工程的人大多都是厚道人，可是他们做贸易的不是这样的，他们是很多疑的，而对于多疑的用户施用XP往往不会有什么好的结果了。
longbocheng 2003-05-31
  • 打赏
  • 举报
 回复
现在终于知道需求分析的重要性了，需求分析做得不好，是不可能有较好的设计的。
dreamboy329 2003-05-31
  • 打赏
  • 举报
 回复
需求管理很重要

合同也很重要
熟人更要先小人后君子
协议合同制定的详细一点，后面活做的漂亮点
shuker 2003-05-31
  • 打赏
  • 举报
 回复
up
stonespace 2003-05-31
  • 打赏
  • 举报
 回复
如果风险很大，应该用类似XP之类的迭代过程来开发，争取尽可能早把可以运行测试的软件（原型）拿给客户看，并且尽早得到反馈。

风险越大，迭代的周期应该越短。不用迭代方法等于找死。
kinsing 2003-05-30
  • 打赏
  • 举报
 回复
需求管理是一方面的原因，与客户的沟通我觉得觉得才是症结所在。
项目开发过程中每个阶段都要能够得到用户的反馈比较好。比如将一些原型系统给用户演示,启发他提出问题。
合同签订也比较关键，保证了双方的利益。

这也是比较难得的经验，感谢你将你的经历拿来出来给大家共享。另不必灰心，总结一下重新再开始。
kjrick 2003-05-30
  • 打赏
  • 举报
 回复
斑竹有没有搞错？？？
刚刚我的帖子被错能到隔壁去了，这个系统由bug你查一下
kjrick 2003-05-30
  • 打赏
  • 举报
 回复
怎么看不见
数据库设计经验谈.docx
数据库设计经验谈全文共11页，当前为第1页。一个成功的管理系统，是由：[50% 的业务 + 50% 的软件] 所组成， 而 50% 的成功软件又有 [25% 的数据库 + 25% 的程序] 所组成，数据库设计的好坏是一个关键。 如果把企业的数据比做生命所必需的血液，那么数据库的设计就是应用中最重要的一部分。 有关数据库设计的材料汗牛充栋，大学学位课程里也有专门的讲述。 不过，就如我们反复强调的那样，再好的老师也比不过经验的教诲。 所以我归纳历年来所走的弯路及体会，并在网上找了些对数据库设计颇有造诣的专业人士给大家传授一些设计数据库的技巧和经验。 精选了其中的 60 个最佳技巧，并把这些技巧编写成了本文，为了方便索引其内容划分为 5 个部分： 第 1 部分 - 设计数据库之前 这一部分罗列了 12 个基本技巧，包括命名规范和明确业务需求等。 第 2 部分 - 设计数据库表 总共 24 个指南性技巧，涵盖表内字段设计以及应该避免的常见问题等。 第 3 部分 - 选择键 怎么选择键呢？这里有 10 个技巧专门涉及系统生成的主键的正确用法，还有何 时以及如何索引字段以获得最佳性能等。 第 4 部分 - 保证数据完整性 讨论如何保持数据库的清晰和健壮，如何把有害数据降低到最小程度。 第 5 部分 - 各种小技巧 不包括在以上 4 个部分中的其他技巧，五花八门，有了它们希望你的数据库开发工作会更轻松一些。 第 1 部分 - 设计数据库之前 考察现有环境 在设计一个新数据库时，你不但应该仔细研究业务需求而且还要考察现有的系统。大多数数据库项目都不是从头开始建立的；通常，机构内总会存在用来满足特定需求的现有系统（可能没有实现自动计算）。显然，现有系统并不完美，否则你就不必再建立新系统了。但是对旧系统的研究可以让你发现一些可能会忽略的细微问题。一般来说，考察现有系统对你绝对有好处。 定义标准的对象命名规范 一定要定义数据库对象的命名规范。对数据库表来说，从项目一开始就要确定表名是采用复数还是单数形式。此外还要给表的别名定义简单规则（比方说，如果表名是一个单词，别名就取单词的前 4 个字母；如果表名是两个单词，就各取两个单词的前两个字母组成 4 个字母长的别名；如果表的名字由 3 个单词组成，你不妨从头两个单词中各取一个然后从最后一个单词中再取出两个字母，结果还是组成 4 字母长的别名，其余依次类推）对工作用表来说，表名可以加上前缀 WORK_ 后面附上采用该表的应用程序的名字。表内的列[字段]要针对键采用一整套设计规则。比如，如果键是数字类型，你可以用 _N 作为后缀；如果是字符类型则可以采用 _C 后缀。对列[字段]名应该采用标准的前缀和后缀。再如，假如你的表里有好多"money"字段，你不妨给每个列[字段]增加一个 _M 后缀。还有，日期列[字段]最好以 D_ 作为名字打头。 检查表名、报表名和查询名之间的命名规范。你可能会很快就被这些不同的数据库要素的名称搞糊涂了。假如你坚持统一地命名这些数据库的不同组成部分，至少你应该在这些对象名字的开头用 Table、Query 或者 Report 等前缀加以区别。 如果采用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符号来标识对象（比如 tbl_Employees）。我在和 SQL Server 打交道的时候还用过 tbl 来索引表，但我用 sp_company （现在用 sp_feft_）标识存储过程，因为在有的时候如果我发现了更好的处理办法往往会保存好几个拷贝。我在实现 SQL Server 2000 时用 udf_ （或者类似的标记）标识我编写的函数。 工欲善其事, 必先利其器 采用理想的数据库设计工具，比如：SyBase 公司的 PowerDesign，她支持 PB、VB、Delphe 等语言，通过 ODBC 可以连接市面上流行的 30 多个数据库，包括 dBase、FoxPro、VFP、SQL Server 等，今后有机会我将着重介绍 PowerDesign 的使用。 获取数据模式资源手册 正在寻求示例模式的人可以阅读《数据模式资源手册》一书，该书由 Len Silverston、W. H. Inmon 和 Kent Graziano 编写，是一本值得拥有的最佳数据建模图书。该书包括的章节涵盖多种数据领域，比如人员、机构和工作效能等。 其他的你还可以参考：萨师煊　王珊著　数据库系统概论 畅想未来，但不可忘了过去的教训 我发现询问用户如何看待未来需求变化非常有用。这样做可以达到两个目的：首先，你可以清楚地了解应用设计在哪个地方应该更具灵活性以及如何避免性能瓶颈；其次，你知道发生事先没有确定的需求变更时用户将和你一样感到吃惊。 一定要记住过去的经验教训
数据库设计经验谈.pdf
数据库设计 数据库设计 1 第 1 部分 - 设计数据库之前 3 第 2 部分 - 设计数据库表 3 第 3 部分 - 选择键 3 第 4 部分 - 保证数据完整性 3 第 5 部分 - 各种小技巧 3 第 1 部分 - 设计数据库之前 3 考察现有环境 3 定义标准的对象命名规范 3 工欲善其事, 必先利其器 4 获取数据模式资源手册 4 畅想未来，但不可忘了过去的教训 4 在物理实践之前进行逻辑设计 5 了解你的业务 5 创建数据字典和 ER 图表 5 创建模式 5 从输入输出下手 5 报表技巧 5 理解客户需求 6 第 2 部分 - 设计表和字段 6 检查各种变化 6 采用有意义的字段名 6 采用前缀命名 6 标准化和数据驱动 6 标准化不能过头 7 Microsoft Visual FoxPro 报表技巧 7 不活跃或者不采用的指示符 7 使用角色实体定义属于某类别的列[字段] 7 采用常用实体命名机构数据 8 用户来自世界各地 8 数据重复需要采用分立的数据表 8 每个表中都应该添加的 3 个有用的字段 8 对地址和电话采用多个字段 8 使用多个名称字段 9 提防大小写混用的对象名和特殊字符 9 小心保留词 9 保持字段名和类型的一致性 9 仔细选择数字类型 9 删除标记 10 避免使用触发器 10 包含版本机制 10 给文本字段留足余量 10 列[字段]命名技巧 10 第 3 部分 - 选择键和索引 11 数据采掘要预先计划 11 使用系统生成的主键 11 分解字段用于索引 11 键设计 4 原则 11 别忘了索引 11 不要索引常用的小型表 12 不要把社会保障号码（SSN）或身份证号码（ID）选作键 12 不要用用户的键 12 可选键(候选键)有时可做主键 13 别忘了外键 13 第 4 部分 - 保证数据的完整性 13 用约束而非商务规则强制数据完整性 13 分布式数据系统 13 强制指示完整性(参照完整性?) 13 关系 14 采用视图 14 给数据保有和恢复制定计划 14 用存储过程让系统做重活 14 使用查找 14 第 5 部分 - 各种小技巧 14 文档、文档、文档 14 使用常用英语（或者其他任何语言）而不要使用编码 15 保存常用信息 15 测试、测试、反复测试 15 检查设计 15 Microsoft Visual FoxPro 设计技巧 15 一个成功的管理系统，是由：[50% 的业务 + 50% 的软件] 所组 成，而 50% 的成功软件又有 [25% 的数据库 + 25% 的程序] 所组成， 数据库设计的好坏是一个关键。如果把企业的数据比做生命所必需的血 液，那么数据库的设计就是应用中最重要的一部分。有关数据库设计的 材料汗牛充栋，大学学位课程里也有专门的讲述。不过，就如我们反复 强调的那样，再好的老师也比不过经验的教诲。所以我归纳历年来所走 的弯路及体会，并在网上找了些对数据库设计颇有造诣的专业人士给大 家传授一些设计数据库的技巧和经验。精选了其中的 60 个最佳技巧， 并把这些技巧编写成了本文，为了方便索引其内容划分为 5 个部分： 第 1 部分 - 设计数据库之前 这一部分罗列了 12 个基本技巧，包括命名规范和明确业务需求 等。 第 2 部分 - 设计数据库表 总共 24 个指南性技巧，涵盖表内字段设计以及应该避免的常见问 题等。 第 3 部分 - 选择键 怎么选择键呢？这里有 10 个技巧专门涉及系统生成的主键的正确 用法，还有何 时以及如何索引字段以获得最佳性能等。 第 4 部分 - 保证数据完整性 讨论如何保持数据库的清晰和健壮，如何把有害数据降低到最小程 度。 第 5 部分 - 各种小技巧 不包括在以上 4 个部分中的其他技巧，五花八门，有了它们希望你 的数据库开发工作会更轻松一些。 第 1 部分 - 设计数据库之前 考察现有环境 在设计一个新数据库时，你不但应该仔细研究业务需求而且还要考 察现有的系统。大多数数据库项目都不是从头开始建立的；通常，机构 内总会存在用来满足特定需求的现有系统（可能没有实现自动计算）。 显然，现有系统并不完美，否则你就不必再建立新系统了。但是对旧系 统的研究可以让你发现一些可能会忽略的细微问题。一般来说，考察现 有系统对你绝对有好处。 定义标准的对象命名规范 一定要定义数据库对象的命名规范。对数据库表来说，从项目一开 始就要确定表名是采用复数还是单数形式。此外还要给表的别名定义简 单规则（比方说，如果表名是一个单词，别名就取单词的前 4 个字 母；如果表名是两个单词，就各取两个单词的前两个字母组成 4 个字 母长的别名；如果表的名字由 3 个单词组成，你不妨从头两个单词中 各取一个然后从最后一个单词中再取出两个字母，结果还是组成 4 字 母长的
构建实时数仓的流批一体ETL工具-Streamsets
本课程来自一线项目(实时数仓建设)。创建实时数仓，是当前很多公司... 课程全程以实战的方式进行，每节课一到两个例子，并且会将创建实时数仓过程中的经验和教训穿插到例子讲解中，欢迎大家一起讨论实时数仓架构设计！
关于软件工程血的教训之文档管理
文档管理混乱是上个项目最为致命和混乱的，我个人认为，如果一个项目小组进行开发一个系统的时候没有文档的开发个人认为是可怕的，而在系统的开发中没有对文档进行有效管理是恐怖的，我们要做的是一个产品，而不是自娱自乐的一个试验品，作为产品，必须要标准，无论是客户给我们的标准还是开发小组给自己的标准，关于标准将在后面做详细讨论。而有标准就必要有相关的文档，关于文档的好处大家都清除，无论在软件开发部署以及维护的
产品经理的需求池管理
在做项目的时我们经常会面临各种各样的需求，有的需求来自领导的指示，有的需求来自用户的反馈，有的需求来自灵光一闪，有的需求来自团队其他小伙伴等等，那么对于各种需求我们应该如何处理和管理呢？这个就是今天要和大家分享的内容：“产品经理需求池的管理”。 需求池是什么 需求池可以理解成一个产品迭代依据的库，数据库记录各种数据，那么需求池记录的是各种需求。 为什么要有需求池 在聊这个问题前，先聊下没有需求池的尴尬，笔者是从UI设计师到UX设计师再到PM过来的，当时做UI的时候是没有需求池的，大...
研发管理

1,265

社区成员

28,324

社区内容

发帖
与我相关
我的任务
社区描述
软件工程/管理 管理版
社区管理员
  • 研发管理社区
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章