本系列文章一共分为 4 篇。本篇是第三篇。建议阅读本篇之前先阅读前两篇。

二、产品的(0.5 ,1]

当产品形态及功能确定后,则进入到需求确认阶段。这个阶段是需要产品的所有参与者参与其中的,但是主要将以开发人员为主,确认产品功能的可实现性。

1,需求讨论 —— 大家来找茬

(1)目的:与开发人员准确、高效地确认需求
(2)适用场景:产品的某一个迭代,需要确认需求
(3)所需资源:

  • 7名以内项目参与人员(需包涵产品设计者、用户体验设计师、开发人员),开发团队负责人必须参与,其他开发人员尽量参与(如果人数超过7人,可以采用金鱼缸协作模式)
  • 产品全景图
  • 迭代功能的较详细文档(可能是word文档、可能直接是设计稿、可能是更具体的故事地图)

(4)操作方式:

  • 各参与人员站在自己的角度,思考各功能点在流程中可能出现的情况与问题,挑刺与找茬
  • 根据刚刚点意见,优化流程或提出更好的方式
  • 将讨论结果在不同颜色的卡片/便利贴上写出,贴在功能点的旁边

(5)解释/说明/tips:

  • 为什么需要产品全景图?这样做有什么好处?

    产品全景图可以帮助开发人员建立整个产品形态,能够完全清楚当前的整体的开发内容,利于架构的搭建,代码模块化/复用等等。

  • 需要注意的一点:在此过程中需要控制住,尽量不要延伸出新功能,也不要大范围的修改功能。如果大范围的修改了功能,也不建议直接以会议结果为最终结果。因为原本的方案是经过深思熟虑的,而在会议上,人太过于兴奋的状态下容易冲动,冷静下来再思考一下方案也会发现会议上的结果可能会存在很多漏洞。


2,需求拆解 —— story 下的 story 细分

(1)目的:将当前的 story 细分为开发人员可以接受、方便开发的 story

(2)适用场景:当产品的 story 颗粒度过大时,开发人员需要将 story 进一步细化

(3)所需资源:(与需求讨论的资源一致)

  • 7名以内项目参与人员(需包涵产品设计者、用户体验设计师、开发人员),开发团队负责人必须参与,其他开发人员尽量参与(如果人数超过7人,可以采用金鱼缸协作模式)
  • 产品全景图
  • 迭代功能的较详细文档(可能是word文档、可能直接是设计稿、可能是更具体的故事地图)

(4)操作方式:

  • 在多方讨论下,将大的 story 按照开发需要进行拆分
  • 将拆分好的 story 写在卡片/便利贴上,贴在对应大的 story 下方/旁边

5)解释/说明/tips:

  • 产品经理不要太过于干涉技术人员的拆分,在不涉及原则的情况下,他们开发怎么舒服就随着他们来吧。


3,优先级排序

(1)目的: 开发人员在一个迭代内,对开发内容进行排序

(2)适用场景:在“需求拆解”后,很自然的进入到优先级排序

(3)所需资源:(与需求讨论的资源一致)

  • 7名以内项目参与人员(需包涵产品设计者、用户体验设计师、开发人员),开发团队负责人必须参与,其他开发人员尽量参与(如果人数超过7人,可以采用金鱼缸协作模式)
  • 产品全景图
  • 迭代功能的较详细文档(可能是word文档、可能直接是设计稿、可能是更具体的故事地图)

(4)操作方式:

  • 在多方讨论下,将已经拆分成颗粒度适宜的 story 进行排序