低摩擦最小要求收集

时间:2008-09-29 01:24:20

标签: requirements process-management product-management

我们的团队如何以尽可能低的摩擦力从我们的“产品负责人”收集需求?

现在这里是指导方针 - 没有任何帖子无法完成,或者企业需要做出关心质量的决定,yada yada。我工作的产品是一个多年来一直成功的小团体。我只是想帮助他们提升一个档次。

基本上,我是一个拥有一个产品负责人的6人或7人团队。她做得很好,但是却扮演着一些不同的角色(我相信在极小的团队中很常见)。通常需要在零星的时间(电子邮件集合,面对面讨论,会议等)提出要求。它们永远不会进入系统,有时会因为每个人都忘记了必要的功能而导致功能缺失发布或推迟发布。

如果你遇到类似的情况,但是你找到了解决这个问题的方法,我很乐意听到。我很乐意编写代码来帮助缓解这种情况,但它不能成为产品负责人必须去的网站才能完成任务。她非常忙碌,我们需要一些团队合作的方式来收集这些要求。

我目前正在考虑这样的事情:开发人员和团队成员收集面对面会议中讨论的要求,并写一些关于维基页面上讨论的功能的快速说明。每当这些页面更新时,产品所有者都会收到通知,然后她就有责任确保准确性。

优点:我们会有一些功能记录。缺点:开发人员对他们通常不会做的事负责。我在这里很好。我认为在这种情况下,这是团队合作。

当然,一旦我们这样做,我们就会发现产品所有者可能没有足够的时间来确保功能准确性。最终她负担过重,我认为这有助于展示这一事实,但我只需要能够引起人们的注意。

那么有什么建议吗?

P.S。她的时间非常有限,所以期望她在讨论后需要输入要求被认为是不合理的。她只有时间讨论一次并继续前进。

3 个答案:

答案 0 :(得分:5)

答案 1 :(得分:1)

“开发人员和团队成员收集面对面会议中讨论的要求,并撰写一些快速笔记”

从那开始。如果你没有记笔记,只需做一个小改动。做笔记。稍后,您可以将它们发布到维基或创建功能积压或开始使用Scrum或bugzilla或其他东西。

然而,首先,做一些小改动。写下来的东西听起来就像你没有做的事情,所以就这样做,看看有什么改进,接下来你可以做些什么。敏捷。增量工作。

答案 2 :(得分:1)

您可能需要小心房间内的HiPPO。最高薪人的意见并不总是好的。我们倾向于更多地关注为开发人员提供出色的工具和支持。这些事情做得恰到好处,将一些麻烦从开发中解放出来,以便它变得更快,更有趣。然后,开发人员在工作量方面更加灵活,更容易接受最新的变更。

一键式测试和部署是一些好的开始;确保每个开发人员都可以在几秒钟内运行自己的软件堆栈并直接尝试创意。然后,开发人员可以快速进行修订或沿着他们感兴趣的侧面路径运行,这些路径通常是最成功的。通过成功,我的意思是根据在系统中收集的实际指标来衡量成功,并使所有相关人员都能随时获得。然后,所有者可以设置他们可能关心的指标,而不是他们要么不关心或没有定义经验的要求。

当然,这取决于所有者和您的具体情况,但我们发现指标比需求更容易讨论,开发人员也非常擅长解释它们。一个典型的问题可能是客户似乎花了很长时间来填充他们的购物车,但不会继续结账。

1)营销要求可能是使结账按钮更大更红。 2)首席执行官的要求可能是让客户直接结账,因为首席执行官只会一次购买一件物品。 3)UI设计师的要求可能是在购物车顶部放置第二个结帐按钮,在底部放置现有的按钮。 4)开发人员的要求可能是一些Web 2.0 AJAX小部件,它遵循屏幕上的鼠标指针。谁是对的?

谁在乎......客户可能看到了交付的荒谬成本并逃之夭夭。但是,将问题重新定义为度量标准,而不是要求,突然开发人员对此感兴趣。开发人员不必与CMO进行10轮比赛,按钮应该是红色的。他可以整周玩他的Web 2.0,然后在周一早上赶走其他3个解决方案。每个人实时部署48小时,并立即测量并报告购物车到结账率。这些都没有任何区别,但是开发人员必须完成他们的工作,并且业务将重点放在他们销售的蹩脚产品和他们交付的价格上。

好吧,好吧,所以这个例子是做作的。这里有很多工作要确保项目规模小,团队经验丰富,热部署简单,提供即时回滚,以及每个人都在工作。我们想要达到的状态是开发人员的全部潜力不被浪费的状态,这就是为什么他们不仅从一开始就参与其中,而且也参与成功。从注册过程中的点击次数过高等问题开始,通过设计委员会运行,我们发现设计规范中的点击次数实际上增加了。无论如何,这是我们的经验。但是让开发人员可以自由地减少点击次数,你可能真的会像我们一样获得专利解决方案。并不是说开发人员关心专利,但它有优点 - 而且没有点击!