Проекты 1С по Scrum глазами Scrum-мастера

Меня зовут Олег Миньков. Я работаю Scrum-мастером в компании-интеграторе Первый БИТ в проектном подразделении БИТ:ERP, которое специализируется на средних и крупных проектах ERP.

В 1С я уже 15 лет, работал программистом, внедренцем, руководителем проектов разной величины, возглавлял большое производственное подразделение, где набирался управленческого опыта.

Поворотной точкой в моей карьере стало знакомство с наставником Романом, который познакомил меня с кругом людей, задач и проектов, где использовались такие понятия как гипотезы, MVP и спринты. Там я увидел, что даже большие и сложные проекты можно запускать быстро, сразу получать обратную связь, доставлять много ценности клиенту.

Но на наших проектах мы в то время месяцами, а то и годами могли жить с клиентом в мире иллюзий: тщательно эти иллюзии документировать, потом тщательно их разрабатывать, и в момент запуска столкнуться с жестокой реальностью, что половина из этих фич не нужны, а еще часть – нужно переделывать. Это приводит к разочарованию с обеих сторон. А я не люблю разочаровываться сам и не люблю разочаровывать своих клиентов.

Поэтому я поставил перед собой вопрос: «Можно ли эти гибкие технологии, которые я увидел, адаптировать под проекты 1С?»

Тогда я присоединился к команде БИТ:ERP, которая уже несколько лет до этого адаптировала Scrum на проектах, и стал первым Scrum-мастером в мире 1С. Я – точно первый, я проверял.

Мы вместе с офисом БИТ:ERP собрали ряд инструментов и практик, которые в итоге позволили нам выполнить один, как я считаю, образцовый проект. О нем я в конце расскажу подробнее.

Моя цель сегодня – поделиться этими инструментами и управленческими решениями с командами, которые собираются у себя внедрять Scrum или, может быть, уже внедряют. Чтобы они наш путь прошли быстрее.

Все инструменты, о которых я расскажу, на мой взгляд, в равной степени подходят и командам инсорс, и командам аутсорс. Я, как Scrum-мастер, разделил эти инструменты на три уровня взаимодействия:

• с бизнесом;

• с владельцами продуктов;

• с командой разработки.

Инструменты Scrum для взаимодействия с бизнесом

Это – слайд для менеджмента. Что нужно сделать на уровне организации, чтобы Scrum у вас имел шансы «взлететь»:

1. Если у вас есть привычка жестко вмешиваться в работу команд в режиме чайка-менеджмента, вам нужно поработать над собой и перестать это делать. Потому что это разрушает безопасную доверительную среду, которая должна существовать в командах по канонам Agile.

2. Нужно превозмочь себя и перестать натягивать сову на глобус, т.е. перестать задействовать разработчиков сразу в двух, трех и более проектах. Это не взлетит. Нужно локализовать команду под один проект.

3. Если вы считаете, что работать спринтами – это уже Scrum, на самом деле это не так. Чтобы был Scrum или хотя бы что-то похожее на него, нужно регулярно запускать какую-то функциональность в продакшене. Не каждый спринт, но регулярно. Для этого у офиса БИТ:ERP есть свое ноу-хау, своя разработанная технология – запуск ERP поблочно. Я об этом рассказывать не буду, это не тема доклада. Но вам тоже предстоит найти или воспользоваться какой-то уже готовой технологией, чтобы запускаться в продакшене регулярно. И договориться со своим заказчиком об использовании такой технологии.

4. И чисто инструментально: начните вести свои проекты в каком-то task manager. Я рекомендую Jira, потому что там есть много пошаговых туториалов на русском языке, с которыми вы легко сможете начать это делать.

Инструменты Scrum для взаимодействия с владельцем продукта

Владелец продукта – это человек, который управляет содержанием продукта или проекта. Он формулирует задачи, приоритизирует их в бэклоге, чтобы давать заказчику здесь и сейчас максимальную ценность. И в конечном итоге он отвечает перед заказчиком за результат.

Если говорить про проекты ERP, владелец продукта также отвечает за то, чтобы в базу ERP максимально быстро пересели пользователи, и она уже начала реально жить.

У нас владельцами продуктов стали бывшие руководители проектов. И я думаю, что это классический сценарий, по которому пойдут другие команды.

