进公司差不多2年了, 做的项目大大小小也有10多个了, 这两天两个项目的PRD评审, 让我真真切切的感受到了不管是开发, 测试, PM, 还是PD, 都是在一个不断完善和自我改进的过程中.
这里, 第一次让我感受到, PD害怕了, 害怕评审又没通过, PM害怕了, 害怕测试这边再来一个一票否决. 两个细节:
1. 在讨论一个接口定义的时候, 测试开发一致认定一个接口在PRD中描述不完全, PD很委屈的拿出一期PRD文档, 说, 我是按照一期的内容来写的, 所有参与过一期的同学们看着以前自己亲自认定通过的PRD, 低头不语... 呵呵, 妈的, 当初我是怎么让这个PRD通过的. 而一期的内容, 距现在的时间, 还不到半年.
2. PRD第三次宣讲完毕之后, PD笑着, 用很诚恳的声音说到: 我要问问六太是怎么说的, 通过还是不通过.. 当我一大段超级官方的恶心套话之后, 说, 通过, 竟然有一种救人一命的感觉.... 第一次, 让我感觉到, 测试方在需求评审中的地位..
其实, 测试开发越早介入, 前期投入越多, 后期不明确的东西还有返工的机会就越少, 这点自从我进公司以来就不断的再提, 只不过, 那个时候, 谁都没有意识到, 哪些是该PRD中产出的, 或者说那个时候测试方还不够强硬, 记得有一个firefox安全控件的升级包, 需求3句话, 前两句是说这个控件有哪些特殊点, 最后一句是: 其他请参照ie下安全控件内容. 那一次, 我们三个测试围着一个PD, 轮番轰炸, 叫的比菜市场还热闹, 其他部门的兄弟们都围过来看到底是杀猪还是卖羊, 可结果还是无果而终. 那个时候, 测试是如此的软弱与无助.
上个季度, 上海的STA进行了一次测试分析的深入讨论, 其中一个边缘议题就是, 如何在PRD评审中拦截住更多后期的隐雷, 最好是有一个规范, 规定哪些部分是不应该由系统分析代为产出的, 即使这些需求可能依赖于系统设计的产出. 我找了一个系统分析, 在原来没有沟通的情况下, 竟然发现双方的意见竟如此一致. 虽然后续没有产出一个成型文档, 不过从侧面可以了解到, 其实开发现在也不愿意承担独自产出隐形需求而引起的纷争了. 宁愿在PRD阶段多协助PD做些事情, 也要尽可能的把该由PD拍板的内容早点拎出来.
今天的需求评审, 就是一个好的开头, PD与研发人员的关系, 就是奴隶与奴隶主的关系, 前期你剥削的越多, 后期自己享受的就越多.
没有评论:
发表评论