Доклады

Техдолг и технозадачи — разные вещи. Одни замедляют разработку, а вторые помогают её ускорять.
* Как можно посчитать количество техдолга и как его оценивать?
* Как за ним можно следить и вовремя править?
* Как сравнивать технозадачи и понимать, какие из них делать прямо сейчас?
* Как можно управлять приоритетами и не замедлять продуктовую разработку?

Я работаю в заказной разработке и моя "спецификация" — помогать легаси-проектам, которые оказались в "сложном положении": предыдущая команда "не справляется" и нужно "починить" ситуацию. Часто это означает частичную или полную замену команды разработки, а иногда и менеджмента проекта. Здесь есть много специфики: может не быть истории изменений, документированного деплоя, процессы "хромают" или и вовсе не "настроены"... В конце концов, почему этот проект приходится "спасать"?

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

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

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

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

Заполнить bugtracker задачами технического долга недостаточно: чтобы продать бизнесу технический долг, нужно понимать “процент выплат” по каждой из задач. Встает вопрос "что важнее": вычистить лог, чтобы саппорт быстрее с ним разбирался, добавить метрики в Prometheus, чтобы DCO видело падение производительности, доделать честную многопоточность для хороших циферок масштабируемости и производительности или отрефакторить старую подсистему.

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

Из опыта: команда разработки и команда продуктовой безопасности редко сосуществуют в тесной дружной обстановке. Первым нужно бежать вперед, выпускать новые фичи и переходить на современные технологии. Вторые закручивают гайки и обожают слово «нельзя».

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

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

Со временем зрелые команды по наитию решают эти проблемы инженерными практиками и подходами, даже не подозревая, что пришли к InnerSource. Хорошая новость в том, что сообщество энтузиастов из мировых компаний InnerSource Commons делится лайфхаками и правильными рецептами приготовления InnerSource. Принципы open source, уже давно доказавшие свою состоятельность в разработке сложных программ, отлично перекладываются на корпоративные реалии.

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

Часто, когда мы говорим о крупных компаниях, у нас возникают ассоциации вроде "кровавый enterprise", бесконечные NDA и тщательное регулирование всех процессов разработки.

В докладе я попробую побороться с таким имиджем, рассказав три истории о том, как внутри банка развивалось и продолжает развиваться совместное владение кодом, основанное на принципах inner source. У каждой из историй разные предпосылки и особенности, но все они про совместную разработку на основе открытости и сотрудничества. В процессе рассказа разберемся, откуда берется InnerSource и как его создать внутри вашей компании.

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

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

В общем, это краткий курс по инвестированию в людей, который точно даст вам пару применимых на практике инструментов.

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

Можно таким образом найти единомышленников, вместе с которыми можно совершенствовать подходы, в которые верите.
Можно найти будущих коллег: допустим, кто-то из зрителей не согласен с вами и пришёл об этом сказать. Вы взяли по чашке кофе, поспорили, остались каждый при своём мнении, а через месяц уже работаете в одной компании. Так бывает.
Наконец, выступления помогают строить личный бренд. Поиск по вашему имени в youtube — такая же строчка в резюме, как и профиль на github.

Однако многим классным специалистам мешает внутренний барьер. Все рабочие задачи делятся на два типа:
1) абсолютно тривиальные,
2) те, которые вы ещё не решили.

Про первые говорить как-то совестно, они же тривиальные, а про вторые и сказать нечего, вы же их ещё не решили. Вы сталкивались с этой проблемой? Тогда мы идём к вам! Точнее, это вы приходите на доклад, и я поделюсь с вами своим алгоритмом поиска в работе того, что может быть интересно другим.

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

Пора признать: 5/10/30 умных человек на встрече ≠ полезная встреча.

Затянутые груминги, бесполезные синки, токсичные и невовлеченные участники, неразрешимые споры и унылая атмосфера — всё это и другие признаки поганых встреч частенько встречаются в IT-компаниях.

Хватит это терпеть! Приходите на мастер-класс по фасилитации.

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

Фасилитировать — это нестыдно!