• Плюсы в том, что зачастую это специалисты с большой экспертизой, большим опытом и большим количеством проектов. И это – серьезная основа для перехода в новую роль.

• Минус один, но очень большой – они привыкли руководить командами в режиме микроменеджмента, а это противоречит основам Scrum.

Расскажу, как это проявлялось на практике. Когда я присоединился к команде, она находилась в середине большого проекта по внедрению ERP. Владелец продукта первое время позволял себе всяческие эксперименты – пытался дистанцироваться от команды, чтобы дать ей определенную автономность. Но как только ситуация начала выходить из-под контроля и заказчик стал поддавливать по срокам, владелец продукта вернулся к привычным методам управления – начал раздавать задачи команде и контролировать их выполнение.

Эта попытка совместить две роли – микроменеджер и владелец продукта – привела к тому, что ему приходилось работать по 12-16 часов в день, чтобы успевать и там и там. Естественно, это сказывалось на его здоровье и не только. Важно то, что это сказывалось на его команде – она была несамостоятельная, ждала, когда ей дадут задачи, не брала на себя ответственность за выполнение целей.

И задача Scrum-мастера – в этот период укрепить команду, взять ее под свое крыло, чтобы владелец продукта мог больше концентрироваться на заказчике, на продукте, осваивать новые для себя инструменты.

Расскажу об инструментах.

Когда я посмотрел на бэклог задач в Jira у разных проектных команд, я увидел одну и ту же тенденцию – огромное количество технических задач типа «создать какой-нибудь регистр», «написать обмен», «добавить реквизит». На мой вопрос «зачем?», часто ответ был какой-то невразумительный или его вообще не было. Тогда мы договорились, что будем описывать функциональность в виде так называемых пользовательских историй. Такие задачи – одна из ключевых зон ответственности владельца продукта.

Мы договорились о том, что весь бэклог будет состоять либо из пользовательских историй, либо из задач, которые с этими историями связаны. Так мы прямо или косвенно всегда сможем понять, какую ценность несем заказчику выполнением этой задачи, потому что ценность зашита в саму структуру пользовательской истории.

На слайде приведены расширенный (основной) и сокращенный вид пользовательской истории.

Пример задачи, сформулированной в виде пользовательской истории: «Назначить ответственного за согласование нового пришедшего документа по ЭДО, чтобы быстро пройти процедуру согласования».

Когда мы начали формулировать пользовательские запросы в таком виде, мы получили два неочевидных до этого результата:

• Первый результат – даже опытные консультанты, опытные руководители проектов с трудом формулировали, какую выгоду несет бизнесу эта задача. У них началось переключение мышления на ценностно-ориентированное.

• Второй результат – куча задач, которые поначалу казалось, что выполнять просто необходимо, через такую проверку на ценность не прошли. Оказалось, что их делать совершенно не нужно – это стало очевидно и команде, и заказчику.

Поначалу для целостного описания бизнес-процессов команды использовали схемы в разных нотациях.

Но когда мы начали формулировать пользовательские истории, оказалось, что эти два инструмента не уживаются и нужно искать какой-то другой, чтобы, как из мозаики, из этих пользовательских историй складывать процесс.

Мы воспользовались известным инструментом – карта пользовательских историй (user story map).

На слайде приведен пример реальной карты пользовательских историй с одного из наших проектов. Он выполнен в приложении FeatureMap. У нас оно прижилось, но у него есть ограничения на бесплатное использование. Есть еще Jira с определенными расширениями, которые тоже позволяют такие карты пользовательских историй составлять.

Порядок составления пользовательских историй и карт пользовательских историй мы изучали по книге Джеффа Паттона User Story Mapping. Рекомендую ее вам. Хотя по этой теме есть, конечно, много другой полезной литературы.

Резюмирую, куда развиваться новоиспеченным владельцам продуктов.

• Владельцу продукта нужно сознательно делать над собой усилие, чтобы не сваливаться в микроменеджмент и в управление командой. Задачу укрепления самостоятельности команды должен взять на себя Scrum-мастер.

• Основной фокус внимания владельцу продукта нужно направить на изучение продукта, на формулировку пользовательских историй и создание карт пользовательских историй.

• И в конечном счете сфокусироваться на наполнении бэклога продукта и его приоритизации, тщательно готовиться к планированию спринтов.

