Искусство управления IT-проектами: как вести команду к результату

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

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

В NUBL IT-команда может разложить работу по этапам, назначить ответственных, связать зависимые задачи и хранить обсуждения рядом с исполнением. Это честная отправная точка для прозрачного процесса, а конкретную методику команда настраивает под свои ограничения.

С точки зрения руководителя команды IT-проекты — это работа по созданию и сопровождению систем или других цифровых продуктов. Здесь результат нельзя физически осмотреть или визуально оценить его качество. Эта специфика влияет на весь процесс управления: от планирования до контроля выполнения задач.

Чтобы не проговаривать банальные особенности, я остановлюсь на менее очевидных, с которыми сталкивался в практике:

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

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

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

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

Этапы зависят от выбранной методологии управления проектами в IT. Расскажу про 2 основных подхода.

Этот подход применяют не только в IT, но и в строительстве и производстве. Он предполагает последовательное прохождение заранее заданных стадий.

Если разбивать процесс детально, то мы получим такие этапы:

1. Замысел проекта. Отправная точка — идея. Вы определяете, зачем нужен проект и какую задачу он решает. Подключаете ключевых стейкхолдеров, формулируете общие требования к решению.

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

3. Планирование. Проект-менеджер собирает календарный план. Определяет, какие работы допустимо выполнять одновременно, а какие зависят друг от друга, и сколько специалистов потребуется.

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

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

6. Разработка и тестирование. Разработчики реализуют функциональность, тестировщики проверяют результат и фиксируют дефекты. Найденные ошибки устраняют.

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

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

9. Запуск. Решение запускают для всех пользователей.

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

Здесь имею в виду Agile-методологии , в частности фреймворк Scrum . Все итерационные подходы устроены иначе по сравнению с waterfall и подходят для решений, где конечный вид продукта ещё не определён, а направление движения можно менять каждые 2 недели.

У команды нет детальной проработки требований на старте, поэтому процесс работы выглядит проще:

Такой процесс более итеративный и зависит от новых вводных, которые приходят от пользователей и рынка.

Решение зависит от проекта и процессов в конкретной компании:

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

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

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

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

Чтобы было проще определиться с подходом, можете сделать следующее:

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

Теперь перейдем к ролям. Вот костяк, который, по моему опыту, нужен на любом проекте:

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

Здесь тоже нет единственной правильной схемы. Показал 2 сценария в таблице:

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

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

Ограничения. Чем больше команда, тем выше затраты на координацию: больше времени уходит на коммуникацию, а риск конфликтов и текучести растёт.

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

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

Ответы на эти вопросы помогут определить, какая команда нужна, можно ли объединить роли или нужны отдельные специалисты на каждую функцию.

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

Единственное, что более-менее стандартизировано — размер команды. Обычно тимлид управляет группой из 7-10 человек. Когда команда разрастается, появляется второй уровень управления, и руководителя уже называют не тимлидом, а менеджером 2-го уровня.

Что входит в область ответственности тимлида

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

Тимлид отвечает за:

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

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

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

Файловое хранилище и почта — базовые вещи для любой работы.

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

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

Wiki-система. Нужна для ведения организационных материалов, требований и базы знаний команды или компании в целом. Конкретный инструмент зависит от стандартов компании.

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

Отталкивайтесь от реальной потребности. Какой у вас workflow? Что вы хотите отслеживать? Какие процессы нужно визуализировать? Под эти требования и выбирайте инструмент.

Многие из них пришли из Scrum, но полезны независимо от выбранной методологии.

Daily-митинги. В идеале ежедневные, но если их проводит через день — тоже хорошо. Вы понимаете, чем занимается команда и в каком состоянии находятся задачи.

Практический вывод: Главное — проводить содержательно daily. Недостаточно по очереди озвучивать статусы. Нужно выявлять блокеры, проблемы, ожидания друг от друга. Часто на дейликах всплывает, что кто-то чего-то ждет от коллеги

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

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

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

Планирование. Заранее фиксируйте объём на ближайшую итерацию и какие главные цели должна достичь команда. Если не ставить перед ней цели, они не будут достигнуты.

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

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

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

Поделюсь принципами и практиками, которые я тоже использую в работе:

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

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

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

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

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

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

Эти ошибки сразу приходят мне в голову, когда речь идет об управлении IT-проектом, так как они приносят больше всего проблем.

Ошибочная стартовая оценка. Недооценка происходит по разным причинам. Команда не учла часть работ. Аналитики дали слишком оптимистичные прогнозы. Не заложили время на непредвиденные сложности. Результат один — вы не оправдываете ожиданий заказчика.

Практический вывод: Если при оценке проекта ошиблись больше чем на 25% в сторону недооценки, проект уже не спасти. Каким бы опытным ни был проект-менеджер, завершить работу в заложенных рамках не получится. Заказчик останется недоволен

Тщательная оценка на старте — это инвестиция, которая окупается многократно. Лучше потратить неделю на детальную оценку, чем потом 3 месяца объяснять, почему проект идет не по плану.

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

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

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

Пассивное наблюдение вместо действий. Я встречал проект-менеджеров, которые просто приходят на статус-митинг и слушают про проблемы команды, несделанные задачи и блокеры. Затем спрашивают: «Когда будет готово?» — и на этом их участие заканчивается.

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

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

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

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

→ Ключ к успеху лежит в осознанном комбинировании подходов, будь то строгий Waterfall или гибкий Agile , и в построении процессов, которые усиливают слаженность команды, а не сковывают ее бюрократией.

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

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

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

Выбор зависит от типа проекта:

Базовая команда включает: владельца продукта, аналитиков (бизнес и системных), разработчиков (frontend/backend), тестировщиков, DevOps-инженеров, технических писателей и управленческие роли (тимлид, проект- или delivery-менеджер). В небольших командах один человек может совмещать несколько ролей.

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

Три ключевые ошибки: