生产中的MVPS
建立产品管理流程

通过manbetx官方网站多少

生产中的MVP:建立产品管理流程

这篇文章是生产中的MVPS系列。一定要让自己熟悉我设置的上下文在引言中.

在这篇文章中,我将解释我如何设计支持每一个初创企业中一个关键操作的流程:改进为客户或应该提供价值的技术,如果你正在努力签署你的第一个客户。

驾驶原则是两个相反的需求:最大化不间断时间和灵活性。开发人员希望在数天和数周内不间断地工作,商业利益相关者需要做尽可能多的事情,理想情况下,现在和同时。在一个初创企业中,没有什么可以计划的,所以我们要承担尽可能快地构建新功能的不可能情况,这需要准备和卓越才能使它正确,同时,留出足够的回旋空间,以快速改变焦点或融入最后一分钟的变化。

你也可以称这是一种疯狂的情况,努力实现两者。作为一个我无法改变的现实,我试图找到一个平衡点。当你加入一家初创公司时,你正以极端的杠杆率向外界提供大量的刺激,而且你通常每周都在拖累你的公司。没有多少经验,世界级团队成员,颠覆性的想法可以改变这一点。

将冲刺与发布分离

作为一个构建基于Web产品的产品团队,意味着您的产品可能会一直失败。在到达下一个发布日之前,您不能等待修复bug。必须立即修复缺陷,如果它们很重要,也就是说,当然。必须立即修复可能影响所有用户(如逻辑错误)或损坏数据的错误。使10%的用户无法点击按钮的浏览器错误应在一个工作日内修复。.无论如何,每隔一天你就会修复一次虫子,错误修复意味着:发布一个新版本。

所有更改代码的人,应该能够发布新版本,并观察他们刚刚发布的特性或修复在实际用户使用时的行为。这对于特性发布尤其适用。在过去的五年里,我从未见过一个新功能被故事所有者彻底审查过的案例,因为事实上,当你需要的时候,很难找到领域专家……但是你可以把这变成你的优势,让你自己从故事所有者的“回顾”中解放出来,让你的客户有一个新的功能。它们的行为将告诉您某个特性是有效的还是需要更多的工作。如果出了问题,有一些技术可以限制爆炸半径,我将在另一章中讨论。

因为开发人员拥有他们的特性的操作,并且他们是唯一能够判断特性是否准备好部署或者缺陷是否被修复的人,只有在每次冲刺结束时才发布,这将适得其反。这只会为不兼容的更改和合并地狱创造更多的机会。而且,由于它们只是构建了这个特性,所以很容易回忆起在哪里查找某个功能是否如预期的那样工作。

缺陷修复和特性开发同时存在,我发现这是为了在日常生活中创造一个良好的平衡。我会在一个分支中处理一个大功能,一旦我在某个特性(或保存点)中达到了某个里程碑,在那里我可以重新平衡并强制推我的功能分支)我可以花几个小时的时间不去想,修复错误,完成内务管理任务,将新版本的master发布到生产环境中。所有这一切还确保了更改在准备就绪时被释放,在最好的时候,而不是预定的时间。根据我的经验,发布日期将创建一个需要满足的目标,快捷方式是“在sprint审查之前提交最后一个修正……哎呀!”).让我们诚实地对待我们所学到的:在构建软件时,只有一件事是确定的,尤其是一个从未被建造过的:所有选择一个完成日期的尝试都是徒劳的,这些日期都是死的,薛定谔的猫:只要你不打开盒子,它们仍然是死的,但它们没有气味。

以及影响不到3%用户的不明显的IE错误,可以被安全地忽略,直到你真的没有更好的事情做,或者这些用户切换到其他浏览器。重要的是要了解排除一定数量的用户是如何转化为损失的收入的,并做出一个有教育意义的决定,确定修复这个bug是否有投资回报。

故事,不是问题

为了管理要做的事情,我反复使用受看板启发的Trello。我个人不相信使用像Github问题这样的问题跟踪程序,吉拉雷德明推动故事的实现。Trello中的卡片以团队中任何人都可以访问和理解的格式提供内容,但提供了其他功能,如清单,链接提交等。这有助于跟踪该特性的实现工作。