После 10 лет подъема по технической карьерной лестнице я сменила профиль и стала менеджером продукта.

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

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

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

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

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

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

В своем докладе я расскажу:
* Немного о мутационном тестировании, что это, вообще, такое?
* Как внедряли мутационное тестирование на 1000+ микросервисов усилиями одной небольшой команды.
* Как донести результаты мутационного тестирования до разработчиков и какой инструментарий мы для этого создали?
* И, конечно же, о трудностях, с которыми столкнулись в процессе.

"Предотвратить легче, чем лечить" — отличный слоган! Жаль только, что непонятно, как им пользоваться применительно к разработке софта. Приходится инспектировать готовый продукт/фичу/историю на предмет наличия в ней дефектов. Вот только инспекция качеству уже никак не поможет — качество, плохое или хорошее, уже в продукте. Поэтому мы и решили попробовать делать по-другому — предотвращать дефекты вместо того, чтобы их искать. И деталями наших превентивных мер я хочу поделиться.

Расскажу в своем докладе:
* Почему инспекция не улучшает качество?
* Что мы изменили в процессе разработки для предотвращения дефектов?
* Причём здесь документация? 

Каждый раз, когда мы готовим новую версию API или просто новый интеграционный протокол, мы попадаем в среду с типичными входными условиями:
• API нужно через неделю;
• контрагент готов с нами сотрудничать;
• "тут же чуть-чуть поправить то, что у нас есть!".

А мы, как разработка, стремимся к:
• сделать "стильно, модно, молодежно" (соответствие современным практикам);
• убрать "раздражающее" несоответствие между текущими внутренними сущностями и API;
• отгадать требования "из будущего" и заложить точки гибкости для упрощения поддержки.

За последние 1,5 года мы выпустили 2 крупных продукта, завязанных на интеграцию информационных систем нескольких компаний между собой (6 API для внешней интеграции только на нашей стороне: 4 протокола для платежей и фискализации и 2 протокола для идентификации физических лиц).

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

В 2016 году команда Хекслета переехала на разработку через Docker, который имеет проблемы с производительностью в macOS. Для решения этой проблемы, среди прочего, решили попробовать разработку на удаленных машинах. Оказалось, что у такого подхода есть масса неочевидных плюсов.

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

Темы:
* Проблемы разработки на Маке: память, докер, среда.
* Провайдеры (aws, google, do), коннекты, задержки.
* Ненапряжная работа в Vim, VScode.
* Правильные терминалы и интеграция с Tmux.
* Совместная работа и внешние домены.
* HTTPS, веб-хуки, интеграции с внешними системами.
* Terraform, Ansible и друзья.
* Батарейка!

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

В этом докладе мы немного под другим углом посмотрим на привычные вещи. Проведем ретроспективу с учетом изменений, произошедших в современном мире.

Темы:
* Революция в мире редакторов кода (LSP).
* О чем молчит скрам.
* Надежные процессы без тестировщиков и стейджинга.
* Как мы не поняли SOLID.
* Что сказал Кент Бек, но его никто не услышал.
* Почему пирамида тестирования осталась в прошлом.
* Зачем не нужны микросервисы.

Писать самим или разбираться с чужим кодом? Если этот вопрос для вас актуален, приходите послушать мой доклад и тогда вы:
* узнаете, почему собственное решение уже решенной кем-то задачи может быть хорошо, а может быть плохо. С примерами;
* разберетесь с 8-ю блоками вопросов, каждый из которых характеризует один из аспектов проблемы (пере)изобретения велосипеда;
* познакомитесь с методикой объективной оценки возможности создания рабочего решения взамен существующего;
* сможете тут же попробовать методику на сайте.

1. Сделаю краткий обзор популярных стратегий ветвления (git flow, github flow, gitlab flow, trunk based development), покажу сходства и различия между ними.
2. Разберу вышеупомянутые стратегии на кирпичики — задачи, в решении которых они задействованы: распределение, интеграция, поставка и поддержка. Покажу плюсы и минусы существующих решений, чтобы можно было на их основе собрать наилучшую стратегию для своей команды.
3. Покажу, как оптимальные решения влияют на скорость и качество разработки. Покажу зависимости между рекомендуемыми практиками. Что нужно внедрить сначала, а что можно отложить на потом.
4. Расскажу о нашем опыте внедрения TBD, что прошло успешно и принесло плоды, а что у нас не получилось и какие интересные выводы мы сделали.

