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

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

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

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

Под катом на примере LeadHub #8 рассказываем, как устроены встречи тимлидов, и какой эффект дают на разных дистанциях. С примерами прорабатываемых на встречах проблем и практическими советами по организации подобных ивентов.

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

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

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

Представьте ситуацию. Приходит Product Owner и говорит: «Давайте сделаем новый дизайн страницы сайта». Аналитик берётся за задачу — проводит A/B-тест. Такая же задача случается в соседней команде, в сопоставимом по сложности продукте, — но если в первом случае тест занимал пару часов, то во втором ждать приходится несколько дней. Чем больше команд и аналитиков, тем выше риск разрозненности. 

Унификация процессов помогает минимизировать этот риск, только как к ней лучше подступиться? Подготовить чеклисты, шаблоны, документацию, скрипты..? В нашем случае понадобилось всё это, плюс самодельный инструмент, который автоматизирует статистический анализ результатов A/B-тестов

Под катом пошагово описываем, как мы унифицировали процессы в нашем A/B-тестировании, и что получили на выходе.

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

Под катом автор блога Considerations on Codecrafting рассматривает ошибки, связанные с наложением ссылок, предлагает методы их предотвращения и призывает внедрить эти методы на уровне проектирования новых языков.

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

В теории всё красиво: собрались на отдельную встречу (чтобы сфокусировано обсудить нужную тему), вспомнили недавнюю работу (пока не забылось), определили области для улучшений (итеративное развитие — наше всё).

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

Хорошие новости: можно по‑другому. Повысить вовлеченность команды в ретроспективу, помочь увидеть конкретный результат своих усилий по улучшению работы. Уйти от вопросов «Что будем обсуждать на ретро?» и «У нас все хорошо?» к прозрачной картине того, что происходит с командой, чего удалось достичь и куда двигаться дальше. Помогут нам в этом процессные метрики.