Рекомендации для руководителей IT-проектов: как не попасть в ад и выйти сухим из воды

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

Панацеи тут нет. Но давайте разберемся.

В мире есть два типа руководителей проектов: те, у кого всё горит, и те, у кого всё горит, но они умеют это скрывать 🙂

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

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

Начинайте с конца

Звучит странно, но работает безотказно. Прежде чем писать первую строчку кода или рисовать первый экран в Figma, важно ответить себе на вопрос: «Как мы поймём, что проект успешно завершён?».

Не в общих чертах («заказчик доволен»), а конкретно:

• Какую проблему мы решаем?

• Какую проблему мы решаем?

• Какие метрики должны быть достигнуты?

• Какие критерии приёмки у каждого этапа?

• Что будет считаться провалом?

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

Требования — это святое

Самая частая причина провалов — размытые, меняющиеся или отсутствующие требования. Заказчик говорит: «Ну вы же профессионалы, сами придумайте». Команда придумывает. Заказчик отвечает: «Я не это имел в виду».

Чтобы не попасть в этот порочный круг:

• Фиксируйте каждое требование письменно.

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

• Сразу обсуждайте, как изменения повлияют на сроки и бюджет.

И главное: научитесь говорить «нет». Нельзя объять необъятное. Если требования растут быстрее, чем команда успевает их реализовывать, проект умрёт от «ожирения».

Команда — это не «ресурс», а люди

Звучит банально, но именно здесь большинство спотыкается. Разработчики — не винтики. Если человек выгорел, не всегда его возможно просто «заменить другим», а если люди в команде выгорают массово — это определенно повод задуматься что вы как руководитель делаете не так. На поиск и онбординг новой команды вы потратите намного больше ресурсов и времени, чем на элементарную заботу о текущей.

Что работает на здоровье и мотивацию вашей команды:

• Прозрачность. Говорите команде правду о статусе проекта, проблемах и рисках.

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

• Уважение ко времени. Не дёргайте людей по пустякам, не назначайте встречи без повестки и не требуйте отчёты каждый час. Доверяйте своей команде, а фокус с микроменеджмента смещайте на конкретный результат (к этому ниже ещё вернёмся).

Когда команда чувствует, что вы в одной лодке плывёте с ними к цели, а не стоите на берегу, щёлкая кнутом, — вы вместе сможете горы свернуть.

Рисками надо управлять

Риски есть всегда. Даже если проект — это «сайт-визитка для бабушкиного магазина». Даже если вы делали такое сто раз.

Как работать с рисками:

• Составьте список того, что может пойти не так. Без оптимизма.

• Оцените вероятность и последствия.

• Для каждого риска пропишите, что вы будете делать, если он наступит.

Когда риск материализуется, у вас не будет паники. Будет план Б. А иногда и план В 🙂

Коммуникация — ваша главная работа

Если вы думаете, что ваша работа — следить за сроками и таскать задачи в Jira, вы ошибаетесь. Ваша работа — быть центром коммуникации.

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

Вы — фильтр. Не все новости нужно доносить до команды. Не все проблемы заказчика должны сыпаться на команду.

Контроль без «чайка-менеджмента»

Есть такая болезнь — страсть к микроменеджменту. Когда руководитель лезет в каждую мелочь, проверяет каждый коммит и требует отчёта о любом чихе. В простонародье такой тип управления окрестили чайка-менеджментом: прилетел, наорал, насрал, улетел.

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

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

Как найти баланс:

• Контролируйте результаты, а не процесс.

• Договаривайтесь о точках проверки заранее.

• Доверяйте, но проверяйте. Проверяйте, но не унижайте.

Если вы наняли профессионалов, дайте им работать. Если вы наняли не профессионалов, то тут вопрос к вам: «а зачем вы их наняли?».

Технический долг — это кредит под бешеные проценты

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

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

Учитесь на чужих ошибках. И на своих.

В IT нет проектов, которые идут идеально. Всегда что-то идёт не так. Хороший руководитель от плохого отличается умением делать выводы и учиться на ошибках.

После каждого этапа, каждой итерации, каждого релиза проводите разбор полётов:

• Что пошло хорошо? Будем делать так и дальше.

• Что пошло плохо? Как сделать, чтобы это не повторилось?

• Что можно улучшить? Даже если всё прошло хорошо, вы можете сделать лучше.

Такую ретроспективу можно проводить как самому, так и с командой проекта. Главное помните, что ретроспектива — это не место для поиска виноватых, а место для поиска решений.

Не геройствуйте

Руководитель, который работает 24/7, пишет код по ночам, разруливает конфликты в выходные и при этом ещё и отчёты за всех заполняет, — это не герой, а проблема.

Если без вас всё разваливается — значит, вы не выстроили систему. Вы создали зависимость, а не устойчивость. И вам нужно научится делегировать. Учитесь отдыхать.

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

Помните, зачем вы все это делаете

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

IT-проекты — это не про код. Это про решения проблем. Регулярно возвращайтесь к вопросам из первого пункта, чтобы сверить курс: вы с командой всё ещё делаете важное и нужное дело или курс сбился? Особенно важно делать эти сверки при планировании предстоящих спринтов, чтобы убедиться: набираемые в спринт задачи действительно важны и полезны этому миру.

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

Быть руководителем — значит видеть на шаг вперёд. Слышать то, что не говорят. Замечать то, что прячут. И при этом оставаться человеком, а не функцией.

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

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