应实现的特性将添加到积压工作板中,并包含解释此特性的用户目标的描述,并提供其他背景信息,如线框和其他概念工作的链接。由于Trello无法处理卡描述上的协作,我更喜欢用谷歌文档来写概念文档。它的实时编辑功能优于我使用过的任何其他功能,并且与注释/注释功能结合在一起,它是编写概念文档甚至绘制伪代码的最佳工具。

故事是按主题组织的:我对什么是好的主题没有明确的规则,只是自然的故事聚类会自动出现。我通常每个产品都有一个主题,对于网站,营销。因为有些话题可以创造出源源不断的新故事,这很容易让人觉得它们更重要。但是有必要想象每个主题都有它的目的,并且有一些故事永远不会让它进入冲刺阶段,这更容易理解,如果他们总是在他们的主题列表上。

建立产品管理流程:积压Trello板

因为我们使用的是看板启发的方法,最重要的故事必须在每个主题列表的顶部。通常,每个主题都有一个专门的所有者,负责通过从客户和其他利益相关者那里获取信息来确定主题中故事的优先级。这个角色可以由任何团队成员担任,理解主题的重要性并有足够的资源来完成它。这不仅在更多的团队成员之间分配此任务的工作量,而且实际上为每个主题提供了一个单独的支持者。这不是最佳的,不过。我曾在初创公司工作过,在那里我们没有专门的产品经理,我认为这是任何初创公司都能犯的最大错误之一,但是拥有一个主题意味着你必须不断地重新评估现有的故事并回顾新的故事,这需要时间和承诺,这在初创企业中是很难找到的,因为每个人都已经做了比他们应该做的更多的事情。所以,找一个专门的产品经理!

积压板非常繁忙,往往会积累陈旧的故事。通常情况下,从积压到冲刺的故事流出比新故事流入积压要小得多。陈旧的故事是那些经常被优先考虑的比新的和更重要的故事低。随着时间的推移,整理积压工作需要越来越多的时间,因为您必须重新访问更多的故事并检查它们是否仍然有效,前提条件发生变化或出现新的前提条件。

尽量不要把它当作个人想法的草稿板。向董事会讲述的故事至少应该有一个明确的目标,更重要的是要有一个明确的价值主张:如果我们做了x,这将如何影响我们的收入?作为主题所有者,请注意一句话,很高兴有和使用标签来标记这些,并与故事的所有者跟进填补空白。如果他们不能,毫不犹豫地删除这些故事,因为它们要么不重要,要么不重要,将在稍后的时间重新出现。这里最大的规则是:听你的用户说!如果一个故事是从一个“我认为我们需要X”开始的,那它将是一个糟糕的开始。…如果你和一个“客户A说会为特性C支付B”合作,你的特性会更好。如果一个故事缺少一个真正的客户(a),意向书(b)或明确的用户故事(c)花时间去得到它们!

我鼓励主题所有者在他们的个人计划中有一个单独的积压板。通过这种方式,他们可以收集想法,并以一种允许更多自由的方式组织它们,并且与他们喜欢的工作风格更加紧密地联系在一起。然后,他们将要实现的故事转移到积压板中。

约翰·卡特勒有一个一大堆问题考虑。

冲刺计划

积压工作正在进行,每天都在进行。另一方面,拥有某种结构是很重要的,尤其是因为在初创企业中协调日历是如此复杂,所以对付这个跳蚤马戏团的唯一方法就是找到一个固定的时间来安排会议,不管怎样都要坚持。在我的经验中,参与构建产品的每个人都必须进行一次同步,没有工具能够完全消除同步会议。

冲刺计划是我在两周冲刺周期内建立的两个会议之一。通常发生在周一,每周之后。在这次会议中,团队将决定每个主题中优先级最高的故事中的哪一个将被带到冲刺中。如果积压板维护良好,这个会议可以很快完成:在准备阶段,我们将把每个主题中优先级最高的故事放到sprint计划栏,然后按优先级顺序重新安排它们。在这一点上,我们还将讨论考虑到未来两周的预期能力,我们对这些故事中的哪一个有信心建设。

建立产品管理流程:积压Trello板

两周只是我觉得可以轻松预测的地平线。四周是一个时代,考虑到大多数故事确实很难估计,因为你正在构建的大多数功能都是实验性的和独特的,几乎不可能从以前的故事中得出关于故事大小的结论。另一方面,一周时间太短,无法真正完成任务,因为在任何给定的一周中,可能只有一两天时间可以集中精力完成一项任务,持续半天。

