求解项目中的需求分析

先说说项目的背景情况，项目为一政府项目，分为很多模块。production于07年上线，至今support team已支持一年运转，现有一enhancement要进行开发，目前正在做需求分析，评估影响等。可惜的是当年做production时候的大部分人都已离职，而现在做enhancement的大部分人对这些模块不是很熟，在做需求分析的时候不可避免的会丢一些需求，因为用户给的需求也不会给的这么完美，这样在后期也就相应的会多N个bug,想请问大鸟们，像这种情况，怎么最大程度的去挖掘需求？

不太理解你的“Enhancement”的定义是什么。新版本？还是小的需求改进。

很难啊，bug很难避免。困难不仅仅是需求方面吧？
觉得有几个关键点：（１）找对业务最熟的人做产品经理，遇到问题随时问（不一定是开发的大拿，销售对这个项目熟悉的也行）
（２）搭建尽可能真实的测试环境，尽早测试，尽早发现问题
（３）用户推广阶段要长一些，有可能的话，中间多给用户出几个“抢鲜版”，让用户帮助测试一下

多谢上面的兄弟回复：

不太理解你的“Enhancement”的定义是什么。新版本？还是小的需求改进。
指的是一个功能改进，不过这个改动很大，10个人的团队要做一年左右的时间。

用户给的需求是挺简单的，他只说明了我要做什么，其实这中间会影响很多目前已经存在的功能，如果这个在需求分析阶段没有做好，必定会影响项目的整个周期性。
现在的负责人是以前留下来的老员工，大部分东西只有他比较熟悉，其他人都只能停留在代码阶段，因为不熟，没有什么背景，也看不到很深。时间比较紧，开发时间只有5个多月，用户要测三个多月，因为是政府项目，数据是不允许有丝毫的差错的。

经过自己的分析，认为楼主的意思应该是：应该是如何最大限度地兼容之前的系统。

这个其实很简单，只要把以前的数据库拿来分析就行了，如果没有设计文档就只有参考代码了，祝好运。

那么说你们的team有20多人喽？


其实需求都是在不断做，交流，改动中确定的。
这就是上面说“抢鲜版”的问题所在。用户不断看到新的东西，对你们就会有信心。也不排除中途变更需求和合同的可能。



这才是真正的关键所在。假设你们是一个20人左右的团队，只有一个项目的老人，其他人既然没什么背景，估计业务/技术水平多数也不高。那这样一个团队运转起来是很困难的。
如何把团队运作起来，分阶段完成整体需求，是很考验你们经理和team leader水平的工作。

其实我们现在讨论的是怎么最大限度去挖掘用户的需求，当用户给你些简单的需求时，避免后期开发陷入僵局，设计文档也只能反映以前做了什么。

还有10多人在做support,Enhancement只有10人哈。



其实这也是问题的关键所在啊，由于用户是HK政府部门的人，不是一般的用户，他接受不了你交给他的版本中有问题，哪怕是两三次，人家就会对你失去信心。所以这个“抢鲜版”用户不会接受的，他也没这么多时间来测，因为整个系统要回归测完一次的话，至少一两个月。



这话说到点子上了，我们的风险全在这上面了。后期要不要加班也全靠他了。

1. 客户交流是最重要的。无论你怎么强调它的重要性都不为过。如果客户不能理解你的要求，无法进行有效的交流，那么等待项目组的只有失败。因为任何一个项目都不可能闭门造车而产生。
2. “抢鲜版”不是让客户帮你测试。它的作用有两点：一，让用户知晓你对需求的理解程度；二，迫使项目组不断拿出可用的版本，从而保证进度/质量。如果客户很忙，没有时间看所有功能，那么至少让他们能够很方便地看到新作的部分，尤其是你对需求不清楚地部分，让他们帮你决断。这样，一旦开发有了偏差，就能够尽早回头。
3. 有点偏题，但是说明你们的测试有问题.回归测试不是要求覆盖所有用例，而是改哪儿，测哪儿。最多测到模块测试的级别就可以了。像你们的项目如果回归测试做不到在一周以内完成，那么项目质量完全无法保证。
4. 你们的工作量估计／进度安排似乎有问题。“10个人的团队要做一年左右的时间”的项目，最后只安排了１０人做５个月，究竟是估计值太高呢，还是进度过紧了？无论哪一点，都是很致命的问题。

最后总结一下你们项目的风险，解决问题还是靠你自己：
1. 客户交流
2. 测试管理
3. 团队素质
4. 工作量估计／进度

<quote>说明你们的测试有问题.回归测试不是要求覆盖所有用例，而是改哪儿，测哪儿。最多测到模块测试的级别就可以了。像你们的项目如果回归测试做不到在一周以内完成，那么项目质量完全无法保证。
4. 你们的工作量估计／进度安排似乎有问题。“10个人的团队要做一年左右的时间”的项目，最后只安排了１０人做５个月，究竟是估计值太高呢，还是进度过紧了？无论哪一点，都是很致命的问题。

最后总结一下你们项目的风险，解决问题还是靠你自己：
1. 客户交流
2. 测试管理
3. 团队素质
4. 工作量估计／进度</quote>

多谢兄弟的建议，由于我们不是直接面对客户，中间需要经过第三方来传递，所以需求的时间是要花很多，现在对项目也不是很乐观，关于上面的测试需要一两个月，写错了，是一轮UAT时间大概要这么久。
风险大，迷雾重重。

这个项目我认为风险非常大，主要原因在于客户能力差，并且交流有问题。
本身就一个信息系统来说，功能修改的复杂程度，往往会大大高于新建功能。这是因为改造型项目，往往是以运行的，组织的业务流程和资源配置都已经就位，任何看似细小的修改，都可能造成很大的内在不平衡。而如果在早期建设中，就没有树立起，过程持续改进的意识，那么这个客户的项目几乎就不可能成功。当然就我所接触的情况来看，香港政府和日本地方政府的几个项目都是存在这些方面的问题，可以说他们对此方面比国内的各级政府还差。因此在此方面，客户教育的工作就很重要。
进一步来说，类似的项目，其主要责任在客户。更加明确的说，需求分析和需求理解的主要责任在客户，而不在开发者。同时必须要认识到，这种项目所支撑的业务流程，是基于行政管理和政治考虑的，而不是基于信息系统自身规律的。这就给其开发，造成了十分危险的内在逻辑漏洞。开发者的责任，在于明确指出问题的所在，而同时也必须强调开发者自身无法解决相关问题。
我认为上面两点，是造成目前困境的主要因素。这两个问题不解决，其他方法都是事倍功半以至于是缘木求鱼的做法。