Базовые принципы управления IT-проектами: что должен знать каждый тимлид

Kaiten

Управляйте задачами, проектами и командой в одном месте

Попробовать бесплатно

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

Меня зовут Артём Харченков. Я Java-lead и руководитель разработки с опытом более 13 лет. В этой статье я структурно разберу основы управления IT-проектом. Поговорим о ключевых моментах: от выбора методологии до борьбы с типичными ошибками тимлидов.

Начну с неочевидных отличий IT-проектов от проектов в других сферах

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

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

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

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

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

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

Руководителю приходится балансировать между необходимостью поддерживать здоровую атмосферу в команде и пониманием, что расставание с проблемным, но ценным специалистом может серьезно затормозить проект»,

Артём Харченков, руководитель Java-разработки в «Кросстех Солюшнс Групп».

Управление IT-проектом изнутри: из каких этапов оно состоит и на какие методы опирается

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

Водопадная методология

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

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

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

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

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

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

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

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

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

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

9. Запуск. Решение переводят в промышленную эксплуатацию.

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

Гибкие подходы

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

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

1. Команда ставит гипотезу.
2. Собирает минимально жизнеспособный продукт.
3. Выпускает его на рынок.
4. Смотрит на реакцию пользователей.
5. Корректирует план разработки на основе обратной связи и оптимизирует процессы на основе ретроспектив.

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

Выбрать подход к управлению проектами в IT-сфере не так просто

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

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

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

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

Как же тогда выбрать подход

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

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

Артём Харченков, руководитель Java-разработки в «Кросстех Солюшнс Групп».

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

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

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

Про команду: какие специалисты вам нужны для любого IT-проекта

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

• Владелец продукта или заказчик. Тот, кто заинтересован в развитии продукта и выступает в роли основного стейкхолдера. В продуктовой разработке это владелец продукта, в заказной — заказчик или его представитель.
• Бизнес-аналитики. Прорабатывают верхнеуровневые требования, описывают гипотезы с рынка, переводят бизнес-потребности в требования к продукту.
• Системные аналитики. Ставят задачи разработчикам. Описывают на системном языке, как именно должна работать функциональность.
• Тестировщики. Бывают ручные тестировщики, которые проверяют функциональность вручную. Автотестировщики пишут автоматические тесты. Нагрузочные тестировщики проверяют, как система ведет себя под высокой нагрузкой.
• Тестировщики. Бывают ручные тестировщики, которые проверяют функциональность вручную. Автотестировщики пишут автоматические тесты. Нагрузочные тестировщики проверяют, как система ведет себя под высокой нагрузкой.
• Разработчики. Делятся на фронтенд-разработчиков и бэкенд-разработчиков. Первые создают пользовательский интерфейс, вторые — серверную логику.
• DevOps-инженеры. Отвечают за сборку и поставку продукта. Настраивают тестовые стенды, развертывают приложение на production, восстанавливают его после сбоев.
• Технические писатели. Описывают функциональность, ведут документацию, создают руководства пользователя и администратора.
• Проект-менеджер, delivery-менеджер, тимлид. В зависимости от размера команды и сложности проекта нужны управленческие роли. Проект-менеджер управляет проектом, у которого есть начало и конец. Delivery-менеджер ведет продуктовую разработку. Тимлид руководит командой.
• Технический лидер. Отвечает за техническую сторону: архитектуру, code review, технические решения.
• Дизайнеры (опционально). UI/UX-дизайнеры создают внешний вид интерфейсов. Эта роль нужна не во всех проектах — иногда разработка ведется на фреймворках без сложного дизайна или система вообще без графического интерфейса.

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

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

Артём Харченков, руководитель Java-разработки в «Кросстех Солюшнс Групп».

Как правильно сформировать команду

Здесь тоже нет одного верного ответа. Показал 2 сценария в таблице:

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

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

Роль тимлида в управлении IT-проектами

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

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

Что входит в зону ответственности тимлида

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

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

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

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

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

Артём Харченков, руководитель Java-разработки в «Кросстех Солюшнс Групп».

Какие IT-инструменты помогут тимлиду в работе

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

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

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

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

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

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

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

Успешные компании уже используют Kaiten Попробуйте расширенный функционал на своем проекте бесплатно

Попробовать

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

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

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

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

Артём Харченков, руководитель Java-разработки в «Кросстех Солюшнс Групп».

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

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

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

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

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

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

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

Артём Харченков, руководитель Java-разработки в «Кросстех Солюшнс Групп».

Какие еще практики помогают мне повысить эффективность команды

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

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

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

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

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

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

Артём Харченков, руководитель Java-разработки в «Кросстех Солюшнс Групп».

Почему я считаю эти практики полезными

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

Напоследок 3 ошибки, из-за которых IT-проект может свернуть сильно не туда

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

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

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

Артём Харченков, руководитель Java-разработки в «Кросстех Солюшнс Групп».

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

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

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

Артём Харченков, руководитель Java-разработки в «Кросстех Солюшнс Групп».

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

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

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

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

Артём Харченков, руководитель Java-разработки в «Кросстех Солюшнс Групп».

Ключевые мысли статьи

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

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

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

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

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