作为一个程序员的角色看开发测试与需求的交互
需求人员的痛苦：
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. 针对需求和测试的交互，我觉得自己是一个门外汉，不知道有那位能够提出一些想法和解决方案。