epic控制有多大(Epic定义)
epic控制有多大(Epic定义),本文通过数据整理汇集了epic控制有多大(Epic定义)相关信息，下面一起看看。
史诗级(对史诗的控制)史诗级功能是如何设计的？如何刷动态评分敏捷项目管理将Feature分为“史诗”和“故事”两个层次。史诗 是用多个故事来描述一个非常庞大的功能。作者从实际工作中的方案设计出发，讲述了如何完成一个史诗级的功能设计过程。
当我们决定做某个功能的时候，我们就进入了产品经理基于对需求的理解设计功能方案的环节。
场景和需求的细节在本文中不再赘述。本文只谈功能方案设计的过程。
01史诗？众所周知，敏捷项目管理把特性分为两个层次史诗和故事。
史诗是 多个故事来描述一个非常大的功能。如甘特图、地址字段等。所有这些史诗都可以拆分成至少一个MVP版本的大故事和后续打补丁的小故事，单独发行。
以甘特图为例，我们只需要在Phase1的MVP阶段按“开始日期”和“结束日期”生成甘特图，就可以在时间线上显示项目的进度。
对于“甘特图可以根据某个字段进行着色”、“任务可以在甘特图中分组显示”、“故事和结束日期可以通过拖拽设置”等需求，则拆分到后续故事中单独发布。
这样做的好处是尽可能缩短一个大功能的发布周期，避免把资源花在对用户价值不大的功能上。
敏捷和瀑布的优缺点，太基础了，不谈。我们就开门见山的说一下，当我得到一个史诗级的函数时该如何处理。
我仍然渴望生存。我声明，本文仅代表我个人观点，不代表公司立场。
阶段02说明我会从想法整理、初步方案、阶段1总体方案、验收用例、交互细节四个阶段来推广一部史诗。
这四个阶段将产品经理和交互设计师常用的英国设计协会“双钻石模型”与d.school的IDEO设计思维相结合，梳理成更符合黑帕云产品功能设计节奏的 形式。
双钻模型
IDEO设计思维
不难看出，以上两种思想的 都是先发散再收敛，再发散再收敛，达到促进功能的发展阶段。
从每周发布功能的数量可以清晰的了解到，黑帕云是一家高效的产品公司。我们有三个产品经理和两个设计师。虽然每个人负责不同的产品线，但我们还是需要每周固定时间见面开一次研讨会。在会议上，负责人将解释需求背景和功能设计方案。
在CEO陈金洲先生(微信官方账号米高说)的一再强调下，为了保证产品研讨会的效率，很多流程产品都不会在本次会议上进行宣讲和讨论。(比如各种脑图、流程图……)
在产品设计之前，属于“响应客户需求”的阶段。从“提出需求”到“采纳需求”的具体分析，请参考上一篇如何响应客户需求的文章。
1.分析与研究得到C 给出的信息后，我们开始了一些分析与研究工作。这个阶段是一个分歧的阶段。我们需要尽可能地找出用户的问题是什么，业务上下文是什么，竞品的动作等等。还会有一些零碎的、无结构的研究成果。
但在这个阶段，我一般不会形成文字材料，只是把老鹰或麻雀的笔记扔进去，草草记下。易于快速记忆，易于快速查找和浏览。
2.做完思路的分析和研究，问题的雏形已经开始在大脑中形成。接下来要做的就是把这些思路聚焦到问题上，定义出对用户最有价值、技术成本相对较低的要解决的核心问题。主要进行宏观需求分析，梳理大致思路。会形成一些速成的思路，但还是主要是梳理目前的问题和局限。尽量根据这些问题快速解决 问题，不考虑现阶段的细节、交互和呈现，也不考虑phase1计划做什么。
过了这个阶段，会有一些低保的图片，可以用来表达想法，在会上讨论。讨论过程中需要关注解决方向是否合理，技术是否有限，是否可行。
3.初步方案在整理思路的结果基础上，我会开始做一些设计探索，开始铺开不同角色视角的界面呈现。
在这个阶段，方案的范围将被框定，功能逻辑将被编写并显示在真实场景仿真的中高保真界面中(它有助于描述功能和表意组件之间的层次结构，但不代表界面设计方案)。现阶段不关注界面设计是否合理，文案是否优雅。而是要把重点放在需求层次和功能的设计上，通过两三次讨论吸收会上大家的反馈，然后再进行突破和审视，避免遗漏业务场景，从而对设计方案做出更好的解决方案。
4.初步方案讨论后，第一阶段的总体方案将与最小最简单的业务场景相衔接，第一阶段的总体方案将被框定。框架是基于模拟一个真实的场景，在这个场景中遍历业务，看初步方案是否能满足要求，然后从之前的方案中裁剪出功能，把范围降到最小。然后拆分其他功能，安排在后续版本迭代中。
栗子比如“地址字段”功能MVP可以填写收货人地址，在订单场景中筛选收货人地址。分组和统计需求可以被分解到后续的迭代中。这一阶段的重点将不再是多场景，而是评估所选择的场景是否合适，以及第一阶段的功能设计和范围是否能够满足所选择的场景。
5.验收用例与交互的阶段主要是故事拆分和细节验收标准(AC)的编写。一般我们不会在现阶段的产品讨论中与大家同步。一是细节太多，二是没必要讨论，三是浪费大家时间，讨论价值不高。
，故事的粒度是基于能够交付给客户的价值(也可以描述为能够进入一个完整的测试)。在拆分故事的过程中，AC需要描述清楚。在Show Case中开发时，AC将被逐个显示。
AC需要描述用户的使用路径，什么角色看到什么入口，点击后会发生什么。除了正常逻辑之外，还需要处理一些异常逻辑，比如数据量超过X块时不允许复制数据。除了期望的功能之外，还应该考虑其他相关的影响。
示例例如，如果在成员字段中打开了“允许多个成员”，则函数期望在填充成员字段时可以添加多个成员。相关影响包括如何在过滤条件中过滤多成员字段，如何在增量导入数据中识别多成员，是否可以进行分组，是否可以由多个成员生成图表等等。
在这个阶段，我们会尽量避免遗漏场景，并仔细检查交互是否合理。
接下来以某黑Payun在2021年6月4日发布了一个“筛选关联”的功能为例，说明功能设计的全过程。
需求背景最早由从事汽车后市场的肖特科技提出。Little Tech使用Heipa Cloud来管理他们商店的订单数据。
在上一篇文章中，数据表中最新的关联记录中提到了“关联”。同样，订单数据中有几个相关的表
所以当你创建一个订单的时候，你需要填写“订单商店”，购买的“商品类型”，填写购买的“商品”(库存表)，像这样
选择“购买商品”会显示库存表中的所有数据。
在Airtable中，会显示所有商店和所有类型的库存商品，商品是否有库存取决于人工筛选
特科技建议，可以根据刚才订单中选择的“门店”和“商品种类”直接选择库存商品，这样就不用每次都用肉眼寻找了。
在研究阶段，竞品的研究是必不可少的。可惜当时Airtable没有这样的能力，所以没有参考方案。
在对需求和业务有了足够的了解后，我开始整理一些快速的想法。
1.，场景模拟找到了几个比较真实的场景
(1)如图所示，订单中有“商店”和“商品类型”字段。当您要选择商品时，可以根据大于0的“店铺”、“商品类型”、“存货”筛选条件筛选出符合条件的商品
(2)培训机构的财务部门正在为在校学生记录缴费记录，希望关联的学生名单能够过滤出“在校”学生。
(3)在生产工单中，已经选择了该工单的工序。选择设备时，希望能直接过滤掉该工序的设备。如果选择的工艺是“表面处理”，希望在选择设备时，只出现“表面处理”的设备。可以过滤掉“热处理”和“退火”等工序的设备。
这些场景的共同点是过滤可能是一个固定值(例如，您可以将员工的状态设置为“在职”)，但它也可能是一个动态值，具体取决于订单或工作订单中填写的值。
于是我们在商业价值上有所收敛，即“通过设置一个固定值或者动态值，可以对关联数据进行筛选，从而快速选择用户需要的数据。”
接下来，定义问题。筛选很容易做，但我们提供这样的能力。是权限问题还是辅助问题？
2.如果是权限问题，请定义问题(1)
即订单员、财务、生产工单调度员只能选择按过滤条件过滤的数据。例如，所选商品必须是所选商店所有且库存必须大于0，所选学生必须在学校，所选设备必须是上一流程对应的设备。例如，设置如下
(2)如果是辅助筛选问题
既然不是权限问题，只是一个快速过滤功能。意思是选择要过滤的数据时，可以选择按过滤条件过滤的数据，但也可以使用不符合过滤条件的数据。比如可以选择库存小于0且不在所选店铺的商品、已经退学的学生、与所选流程不匹配的设备等。
乍一看真的是权限问题？不要妄下结论，先思考这两个问题
如果要限制订单中所选店铺可以选择的商品，如果订单中的店铺选择了“钟楼店”，并且在选择了钟楼店的商品后，再将订单中的店铺修改为“大明宫店”。如何避免这种情况？
提交数据时是否要判断所选商品是否符合筛选条件？
考试要来了，测试你一个阶段的研究水平。虽然你的用户在创建订单和工单的时候只提到了场景，你需要深入挖掘整个业务流程。直到你发现“客户的订单处于状态，而且这些状态都是在仓库里修改的。比如库管员要在仓库操作后改变状态，填写快递单号。”3354这是需求的B面。用户不会主动说自己认为不相关的信息。这些都需要你有需要看到事物全貌的感知，然后继续探索和挖掘。
在学校给学生交费也是如此。A面是为在校学生正常录入缴费记录，B面是为已经退学的学生缴费。
所以，如果这是一个权限问题，你得到的答案要么是权限不严谨，要么是用户觉得做功能总比不做好。
05初步方案最终定位了上一阶段的问题后，我们开始下一步的功能设计方案的探索。
你可能会想，产品经理一定要做功能设计吗？在一个高效的产品设计团队中，每个人的职责边界并不是那么清晰。我们没有一个人在做螺丝钉的工作，所有的工作都是为了更好的设计一个用户喜欢的有价值的功能。
虽然衡量商业价值和定义功能是产品生的核心工作。对于一些逻辑非常强，业务相对复杂深入的功能，如果把这些信息传递给下游的设计师，中间肯定会丢失一些信息。如果能做的更多，尽量不要向下游传递信息。
说到下游的交互设计师或者UI设计师，他们的目标不仅仅是上色和整理间距，而是要站在产品同学设计的功能方案的基础上，站在用户的角度重新思考。这个功能的重要信息和次要信息是什么，用户在使用过程中如何更清晰、更容易地达到自己的目的？这是设计价值的体现。
需要注意的是(也是我犯过的一个错误)我们不能只是把需求描述和功能设计方案直接扔给设计师，然后要求他们进行最终的UI设计。
因为如果你这样做，要么你得到的是一张功能改得面目全非，在你看来漏洞百出的设计图，要么你得到的是一张没有任何设计点的工整设计图。
后来才知道，对于设计师来说，需求和功能设计方案是不够的。设计师也需要我为R&D开卡，把设计师需要帮忙做的事情解释清楚，需求背景是什么，为什么会有这个需求，我得到这个需求后的整个思考过程是什么。确定我和设计师的目的一致，也就是所谓的“拉通，对齐”。
这样做的目的是让产品经理和设计师的价值和效率最大化，发挥自己擅长的东西，让对方补上短板。
，如何衡量功能和UI设计方案是否达标，可以用基本的G 模型快速评估
说到 ，突然想跑题了。
这两年，似乎大家都对 的理论嗤之以鼻，认为它只是机械的照搬，尤其是我们这些非专业的产品经理和一些靠自己的经验和天赋成长起来的设计师。
很惭愧的说，我自己两年前也是 理论初学者，学到的东西。如常见的用户体验之旅、电梯演讲、利益相关者地图、共情地图、盗版模型(AAARR)等。为了让设计方案“高级”，这些内容都是在现有方案上包装的。
这显然违背了 论的初衷。 理论是前人在经验的基础上形成的一套认知和指导理论。让我们站在他们知识的肩膀上，更好、更高效地进行设计。
经过两年紧张的研究实践，突然发现 的很多理论都在不知不觉中被自己用上了(比如上面提到的G 模型)。这是因为在熟悉了 的理论之后，思维方式和设计策略都受到了影响，哪怕只是一个小点的运用和自己的“本土化”，最终得到一个经得起用户推敲和评价的方案。我想这就是人们学习 理论的目的。
回到正题。
再重申下面这个问题选择关联时如何辅助筛选，让用户快速找到目标数据？
想想谁能做这个筛选，筛选入口在哪里合适。第二个问题有一个明显的答案，因为题干已经告诉我选择联想的时候。
然后，您可以直接将范围缩小到选择相关数据的项目符号框。然后再考虑谁能做这个筛选。
我觉得在某些场景下，这个子弹盒是可以看到的，一般是经常操作的一线业务人员，比如模拟场景下的店员、财务、生产订单调度员等。他们通常不是应用程序管理员。
会不会有人不注意改设置影响到别人？管理员可以信任应用程序成员的权限吗？或者您需要权限来管理此筛选器？
这些都是需要发散探索的东西。
这种情况下的这一步，其实我当时也没做好。现在回过头来整理复盘，发现自己当时传播的还不够，也没有做什么深入的研究。我只是凭直觉认为它的权限应该是被管理员控制的，然后就把问题匆匆扔进了研讨会。
会上，有经验的CEO观点指出，建议先把权限放开给所有用户。原因是我们现在的目标是让这个功能被更多的人发现，被更快的使用，更快的传递价值。所以它的受众不应该仅仅局限于管理员，即使非管理员做筛选，也没什么大不了的。
回过头来看，我对功能有了更深一层的理解管理员并不在乎别人关联的是什么数据，因为这不是权限控制的问题，这是在快帮的使用中筛选目标数据的问题。如果没有关联的权限，那么还应该在角色和权限中设置该角色对关联表数据的可见权限。
确定以上两个问题后，推导出以下设计目标
拥有相关字段编辑权限的用户可以轻松发现这一新功能，成功设置过滤条件，并保存设置。要让别人收到“数据已被过滤”的信息，就需要有一个相对明显的标记，防止用户产生“为什么数据不完整”的疑惑。下一步是探索具体方案。
如下图所示，我的一个方案是把条目放在对话框表头的右侧，关闭按钮的左侧。(因为这里有一个按钮，所以单击后可以在下拉列表中对关联表的字段进行排序和隐藏)
点击查看如下设置说明
这个程序得到的反馈是“把简单的函数复杂化可能是你现在最得心应手的能力”。
只是，真的，用户没必要看那么一长串的功能描述。结果是“让用户快速使用功能”这个信号的分数在及格线以下。
看第二个计划
这个方案非常接近设计目标。是否通过开关使用设定的过滤条件，完全由个人决定。单击右侧的“展开筛选条件”展开，查看现在有哪些筛选条件可用。
不过CEO也对设计方案做了一些用户感知的优化建议，就是我们在网上看到的版本。
当没有过滤条件时，你会看到“过滤”按钮，用户可以在这里快速得到需要过滤的信息。
点击过滤后，还会展开设置过滤条件
保存后，您会清楚地看到这些数据经过了筛选
6一期方案这部史诗非常容易拆解，因为总体设计方案已经在阶段决定了。
所以在设定一期场景的时候，整个设计方案的框架是不能跳过的。
在之前“04思路整理”阶段的“场景模拟”中提到
这些场景的共同点是过滤可能是一个固定值(例如，您可以将员工的状态设置为“在职”)，但它也可能是一个动态值，具体取决于订单或工作订单中填写的值。
所以很容易拆解Phase1，满足那些需要过滤“定值”的场景。设计也完美的覆盖了这个场景。
之后在今年9月9日发布了动态值的过滤。收到了用户“筛选他们很久了”的好评。
07写在写这篇文章的，我发现Airtable已经发布了类似的功能。
它的条目是在这个关联字段的设置上，也就是我们开头讨论的“权限问题或者辅助筛选问题”。不能说Airtable对业务理解不够深入，而是他们这样做是因为与黑帕云在产品受众和定位上的差异。
我相信国内的竞争对手很快也会有类似的功能，我很期待看到他们如何定义这个功能。
个人猜测还是会像Airtable一样，因为定位更相似，都是团队合作的结构化电子表格。拭目以待~
作者高拉，微信微信官方账号高拉
本文由@ Gola原创发布。每个人都是产品经理。未经许可，禁止复制。
来自Unsplash的图像，基于CC0协议。
此观点仅代表作者本人，大家都是产品经理。平台只提供信息存储空间服务。
epic平台的界面有什么优缺点？
更多epic控制有多大(Epic定义)相关信息请关注本站，本文仅仅做为展示！