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

本文是一个系列文,主要是将我自己目前产品工作中踩过的坑和遇到的困难进行反思和总结,然后将其输出为一个工作规范。同时也因为我现在负责公司产品组管理的工作,制定相关的规范和准则,一来可以约束自己,形成良好的工作方式和流程;二来可以约束团队,方便新人工作和成长更加具有科学性和条理性。初步定的内容和模块大概有三个大模块,九个小细项,希望我能坚持写完。

前言

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

要做什么?

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

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

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

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

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

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

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

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

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

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

能要求什么?

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

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

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

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

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

那么请思考,产品能在此阶段要求什么?

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

最后

此篇的内容主要是讲需求研发,此文的主体大纲是参考李宽的B端产品经理必修课中的内容来写的。初看此文,我感觉讲得东西都是大同小异没有什么花样,实际到了我要去践行并带领团队的时候,我发现其中的一些观点和内容其实处处凸显了作者丰富的经验及阅读量,此书可算得上是B端产品的一本很好的指导书了。希望大家以后在遇到相关的书籍的时候可以沉下心,带着目的和思考去阅读,这样的话收获会很大也很容易与作者形成共鸣,加深对某些观点和看法的理解。

此处再次感谢@李宽,7月份的工作,此书对我的帮助巨大,也推荐大家去购买并阅读此书。

7月份的时候我花了一些时间去制定团队内的产品作业规范,所以也打算把制定规范的过程中所学习到的东西写出来。如今已经9月下旬了,很多内容现在会过头去看会发现有些生涩和单薄,但是所幸的是我在7月份的时候做了这些,如今回过头去复盘的时候才能发现原来这里面还有这么多内容是可以提升和优化的。

团队规范从大方向来说我所选的这几个方面应该都包含到了,主要是执行起来的时候并没有理想中那么顺畅,毕竟规范只是确保少犯错误,它不能杜绝错误,更不能带来质的提升。所以更多地是约束大家,形成良好习惯和培养团队默契。

希望以上会对你有所帮助,下一篇是将项目管理方面的内容,我应该多去啃点书才能写好这方面的规范了。

--本文到此结束感谢您的阅读--
随缘打赏,佛系产品
0%