Какое чувство сильнее гордости за то, как вырос инженер в твоей команде? Только горечь расставания с мидлом, которого ты год тащил до senior level, а тот вдруг раз и свалил. Да и не каждого дотянешь, тем более по удаленке, а уж себе замену подыскать...

У хорошего лида всегда цейтнот, поэтому приходит понимание, что инвестировать в команду нужно, но с умом.

В своем докладе я расскажу, что такое ELTV (employee’s lifetime value) и как его улучшить, а также покажу свой собственный silver bullet для развития и удержания инженеров — визуальный Personal Development Roadmap.

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

Основные вопросы, которыми мы задавались:
* Как понять, кто сможет работать с той или иной технологией?
* У кого достаточно знаний и умений для выполнения задач на том или ином проекте?
* Как упростить процесс оценки знаний у людей и снизить операционные расходы?
* Как понимать скорость роста сотрудника?
* Где и как хранить эти данные, чтобы не пришлось вычислять их на лету?

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

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

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

У вас есть в компании архитекторы? Крутые ребята, не правда ли?
Разве могут такие спецы быть врагами разработки, раздражать так, что не хочется даже их слушать, а тем более ждать их архитектурного решения по несколько недель? Демотивирует? Замедляет разработку?
Уверен, что они хотят, как лучше. Так ведь, архитекторы?

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

Знакомо? Тогда вам может зайти опыт Ак Барс Цифровые Технологии (Ак Барс Банк), как мы перешли на подход к гибкой архитектуре. В этом нам помогают движущие силы архитектуры.

В интернете сотни курсов для новичков: «Как написать своё первое приложение на X», «Y за 7 дней», «Изучаем Z — полный курс для начинающих». Но о вещах чуть сложнее, чем базовых, материалов почти не найти.

Начинающие мидлы, признающие, что они еще недостаточно круто знают свой язык программирования, начинают курсы — и бросают их, открывают книги — и читают лишь первые полглавы, врубают стрим конференции — и проматывают её на x2, разочаровываются в идее последовательного, проактивного обучения — и плывут по течению, реактивно обучаясь на рабочих задачах.

К каким проблемам приводит такой несистемный подход? Как их решать? И может ли кто-то помочь опытным разработчикам в прокачке их навыков, кроме них самих?

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

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

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

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

P.S. * Расшифровка сноски про лучший мобильный банк:
— Лучшее мобильное приложение для розничных клиентов в Центральной и Восточной Европе по мнению Global Finance The World’s Best Digital Banks 2020.
— Лучший мобильный банк для ежедневных задач (daily banking) в Mobile Banking Rank 2020 от MarksWebb.

“Вот бы всё это было на другом стеке” — за мою карьеру IT-инженера такая мысль приходила мне в голову, по грубым оценкам, больше одного раза.

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

Но одно дело — мечтать, а другое — пойти и действительно сделать. В конце 2019 года мы в Самокате решили сменить стек: перейти с Python на Kotlin. На тот момент мы были в продакшне: реальные пользователи, курьеры, дарксторы, логистика, инфраструктура, партнёры.

Переход на новый стек занял 9 месяцев. В процессе мы узнали много интересного: как искать баланс между “перепроверим заранее всё-всё” и “взорвём, а там посмотрим”; как планировать бэклог, чтобы уложиться к дедлайну; как работать с недокументированными частями системы; как не сжечь команду высоким темпом.

Тизер: мы успели к дедлайну и теперь пользуемся инсайтами из опыта смены стека в “мирное время”.

Поделюсь опытом, как мы "обозреваем" состояние разработки в растущей команде.