Инструменты Scrum для взаимодействия с командой разработки

Когда мы говорим про команду разработки, обратите внимание на пять ценностей Scrum. Классная команда разработки:

• Commitment – достигает цели спринта;

• Courage – развивается и совершенствует свои процессы;

• Focus – сосредоточена на том, чтобы приносить заказчику максимально много ценности;

• Openness – открыта для обмена информацией и делает результат работы прозрачным для клиента;

• Respect – уважает коллег и заказчика.

Но это в теории. А что на практике?

Commitment (обязательство, вовлеченность). Поначалу во всех командах и проектах, с которыми я работал, мы тотально не выполняли цели спринта. Мы на этом особо и не фокусировались: цели либо вообще не ставились, либо ставились как-то размыто, либо ставились недостижимо.

Для меня поворотной точкой стала фраза, которую я услышал от Agile-коуча Ильи Павличенко: «Scrum начинается с выполнения целей спринта». Это правило я взял себе за постулат.

• Я пошел к владельцу продукта и предложил вместе учиться формулировать понятные и достижимые цели спринта – подбирать под них задачи, которые ведут к их достижению, а потом это все растолковывать командам.

• На следующей стадии мы сделали так, чтобы планирование с командой было не просто формальным событием, а реально рабочим инструментом. Для этого нужно прийти к балансу между требованиями и пожеланиями владельца продукта и возможностями команды – для этого команда оценивает все предложенные владельцем продукта задачи, получает некую суммарную оценку.

• Также мы оцениваем производительность, продуктивность команды. Разница между пожеланиями владельца продукта и продуктивностью команды должна отрезаться безжалостно. Это делается за счет того, что владелец продукта либо упрощает требования, либо просто их снимает. И задача Scrum-мастера в этом процессе – отбить команду, дать ей голос, и не дать владельцу продукта накидать требования, которые заведомо невыполнимы по пропускной способности. Когда мы стали отказываться от задач сверх оценки продуктивности, команды начали реально достигать целей спринта. Как сказал один участник нашей команды: «Цели начали светить». До этого выполнение целей не светило.

Focus (фокус). Я много раз видел, что у ребят может находиться 5-7-10 задач в работе одновременно. Это дикий ужас. Я думаю, все видели результаты исследований о том, что, если постоянно приходится переключаться между разными задачами, продуктивность стремительно падает.

Чтобы с этим разобраться, мы решили научиться фокусироваться. И для этого воспользовались двумя принципами из канбан-метода.

• Один – это Pull или вытягивающий принцип работы с задачами.

• А второй – это WIP лимиты.

Как это работает? На слайде вы видите нашу реальную Scrum-доску. На ней статусы прохождения задачи идут слева направо. И каждое утро на стендапе мы открываем эту доску и идем справа налево, т.е. вытягиваем задачи.

Допустим, мы видим задачу, которая почти готова, и смотрим, что нужно сделать, чтобы отправить ее в «готово». Мы не берем следующие задачи, пока не закрыли все, что максимально близко к завершению.

Если говорить про WIP лимиты, здесь тоже все просто. Допустим, у вас команда из четырех разработчиков, и вы считаете, что больше шести задач в единицу времени у них в работе быть не должно. Вы в Jira или где-то еще ставите этот лимит на колонку со статусом. И если команда берет в работу седьмую задачу, у вас весь столбец начинает гореть красным. Тогда на следующем стендапе вам стоит эту ситуацию обсудить – почему не закрыли одну из шести задач, а взяли седьмую.

Когда у нас эти два инструмента заработали, разработчики действительно начали фокусироваться, начали выполнять свои задачи гораздо ритмичнее, быстрее и эффективнее.

Openness (открытость и прозрачность). Про это можно было бы, наверное, отдельный доклад сделать, но я ограничусь тезисами. Для меня суть этой ценности заключаются в следующем:

• Во-первых, я хочу по каждой задаче проекта видеть, что с ней происходит прямо сейчас.

• Второе – прежде чем взять задачу в работу, мы должны добиться, чтобы для нее выполнялись критерии готовности definitions of ready (DoR). И прежде чем задачу закрыть, для нее должны быть выполнены критерии закрытия definitions of done (DoD). На слайде показано, какие критерии мы применяем у себя на проекте.

Зачем нам это?

