我们的目的不是发现新的做事方法，而是发明有用的方法来清理和整顿局面，并建立合适的团队结构，从而提高团队内部和团队内部的一致性。
在mesosphere(https://mesosphere.com/,which将在前面介绍)，产品想象团队正在努力将产品的UX(用户体验)可视化。一般情况下，UX主要触及我们主要产品DC/OS的GUI部门，以及CLI、UXideas、API、文档等开源产品。
我喜欢想象团队业务流程的样子。作为一个有远见的人，了解其他团队是如何做的，他们取得了什么成就以及如何应对这些问题通常是有效的。
受Buzzfeed、Airbnb和Shopify的启发，我们最近整理了我们的产品创意流程。我们不是第一个在集合上公布我们业务流程的团队，但是我觉得把那些内容写下来分享给大家，让大家一起去讨论利益，是一种很棒的体验。
我们的目的不是发现新的做事方法，而是发明有用的方法来清理和整顿局面，并建立合适的团队结构，从而提高团队内部和团队内部的一致性。
——Buzzfeed想象力经理汤姆·哈曼
在中间层关闭
首先，我来介绍一下风景。
在Mesosphere，我们为Yelp、威瑞森和彭博等公司提供产品和服务，以处理其IT硬件和软件基础架构。
我们的主要产品MesosphereDC/OS是一个以数据为中心的 *** 作系统，可以真正实现服务器的资本处理，包括处理器、内存、硬盘等存储资本。
鉴于我们产品的特点，其实就是安装在公司一个服务器上的 *** 作系统，不需要每天发布更新。我们大版的出版周期是一年三次，是比较小的出版周期。
想象中的产品脚色
我们的产品处理团队和开发团队一起努力工作，提供具有成本效益的产品和功能，并可以为客户停止。
对于每个项目来说，E(工程)、P(产品管理)、D(设计师的想象力)就像一个三脚凳。
在一个成功的项目中，这三个圈子必须得到同样的尊重。当然项目里还有一些其他的队伍，但是那三只脚对于中心战来说是必不可少的。
从一开始，开发、产品和想法就会融入其中...团队应该像一个三条腿的凳子，每只脚代表一圈成功的产品。如果一开始就能达到图A的水平，那么按适当比例展开后就能形成图B。
——AirbnbImagination副总裁AlexSchleifer
我们真的停止了“单轨”的产品开发形式。那种开创形式有两条无止境的轨道，一条是“委托”，一条是“发明”。“委托”关心下一版的特性开发，“发明”关心下一版。
想象一下，老师会专注于“发明”产品和技术组，花很多时间在一起，停止快速学习，研究产品特性和市场。
为什么记录想法的过程很重要？
我们公司计划为团队创造一些情境:
想象一下，各个部门正在用不同的过程处理他们自己的项目。
我们的团队应该做什么，大概告诉我们做了什么，但是我们不清楚那些成绩。
当一个新的有远见的人上任时，无论是新人还是有新人的有远见的人，都很清楚如何在当前的项目中开展事情。
我们堆了很多处理过的结果，提出过假设，但是都有记录。
老师不能快速反应，因为他们其实不知道自己是否有权力去阻止一些决议和计划。
我们怎么做呢？
我一个人处理不了那个工作，所有的需求都指望团队来完成。因此，我们找到了不同团队的远见者，花了两个小时构建了一个构思研讨会。
以上成绩我都在背。然后，我们将通过流程讨论其他想象中的团队(例如，BuzzFeed、Airbnb、Intercom和Shopify)，以了解他们在做什么，包括讨论IDEO、GoogleVentures和DesignCouncil上正在宣布的一些停止业务流程。
然后我列出了我们期望达到的目标:
将团队的讨论与我们一起进行，差异将被记录下来。
我们正在停止公司内部对我们事务的宣传和培训。
让团队的新视野者快速上手。
让远见者更快地融入新项目。
给远见者必要的决策权和计划权，让他们在项目中快速反应。
我们在黑板上标出项目需求的各个阶段。然后，我们用一种颜色的纸条写下设计师每个阶段需要做的事情，用另一种颜色写下我们需求咨询的突出成果。
以上产品我们都很满意，接下来我们会拿着产品，开辟一个团队来分享我们的效果。这些效果可以作为他们下一步的输入。
为什么我们没有接受现有的流程？
毫无疑问，我们可以获得公布的模型流程，那些流程可以处理我们80%的成绩。但是每个公司，每个团队都不一样。
如果你想让事情恶化，有很多因素需要考虑。我们公司现在处于什么阶段？我们多久发布一次？我们团队的规模和范围？产品战打开的东西是什么形态？利用急流、瀑布或者两者兼而有之，是一种开拓性的形式吗？一个过程需求符合一切的项目，不仅是UI项目，还有CLI、API和其他开源项目的例子。水果太多了，想都不敢想。
让团队想象事情的流程，对我们大有好处。我的想象就是给团队里的每个人发言的机会，每个人都为最终的效果做出贡献。
我们最终产生了八个阶段的东西，接下来我就不再一一介绍了:
术语定义
想象一个小团体
我们需要明确界定想象集团的责任，这样我们才能清楚地知道谁有权决定我们计划何时停止决议，以及我们希望完成什么。
想象一下这个群体更少:
所有的目标都应该是努力的。
在这个项目的可用性、易用性、阻止能力上下功夫。
除了需求输出，假设计划是按需求为最终产品努力。
在走产品管理，少技术组，开放管理和员工合作的过程中，我们需要做设计师的代表。
有视觉想象和用户体验圈的决策方案权。制定决策计划时，带着产品，展开谈判。
努力收集相关方的反馈，确保委托符合公司的经营目标、理念和品牌要求。
想象项目
肯定有某种援助。我们正在构建现有待办事项列表中战争定义项目的下级。富有想象力的项目通常由产品路线图驱动(由产品团队努力完成)。还有一些项目是由UX改进或一些组件项目推动的。
项目是由项目组确认的任务。
一般情况下，场景项目是对要发布的功能停止用户体验的场景，场景包括GUI和CLI。想象将是对“发明”曲目特征发音的考证，未来的争议将落实。
每个项目都有少量的场景，并且可以有多个场景。
当场景停止(被其他方认可)时，该场景项目视为“已完成”。但是虚组还是需要跟进试战的发展，这样就有一些改良的物品需要打了。
中间层产品想象过程
第一阶段:定义。
确保你知道要处理的成绩，而且那个成绩已经在需求、供给、品类用户的故事里讲过了。与此同时，需要确保跨本能功能的团队即将结束这一成就。
知道提出那个成绩的客户是谁，大概是被那个成绩磨炼出来的。
让跨本能职能团队召开启动会议。
保证脚色战的责任明确。
可视化项目告一段落。
创建与项目相关的文档。(例如:项目类别文档、wiki相关页面、战争进度跟踪、集合页面、任务、待办事项)
第二阶段:讨论
我们用Dropmark记录灵感。
了解用户的成就，建立共情。只是收集了很多疑点，整理出来变成团队可以接受的常识。
与用户/客户交谈并测试测试体验分数。
与内部专家和相关人员交谈，找出对手。
看看别人是怎么处理那个成绩的，包括合作对手的类似事情。
记录你的分析结果，停止在团队内部分享。
找出是否有一些工艺限制。
第三阶段:诵经。
跨本能想象工作坊可以接受6-up法唤起很多念经。
让跨本能团队的人出去，可以拓展你的思维，打开你的大脑，给你一些你以前读过的目标。
使用草图、线框和流程图。
建构超本能机能思维风暴战争想象的研究环节。
为假想团队提供反应战输入。
检查可检测性。另一方面，我们可以通过与产品谈判来解决我们的分歧。
第四阶段:假设
我们通过视觉处理这种类型。
用最好的想法创建一个可测试的意见模型(比如这个模型)。在最后的讨论和分歧的结论之后停止细节的想法。
创建一个可验证的视点模型，如图表、流程图和交互式原型(可以使用InVision、Framer等。).
随着每一次迭代，逐渐细化和完善，以保证真实程度。
后期不要做逼真度太低的模型，不然你会发现关注点会焦虑:加工方案的业务流程是否能准确转移到按钮的颜色上。
但如果太低，得不到预期的反应，影响反应的片面性。
第五阶段:考证
相关方、用户和客户会一起去研究和处理你的计划的一些假设。获得反应后，停止治疗方案的恶化，经过无尽的循环，获得已经走到尽头的治疗方案。
可能会停止现场用户测试会话。
带客户停止间接对话。
以开源社区为例，讨论UX专家分享东西的功效。
带所有小组去确认热线案件的停止。
带内部相关人员停止审查。
第六阶段:委托。
我们为各大部门的所有项目提供了wiki页面，并在其中放置了交互式战争草图文件。
在每个开发完成之前(注意:我们一年发布三次)，将有一个发布计划阶段，概述该发布将包括的内容。那个计划将涉及整个公司的各种相关人员。
一旦我们确定了公告的范围，我们就可以开始研磨和恶化我们的想法。我们都知道在发展的过程中，可能会有变化。然而，当我们的想法“准备好”时，我们需要告诉先锋员工，我们可以开始先锋和实施。
得到一个磨人的想法。检验品牌战想象系统的要求。
确保这个模型是最新的。
确保任何过程或附加的概念性文件被修订是有用的。
更新想象用户故事和战争的Wiki页面，使用Wiki帮助创建自己的任务。
确保你在需求的时候考虑的是不同的场景，比如:故障模式，空价值模式，开源用户的不同场景。
那个项目上拿了拓荒战文档的团队停止了具体对接。
第七阶段:发展
我们之前的开发包括:React，Node，Webpack。
一旦项目进入开发阶段，开发工程师就开始实施处理方案。在这个过程中，设计师需要为开发提供持续的质量保证和指导。
协助并主动与员工合作。
快速响应阅读分数的要求，给出处理方案。
停止在过程中成功地展示事物。
在那个阶段，设计师会花你80%的时间去想象和发明下一个版本的需求。
第八阶段:评估。
只要把功能委托给用户，用户也在实际使用，我们就可以认为整个过程在那个时候就完成了。然而，虽然过程结束了，我们仍然需要不断地收集内外反应信息。
为每项相关成就列出一个成就列表(任务、缺点、计划)。
带着产品分析小组一起评估对治疗方案的影响。
通过持续的过程用户测试和讨论收集定性数据。
召开跨本能职能团队的召回会议。
乘积虚反应环
我们鼓励我们在每个阶段都实现那种想象的反应循环。该方法的想法来自Buzzfeed项目。当你制作出一些草图和边界，展示给他们，以聚集远见者、开发者和用户，收集他们的评论和反应，过滤和修正他们对Synthesize的意见(哪些是你赞同的，哪些是你采纳的)，然后再周而复始。
想象一个持续迭代的过程，所以开放的心态很重要。
项目(生命)周期
目标示例和范围决定了项目周期。一个小的项目团队可以很快完成项目，而一个跨本能功能的大项目，会需要各种相关方出席很多迭代战反应环节。
这是一个项目周期的例子，每个项目都是不同的。重点是我们如何定义每一个阶段的完成尺度，每一个阶段有没有反应回路要忘记。
一些经验分享
您的业务流程需要基于您自己的跨职能团队，尤其是您的每日或每周业务流程。
我们需要前端和后端的配合在场，这样我们才能理解什么时候这个想法才算“完成”。这样一来，我们去道的念头就在不断地变质，总会有尽头。但是，在走了前后开发和停止咨询之后，我们至少可以知道这个想法达到什么水平可以被称为“停止”，也就是说，他们可以把它作为输入来开始自己的开发。
产品处理团队会到场，这样我们就可以知道待处理结果的劣等，以及可用性测试和UX评审。产品管理团队关注整个过程的这一部分，也期望参加更多关于这些任务的会议。
把清理过的流程放到Wiki上是有必要的，但不仅仅是这样。你需要停止向相关利益方宣讲流程，接收一些特殊的客人和邮件，停止在一些不正规的地方宣讲。给新跨本能团队的成员和一些集会领袖讲课。
标签
如果你把整理和粗略记录团队事务的过程借出去，我强烈建议你开始整理和整改。你会觉得我们现在的情况挺好的，虽然大概有书面的整改程序，但是没有几个是我的样子。但是，通过对事情的整理、整顿和记录的过程，你将能够发明一些你以前注意到的成就。也许你觉得有区别，每个人知道的东西都不一样。
把所有人召集起来，仔细检查你的业务流程。每个人都可以 *** 纵饭盒停止说话，提出自己的观点。每一次迭代之后，我们都会回头看看，找出哪些是有效的，哪些是可行的。在此基础上，您正在迭代地恶化您的业务流程。
首先，我们在全公司宣传你的业务流程。不要指望别人问你:“你的业务流程怎么样？”推广你的业务流程，那是你的事。
译者:肖静，正在理论路上的高级商业分析师(BA)。我的个人名字是xiaojing-jessieyj。
本文位置:https://blog.usejournal.com/how-we-design-enterprise-software-916124FB73db
本文由@小静翻译团队，产品经理翻译，已获本网认可，禁止转载。
标题来自unsplash，基于CC0和谈。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）