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

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

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

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

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

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

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

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

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

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

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

У нас в ИТ-команде Сравни есть принцип: в любой непонятной ситуации вместо того, чтобы раз за разом решать похожие проблемы, лучше сделать инструмент, который поможет системно решать целый класс таких задач. Шаблонизация, автоматизация занимают важное место у нас в бэклогах. Поэтому эксперименты с Copilot от GitHub и OpenAI, наверное, были для нас неизбежны.

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