• Критерии позволяют придерживаться определенного уровня качества по выполняемым задачам на проекте.

• Также критерии позволяют нам сократить потери времени: на поиск информации; на то, чтобы разобраться, какой у задачи статус; на то, чтобы отвлечь коллег, подергать, что-то у них спросить. Раньше мы такие потери несли в большом количестве. Сейчас мы тоже их несем, но если бы мы не использовали эти критерии в работе, была бы вообще катастрофа. И она еще усиливается тем, что когда вы переходите на Scrum, вы перестаете выпускать всякую тяжеловесную документацию типа технического задания, функциональных требований или пошаговых инструкций. К такой документации у вас просто нет возможности обратиться.

Мы у себя стараемся эти критерии внедрять. На каждом проекте, конечно же, мне приходится снова и снова договариваться с командой и объяснять людям, зачем эти критерии выполнять, и стараться доводить их выполнение до автоматизма.

Но если бы мы этого не делали, мы бы потеряли управление бэклогом, нагенерилили бы кучу бесполезной, ненужной работы, а потом потратили кучу времени на то, чтобы навести порядок. Это уже на практике проверено.

Respect (уважение). Тема про уважение – моя любимая. Когда я присоединился к командам, не все меня там ждали с распростертыми объятиями.

Меня встретили скептически настроенные, недовольные разработчики. Это недовольство проявлялось по-разному, иногда очень конфликтно. Например, они могли сорвать проведение ретроспективы или даже где-то перейти на личности. Это, конечно, много седых волос в моей бороде породило.

Но я для себя сделал вывод, что этот скепсис, это недовольство появляется по двум причинам.

• Первая – потому что Scrum создает прозрачную среду, где становится видна неэффективность и низкое качество работы. Но не все готовы меняться, становиться лучше.

• А вторая причина в том, что некоторые разработчики не готовы работать в среде неопределенности, которая приходит со Scrum. Им хочется работать по четко поставленному ТЗ, с детально прописанной архитектурой и т.д.

Мы со всеми разговаривали, объясняли им про новые выгоды, про новую политику. Но не все были готовы слушать, и не все были готовы меняться.

Все пришло к тому, что скептики Scrum покинули офис: кто-то сам принял такое решение; кто-то – под давлением руководства; а кто-то – под давлением команд, которые не хотели работать в деструктивной атмосфере.

Подведу итоги – как поставить команду разработки на рельсы Scrum.

1. Попробуйте договорится с сотрудниками, которые словами и действиями сопротивляются трансформации. Если этого не сделать, они будут очень жестко якорить всю команду. Нужно либо найти им какое-то другое применение, либо попрощаться.

2. Научите разработчиков фокусироваться на одной-двух задачах. Для этого Pull и WIP-лимиты вам в помощь.

3. Научитесь работать с владельцем продукта – ставьте понятные цели, объясняйте их, доводите до команды.

4. И научитесь делать так, чтобы планирование начало у вас работать. Дайте голос команде, чтобы она могла отказываться от какого-то объема задач.

5. Но когда команда получает этот голос, просите в обмен, чтобы она начала брать на себя ответственность и выполнять цели спринта. На мой взгляд, это – ключевой фактор успешной команды, к нему нужно стремиться.

Итоги

Когда мы говорим о пользе от внедрения Scrum, профиты для заказчика и для команды разные.

• Для заказчика профит от Scrum – быстрый запуск продукта с наиболее востребованными функциями: гибкое управление задачами на проекте и гибкое управление бюджетом.

• Для команды Scrum устраняет три фактора, которые присущи иерархическому устройству: бюрократия, контроль и постоянные переключения между задачами. Устранение этих факторов не только помогает разработчикам выполнять задачи быстрее и эффективнее, но и приводит к тому, что они это делают с хорошими эмоциями, т.е. способствует классному и драйвовому климату в команде.

Когда мы все эти инструменты, о которых я рассказал, собрали и использовали на одном своем проекте, мы получили все эти профиты и для заказчика, и для команды.

И заказчик признал этот проект безоговорочно успешным, и команде тоже понравилось так работать – на слайде ребята запечатлены на финальной ретроспективе.

Мой предыдущий опыт показывает, что такие проекты по каскадной модели делаются гораздо дольше, бОльшими командами, с бОльшими затратами и с меньшим шансом на успех.