При росте бизнеса возникают вопросы, как двигаться максимально быстро и удержать качество на определенном уровне. Все ли у нас сейчас “хорошо” или будет “хорошо” на горизонте дня/спринта/квартала/года. Для ответа на эти вопросы необходимы данные/метрики и их анализ.

В рамках данного выступления разберу повестку в разрезе:
- мониторинг (ключевые бизнес-метрики, разбивка по командам, показатели инфраструктуры и сервисов);
- Live Site Review(LSR) / Incident management — управление инцидентами и аналитика инцидентов, как метрики для "обзора состояния инженерии";
- релизная политика — предсказуемость поставок;
- технические проекты — развитие и фокус на важном.

Команда Tarantool — это вендор одноименного софта. Отдел Delivery, который я возглавляю, отвечает за внедрение конечных решений на Tarantool'е, продвинутую поддержку и заказные работы. И самое сложное в нашей работе — пройти между Сциллой и Харибдой, оставив Заказчика довольным, а с другой стороны — опробовать новые фичи и инструменты от продуктовой команды и первыми собрать в них все грабли (а от Заказчика это скрыть). Как же сделать так чтобы продуктовая команда и команда внедрения при этом друг друга не передушили?

В докладе я расскажу:
- как приучили абсолютно всех инженеров чувствовать боль пользователя и реагировать на нее (a.k.a "как развить эмпатию у аутистов");
- какие инструменты нам в этом помогали
- и как вообще отличаются каналы коммуникации в среде из десяти и в среде из ста инженеров

* Запускать новые микросервисы за четыре минуты?
* Видеть всегда актуальную карту микросервисов?
* Выкатывать сервисы на определенный процент пользователей?
* Выкатывать сервисы только для QA?
* Тестировать определенный сервис в стейджинге, не ломая остальные сервисы?

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

У нас была куча проблем с сайтом — важнейшим маркетинговым инструментом компании, состоящим из тысяч страниц.

Среди них: запутанный и ненадёжный код, долгие и часто необратимые релизы, поломанные и крайне долгие e2e-тесты, ужасающе низкая скорость разработки, проблемы с качеством, устаревшие технологии и отвратительный developer experience, вымотанная команда — а также необходимость уложиться в срок с уже затянутым проектом редизайна, нанять больше разработчиков и вернуть доверие стейкхолдеров.

Что с этим делать техлиду? Уволиться! — скажете вы и, возможно, будете правы.

Но я решил принять вызов — и выделить view layer сайта в отдельный stateless HTTP-сервис, чтобы починить все эти проблемы.

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

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

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

Как мы обычно планируем и делаем работу в команде? Вася берет фичу A, Петя — фичу B, а Женя — С. Потом мы расходимся на несколько дней и каждый вдумчиво делает свою работу. И все бы хорошо, но с этим подходом есть несколько проблем:
* Некоторые (обычно крупные фичи) доползают до релиза медленно, потому что ими занимаются 1-2 человека. А именно такие фичи обычно самые важные и ценные!
* Время доползания до релиза увеличивается, если Вася заболеет. Перехватить то, над чем Вася работал уже несколько дней, не так-то просто, да и свою фичу надо доделывать!
* Синергии от коллективной мудрости команды не происходит или она случается поздно — на code review, когда принципиально переделывать решение, может быть, уже не хочется.

Помогает подход “навалиться и сделать”: внучка за бабку, бабка за дедку — но если в случае с репкой все понятно, то как быть нам?

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

Разработка игр — территория высоких ожиданий и огромной конкуренции. Очень сложно найти свою аудиторию, и столь же сложно удержать её.

Рассказ посвящён тому, что может сделать руководитель Tech-команды, чтобы добиться успеха проекта в целом.

Поиск работы за рубежом полон сюрпризов. То рекрутер в “Компании Мечты” упорно игнорирует ваше полное релевантного опыта CV. То после 20-часового тестового и суперпозитивного фидбэка от команды вам внезапно отказывают на Culture Fit интервью. А с прошлого года всерьез спрашивают почему diversity не работает без inclusivity. Но если все сделать правильно, релоцироваться все же можно!

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