Привет! Я Андрей Леонтьев, тимлид разработки в вертикали Авито Товары. В этой статье рассказываю, зачем тимлиду осознанно прокачивать visibility — управляемую «видимость» инженеров — и как это напрямую влияет на калибровки, промо и скорость получения ресурсов. Покажу, куда «светить фонариком», как выровнять систему ценностей и подбирать инструменты под мотиваторы. Материал пригодится тимлидам, техническим лидерам, PM/PO и инженерам.

Содержание:

• Как я пришел к идее видимости команды

• Performance review и калибровки: почему одним инженерам не нужны «адвокаты»

• Visibility управляема: как формировать то, как вас видят коллеги и руководители

• Инфографика командных успехов: зачем фиксировать проявления в спринте

• Как не потерять ценный кейс: история про инструмент для саппорта

• Куда «светить фонариком»?

• От признания до автономии: как подобрать подход к разным типам инженеров

• Что в итоге

Как я пришел к идее видимости команды

В разработке я с 2012 года, успел проработать в разных компаниях на разных продуктах. Это были информационные системы для госсектора, ИИ-стартапы — еще на заре развития этой сферы, небольшие финтех-решения для малого и среднего бизнеса, интеграция и агрегация данных и предоставление витрины, интеграция с партнерками и т.д. После активно работал в крупном E-commerce, покрывающем всю нашу необъятную Россию. А сейчас  — в классифайде. 

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

Почему я вообще пришел к мысли о том, что кому-то будет интересно поговорить о visibility?

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

Performance review и калибровки: почему одним инженерам не нужны «адвокаты»

У нас в Авито есть процесс performance review. Думаю, во многих компаниях тоже есть похожий инструмент, и, скорее всего, мало кто его любит. Для тех, кто с ним не знаком, базово расскажу, как он выглядит и из каких этапов может состоять. 

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

Процесс performance review — это своего рода рефлексия над тем, что инженер успел сделать за отведенный период. Те, с кем ему удалось повзаимодействовать, оставляют фидбэк за эти полгода: это могут быть, например, представители бизнеса или продукта, коллеги из своей или другой команды.

После сбора фидбэка идет этап, который я называю «вишенка на торте», — это процесс калибровок. 

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

И вот на одной такой калибровке дошла очередь до моего инженера — для простоты назовем его Леха. Когда ребята смотрели его self review, один из менеджеров сказал:

«О, так это ж Леха! Леха классный. А что там оценивать-то? Передай ему просто большое спасибо».

Я подумал:

«Действительно клево, что мне не потребовались дополнительные ресурсы для того, чтобы защитить Леху! …Вот только чем Леха отличается от других моих инженеров? Может быть, у него self review какой-то особенный? Вроде нет».

Теперь я дам вам небольшое представление о Лёхе: что вообще это за инженер? Леха у нас в компании работает больше двух лет. Во время работы он активно участвовал в найме: проводил колоссальное количество технических интервью и брал не только количеством, но еще и качеством. Каждое его self review — это выжимка фактов, как кандидат справляется с задачей и как Леха его оценивает в качестве потенциального коллеги. Также за все время своей работы Леха запустил много классных продуктовых фичей, которые действительно приносят пользу и реально зарабатывают. Часть этих фичей была на стыке нескольких команд — здорово!

Получается, что Леха на всем интервале работы за 6 месяцев так или иначе был на виду у других менеджеров, они его знают. Леха был всегда как на ладони. Все взаимодействия, которые он проводил, видны.

Видны, в том числе за счет того, что у Лехи есть такое свойство — если у него есть проблема, он обязательно ее проработает полностью: раскопает все необходимые факты, если что-то непонятно, обязательно соберет созвон со всеми оунерами сервисов, в которые ему нужно интегрироваться, а после этого еще follow-up напишет: «Ребята, у нас был созвон, мы договорились до следующего вот о чем...», сформирует договоренности, а потом еще последит за тем, чтобы договоренности были выполнены. Эта работа никогда не была лишней. Благодаря этому Леха осознанно, а может, где-то и не очень осознанно, но эффективно поработал над своей видимостью.

Карьерный рост = результат × опыт × видимость

Здесь любой скептик скажет:

«Чем другие инженеры были хуже на этом перфоманс-ревью? Они тоже классные. Они тоже делают задачи, готовят фичи, отдают техдолг, решают баги, проводит исследования».

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

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

Здорово, если вы как руководитель построили процесс таким образом, что все коллеги понимают, чем занимаются их тиммейты. Еще круче, если у вашего владельца продукта (Product Owner) нет необходимости узнавать статус текущей задачи. Для него это все прозрачно, и каких-то дополнительных ресурсов на это он не тратит.

Но как обстоит дело с visibility ваших инженеров для других команд? А для представителей бизнеса, которые чуть дальше, чем Product Owner, и не так плотно интегрированы в вашу команду? А как дела с вашим руководителем? Именно та роль, которая находится на уровне +2 в отношении ваших инженеров.

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

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

1. Результат, который несет сотрудник (необязательно инженер).

2. Знание и опыт, которые у него сейчас есть. 

3. Видимость — то, как он преподносит свои результаты и опыт, какой образ формирует вокруг них. 

Соотношение этих составляющих у всех разное. Если с нами работает инженер, то для нас в первую очередь важно то, как он поставляет результат, а по остаточному принципу уже его знания/опыт, как он применяет их, и видимость, как он эти кейсы упаковывает и преподносит. Для одного это будет соотношение 60−20−20, для другого: 60−30−10. 