Здесь хотелось бы сказать «раунд!», но есть еще небольшой бонус.

По ссылке приведена табличка, которая называется Scrum checker. Она придумана не мной, но я ее перевел на русский язык. Там вы найдете очень простой гайдлайн, по которому легко разберетесь, как измерить и оцифровать свой текущий или будущий Scrum и найти векторы для развития.

Я вам искренне желаю пройти наш путь гораздо быстрее.

Вопросы

Приведите пример конкретных, понятных и лаконичных целей спринта и задач к нему.

Я вряд ли смогу это сделать на ходу, но на слайде про Commitment были приведены и цели, и вложенные задачи. Это как раз один из результатов наших экспериментов с целями.

Как изменились ваши обязанности со времен, когда вы начинали быть Scrum-мастером, и в текущих реалиях? Что принципиально изменилось за это время?

Если так рассуждать, то обязанности я, по большому счету, придумал себе сам, опираясь на литературу.

И если говорить о том, что изменилось и как изменилось, то об этом мой сегодняшний доклад.

В первое время мы нащупывали все эти инструменты, наступали на определенные грабли, а потом на одном проекте собрали лучшие практики. Теперь моя задача – эти практики на другие проекты распространять, искать новые инструменты.

Когда вы показывали слайд с командой проекта, в команде был владелец продукта, Scrum-мастер и четыре разработчика. С точки зрения компетенций и ролей разработчиков ваша методология не предполагает использование таких ролей, как аналитик в проекте, либо о них не упомянули? Может, эти роли как-то были транслированы? Расскажите подробнее.

С точки зрения Scrum-гайда все участники команды называются разработчиками, и я придерживаюсь этой терминологии. Но интересно, что именно эта команда в себя включала 4 универсалов. Трое работали аналитиками, при этом они не только работали непосредственно с клиентом, но могли и кодить.

Если говорить про контрактовку с заказчиком, какой формат контрактовки подходит для исполнения проекта по Scrum? И если это не коммерческая тайна, конечно, какой формат контрактовки здесь был – это Fixed Price или Time and Materials?

Мы рассчитываем свои бюджеты на проект, исходя из full-time участников команды разработки. Получаем таким образом стоимость спринта. Потом умножаем на количество спринтов, которые в результате нулевого спринта (или, можно сказать, обследования) определяем и закладываем на проект. И получаем, наверное, Fixed Price, только с ритмичным актированием по спринтам.

А если у вас будет больше спринтов, Fixed Price изменится или нет?

Мы с заказчиком это обсуждаем. И для себя, естественно, закладываем определенные риски.

Но и вся суть Scrum в том, чтобы гибко реагировать, двигаться и менять приоритеты, менять решаемые задачи, чтобы уложиться в имеющуюся стоимость.

И даже если какой-то спринт добавится, однозначно не будет удвоения стоимости проекта.

Как вы работаете на проекте с ошибками, учитывая, что у вас есть спринты? И как вы эти ошибки, баги учитываете на доске в Jira?

Мы таким задачам назначаем в Jira тип «ошибка». И работаем с ними в зависимости от критичности.

Какие-то критичные ошибки, которые требуют решения здесь и сейчас, можем взять в текущий спринт, какой-то приоритет подвинуть.

Если это не очень критично, можем это отложить до следующего спринта.

Т.е. вы пересобираете спринт? Насколько я помню, спринт неделимый после планирования, и если вы хотите добавить задачу, вы должны его пересобрать.

Scrum-гайд не запрещает добавлять задачи в спринт, может возникнуть ситуация, что задача добавляется в спринт. Но задачу может добавить только команда, если команда понимает, что для достижения цели спринта нужны еще задачи.

Мы можем предусматривать это при планировании и оставлять какие-то небольшие допуски. Мы же понимаем, что ошибки, особенно во время запуска какого-то блока, будут – они будут появляться через обратную связь от пользователей, через Service Desk. И мы закладываем на это, допустим, 20% времени.

В Jira для работы с ошибками можно использовать выделенную Swimline, задачи с которой разработчики будут брать в первую очередь.

По вашему мнению, какие 1С-проекты (или при каких условиях) на Scrum не взлетят?

Если заказчик не понимает, не принимает философию Scrum – не пытается понять и вникнуть, говорит: «Делайте как угодно, только работайте по Fixed Price», это ключевая опасность. Я бы ее подчеркнул и выделил.

