我们都粗略地想象大公司的发展是什么样的，而小发展又有什么不同。 但是，如果公司规模迅速变化且员工人数在过去几年中增长了十倍，会发生什么情况？ 当一家新兴企业迅速成长，并且您需要适应旅途中的新情况时，这会如何影响一切（从流程到技术）？
ManyChat将参加我们的HolyJS会议，这正是正在发生的情况。 因此，我们要求为前端
Evgeny Kuvshinov的开发提供技术支持，特别是有关ManyChat的要求，以及总体而言，在初创公司中进行（前端）开发的感觉。
-首先，简要介绍一下您在ManyChat从事的工作以及公司本身的工作。-我只是作为前端开发人员来到公司的，六个月后，我成长为前端团队的负责人。 然后我们仍然有这样的职能团队-前，后，测试，产品。 在LeSS上重建所有流程之后，我回到了开发领域，几乎没有以前的组织任务。 我从事用户体验，我尝试涉及产品部分，部分作为产品经理成长，但同时不断编写代码。
作为一家公司，我们帮助企业使用相对较新的沟通渠道Facebook Messenger。 ManyChat是一个平台，可以快速轻松地为Messenger创建聊天机器人。 这不是关于人工智能，不是关于模仿人类交流的尝试，而是关于不需要这样做的场景。 在我们的漫游器的帮助下，您可以只做新闻通讯，还可以设置更复杂的交互式事物，例如订单，预订，会员计划。 它们还可以通过视觉和清晰的方式完成，并且可以由相当高级的企业主或没有编程技能的营销人员来完成。
通过一个特定的示例，您可以看到机器人在Messenger中的一般工作方式：及时使用HolyJS，我们制作了一个
特殊的bot 。
-当然，您经常听到“但是聊天机器人几年前失败了”的字样。 您的经验是否表明，总体而言，在特定情况下，它们是否适当？-是的 也许最重要的是，权宜之计甚至没有通过我们的案例证明，而是通过微信平台证明。 这是一个几乎在中国每个人都使用的信使，里面有很多业务，并且通过微信现在正在积极地在中国订购比萨饼或出租车等事情。 这表明人与企业沟通的某些交互场景确实能很好地工作，对双方都很方便。
几年前曾大肆宣传的用法-就像您可以与机器人聊天一样，他将提供飞往飞机的最佳版本-确实，效果不是很好。
我们正在与微信紧密合作，但在其他市场也正在实施：首先是在美国，尽管在全球也是如此。 我们有来自欧洲的大量客户，在中国附近的国家，也有许多人现在使用Facebook Messenger。
-谈到增长问题：公司成立了多久了，从那一刻到现在我们成长了多少？-公司于2015年出现。 它始于其联合创始人Mikael Jan需要在Telegram上发布新闻通讯（当时那里还没有任何频道）。 他意识到这很复杂，并且一个特殊的工具将很有用。 结果，Michael和Anton Gorin首先创建了一个用于在Telegram中创建机器人的平台。 平台开始足够快地增长，他们冲击了硅谷的启动加速器。
当他们在加速器中时，Facebook打开了Messenger的API。 那是他们决定做出重大突破的时刻，即专门为Facebook Messenger开发新产品。 Messenger的每月受众为14亿，在Facebook上，许多公司都以官方页面的形式进行代表。 对于这些页面，您可以创建机器人。
最初只有三名员工：Michael，Anton和另一位开发人员，他们制作了前端的第一个版本。 同年秋天，获得了第一笔投资，很明显，您可以开始扩展团队。 然后，我和其他三名开发人员来到了公司，所以在2016年底，我们中有七个。 而现在，两年后，已经有五十多个人，并且还在继续增长。
如果您查看平台本身的数量，那么我们已经有超过40万个已连接的机器人。 而且我们在财务指标方面发展良好：目前，我们已经是一家盈利公司，同时我们继续寻找投资以更加积极地发展。 明年，我们计划至少将人数增加一倍。
-初创公司是一个实验性很强的领域，其中很多工作都是通过反复试验来完成的（就像提到的枢轴一样，当我们从一个概念开始，然后在旅途中进行更改）。 这如何影响发展？ 这是否意味着您始终需要为以下情况做好准备：“您实施的功能将被丢弃”？-确实，您可以做一些事情，但是最终用户不会需求它，它的采用率很低。 否则她可能根本就不投入生产，因为我们自己看着发生的事情会明白我们不喜欢它。
为了尽量减少这种情况的发生，我们考虑的第一件事（甚至不是在开发过程中，而是在功能产品开发的开始阶段）就是动机。 我们为什么要这样做，对谁来说，它将对现有用户产生多大的影响？我们自己喜欢多少（我们会为我们的产品中出现这样的事情而感到高兴和自豪）。 确定动机之后，也许可以通过在我们的用户社区中进行调查或对我们的用户进行其他一些采访，我们开始发展。 接下来，我们准备进行冲刺的功能，此过程称为PBR（产品待办事项列表细化）：首先进入待办事项列表，然后在等级中升至最高，在某个时候，已经被很好地描述了，可能会落入冲刺状态。
直接在sprint中，我们要做的第一件事是，如果不了解外观，我们将制作一些模型和原型。 但是，无论听起来多么奇怪，有时开发过程中就已经完成了。 因为有时仅通过制作某种布局和绘制插图，很难理解用户对界面的感觉。
通常，在前端，我们制作的原型或交互式功能在原则上已经可以使用，您可以单击并感觉到它们。 然后，在与设计师的紧密合作下，我们将这些原型带到了将投入生产的选项中。 但是，尽管如此，当在此处创建这些原型时，制作，外观和理解自己“不，它不会停止，很不方便”的情况并不少见。 我们尝试使用自己的产品，制造机器人，以便甚至在用户发现可能出现问题的地方之前。 好吧，总的来说，我们专注于用户体验，我们正在尝试构建最易于使用的平台。
-随着公司的快速发展，您可能会遇到这样一个事实，当迁移到数十个人时，对几个人有用的流程就会停止工作。 从组织的角度来看，您的发展有何变化？-很难。 在今年年初，我们遇到了一个相当困难的情况，当我们几个月来做了几项功能时，他们一直能够“完成一点并将其投入生产”，但是这种“一点点”并没有出现。
当我们刚开始的时候，我们有七个。 我们有一个混乱局面，有冲刺，一切都建成，并且进展顺利。 当我们成长为20-30个人时，就像许多公司一样，我们出现了职能团队：后端，前端。 具有自己的流程，内部的sprint和自己的任务队列。 而且，我们没有执行被专门称为“某某特性”的任务，该特性将为某某某用户带来某某利益。 每个团队的任务是本着“前端：重新安排这样一个界面，因此添加一些按钮”的精神来进行的。
这很糟糕，原因有很多。 首先，当我们有多个不同的队列和同一业务任务的各个部分时，它们具有不同的优先级，几乎就无法理解何时该任务将完全准备就绪。 对于特定的开发人员来说，了解他在做什么变得更加困难。 因为他为自己做了一些描述，以及用户如何为结果感到高兴，所以他不知道，因为他甚至可能在很多方面都不知道为什么所有这些都是必要的。
在某个时候，我们意识到下一步是不可能的。 是的，您可以进行一些调整，进行迭代，继续进行冲刺和日常站立训练（由于整个团队都参加了他们，因此开始花费了半个小时以上的时间，但没有提供任何帮助）。 但是这些是不能解决主要问题的装饰性措施。
那时，公司中的一个人告诉我们，有一种叫做LeSS或大规模Scrum的东西：针对已经庞大且成长中的团队的Scrum。 在会议室里坐了几个晚上，讨论了所有正在发生的事情之后，首席执行官兼首席技术官（Mika和Anton）做出了一个非常艰难的商业决策：我们将整个开发过程（我们如何设计功能，实现和推广）扔进垃圾桶。 我们将完成现在正在进行的sprint，然后我们将重新构建所有内容。
这个决定很困难，并且意识到我们正在这样做，我们思考了很长时间：“该死，这行不行？” 但是我们决定尝试所有相同的方法，转向有关LeSS的书和经过认证的培训师。 他们以一种新的方式开始，组成了跨职能的团队-最初有三个人。 我们根据LeSS规则启动了每周一次的短距离冲刺（在这些冲刺上应该举行几组会议的规则）。 我不会告诉您所有详细信息，但是对于似乎挂在我们身上的八个任务的第一个每周冲刺，我们无法连续几个月推出，如果不是全部，那么我们就会正式投产。 而且我们只是不明白发生了什么。 怎么会这样 为什么我们以前不能这样做？ 为什么会发生呢？ 这非常酷，我们开始着手进行新任务，并更快地在跨职能团队中解决它们。
当然，也有一些困难和误解。 但是总的来说，对于大多数团队来说，新兴的流程很受欢迎，因为我们功能的上市时间已大大减少，因此您可以非常快地完成所有工作，并投入生产。 除此之外，我们尝试传达用户的反馈，以便开发人员可以看到有多少人喜欢他们的工作。
另一个有趣的问题是，在切换到LeSS之后我们如何推出前端。 我们意识到，现在我们已经分为多个独立的跨职能团队，并且第一次（至少在前端社区开始工作之前），我们的沟通将减少很多。 然后，我们学会了在需要时随时“按一下手指”即可部署前端...在新的Sprint开始之前，我们召开了一次会议，我们说我们拥有主分支，并且可以随时部署它。 。 在此之前，我曾想过，我们绝对应该构建一个集成UI测试系统，该系统可以检查每个程序集，应该有很大的覆盖率，并且只有当它是“绿色”时我们才能滚动。 但这是一个空想，因为该产品发展非常迅速，在这种情况下，无论您多么努力，仍然无法保持很大的覆盖率。 结果，在与所有开发人员达成一致并赋予他们责任后，我们设法确保现在我们主分支中的代码确实能够正常工作，并且我们始终可以从那里开始并推出所需的任何程序集。
-哇，谢谢你的详细回答。 我想假设，除了所描述的过渡之外，还将发生从“完全堆叠”到狭义的专业化的过渡：当项目中只有很少的人做所有事情时，willy-nilly必须做各种各样的事情，而当五十多个人时，每个人都有一个清晰的圈子任务。 是这样吗-很少时，我们确实必须解决不同领域的许多问题。 例如，一段时间以来，我从事系统管理并建立了CI系统。 而现在，随着向LeSS的过渡，这要少得多。
但这并不意味着现在每个人都只能担任狭窄的角色。 当您进入公司时，您将拥有主要能力（至少是后端，至少是一名设计师），没有人会阻止您将这一特定垂直领域注入太空，但是与此同时，LeSS提供了一个机会（只是一个机会）朝着相关方向发展。
我们分为小型标准Scrum团队，其中有六个（正负三个）人聚集在一起，坐在相邻的桌子旁。 这意味着前端始终可以与后端和设计人员通信。 除了以这种方式建立了很酷的交流之外，您还可以向这些人学习。 并且，例如，如果参与此冲刺的前线人员希望承担一些小型后端任务并扩大该领域，我们欢迎您。 因为您从不同领域获得的知识越多，您就越会专注于整个产品，从而可以更好地解决问题。 当您开始理解设计师为什么要这样做，为什么产品专家会这样做时，有时您可以自己构建一个界面，然后简单地向他们展示，他们说“是的，很酷”。 因此，您可以更快地完成工作。
-创业处于进步的最前沿。 这是否意味着在选择技术时，您可以轻松地将全新的东西投入生产？ 并且是否有任何预防措施，以免导致对可能危害公司的“闪亮新事物”的追求？-简短的答案是，是的，超新星，酷而有趣是可能的，我们以各种方式欢迎您。 但是，当然，对于引入新技术有一定的标准。
如果您发现自己感兴趣的任何技术，则需要将其带入社区。 尽管我们的公司不再拥有前端团队，但这里有一个前端社区，我们会定期收集和讨论此类问题。 在这里，您可以告诉每个人为什么很棒，以及为什么将来更容易使用它。 一些公司可能有某种特定的选择系统，需要比较的复杂表格。 我们没有那样的东西，所有决定都是在一些非常主观的感觉上做出的，但是与此同时，真正好的和有趣的技术已经足够快地出现了。
有时有些事情尚未发布。 我们开始使用该库在React上创建面板，那时它还很原始，据我所记得，甚至还捐赠了一点。 我们开始使用带有某种Beta的Babel 7，因为它使我们能够比上一个版本更快地构建项目。
而且，也许没有团队成员抱怨他想要一些新奇的东西，但是他们对他说：“不，我们有这样的政策，我们不会这样做。” 虽然我不记得会引起这种问题的单个问题，但欢迎使用有趣的新技术。 这对我来说很奇怪，因为根据我以前的经验，我在此级别上做出了许多错误的决定。 但是在ManyChat中，也许只是在社区的帮助下，也许出于某些其他原因，我们在选择某些内容时没有这些文件，然后我们不得不将一半的代码库重写为另一种技术，因为这个还没有进入。
-有关“进步的秘诀”的更多信息：我想假设一家创业公司可以让您平静地呼吸“您不必处理旧代码”。 是这样吗-好吧，每个人都以自己的方式理解“传统”一词。 例如，如果我们用它来指代一个三年以上的代码，那么在三年以下的公司中，当然不是。 但是您可以加强这个概念，那么我们将拥有一定比例的遗留代码。 从它的写作不是三年前，而是几个月前开始的，但是那时我们不知道如何正确地做某事，但是现在我们已经知道，我们可以做一百行而不是一千行，他们会做同样更加可靠。 当然，这样的代码是不可避免的。 但是，我们没有什么需要寻找某种“大胡子的开发人员”的，因为只有他们知道这种编程语言，我们才能拒绝它。
-创业开发对“自行车建设”有多大贡献？ 大型公司在做内部的一切工作时，您不是做到了吗？ 还是新兴企业就是每个人都做自己的事的地方？-对我们来说，商业价值至上。 我们已经可以盈利，但是如果我们放慢脚步并开始输给某人，那将是非常痛苦的。 因此，如果第三方开发符合业务需求，解决了业务问题并且没有大问题，那么我们可以放心地使用它。 - - , , . — - .
— , ? , - «»?— , — . , , , , - , - . : , .
. ManyChat React, Baobab. , React . view React, store Baobab. , , .
2017 . React, Redux middleware – Thunk Fetch API. , . , , , , .
— , , , . -, «» ?— c , Flow, — Flow Builder. , :
, , 2D-. Flow Builder PixiJS — WebGL/Canvas.
. , . PixiJS requestAnimationFrame . , , , , . ( 12- MacBook, , ). , , , .
, , -, - , - , , , . 2D-.
— «»? , , ?— , , , , , … , HTML, Canvas WebGL , . Pixi, .
: , Canvas, - WebGL. Pixi , , . , - . , issue,
GitHub , , , .
, , , Canvas , HTML CSS. , Flexbox layout', . . Canvas, : Canvas, textarea, CSS scale , : Canvas - , HTML.
, . , Pixi - , , Flow Chart . - - , : , . , , , , . .
— . , , , . - , - ?— , , . , - , . , - , .
: - -, - - , , , . , , . , , - -. , , , , . -, , , , .