Представим ситуацию, что вы нанимаете инженера. На финальном этапе перед вами кандидат и у вас из артефактов его пути по процессу найма только результат технического интервью и то, как он упаковывает свой опыт и преподносит через кейсы из других компаний. У вас как у менеджера нет на столе результатов с его прошлой работы, нет опыта взаимодействия с этим кандидатом, на основании которых вы могли бы сделать выводы. И поэтому ваш фокус при принятии решения смещается на другие составляющие. Мнение вы складываете, с одной стороны, на основании опыта и знаний, которые он показал на техническом интервью, а с другой, на основании того, как он эти кейсы преподносит. Эти два фактора влияют на ваше решение где-то 50 на 50 вот, может быть, 60 на 40. То есть значимость самопрезентации и упаковки кейсов повышается, а это является фундаментом формирования visibility. 

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

Visibility управляема: как формировать то, как вас видят коллеги и руководители

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

Представим антипаттерн — мы берем самого ответственного и опытного инженера и говорим: «Ты теперь будешь тимлидом, на тебе команду, будешь руководить». Чтобы принять это решение, нужно, чтобы этот инженер был еще и видимым, то есть мы должны выделить его на фоне других. Например, Леха, про которого мы только что говорили, будет нашим тимлидом. Получается, что даже в таком кейсе видимость, насколько заметен сотрудник, действительно важна.

Visibility (от англ. «видимость» или «заметность») — управляемая профессиональная видимость. Умение не только делать свою работу на «отлично», но и быть замеченным нужными людьми в нужной роли и в нужное время.

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

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

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

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

01.  Анонс релиза в мессенджере

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

02.  Лайв-демо на ревью спринта

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

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

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

03.  Публичная благодарность

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

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

04.  Запрос обратной связи по результатам

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

Рекомендую использовать небольшой лайфхак. Если просто прийти и попросить дать обратную связь, как все прошло, чаще всего вам скажут: «Ну, все классно было». В чем ценность такой обратной связи, запомнят ли такое взаимодействие? Я предлагаю запросить 2−3 зоны роста, которые, по мнению вашего коллеги, были бы для вас актуальны. Это заставит его порефлексировать над тем, как действительно все прошло, где были острые углы, которые можно было срезать, а где вам стоит обратить внимание на точки роста. Такая форма обратной связи:

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

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

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

05.  Технический вклад

Вишенка на торте: мы можем рассказывать о своих достижениях не только с помощью фичей.

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

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

06.  Персональный рост и развитие

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

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

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

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

Карточки разного цвета:

• красные — проявление, в котором инженер где-то «не дотянул». Это повод дать ему развивающую или корректирующую обратную связь; 

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

• светло-зеленые — уже повод для того, чтобы инженера похвалить;

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

Как карточки появляются? Я фиксирую сигналы на протяжении определенной работы. Это могут быть дейлики, коммуникация с другими командами, с саппортом.

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

Как не потерять ценный кейс: история про инструмент для саппорта

Еще важно понимать, в какую аудиторию вы несете ту или иную ценность. Как уже говорил, я люблю примеры из жизни, это — один из них.

Однажды ко мне в личные сообщения пришел инженер. У нас случился примерно такой диалог:

У меня возник вопрос: а что от меня инженер хочет? Сценариев было много:

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

2. Может быть, мы пропустили какой-то алерт, который аффектит другую команду, и потому мы принесли кому-то негативный импакт?

3. А может, в компании просто происходит исследование анализа инцидентов?

Вариантов много.

Тогда я задал инженеру важный вопрос: «Слушай, а мы сейчас какую проблему решаем?». Оказалось, проблемы вовсе и нет. У команды этого инженера просто была боль: сложно смапить обращение пользователя и технические артефакты (логи, трейсы в observer, внутренняя система Авито для сбора логов и тресинга). Тогда они придумали инструмент, который их связывает: можно просто взять обращение, по нему найти все интересующие артефакты и быстро локализовать инцидент — классно. Я бы первый сказал: «Давай-ка и мне интегрируем!». Случился потерянный кейс.

А если исходить из ценностей, как здесь можно организовать коммуникацию?

Если мы несем информацию тимлиду, то для него важны следующие критерии:

• как изменилась команда?

• стали ли процессы более оптимальными и насколько?.

В нашем случае можно было пойти от сокращения времени на разборы инцидентов: 

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

Куда «светить фонариком»?

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

01.  Своя команда

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

02.  Вы как руководитель

Здесь недостаточная видимость результатов и процесса получения ценности вызывает тревогу. Чаще всего это первое, что фиксят менеджеры. 

03.  Ваши руководители

Это люди на уровне +2, которые принимают решения о карьерном развитии ваших инженеров.

Они либо решают, как изменяется грейд и мотивация вашего инженера, либо согласовывают ваше решение, то есть все равно выносят финальное решение. Поработав над видимостью на этом уровне, вы снимите с себя часть аргументационной работы при защите того или иного инженера. Если ваших инженеров видно на уровне +2, неудивительно, что к вам придут и скажут: «Слушай, у тебя Леха давно уже классный парень, давай его уже повысим. Когда ты планируешь его повышение?».

04.  Представители бизнеса

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

05.  Другие команды

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

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

От признания до автономии: как подобрать подход к разным типам инженеров

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

Вспомним топ-6 мотиваторов по Адизесу:

01.  Чувство принадлежности и вовлеченности

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

02.  Признание и уважение

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

03.  Справедливая система вознаграждений

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

04.  Автономия и ответственность

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

05.  Чёткие миссия и цели

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

06.  Профессиональный рост и развитие

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

Что в итоге

• Visibility — это ответственность тимлида

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

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

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

• Используйте разнообразные инструменты.

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

• Управляя видимостью, вы строите сильную команду.

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

Какие приемы вы используете в своей работе? Делитесь инструментами и практиками в комментариях!

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