产品日常工作规范之需求研发（第三篇）

本文是产品日常工作规范的第三篇——需求研发，其中的内容是承接上文需求收集和需求设计之后要做的一些事情，需求研发的主要工作是交付给开发和测试来完成的，在这个阶段产品经理能做的事情较少，所以本文提及的一些东西也会较少，是一篇短文。

当产品交付了需求文档或者TAPD，同时还有相关的原型图，流程图之后，意味着评审通过了，且开发也认可了你的设计方案和思路，接下来就是需求的研发阶段了。

需求的研发更多的是开发工程师和测试工程师的工作，开发会根据需求的描述和要求进行代码的编写，而测试则根据最后开发完成的结果进行查缺补漏。那么产品在这个步骤要做的东西主要就是：项目管理。

项目管理会在下文的「项目管理」模块详细说明，这里说的项目管理主要是指狭隘地对开发中的需求进行监控和反馈的动作。

当前我们使用的敏捷开发工具是腾讯的TAPD，敏捷开发是指项目的生命周期，而我们使用的工具则是在项目的生命周期内，进行项目管理的一个手段。

当产品将需求描述填写在TAPD上且通过评审之后，状态就会流转到开发手里，此时开发应该根据自身对需求的理解填写“开始时间”和“预计完成时间”，并需要将状态流转为“开发中”。

“开始时间”是需求的开始进入开发时间，“完成时间”是需求大概能在什么时候完成开发。但是这里的时间其实具有一定的歧义，因为一般的需求上线还需要测试，还需要发布版本等，所以这个完成时间我们内部约定是指“开发完成的时间”。

当一个迭代有众多需求的时候，查看TAPD的“故事墙”其实就是指需求研发中所讲的看板模式，看板呈现泳道图的样子，众多需求的状态一一展现在不同的泳道上，哪个泳道是空的，哪个泳道最拥挤，哪个泳道即将过渡到结束状态，都是一目了然。

TAPD的看板非常适用于一个迭代需求非常多的时候，同样的也非常适用于管理者在上帝视角中对一个迭代进行了解或者掌控。无论是站在产品经理的角度，还是项目经理，甚至是部门经理、老板等，故事墙都能让人迅速了解迭代的宏观进展和微观进度，这也让产品经理对TAPD的数据和字段内容的维护要求很严格，也对开发和测试的工作内容更新、维护等要求很严格。要确保需求状态的及时更新、流转，这个故事墙的意义才能体现出来。

当TAPD中出现一些脏数据，不规范的数据的时候，产品经理要及时对数据进行调整和修改，确保看板的准确和真实性，同时也能在季度或者年度总结的时候有更好的数据载体进行复盘总结。

所以，这里提出要求：产品经理要对TAPD维护和管理负责，同时也要指导和培训对应的项目组的开发和测试也重视这件事，严谨、认真地进行状态的流转和数据的维护。

很有意思的是，很多人都喜欢吐槽产品经理不靠谱，亦或者是觉得产品的能力低下导致了项目的失败或者是项目的平庸。吐槽者研发居多，测试其次，最后还有一部分是同行相轻。大家往往觉得产品应该多做很多，应该对外，应该对内，要写立项报告，要记需求，要写需求文档，要写上线报告，要做原型设计，又要做一些规则限制等等……

没错，上面很多东西都需要是产品去做的，这是这个岗位的工作职责限定的，但是吐槽者往往忽视了一点，那就是“当我们用食指向别人的时候，其实有三根手指也指向了自己”。这个时候作为一个产品不禁想要问：作为开发是否除了开发完成功能就够了？作为测试，是否测试完成相关的需求就够了？

想必答案大家心里也有数了，其实这里扯了一些闲篇，有点引战的意思，但是也是给自己提个醒了。当我们给自己制定了一堆规则和规范的时候，其实作为开发或者测试也需要有自己的规则和规范，这些可以是他们自己内部自己制定，也可以由产品提出来制定。最终的目的是为了确保项目能够保质保量的完成，团队协作能高效顺畅。

例如我目前合作的开发团队就会对迭代相关的内容和开发改动的地方做Excel记录，最后形成一个版本提测模板，测试根据这些改动点，去制作相关的测试用例和测试报告。这是一个好习惯，但是其中有时候也有不规范和大家偷懒的时候，这说明其中的约束力不够，大家不愿意遵守，亦或者是这种办法太繁琐或者体验不好，那我们可以针对此内容进行调整和优化。

总得来说，在需求研发阶段，产品除了知道自己要做什么之外，还要明白自己能要求什么？这些要求不算过分，它不是命令，它只是为了确保项目如期交付的一个手段，如果大家真切地去思考整个项目管理的周期会发现，约束应该要互相之间给予，这样会让大家都有紧迫感和关联性，更加有利于团队的协作，以便于打造更高效、科学的开发模式。

那么请思考，产品能在此阶段要求什么？

作为开发或者测试的你，觉得有哪些地方是需要被制定规范和要求的？