Меня зовут Антон Субботин, я фронтенд-разработчик в Яндекс Практикуме. Многие знают Практикум как образовательную онлайн-платформу, но мало кто знает, как много всего мы делаем помимо practicum.yandex.ru. Это обычная ситуация: внешние пользователи видят верхушку айсберга, а сотрудники — всё остальное.

Другая настолько же обычная ситуация заключается в том, что рано или поздно каждый разработчик сталкивается с проблемой, которую нельзя (или сложно, или неудобно, или не хочется ????) решить, используя доступные инструменты. Иногда это специфические проблемы разработки, в других случаях — проблемы в процессах и/или используемых инструментах.

Когда это происходит, возможны два варианта развития событий:

1. Мы забиваем на это и копим тележку проблем.

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

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

Тележка проблем и как с ней работать

Откуда вообще берутся проблемы? Я выделил два основных источника: специфические проблемы разработки и процессные/инструментальные неудобства в работе — нашей и смежников. И если с проблемами разработки мы все умеем работать (например, если нам не хватает функциональности используемой либы, её всегда можно форкнуть), то как разработчику чинить процессы?

Для того чтобы решить проблему, нам нужно понимать, что является её причиной. Рассмотрим пару примеров:

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

2. Коллега постоянно отвлекает вас, просит выполнить какое-то очень простое действие. При этом коллега не сел вам на шею, у него просто нет физической возможности сделать это самостоятельно.

Зная причины проблемы, легко придумать её решение: у кого-то есть конкретная боль, а у вас есть таблетка:

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

И всё-таки как находить боли и где искать аптечку, полную таблеток? Мы выделили несколько подходов, которые могут с этим помочь:

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

2. Общайтесь со своими коллегами (и слушайте их) — подмечайте их боли, проявляйте эмпатию. Вместо «читай доку, всё написано, какая разница, что для твоей задачи нужен ретроградный Меркурий?» спросите: «Как я могу тебе помочь? Что поможет тебе сделать задачу проще и быстрее?» Старайтесь улучшать мир вокруг себя.

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

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

Если вам интересно почитать про инструменты, которыми мы улучшаем свой DX, напишите в комментах, и мы расскажем о них в одной из следующих статей.

Переход из урока на платформе на страницу урока в админке

Как известно, мы в Практикуме разрабатываем образовательную онлайн-платформу. Иерархия контента устроена довольно сложно, как и навигация по ней. Чтобы внести правки в урок, нужно найти его в сущности № 1, которую нужно найти в сущности № 2, которую нужно найти в… вы поняли.

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

Создание легковесной админки для тяжёлого JSON-хранилища

Представьте JSON-хранилище с огромным объёмом данных. Данные разбиты на отдельные куски, называемые нодами. Каждая нода редактируется через графический интерфейс. Каждая правка создаёт новую версию. Множество пользователей имеют права на редактирование. При этом система не предоставляет никакой проверки версий во время сохранения.

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

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

Виджет для управления фиче-флагами

Практически все фичи в Практикуме катятся под фиче-флагами. В нашем случае есть несколько уровней влияния на состояния фиче-флага. Вот они слева направо в порядке возрастания приоритета:

1. Фиче-флаг в конфиге (конфиг в том самом JSON-хранилище ????)

2. Эксперимент

3. Заголовок

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

1. Тестировщик включает фиче-флаг для тестинга.

2. Кто-то отключает его, потому что фича мешает ему на другом стенде или самом тестинге.

3. Тестировщик докладывает, что фича не работает.

4. НЕ PROFIT

Другой тонкий момент — невозможность включить фичу только для себя. Одна из киллер-фичей фиче-флагов (no pun intended!) — возможность посмотреть на фичи в проде перед полноценным запуском. Но как это сделать, если формат наших фиче-флагов не поддерживает включение на конкретный user_id из коробки, заголовки так и не обрели популярность, а костылять не хочется? Какое-то время нас спасали технические (не раскатанные на пользователей) эксперименты, но это было тяжеловесное и неудобное (для этой конкретной задачи) решение: нужно зайти в админку экспериментов, которой не все умеют пользоваться и в которую не у всех есть доступ, завести техническую выборку, нигде не накосячив, перекреститься и только спустя несколько минут увидеть изменения на нужном окружении, залипнув в созданную выборку.

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

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

Как мотивировать команду становиться айболитами

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

Будьте примером

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

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

Слушайте других людей

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

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

Ищите единомышленников

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

Вовлекайте младших разработчиков и стажёров

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

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

Защищайте свои задачи на планировании

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

1. Новый, потенциально очень конверсионный флоу оплаты.

2. Виджет, упрощающий работу вашему тестировщику.

При сравнении в лоб первая задача на миллион световых лет впереди по приоритету. Но если вы докажете ценность виджета, то он тоже имеет все шансы попасть в спринт. Говорите с людьми, которых вы хотите убедить, на их языке: расскажите про то, что это уменьшит time-to-market, поможет релизиться качественнее и чаще, реже откатываться. Защищайте свои задачи на языке фактов и метрик, учите этому команду — это очень полезный навык.

Вывод

Не забывайте главное: мы все в одной лодке. Лодка, в которой двое гребут в разные стороны, а третий ковыряется в носу, — это какая-то неправильная лодка.

Старайтесь помогать коллегам, делайте их работу проще, а жизнь — лучше. Когда у вас не окажется готовой таблетки от чьей-то боли — а это будет случаться много-много раз, — химичьте свою. Такую, какая вам нужна. Так, чтобы вам (и не только вам — не стесняйтесь выкладывать не обременённые NDA проекты в open source) было хорошо. В конце концов, мы, разработчики, для этого и нужны.

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