Как IT-менеджеру наладить коммуникацию с командами и бизнесом
Рассказываем, как выстраивать работу в команде, сотрудничать с другими и достигать бизнес-целей.
IT-менеджерам бывает нелегко координировать работу над проектом, чтобы выдать результат — нужный и в срок. Все потому, что без налаженной коммуникации между всеми участниками процесса этого добиться очень сложно: будут гореть сроки и страдать ценность продукта. Рассказываем, как подружить между собой специалистов внутри команды, разные отделы и руководителей бизнеса, чтобы все работали слаженно и без крупных факапов.
Объединить специалистов в команде: не замалчивать проблемы, донести цели, развивать сотрудников
Даже внутри небольшого коллектива часто возникает недопонимание, ведь у каждого специалиста разные задачи, приоритеты и — характер. Если не учитывать эти особенности, конфликты и рассинхрон внутри команды неизбежно приведут к ошибкам.
Задача IT-менеджера — дать членам команды возможность без страха и конструктивно обсуждать проблемы, понимать свою роль и ответственность, расти в проекте. Здесь лучше действовать сразу в четырех направлениях.
Типировать членов команды. Типирование — это методика, которая позволяет проанализировать тип поведения сотрудника: как реагирует на стресс, насколько склонен к конфликтам, как относится к проблемам и работе с коллегами. Если понять особенности всех членов команды, будет проще найти подход к каждому и доносить нужную информацию.
Формировать атмосферу открытости и доверия. Часто трудности возникают из-за того, что сотрудники не обсуждают сложности на проекте. Кто-то боится показаться некомпетентным, кто-то не хочет портить отношения с коллегами. В итоге проблемы копятся или решаются «как-нибудь», а сроки — срываются.
Менеджеру нужно создать в команде атмосферу, в которой люди не боятся говорить о проблемах. Например, проводить регулярные встречи, где каждый может поделиться трудностями в работе и высказать свое мнение.
Важно: критика должна быть конструктивной. А еще менеджеру стоит начать с себя: открыто говорить о трудностях, прислушиваться к мнению команды, признавать и исправлять ошибки. Тогда люди будут охотнее рассказывать о проблемах, а конфликты — плавно угасать.
Пример. Разработчик понимает, что из-за большой нагрузки не успевает выполнить работу в срок. Если в команде принято проговаривать проблемы, он расскажет о своих трудностях. Коллеги заберут часть задач, подвинут сроки, придумают что-нибудь еще. А если боится осуждения — может промолчать и сделать все быстро, но «как получится».
Выстраивать прозрачные процессы. Если члены команды плохо понимают, чем занимаются коллеги, и не видят прямой связи своей работы с результатом, то могут неправильно расставлять приоритеты и путаться в процессах. А значит — допускать ошибки и срывать сроки.
Менеджеру важно создать для команды определенность:
- Ставить цели по SMART: сделать их конкретными, измеримыми, реалистичными и ограниченными по времени. Без этого провал гарантирован практически всегда.
- Разграничить зоны ответственности в команде и описать все процессы — например, в отдельной базе знаний.
Пример. Команда разрабатывает новую функцию для веб-сервиса. Фронтенд- и бэкенд-разработчики работают параллельно. При интеграции выясняется, что API и интерфейс ожидают данные в разных форматах, — нужно переделывать работу, сроки горят. А все потому, что разработчики не согласовали спецификацию API. При четких процессах такого факапа точно бы не произошло.
Развивать сотрудников. Разработчики гораздо больше заинтересованы в проекте, когда видят в нем перспективы роста. Поэтому менеджеру важно создать среду, в которой команда будет системно обучаться. Это снизит отток специалистов, а значит, и вероятность ситуаций, которые могут оттянуть релиз.
Менеджер может помочь члену команды составить персональный план развития — PDP. Для этого нужно вместе с сотрудником определить его цели на ближайшие 6–12 месяцев и прописать план: когда и какие именно навыки он будет осваивать. Идеально, если этот план соотносится с целями компании — человек будет сразу же применять новые навыки на проекте.
Пример. Вы планируете перевести проект на микросервисную архитектуру, а в команде как раз есть разработчик, который хочет изучить это направление, — включите его в план развития. Все довольны: разработчик развивается в профессии, компания — достигает своей цели.
Синхронизировать команды: определить общие метрики, подружить процессы и обмениваться идеями
В IT-проектах задействованы разные команды: разработчики, дизайнеры, маркетологи и другие. От того, насколько синхронно они работают, зависят сроки и ценность продукта. Неслаженные действия могут привести к ошибкам, придется переделывать работу или отказываться от важных фич.
Чтобы синхронизировать работу отделов, менеджеру стоит налаживать общее понимание с лидерами разных команд:
Обсуждать общие цели и метрики. Часто цели, ключевые метрики и KPI команд отличаются. Для успешного релиза важно, чтобы каждая команда работала на общие цели, а их KPI не противоречили друг другу. Для этого менеджеру нужно погрузиться в специфику каждой команды и говорить с лидами соседних направлений на языке их задач — так будет проще донести ценность совместной работы.
Пример. Разработчики хотят быстрее выпускать новые функции, а тестировщики заинтересованы в более тщательных проверках. Из-за этого команда тестирования заводит много тикетов, а разработчики игнорируют «несущественные» баги. Менеджеры обоих направлений договорились и внедрили общую метрику — количество успешных пользовательских сценариев. Теперь команды фокусируются на том, как вместе определять самые критичные баги в продукте и исправлять их в первую очередь.
Унифицировать процессы. Процессы также могут сильно отличаться от команды к команде: разные спринты, инструменты, расстановка приоритетов. Из-за несогласованной работы затягиваются сроки и страдает результат.
Менеджеру важно погрузиться в процессы каждой команды и придумать, как согласовать их между собой. Здесь нет единственно верного решения, стоит пробовать разные варианты. Например:
- Создать единую доску задач. Она станет общим пространством, в котором команды смогут отслеживать работу друг друга. Это поможет лучше понимать, на каком этапе находится проект, избежать дублирования задач и предвидеть возможные срывы сроков.
- Договариваться о ключевых дедлайнах. Если команды работают в разных спринтах, можно зафиксировать только самые важные для проекта даты. Например, подготовку API, запуск бета-версии и релиз. Так каждый коллектив сможет работать в удобном формате, а ключевые дедлайны станут общим ориентиром.
- Внедрить единую базу данных. В ней специалисты будут хранить файлы, которые могут понадобиться в работе коллегам. Например, техническую документацию по продукту. Так командам не придется запрашивать нужную информацию и ждать ответа.
Построить взаимный обмен опытом и идеями. Когда специалисты из разных отделов не взаимодействуют друг с другом, то попадают в «пузырь»: видят только свою часть проекта и упускают важные моменты в работе соседних команд.
Чтобы наладить обмен опытом, подходами и идеями, менеджер может ввести регулярные кросс-функциональные встречи (планерки, ретроспективы, воркшопы, семинары), где специалисты смогут обсуждать не только стратегические, но и рабочие моменты. Это позволит быстрее и точнее находить решения проблем и способы улучшить продукт.
Пример. Команда аналитики обнаружила, что 30% пользователей уходят с сайта на этапе оплаты. Разработчики отметили, что страница загружается слишком долго. А дизайнеры — что на ней нет индикатора загрузки: пользователи думают, что страница просто не открывается. В итоге ее оптимизировали и добавили полосу загрузки. Теперь посетители стали уходить на этапе оплаты лишь в 10% случаев.
Связать команду и бизнес: выяснить ожидания стейкхолдеров и перевести их на язык специалистов
Исполнители и стейкхолдеры по-разному видят проект. Команды фокусируются на своих целях и задачах, которые могут не совпадать с целями бизнеса, а стейкхолдеры — ждут быстрых и часто завышенных результатов, не понимая реальных возможностей и потребностей команд.
Менеджер — это «переводчик» с языка бизнес-целей на язык команды и наоборот. Чтобы команда лучше понимала цели бизнеса, а у стейкхолдеров были реалистичные ожидания и понимание проекта, общаться с ними нужно по-разному.
Со стейкхолдерами говорить на языке их ценностей. У владельцев бизнеса редко есть опыт в разработке, поэтому нужно говорить с ними на языке бизнес-метрик. Менеджер должен четко понимать, какие цели компания преследует в проекте и как будет оценивать его эффективность, — тогда он сможет сформировать у стейкхолдеров реалистичные ожидания, а достижения и потребности команд доносить через пользу или вред для бизнеса.
У руководителей высокая нагрузка — это нужно учитывать. Если на проекте возникли проблемы, важно не просто рассказать о них, а предложить готовые решения и раскрыть плюсы и минусы каждого. Такой подход позволит стейкхолдерам быстро понять ситуацию и принять взвешенное решение.
С командой — на языке конкретных задач. Важно не просто объяснять общую цель проекта, а декомпозировать ее до конкретных задач. Так абстрактные цели превращаются в стратегии для отдельных команд, а дальше — в понятные и измеримые задачи, которые команда берет в работу. Каждый видит, как его работа влияет на цели бизнеса, понимает свою роль и ответственность за общий результат.
Лучше не давать специалистам готовое ТЗ, а начать с обсуждения проблем бизнеса. Так команда сможет предложить решения от себя и подсветить возможные противоречия, а менеджер — конструктивно обсудить это со стейкхолдерами.
Заключение
IT-менеджеру важно создавать прозрачные процессы и поддерживать диалог между всеми участниками проекта. Это помогает избежать недопонимания, снизить ошибки и повысить мотивацию команды. Слаженная работа приводит к более качественному результату и достижению бизнес-целей.