Надо все-таки, чтобы заказчик и на уровне менеджмента, и на уровне мидл-менеджмента был готов к тому, чтобы запускаться итеративно.

У вас было заявлено, что некоторые разработчики были не готовы работать без тщательно прописанной архитектуры. При этом был приведен пример внедрения ERP. Конфигурация ERP сама по себе подразумевает наличие архитектуры, в пределах которой работаем. А когда нам самим требуется конструировать архитектуру решения, возможно, нам все-таки нужно ее прописывать, возможно нечетко?

При работе по Scrum картина начинает прорисовываться постепенно. На входе мы рассматриваем какой-то блок и принимаем решение, исходя из той информации, которую имеем сейчас.

Например, мы решаем, что нужно вести договора по заказам. Это как раз пример локального решения в архитектуре, которое нужно принять здесь и сейчас, исходя из имеющихся вводных данных. Это решение может постепенно измениться под влиянием каких-то обстоятельств.

Но есть ребята, которые говорят: «Нужно посмотреть со всех сторон, детально изучить ситуацию со всех точек зрения – можем ли мы сейчас устанавливать признак, что ведение договоров по заказам». Я говорил именно об их недовольстве работой в условиях неопределенности по архитектуре.

Принятые решения мы фиксируем в Confluence – накапливаем определенную базу архитектурных решений. Но под влиянием новых контекстов это может меняться.

Если вам требуется привлечение каких-то узких специалистов, которых просто нерационально весь спринт держать на конкретном проекте, что делать? У нас же есть требование к фокусировке.

Честно говоря, на нашем проекте таких ситуаций не возникало, такой необходимости не было.

Мы привлекаем каких-то узких специалистов, чтобы они поделились своей экспертизой. Если необходимо, мы обращаемся к специалисту, объясняем контекст и проблему, просим подсказать, в каком направлении копать. Но потом самостоятельно разбираемся.

Подход, когда мы привлекаем на подряд кого-то, чтобы он сделал одну задачу и отключился, мы не практикуем.

Если у нас, условно, есть цель что-то сделать, есть задачи, которые вполне подходят под эту цель, но в один спринт они целиком не помещаются? А в два – уже многовато. Что делать с дробными спринтами, как формулировать цель спринта?

Как сказал один мой наставник, нет цели, задачи для которой нельзя подробить до размера одного дня. Есть разные инструменты, которые позволяют это делать. Поэтому мы ищем формулировки цели, которые могут уложиться в один спринт. Один спринт в нашем случае – две недели. Задачи дольше двух недель – это плохие задачи, очень размытые. Мы ищем возможность их дробить.

Как часто на проекте вы проводили ретроспективы, и что в результате каждой ретроспективы вы выносили – какие плюсы и минусы брали?

Я специально не рассказывал про ретроспективу, потому что не считаю, что это какое-то наше большое достижение. Это – рабочая история.

На этом проекте мы раз в спринт проводили ретроспективу. Шли по классической схеме:

• Заряжались позитивными эмоциями, обменивались тем, что получилось.

• Копали вглубь, обменивались тем, что нас напрягает и что мы хотим исправить.

• По итогу выносили 2-3-4 каких-то решения, которые будем внедрять на следующем спринте силами команды.

Главное, что я для себя вынес, – это должны быть очень простые истории, которые команда реально поддерживает, реально генерит сама. Предложения от Scrum-мастера в вакууме обычно не принимаются. Но если это решение созрело внутри, команда действительно начнет это внедрять.

Про «цели, которые начинают светить» мы узнали именно в результате таких разборов на ретроспективе, после наших экспериментов.

Кто прописывает definition of ready?

У нас есть базовые definition of ready. Самые простейшие были приведены на слайде. Это некие стандарты, которые мы используем всегда в любом проекте.

Этот список критериев может дополняться самой командой.

Например, если мы решили где-то подтянуть качество, мы можем это сделать за счет того, что включим в критерий готовности к задаче еще какой-нибудь пункт. Мы это делаем и таким образом модифицируем базовые критерии.

Ведется ли аналитика внутри спринта? В какой момент появляется постановка задачи? И кто ее прописывает?

Постановка задачи должна появиться до планирования. Ее прописывает владелец продукта.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.