朋友们，节日快乐！ 为迎接新工作年的开始，我们正在完成FrontTalks 2018大会的一系列材料，这是
Polychops开发人员Andrei Salomatin
filipovskii_off的演讲。 Andrei提供了一种平衡的原型制作方法：从执行命令的工匠转变为研究人员-学习如何在不确定的情况下工作，甚至在没有明确计划的情况下也能保持理性。
当选项A或选项B获胜时，定量反馈就是AV测试，二进制结果，这就是定量循环所能提供的全部。 好像我们在一个黑暗的房间里，什么都看不见，但是我们有一个激光指示器。 我们会不时在角落上照亮它，突出显示一些点并了解其中的内容。
我们想要什么呢？ 一个将描述这个暗室的用户，比我们自己了解的多。
大家好！ 我想谈一谈原型制作：为什么要制作原型，我们从中得到什么以及如何使用示例来制作原型。
我将从一个小故事开始。 2012年，我加入了这家创业公司，这是一只奇妙的鹿。 我们有一个类似广告平台的东西，我是Java开发人员来的。 显然，大量的流量，有趣的任务，团队简直是疯了-一切都很棒。 我们已经工作了大约八个月，用键盘操作，我们做了非常酷的功能，我们很快就把所有东西都转了过来。 但是到了2013年，这只鹿的蹄高了。
发生什么事了 我考虑了很长时间，然后去了不同公司的前端和后端开发人员工作，然后我是团队负责人，然后是产品经理。 他在大型企业的初创公司和外包公司中工作。 主要针对初创企业。
我也做了一些这样的项目。 我很幸运能够从事MoscowJS，Frontend Union Conf和RadioJS的工作。 也许我们在某处与您交叉。 现在，我正在执行Code Podcast（英语播客，有关编程中的常见概念的播客）和Polychops（针对音乐家的项目），该项目在浏览器中工作，可帮助您练习乐器，获取更多时间和练习。
HeyMoose怎么了？ 该公司有非常聪明的人，他们现在在Microsoft担任高级开发人员，或者已经成为STO。 我们做了我们最擅长的事情：我们快速而有趣地解决了复杂的技术问题。 但是出了点问题。
许多公司，尤其是初创公司出了问题。 创业公司之所以枯竭，主要有两个原因：要么他们不了解产品，要么错过了产品，要么钱用光了。 很多时候，他们用光了钱，因为他们正在寻找产品并且找不到足够长的时间。
但是，为什么外包公司的定制开发没有关闭？ 还是为什么大型企业不关门？ 他们似乎慢一些。 通常，团队的积极性至少要低一些。 有什么区别？ 工作机制是相同的：在定制开发中，我们编写TK或向客户询问TK，他们为我们绘画，提供给我们，我们制作模型，代码，然后我们编写-相同的过程。 在初创公司中，在大公司中可能会有边缘实践。 都一样 那么为什么初创公司会枯竭呢？
首先让我们想象一个假设的情况：一个产品经理来找我们，问我们是否可以添加一个可以在浏览器中工作的节拍器，以周期性的间隔和同步的可视化效果发出声音，从而使不同的灯光与节拍器一对一地闪烁。 这样一来，无论计算机，其他进程等发生什么情况，这一切都是准确的。
谁能百分百确定我们可以使用浏览器和浏览器API来做到这一点？ 没有一个人。 谁有80％的把握我们可能做到这一点？ 3-4手。 谁能确定50到50？ 多数。 谁能确定我们根本无法做到这一点？ 老实说
下面的例子。 假设我们正在一家移动银行的另一家公司工作。 我们对产品有更多的考虑，并认为有必要增加使用我们的移动银行的用户数量。 我们提出了一个功能：现在，用户可以在社交网络上共享购买或补充帐户。 钱来了，他就像在Facebook上一样-看，钱来了。 您认为这将有助于吸引更多用户吗？ 谁对此有100％的把握？ 没有一个。 谁能百分百确定这不会以任何方式帮助我们？ 两三手。 其余的介于两者之间。
还有最后一个例子。 我们提供云服务，开放我们的公司。 云服务将从中小型企业的前端和后端的项目中收集日志，进行汇总，机器学习，人工智能等等。 我们将出售它。 谁能确定这是100％成功还是100％损失？ 几个人。
所有这三个问题只有一个正确答案：“可能”。 我们对某些问题的答案有50-80％的把握。 在很大程度上取决于上下文和实现。 带有可视化功能的节拍器-我已经完成了工作，但您无法使其在所有情况下都能正常工作：例如，使用蓝牙耳机。 但这可以针对两个或三个广义情况进行。 以我的理解，这“可能”是有原因的-新兴企业之所以关门，是因为HeyMoose为此而生。 也许我们会做点好事，或者我们只是在浪费时间。 而且我们无法理解我们对自己所做的事情有多自信。
有点理论。 定制开发和启动之间有什么区别？ 区别在于上下文。 在这种不确定性的背景下，我们有成功的可能性和失败的可能性。 好像我们在地面上跑步和在没有重力的太空中跑步时尝试使用相同的方法和实践一样。 似乎我们正在运行，但是什么也没发生。 我们做错了什么？
这种不确定性来自三个主要方面。 它来自市场-因为我们不清楚不清楚其他哪些公司参与了日志聚合。 也许这个市场已经被某人占领了？ 市场上的什么人口统计学价格是多少？ 不确定性可能来自产品。 我们不知道客户遇到什么问题以及如何解决。 这是来自移动银行的示例。 我们似乎有一个了解，但是我们不确定用户是否有此问题以及如何解决。
并且存在实施问题。 节拍器的一个例子。 我们不知道100％在理论上是否可行。
或另一个例子。 如果我们发明治疗癌症的药物，而这仅仅是一种被接受且健康的药物，那么我们的市场或产品就不会有问题。 但是，如何实施这种药有很多不确定性。 我们处在战争的迷雾中，但同时我们的行为似乎也就不存在，因为我们拥有与定制开发相同的原理。 我们只是将它们移入不确定性环境。
我们假装这种雾不存在，没有不确定性。 我们正在努力预测未来。 当我开始担任产品经理时，在开发过程之后，我对产品经理应该产生多少细分感到震惊。 当您向董事或其他人汇报时，您必须看起来很有信心，必须说我们会做到这一点，或者在9月之前抢占市场，一切都会受到伤害。 所有这些-做得好，我认为一切都通过了。 尽管实际上我知道这一切都不存在，但我只是在猜测，并试图对此充满信心。 我们没有一种不确定性和可能性的工作文化。 另外，为了看起来像专家，我们需要不断争取声誉，自信，谈论我们应该做的事情，而不是我们需要检查的内容或不确定的内容。
我们，特别是开发人员，仍然倾向于思考我们所知道，理解和可以控制的内容。 作为开发人员，我们真的很喜欢规划体系结构，思考未来，不要重复自己，进行模式编程等等。
设计师也为此受苦。 他们喜欢思考未来，做出完美的布局等。我们是专家，尽管实际上我们可能需要成为其他人。
我们如何处理不确定性？ 我们有哪些斗争方法？ 第一种方法最重要-将所有卡片放在桌子上，承认我们不确定任何问题。 我们可能有50％的把握，但是要检验假设，我们需要两天时间。 那我们为什么不去检验假设呢？ 我们可能会90％地确定该产品会起飞，但是我们需要八个月的时间来实施该产品并检验假设。 我们会去检查吗？ 或者，也许我们会考虑如何将不确定性降低到90％或100％？
这是第一种方式。 有必要为这种不确定性挂上徽章，以说明不确定性的大小，解决该问题需要进行多少工作等。
人类过去500年来一直在努力的第二种方法是科学方法。 它不是完美的，它有自己的错误，但这是我们目前拥有的最佳机制。 科学方法说：要解决不确定性，我们首先要猜测，然后根据我们的结论得出一个假设，然后考虑一个可以确认或反驳该假设的实验，然后进行实验，查看数字并了解我们的假设是否正确。
在开发中，尤其是在前端，我们有独特的机会以很高的速度运行这些实验。 这种方法称为原型制作。 原型是处理不确定性的一种方法。 这不是产品发明，不是创造用户将使用的理想产品。 这是一个了解我们周围世界的机会。 我们通过创造幻想来学习这一点。 原型是一种幻想，而不是产品。 好像我们是在剧院舞台或电影拍摄舞台上搭建风景一样。 这只是一种幻想。 目的是减少不确定性。
原型在两种情况下起作用：在实现的上下文中，当我们从API的角度理论上不了解时，是否可行;在产品的上下文中，当我们不知道用户遇到什么问题以及如何解决它时。 原型在市场研究中并没有真正起作用-为此存在Excel。
关键是，当我们开发原型时，我们需要放弃专家的思维方式。 我们需要忘记这些编程模式，我们需要忘记如何制作理想的产品-因为我们没有。 我们正在努力促进研究，我们正在成为科学家。
因此，我们无需思考架构，而是需要找到一种快速迭代的方法。 您无需思考和思考未来，而需要考虑如何在短时间内实现。
不用考虑您的声誉，而是如果我说我确定还是不确定，将会发生什么……相反，我需要放弃自己的声誉并成为新来者。 邓斯 我们该怎么做？ 我们可以应用哪些特定的条件来成为新手？
第一个也是最重要的一点是反馈。 甚至在计划原型，绘制布局或其他内容之前，我们都在考虑向谁展示这些模型或原型，如何测试产品以及我们将从该实验中得到什么。 此反馈回路越短，对我们越好。
个人生活的一个例子。 Productive Mobile是我最近在一家公司工作的一家初创公司，他们提供了一个平台，该平台使您可以通过拖放方式从网站制作移动应用程序。 我们之所以将其出售给大型公司，是因为它们拥有SharePoint或SAP之类的产品，这些产品无法在手机上使用，只有捏缩放功能。 我们为他们提供了一个选择：例如，您可以在一周内基于真实站点制作移动应用程序。 问题在于我们拥有非常强大的开发团队和很长的销售周期。 当您出售戴姆勒或宝马大小的公司的产品时，销售周期至少为8个月。 在此期间，一群有才华的开发人员可以提交大量文件。
我们做了什么，对我们有什么帮助？ 我们在公司内部创建了使用该产品的微型用户团队。 而且，我们开始制作和发布的功能数量有所减少。 但是同时，功能的质量提高了n倍。 当我们遇到用户并说我们拥有这样一个平台时，让我们尝试一下，由于某种原因，当我们这样时，紧急情况就停止了：我们没有考虑它，这是新事物。 我们开始制作实际上可以带来结果的功能。 这是由于我们简单地减少了反馈回路。
节拍器的一个例子是我现在正在研究的Polychops项目。 首先，我们在短时间内创建了一个视频，并将其发布到Internet上的某个位置。 在其中，我们询问您如何看待这个概念，您对此有何看法。 根据评论，我们不仅赞赏这是多么有趣。 我们仍然有可以与之交谈的线索，可以邀请谁来电话，面试，尝试原型等等。
我们试图尽早获得反馈。 不仅是任何反馈，而且是定性的，而不是定量的。
有什么区别？ 当选项A或选项B获胜时，定量反馈就是AV测试，二进制结果，这就是定量循环所能提供的全部。 好像我们在一个黑暗的房间里，什么都看不见，但是我们有一个激光指示器。 我们会不时地在角落上发光，突出显示一些要点，并了解其中的含义。
我们想要什么呢？ 一个将描述这个暗室的用户，比我们自己更了解它。 我们需要高质量的采访，电话或其他方式，以扩展形式从用户那里接收信息。
Booking.com是一家非常依赖定量反馈的公司。 我认为，他们的网站上有一些工作要做。
我正在研究的项目的原型之一是一种功能，人们可以使用该功能记录自己，并同时复制自己在节拍器下的演奏方式（好还是坏）。 我们发明此功能是因为我们要求测试原型的人提供质量反馈。 其中一个人写道，一切都很棒，我喜欢节拍器的一部分，但是将节拍器作为音频轨道导出这首歌很酷。 我们就是这样-这是不合逻辑的，为什么？ 他说：“我将其插入程序中以进行音乐处理，然后写下来，然后就可以知道是否有节奏。” 我们就是这样-很棒。
但是，我们决定不只是导出，而是检验假设。 我们与人们交谈，询问他们在玩节拍器时是否完全听自己的话。 许多人说是的，我们经常有一个程序-节拍器，另一个程序-录音机在电话上或其他地方，我们只是在录音并听自己说话。 我们就是这样-我们是程序员，我们可以将其结合在一个应用程序中。 结果，我们获得了此功能。 如果我们刚刚进行过AV测试，我们将永远不会猜到它。
原型最重要的部分是接口。 在全球范围内。 如果我们通过某种API提供某种服务，那么我们的接口就是一个API，那么用户将与之交互。 如果我们正在制作节拍器，那么我们的界面就是视觉部分和声音。 如果我们只是在开发移动应用程序，那么我们的界面就是可视界面。 在原型中，接口是唯一重要的部分。 我们可以伪造的所有其他东西，用毛绒代替。
生产力移动公司的另一个例子。 在某个时候，我们决定在此移动应用程序的拖放编辑器中重写内部API。 API使JS可以恢复您的移动应用程序的某些复杂部分。 作为产品经理，我可以编写规范并将其提供给开发人员。 我相信最多可以在一个月内完成所有工作，并进行测试和完善。 但是我们决定尝试另一条路。 我们只是在纸上记录了我们脑海中存在的API，并将此文件提供给了创建移动应用程序的人。 他们问：如果您有这样的API，理论上您将如何构建应用程序？
他们拿了另一张纸，检查了所有内容。 没有执行。 该API在此阶段不起作用。 因此，在了解API的形式之前，我们进行了5-10次迭代。 我们节省了大量的实施时间。 在理解了表格之后，我们记录了规范并加以实施。 一切都变得美好。
节拍器的另一个例子。 Polychops的第一个想法是使用节奏的节拍器。 我们在Flash上写了大约20分钟的时间制作了第一个原型。 这就是他的样子。 甚至有声音。 我们刚刚去看了，并向其他音乐家展示了，问-您到底如何喜欢它？ 这是唯一重要的事情。
然后，我们在浏览器中制作了一个真正的节拍器，它可以正常工作，动画，等等等等，一切都很好。
但是花了大约一个半月的时间，而之前的原型花了20分钟。
专注于界面。
为了节省时间，请使用设计系统。 Polychops的一个简单示例。
左侧是初始原型，我们只需要所有按钮，就可以自己考虑所有交互。 一段时间后，我们决定需要菜单，导航，下拉菜单等。 我们可以坐下来，与设计师一起思考每个下拉菜单，每个按钮，但这是大量的时间，原则上我们不需要花费时间。 因此，我们采用了完成的设计系统，采用了材料设计，将所有内容完美地记录在案。 搞砸了，一切都很好。
偷 不要从竞争对手那里偷东西。 从竞争对手那里窃取毫无意义。 如果某些内容适用于竞争对手，则无需检查，只需复制即可。 从与您的产品平行的产品中窃取，这些产品不完全是您的产品，而是类似的东西。
Polychops的另一个示例。 录音界面实际上是从现有的声音程序（例如Logic）中舔来的。 自然地，我们大大简化了它，但是人们已经了解如何使用逻辑，这意味着他们可以了解如何使用Polychops。
. , . .
: , . , , .
, , . , , . , , , , , . .
— . , , . , .
, , — . . , React . React, React. , , , Redux Apollo, . . .
— . , , — . , - , . , , , , , . -, . . -, , — , . , , , , , .
, , . . , . — , , .
, . , . . , . . . — , . , .
? « ?» — , . ?
. , . . 10% , , 10%, , — .
. , 90% , . , , 10%. — , . .
, . Productive Mobile , . , , - , .
. React, — React Native. , , — React, React Native. - : «, React Native, , ». .
? . , , 10 React Native , React Native-. , - , , . , , , «write once — use anywhere». Android iOS . . , , , . — , - , - . — .
, , … ?
Polychops - , . , , , , , . - , , . . .
希望您自己尝试。您可能没有在初创公司工作，但是您的公司的项目存在不确定性。对我而言，重要的是要考虑这一点，与您的团队，与您的经理进行讨论，考虑如何在不确定的情况下工作，如何构建流程，以便改善决策流程，从而避免浪费时间在不必要的事情上。如果您成功了并且做出了出色的产品，那么我希望在某个时候我会成为您非常满意的用户之一。谢谢啦