产品负责人应该负责初始原型吗？

Question

产品负责人(甚至是BA)根据需求文档创建一个高级别的系统原型/线框，以确保需求足够清晰，可以开始为UX和开发团队编写用户故事，这是典型的吗？

目前，我正从一名开发人员“升职”为UX设计人员，并负责直接从需求文档创建模拟，但该文档在几个方面不清楚，到目前为止，我大部分时间都在做我认为更多的PO/BA工作，以澄清需求文档中的基本内容。我知道这个过程是迭代的，UX/dev团队可能需要在设计和开发过程中讨论/澄清项目，但是在这之前PO需要交付某种“最低可行的需求”阶段，这是如何确定的呢？

编辑澄清:这里的原型指的是像Sketch这样的高级视觉辅助工具，而不是代码中的第一个修订版实现。此外，在我的示例中，不存在用户故事，只有一个原始的、不完整的需求文档。

Answer 1

我会说不。考虑到PO应该专注于定义业务价值。拥有PO创建的原型在技术上影响团队的发展。我认为很重要的一点是，业务价值得到了很好的定义，这样团队才能实现它。此外，创建一个原型的行为也是一种学习体验，目的是了解如何实现业务价值，甚至可能是什么是业务价值。这将是一个错失的机会，对团队来说，不做原型。团队和PO之间的接口是用户故事和定义的业务价值。让PO做原型可以软化这一点。

这听起来好像PO曾经是个开发人员，我有过这样的经历。

作为一名scrum大师，我相信PO不应该发展。专注于定义业务价值和维护待办事项是产品所有者与团队沟通的方式。(当然，语言上也一直如此，毕竟我们是在使用敏捷原则)

Answer 2

由于Product通常在业务方面，他可能无法以任何方式生成任何代码，甚至连一个基本框架都无法生成，但不应该期望他这样做。

你可以让他在黑板上画线(或者像Visio那样的东西)，但是让他做任何技术工作都是没有意义的。然而，你可以在一块板上一起开发“纸原型”，画出你理解的东西，他根据他的意思或他的喜好纠正你。

Answer 3

PO应该做任何必要的事情，以确保故事是足够清楚和明确的，以便团队能够在它上工作。如果这意味着类似产品的截图，线框，画在餐巾纸背面的涂鸦，文字的墙壁，或者其他什么的，那就这样吧。

这在很大程度上取决于产品/功能的复杂性以及团队的经验。PO对于该功能的外观/工作方式的愿景也将发挥作用。用户输入“是”/“否”选项的方法可以实现数十种，因此，如果PO有特定的想法，线框或模型可以帮助提高清晰度。

而且，它几乎肯定是一个迭代过程(至少要开始)。对于团队来说，故事的第一步可能是完全不清楚的，所以一些细节会被添加或澄清。第二个回合仍然有点不清楚，所以PO增加了一个模型，然后它变得足够清楚的球队得分和工作。

说到底，最重要的是接受标准。模型和屏幕截图可以帮助指导开发，但是团队可能使用一种与PO所想的不同的方法来满足验收标准。