• 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

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

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   产品经理可以参考下图的流程方法:  1)需求收集:包括被动和主动的需求收集,其中主动的需求收集要求掌握需求收集的途径和方法,产品创意需要统一纳入到需求收集的范围;  2)需求分析:通过需求分析的层级模型,透彻地分析需求背后的用户问题和痛点,用户的需求场景,必要时还需要通过一些简单的原型确保准确地理解用户需求;  3)需求分发:不是所有需求都要纳入到下一个产品版本,成熟的需求管理团队能够发现高价值的中长期需求,在需求分发环节将其纳入到产品规划;  4)需求实现:该阶段的责任主体是产品开发团队,产品经理需要确保产品开发的各个阶段没有偏离自己的产品概念;  5)需求验证:包括产品经理对产品的验证...
            0 0 934
            分享
          •   据报道,为了省钱、增加收入,马斯克试图让员工购买Twitter办公室绿植。不愿透露姓名的Twitter工程师称,马斯克关注的重点主要是钱,为了省钱,马斯克已经炒掉了清洁和餐饮员工。  因为管理混乱,Twitter纽约办公室甚至出现蟑螂,马斯克无意与负责清洁卫生的员工续签合约,办公室甚至能闻到恶臭。  去年10月末马斯克收购Twitter,之后大刀阔斧改革,马斯克宣称改革是为了节省成本,防止公司破产。去年11月马斯克曾说Twitter每天亏损400多万美元。刚接管Twitter马斯克便裁员几千人,相当于员工总数的一半,而且公司不再提供免费食品。  因为一些账单未付Twitter被告上法庭,T...
            0 0 1067
            分享
          •      在这次面谈中,杰夫·佩恩,卡福罗的首席执行官和创办者,谈及了关于软件安全。他讨论物联网和它如何关联到关键性安全的设备,一些有用的工具,测试者如何测试安全,以及设备如何更方便地推动在你生活圈内的流程。  詹妮弗·博宁:我们更多在虚拟采访中背对着。希望你总是能在将近2小时我们即将讨论到的经常的话题留着。杰夫将开场。杰夫,感谢来到这儿。  杰夫·佩恩:感谢邀请我。  詹妮弗·博宁:对那些你不知道的事情杰夫,我过去已经和他谈过几次了。其中的一些事我觉得有趣去对虚拟观众谈论的是你也加入进来的事情。很明显的安全方面的大专家,所以我经常喜欢和您谈论关于安全。  杰夫·佩恩:当然...
            0 0 2077
            分享
          •   性能瓶颈就是制约系统性能的最主要因素,性能瓶颈定位指的是为了找出制约(系统、路径等)性能的最主要的因素而展开的分析、设计、测试、比较、调优等工作。  本文所述的性能瓶颈定位方法适用于使用三层架构开发的B/S架构系统的性能测试。根据影响范围的不同和触发时间的不同,我们可以将性能瓶颈分为三类:系统类、事件类和路径类。系统类的瓶颈一般表现在由于硬件、系统配置参数引起的一系列性能问题;事件类瓶颈为通过某些性能指标的表象分析出的系统存在的性能问题;而路径类则是由于程序本身的问题引起的性能问题,比如程序模块调用错误引起的 “http500”的错误,它需要程序员遍历程序路径定位性能问题所在。  本文介绍...
            12 12 3092
            分享
          •   测试报告作为测试阶段产物之一,是很好的收(che)尾(pi)文档,如何写出一份有价值的测试报告是测试工程师需要掌握的能力。  为什么是有价值的?因为部分同学的测试报告仅罗列了测试计划、测试用例、缺陷数据,即使图文并茂,也会因为缺少分析和总结而成为无效报告。  试想,如果你是测试经理/业务负责人/开发负责人,你需要从测试报告中了解到哪些有意义的信息?  笔者根据日常经验,总结出了一份简易的测试报告,里面包含了基础的信息,下面我们详细说一下。  报告编号  可以基于时间、项目名称、版本等标识设置报告编号(以定义好的编号标准为准)。  测试时间  描述测试开始和结束时间。  测试依据  说明该版...
            0 0 984
            分享
      • 51testing软件测试圈微信