• 0
  • 0
分享

  先来跟大家同步下我们的大背景。我们按照功能方向分成若干开发小组。每个开发小组有两到三位产品经理,有六七位研发和两位测试,形成一个相对稳定的交付小组。禅道软件团队的迭代速度比较快,都是以周为单位进行迭代。目前由于回归测试的压力比较大,所以是双周对外发布版本。产品目前主要是项目管理软件的开源版、企业版和旗舰版三个大的方向。

  我们以时间线来讲一下产品团队的日常。我们从周一下午开始讲起,按照流程的先后顺序讲会比较顺。

  周一下午到周二的这一天半左右的时间里,产品经理团队要着手准备后面两个迭代的用户故事列表。这一天半时间中,搭档的两位产品经理会进行各种讨论交流,也会和研发骨干进行沟通交流,确认一些需求实现的难易程度。必要的时候还会和客户侧的同事进行沟通交流,处理来自客户侧的反馈。讨论交流的形式会有正式的会议,也会有随时展开面对面的沟通。会用到物理的白板,也会用到各种在线设计工具,比如2049协作白板等。最终在这一天半左右的时间里面每个产品方向的产品经理都要形成初步的用户故事列表,准备参加周三的评审。

  时间来到周三周四,是我和各个方向的产品经理集中进行需求评审的时间。根据实际情况,一般会在一天半内完成评审。评审方式是以小组为单位,对各位产品经理已经录入禅道中的用户故事列表进行逐一评审。评审的时候一般会交叉讲解,比如产品经理A整理的用户故事由产品经理B来讲解。评审过程中我主要会对需求是否清晰、逻辑是否合理、拆分是否合理、优先级是否合理这几个方向展开。发现问题的话会通过我们开发的需求问题管理插件记录下来,供产品经理后续更改。

  所以我是整个禅道团队需求的出口,基本上绝大部分的需求都要通过我这边的评审。重点是评审下周迭代要开发的用户故事列表,有的时候也会评审两个迭代的用户故事。产品经理们现在对开发团队的速率都有比较好的把握,在准备用户故事的时候会根据开发团队的速率进行预估。一般一个方向的用户故事评审1到2个小时,然后大家会根据评审的结果对需求进行调整,最后再找我做二次的评审。一般来讲二次评审就基本上没有问题了。

  周四中午我们有一个产品开发计划的沟通会。这个会的主要参与者是产品经理和各个开发小组的研发负责人,客户侧的同事如果想了解的话也可以旁听。这个会议主要是看未来两周内每条产品线计划要做的事情。我们采用的工具是禅道里面的看板,通过看板将每条产品线要做的计划版本和目前正在进行的迭代都完整地呈现出来。如下图所示。

1-1.jpg

图文禅道【看板】功能,已做模糊处理

  我们通过区域作为产品线的划分,每个区域下面通过横向的泳道来区分产品。然后通过列来区分计划和迭代,计划下面又分为计划中、进行中和已完成三个子列,迭代也是同样的规则。计划这一整列就是各个产品的计划,以卡片的形式呈现出来。每个产品线的负责人会根据这个看板跟大家来同步未来二到四周内的开发计划,如果同事们有问题可以随时提出来进行沟通交流。

  周四下午到周五上午是迭代功能验收的时间。各个研发小组会跟产品和测试的同事来展示这一周完成的功能,产品经理们对功能进行相应的确认和验收。在这个过程中发现的问题或者缺陷会被记录下来,有的是需要在当期的迭代中完成,有的是放到后面的迭代里面再安排。

  周五下午三点是整个产品经理团队的例会时间,对这一周的产品的工作进行复盘,然后将接下来要做的产品工作梳理清楚,然后把每位产品经理需要梳理的功能方向记录到对应产品中。也就是说我们产品经理团队日常的工作也是按照Scrum的方式来进行的。产品就是我们产品经理的部门,里面按照各个产品方向拆分成不同的模块。然后每个需要整理的功能方向都记录为需求,每周也建立一个迭代,拆分任务,进行跟踪。如下图所示。

1-2.jpg