建立产品管理过程:不确定性

两周的周期也为每隔一周整理积压工作提供了一个很好的机会,这是冲刺周期的第二次会议,在这个过程中,主题所有者和我将浏览下一个冲刺的故事候选,寻找冲突和丢失的信息,这些信息将阻止他们进入下一个冲刺。

这次会议也提供了一个很好的机会来介绍新的,需要放在快车道上的重要故事,基本上胜过了接下来的所有故事。这种情况经常发生,因此,让每个人都知道哪些功能正在开发中,如果他们被推迟到下一个冲刺阶段,那么这总是很好的。解决这类冲突不能通过工具(例如但只能在同步会议中协调。每周都跳这个舞,在春季计划和积压的整理中,将保持每个人对产品开发进度的了解,并将讨论减少到最低限度。

如果你每个人都想找个五个人的午餐约会,尝试重新安排那个日期:不可能。这就是为什么你坚持会议日程,不管怎样。你按点开始会议,然后每个人都会收到会议记录。.准备是关键,如果积压板管理得当,冲刺计划的结果不会令人惊讶。

预先写好的会议笔记对你有很大帮助.

冲刺

在sprint计划之后,使其进入sprint的故事将被移动到sprint板的待办事项列表中。.Sprint板的所有者是开发团队,只有他们在那里移动卡片。它还可以作为已实现功能的历史记录。一旦开发人员开始实现一个故事,它就会从待办事项列表转移到待办事项列表。当他们将其部署到生产中时,这张卡活了下来。live的意思是“它是公开的,但仍需要一些工作”,这种情况发生在so特性上,这些特性从实验开始,在(一些)真正的用户使用它并提供反馈的同时得到了改进。这里也是Trello作为产品管理工具真正闪耀的地方:讨论功能和检查表对于跟踪每个故事的进展都是很好的。

建立产品管理流程:Sprint Trello董事会

Sprint板也用于跟踪错误,它不遵循故事的典型生命周期。它们中的每一个都由Trello中的一个专用卡表示,但是给它们一个不同的标签(我选择了一个红色的“bug”卡)使它们很容易被发现或过滤掉。虫子不需要像故事那样详尽的描述,因为它们通常是不言自明的:bug是指一个特性的行为不符合定义,这也意味着:如果没有定义,它就不是bug。bug卡胜过待办事项列表中的所有其他卡,并从那里快速移动到完成。他们不应该在“待办事项”栏停留超过一天。

一旦一个故事或bug完成,它的定义高度依赖于您的个人需求,但必须在活动文档中定义,但它已移动到当前月份的“完成”列表中。使用它可以为您提供所发生事情的良好历史记录,并且每月分组可以方便地回忆和查找功能,以便以后重新访问它们,当你回顾你在描述故事时对预期结果的假设是多么准确的时候。这也是记录故事最终实现的时间,方法是更新描述并提供最终结果如何表现和外观的详细解释(此处使用屏幕记录有助于轻松理解发生了什么变化)。

特雷洛管家可以帮上忙。

什么是释放?

…当您每天部署到生产环境中时?
…当您的产品由微服务组成时?
…当您为选定的用户组拥有长达数周的功能时?

这是您决定为所有用户激活某个功能的时间点。如前所述,软件发布周期与产品管理过程分离。没有必要协调它们,但只会在合作者之间创建更多不必要的耦合,这些合作者可以以自己的速度完美地工作。

故事卡上公布了一个特性,任何有兴趣的人(订阅了该特性卡的人)都可以看到这个特性,您还可以在相关的松弛频道上发布消息。

这是一个团队的努力

这种管理产品的方法允许每个人都参与到产品开发中来,并且在不占用太多时间的情况下,进度变得明显和透明。它很灵活,在整个团队中培养了很强的自我组织能力。每个人都有一个真理的来源,这是保持每个人都处于循环中的一个关键因素。


这是生产中的MVPS邮政系列。非常感谢你塞巴斯蒂安内尔拉尔夫D米勒斯文·克洛彭伯格花时间回顾了这篇文章,并提供了很好的反馈和想法!

想看更多吗?为了打开下一章,在我开始第二篇文章之前,我希望有10位读者加入我的影响者小组。然后你就可以选择我要继续使用哪一个了!填写这张表格并做出选择!