低摩擦最小要求收集

我们的团队如何以尽可能低的摩擦力从我们的"产品负责人"那里收集需求？

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

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

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

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

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

当然,一旦我们这样做,那么我们将看到产品所有者可能没有足够的时间来确保功能准确性.最终她负担过重,我认为这将有助于展示这一事实,但我只需要能够首先引起注意.

那有什么建议吗？

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

虽然"产品所有者"的概念对我来说有点模棱两可,但我认为我的工作环境非常相似:客户非常笨拙,而且始终是制定需求的瓶颈.

从表面上看,我们在这种情况下尝试做的事情非常明显且看似简单:我们尝试确保客户参与"只读/仅限谈话"模式.没有写作.最低阅读率.大多说话.

当然,魔鬼是详细的.所以,这里有一些关于我们流程的细节(没有特别的顺序):

我们经常从记录问题陈述开始,这是需求的最终来源.实际上,有时问题陈述是我们最初记录的所有内容,只是为了确保它不会丢失.

注意:将问题陈述与要求区分开来很重要.虽然问题陈述有时明显暗示某些要求,但一般来说,单个问题陈述可能会产生一大堆要求(每个要求都有自己的严重性和优先级); 此外,有时我给定义一个需求,为多个问题定义一个解决方案(通常只是一个部分).

记录问题陈述的主要原因之一(这与你的问题非常相关!)在语义上它们有点"更接近顾客的皮肤",并且比从它们得到的要求更稳定.我相信,只要有时间向开发团队提供反馈,这些问题陈述就能让客户更容易,更快地进入适当的环境.

无论何时我们要实现它们,我们都会记录所有要求(并将它们追溯到问题陈述).优先级控制着实施需求的顺序.当然,它们也管理客户审查未完成要求的顺序.

注意: 包含所有要求的单个胖文档绝对禁止!所有要求都放在"问题跟踪数据库"中,并附有错误报告.(一个错误只是我们书中一个特殊问题.)

我们总是尽力减少 "最终确定"每个要求(或一组相关要求)所需的迭代次数.理想情况下,客户只需要审核一次要求.

每当第一次审核结果不充分(一直发生),并且相关要求非常复杂,需要大量文本和/或插图时,我们确保客户不必重新阅读所有内容.划伤.自上一个修订版本以来的所有重要更改/添加/删除都会突出显示.

虽然问题或要求仍处于未完成状态,但所有未解决的问题(主要是客户问题)都嵌入到文档中并突出显示.因此,只要客户有时间审查要求,他就不必召集会议并向团队征求问题; 相反,客户可以先打开任何未完成的文档,看看他究竟期待什么,然后决定解决任何未解决问题的最佳方式和时间(对他来说).有时,客户选择直接撰写电子邮件或将评论添加到问题文档中.

我们尽力建立和维护官方域名词汇表(即使它分散在整个文档中).最重要的是,我们实际上迫使客户坚持使用该词汇.

注意:这是该过程中最困难的部分之一,客户不时试图"反叛".然而,在一天结束时,每个人都同意这是尽可能高效地与客户进行宝贵会议的唯一方式.如果你曾经参加过一个小时的会议,只花30分钟让每个人都在同一个页面上(再次),我相信你会喜欢有词汇量.

注意:只要有可能,官方词汇表中的任何更改都会反映在下一版本的软件中.

有时,一个给定的问题可以通过多种方式解决,如果不与客户协商,正确的选择并不明显.这意味着客户可以选择"需求菜单".我们记录了这样的"菜单",而不仅仅是最终选择的要求.

这可能看起来有争议,看起来像是一种不必要的开销.然而,这种方法可以节省大量时间,无论何时客户(通常是几周或几个月)都会突然跳起来,问题是"为什么我们这样做,而不是那样？" 此外,使用需求文档的正确组织/格式隐藏"被拒绝的分支"并不是一件大事.无聊但可行.:-)

注意:在准备"需求菜单"时,不要过度使用它们是非常重要的.太多的选择或太多的选择嵌套级别 - 下一次审查可能需要比实际需要更多的客户时间.毋庸置疑,精心设计的分支机构所花费的时间可能完全被浪费掉了.是的,这里很难找到一些平衡点(这在很大程度上取决于总是匆忙的客户能够提前考虑两个或更多步骤并快速完成).但是,我能说什么呢？如果你真的想做好自己的工作,我相信一段时间后你会找到合适的平衡点.:-)

我们的客户是一个非常"视觉化"的人.因此,每当我们讨论任何重要的用户界面元素时,屏幕模型(甚至轻量级原型)通常都非常有用.有时实时储蓄!

注意:我们专门为客户筛选模型,只是为了促进讨论.它们也可能被开发人员使用,但它们绝不会替代用户界面规范!通常,有一些非常重要的UI细节以书面形式指定(现在 - 主要是针对开发人员).

我们很幸运,拥有一个非常技术背景的客户.因此,我们毫不犹豫地使用UML图作为讨论辅助工具.各种UML图 - 只要它们帮助客户更快地进入适当的环境并保持在那里.

我当然是在讨论需求级UML图.不是关于实现级别的.我相信即使不是很技术的人也迟早会开始挖掘需求级别的UML图表; 你必须要有耐心,知道要在图表上放什么.

显然,这种过程的成本在很大程度上取决于团队的分析和写作技巧,当然也取决于您拥有的工具.而且我必须承认,在我们的案例中,这个过程看起来非常昂贵且缓慢.但是,考虑到非常低的错误率和低"蒸汽特征"率......我认为,从长远来看,我们可以获得非常好的回报.

FWIW:根据Joel对软件产品的好分类,该项目是一个"内部"项目.因此,我们可以像客户一样灵活应对.:-)