图文禅道【产品】功能,已做模糊处理

  然后来到第二周的周一,和研发团队召开计划会议。开计划会议的时候产品经理和研发小组的同事一起,通过投影或者大电视将禅道里面的用户故事列表放大。由产品经理进行逐一讲解,解答研发同事的疑问,通过估算扑克牌进行估算。

  然后就是日常对研发团队的项目跟踪,参加每天的站立会议,随时跟研发团队和测试团队沟通来确认需求、确认功能。这些工作分散到每天的日常中,随时进行。

  每天下午临下班的时候,还会有15分钟的同步会。由各个研发小组的产品经理和研发负责人跟大家同步下各自的进展。因为禅道团队各个小组之间的配合比较多,所有我们需要有这样一个同步会。

  每两周周五各个小组会有回顾会议,产品经理也都会参加。另外公司层面,每两周也会有一次集中的产品演示会议,大概30分钟,会有各个产品线的产品经理跟公司全员展示最近产品研发取得的进展。

  然后就是不定期的一些事项了:整个产品经理团队每隔两三个月会组织一次全员的头脑风暴,对未来的产品方向进行梳理;还有就是产品经理会不定期地参加我们线下沙龙活动,不定期地和我们的用户、客户进行访谈,做用户调查。

  总之,禅道团队的产品经理们的日常是非常紧凑,节奏很快的,春哥的要求也很严格。当然大家的成果也是非常突出。我们现在的产品经理团队是从去年开始组建的,已经完成了几十项大功能的交付,比如孪生需求、融合模型、研发界面、多人任务、后台菜单、权限梳理、BI模块、ZenDas统计分析工具、音视频会议、融·项目管理平台等等。

  以上就是我们产品经理的日常。希望能够给各位朋友有所参考。


作者:春哥    

来源:http://www.51testing.com/html/82/n-7796482.html

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • jmeter可以用来测接口和性能,由于水平有限,只能大概谈一谈接口。(接口文档跟开发要。)解压好后打开bin目录,里面有个jmeter.bat,运行就打开了。页面挺简单的,就不一一介绍了(实际是不会介绍,上来就干活吧。)这是页面,右击测试计划-->添加-->Threads(Users)-->线程组接下来右击线程组-->Sampler-->HTTP请求再添加响应断言,断言结果,查看结果树什么的,监听器里面的中文基本都可以添加看看,(英文再研究研究)添加完成这种效果,点击http请求,开始在里面填内容,接口在这里就简单模拟一下,抓一个登录接口。URL里的http是协议...
            0 0 859
            分享
          •   性能基准测试  性能基准测试,通常被称为 Performance Benchmark Test,是每次对外发布产品版本前必须要完成的测试类型。  性能基准测试,会基于固定的硬件环境和部署架构(比如专用的服务器、固定的专用网络环境、固定大小的集群规模、相同的系统配置、相同的数据库背景数据等),通过执行固定的性能测试场景得到系统的性能测试报告,然后与上一版本发布时的指标进行对比,如果发现指标有“恶化”的趋势,就需要进一步排查。  典型的“恶化”趋势,主要表现在以下几个方面:  · 同一事务的响应时间变慢了。比如,上一版本中,用户登录的响应时间是 2 s,但是在最新的被测版本中这个响应时间变成了...
            0 0 946
            分享
          • 前言        相信大家对于linux常用的命令一定都不陌生,但是一些简单,好玩,有趣,虽然可能没有实际作用的命令,你又有了解多少呢?话不多说,本期文章为大家带来15个好玩的linux命令,希望大家能够喜欢!1、sl 命令        你会看到一辆火车从屏幕右边开往左边……        当然我们需要先安装软件包sudo apt-get install sl        然后运行sl即可看到效果2、...
            13 13 1555
            分享
          •   作为一个测试人员,报告相关人员影响系统的功能和威胁系统性能的问题是我们工作中的任务。  可能你常会遇到领导拦着问你:我们测试结果如何,还有故障吗?版本可以发布了吗?  但是如果你作为测试人员不知道系统的边界呢?如果你把测试结果的信心只是建立在应该一小部分测试的内容上,该怎么办?如果你不知道系统/解决方案如何或何时更改了怎么办?如果你缺乏这种控制,你怎么能说你对测试结果有信心呢?  其实这些问题与我们产品的可测性相关。如果我们获取知识的平台不稳定,我们怎么能够确保所学的东西是正确的呢?  举例说明  一个系统由许多子系统组成,解决方案由许多不同的参与者更新,一些人手动执行,一些人通过持续部署...
            0 0 478
            分享
          • 1. JMeter是什么?         Apache JMeter 是Apache组织的开放源代码项目,是一个纯Java桌面应用,用于压力测试和性能测试。它最初被设计用于Web应用测试但后来扩展到其它测试领域。可以到http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi下载源代码和查看相关文档。 2. 用它能做什么?         A...
            0 0 1372
            分享
      • 51testing软件测试圈微信