Первый опыт управления IT-командой: три вывода, которые я сделал
Когда я впервые начал отвечать не только за свою работу, но и за результат небольшой IT-команды, мне казалось, что задача руководителя достаточно простая: распределить задачи, определить сроки и проверить результат.
На практике сложнее всего оказалось не контролировать разработку, а сохранять общий контекст, снимать блокировки и не становиться человеком, через которого должно проходить вообще всё.
Вот три главных вывода, которые я сделал.
Сообщение в чате ещё не является задачей
Большая часть нашей коммуникации проходит в переписке. Это быстро и удобно, но именно в чатах задача легко теряет смысл. Я пишу, что нужно изменить определённое поведение, разработчик задаёт несколько вопросов и начинает работу. Через пару дней выясняется, что итог мы представляли по-разному.
Проблема не в невнимательности. Часть контекста, очевидная для меня, просто не была зафиксирована.
Теперь я стараюсь указывать четыре вещи: зачем нужно изменение, что должен получить пользователь, какие ошибки необходимо учесть и по каким признакам мы примем результат. Даже короткое описание работает лучше, чем цепочка сообщений, разбросанная по нескольким дням.
Задержка не всегда возникает внутри команды
Некоторые задачи зависят от внешних систем и людей, которыми команда не управляет. Например, функция уже реализована, но источник данных периодически возвращает ошибку. Можно бесконечно менять клиентскую часть, хотя постоянное решение требует другого способа интеграции и участия смежной команды.
В такой ситуации бесполезно просто требовать «починить быстрее». Нужно разделить саму разработку и внешнюю зависимость: что уже сделано, где возникла блокировка, кто может принять решение и допустим ли временный вариант.
Для меня это стало важным изменением. Руководитель нужен не только для контроля сроков. Он должен подключать нужных людей и не оставлять разработчика один на один с проблемой, которую нельзя решить внутри команды.
Приёмка является отдельной работой
Технически выполненная задача ещё не всегда означает готовый результат. Экран может открываться, кнопка нажиматься, запрос отправляться, но весь пользовательский путь остаётся непроверенным.
Поэтому я стараюсь принимать работу не по отдельным функциям, а по сценариям. Проверяю основной путь, пустое состояние, ошибку сервиса, повторное действие и возвращение в раздел. Такой список не заменяет тестирование, но помогает не принять за готовый продукт набор экранов, работающих только по отдельности.
Что оказалось самым важным
Первый управленческий опыт показал мне, что руководство мало похоже на раздачу задач. Основная работа происходит между ними: сохранить смысл, выбрать приоритет, снять блокировку и проверить, что технические результаты сложились в работающий продукт.
От руководителя не требуется знать ответы на все вопросы. Но он не должен допускать, чтобы команда неделями ждала решения, доступа или недостающего контекста.
А какой вывод стал главным для вас при первом переходе от самостоятельной работы к управлению командой?