作为一个程序员的角色看开发测试与需求的交互
需求人员的痛苦:
1. 针对开发人员:
a) 每次需求人员都要从头说起。(他好像对需求一点都不理解?)
b) 开发人员不看文档,业务理解不深刻。(功能实现有问题)
c) 开发人员针对某个功能问了N次。(我的工作被打断了N次!)
d) 需求人员苦思冥想新功能的解决方案。(如果有开发的支持该有多好?)
e) 需求验证时,发现一堆的问题,程序质量不高。(唉!又要验证几遍?)
f) 开发人员自己在追求完美,其实需求根本不需要那么做。
2. 针对测试人员:
a) 对业务理解不深,Bug深度不够。
开发人员的痛苦:
1. 需求文档没有及时更新,常常出现测试人员、需求人员一起问开发程序是怎么实现的,开发记不起来,还要去查源代码。(唉,打扰是我最大的痛)。
2. 问需求人员业务问题,需求人员对整个业务理解不透彻,考虑问题不够完全,提出一个解决方案后,过一段时间又修改。(又白做了!)
3. 针对某个功能的实现,需求人员说:“这个功能很容易实现啊,不就是这样这样吗?”(需求变成开发了?)
测试人员的痛苦
1. 需求文档没有及时更新。(问一下开发是怎么实现的?)
2. 需求文档太过简单不够严谨。(开发测试都需要不停问需求一些细节问题)
3. 问需求人员业务问题,需求人员自己不清楚,想出了一个自己理解的解释,可能出现推托情况。(郁闷,我该去问谁呀?)
开发人员能够做的:
1. 其实技术和业务是两个不可分割的整体,根据业务才能写出高质量、高性能的代码。开发人员在求技术上发展的同时,同时需要关注业务的发展。
2. 理解需求是什么和为什么有这样的需求同样重要。
3. 多沟通多交流是理解需求的必经之路,但是针对某个功能最好能够系统的提问,减少无谓的交流。
4. 能够针对业务提出不同解决方案或实现方式。
5. 树立高质量代码的意识,用实际行动来保证高质量。
6. 不要闭门造车,也许需求根本不需要把那个功能做得那么完美。
7. 对于不完善的文档,有义务提醒需求人员。
测试人员能够做的:
1. 深入理解业务,对非专业人员尤为重要。只有深入理解业务,才能提出深度的Bug。
2. 对于不完善的文档,有义务提醒需求人员。
开发测试痛苦的核心问题:
需求文档不能及时更新,需求人员对系统的整体业务理解的深度不够,文档不够清晰严谨。
需求人员能够做的:
1. 需求文档能及时更新,明确新任务和文档更新的优先级。
2. 需求文档规范严谨。
3. 对系统的整体理解加深。
4. 需求工作的交接需要稳定的过渡。
5. 对代码不熟悉,请不要说这个功能很简单。(需求管业务,开发估时间,职责要明确)
总结:
1. 需求人员是三个角色中最上游的,如果需求受污染,下游就会泛滥成灾。一个项目中,开发、测试、需求需要在一个方向,一个心态,一个目标上,加上明确简单的流程,整个项目才能做的有激情,有快乐,高绩效,才能有条不紊。
2. 针对需求和测试的交互,我觉得自己是一个门外汉,不知道有那位能够提出一些想法和解决方案。