Управление ИТ-проектом: этапы, роли и типовые риски

Управление ИТ-проектом сводится к четырём вещам: договориться, что именно строим, разбить работу на проверяемые куски, назначить людей, которые принимают решения, и заранее назвать риски. Методология (классическая или гибкая) вторична. Проекты чаще ломаются не из-за выбора Scrum или каскада, а из-за размытых требований, отсутствия владельца со стороны заказчика и недоступных вовремя данных.

С чего начинается ИТ-проект на самом деле

До первой строчки кода у проекта должна быть цель, которую можно проверить. Фраза «нужен новый сайт» или «автоматизировать склад» целью не является. Цель звучит иначе: «менеджеры перестают вручную переносить заявки из почты в таблицу», «клиент видит статус заказа без звонка». Такую формулировку можно сверить с результатом, а значит, можно сказать, что проект удался или нет.

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

Этапы проекта: что должно быть на каждом

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

1. Инициация. Цель, границы, ответственные, примерный бюджет и срок как диапазон, а не как точка.
2. Анализ и постановка. Сбор требований, схема процесса «как есть» и «как должно быть», список интеграций и источников данных. Результат: документ, по которому можно оценивать работу.
3. Проектирование. Архитектура, макеты, структура данных, выбор технологий. Здесь же определяется, что будет первой версией.
4. Разработка по итерациям. Короткие отрезки с показом результата заказчику. Не «через три месяца покажем», а «через две недели вот рабочая часть».
5. Тестирование и приёмка. Сценарии проверки пишутся заранее, а не придумываются в день сдачи.
6. Запуск. План выкатки, план отката, ответственный за решение «запускаем или откладываем».
7. Сопровождение. Кто отвечает за исправления, кто за развитие, как фиксируются обращения.

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

Роли в проекте: кто за что отвечает

Типичная проблема, с которой я сталкиваюсь в проектах такого рода: у заказчика «все причастны», а решать некому. Минимальный набор ролей выглядит так.

• Владелец (спонсор) проекта. Утверждает бюджет и цели, разрешает конфликты приоритетов. Достаточно нескольких часов в месяц, но эти часы должны быть.
• Представитель заказчика (владелец продукта). Каждый день на связи, знает процесс изнутри, отвечает на вопросы за один рабочий день, принимает результаты.
• Руководитель проекта. Следит за сроками, рисками, коммуникацией. В малом проекте эту роль совмещает исполнитель, но совмещение нужно проговорить.
• Исполнители. Разработчики, аналитики, специалисты по 1С, администраторы инфраструктуры. На крупных задачах я привлекаю профильных экспертов, а не пытаюсь закрыть всё в одиночку.
• Пользователи. Те, кто будет работать в системе. Их мнение собирают до разработки и на приёмке, а не после запуска.

Важное правило: у каждой задачи один ответственный. «Ответственны Иван и Мария» на практике означает, что не ответственен никто.

Каскад, Agile или смесь: что выбрать

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

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

Короткий итерационный цикл выглядит так:

Планирование итерации (1-2 часа)
  -> Работа над задачами (1-2 недели)
  -> Демонстрация заказчику
  -> Разбор: что изменить в процессе и в приоритетах

Показ результата каждые одну-две недели ловит недопонимание на раннем этапе, когда исправление стоит дёшево.

Типовые риски и как с ними работать

Реестр рисков не должен быть формальностью на десять страниц. Достаточно таблицы в заметках (в виде списка): риск, вероятность, последствия, что делаем заранее, кто следит. Вот риски, которые встречаются чаще других.

• Расползание объёма. Каждое «заодно добавим» увеличивает срок. Лекарство: все новые пожелания идут в общий список, оцениваются отдельно, и заказчик сам выбирает, что убрать взамен.
• Нет доступа к данным и системам. Проект стоит, потому что ждёт выгрузку, права, тестовую среду. Доступы нужно запрашивать на этапе инициации, а не в день начала разработки.
• Зависимость от внешних сторон. Банки, провайдеры, разработчики смежных систем. Сроки их ответов вам неподконтрольны, поэтому такие работы начинают раньше и закладывают запас.
• Ключевой человек в единственном экземпляре. Если знание процесса или паролей у одного сотрудника, отпуск или болезнь останавливает проект. Знания документируются, доступы передаются по регламенту.
• Неверные ожидания от результата. Заказчик ожидал одно, получил другое. Снижается ранними демонстрациями и письменным описанием приёмки.
• Нереалистичные сроки. Если срок продиктован внешним событием, обсуждается объём первой версии, а не качество.

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

Как оценивать сроки и бюджет без самообмана

Точную стоимость и срок честно назвать можно только после анализа. До него уместен диапазон и перечень допущений. Хорошая оценка содержит три вещи: что входит, что не входит и от чего зависит цифра (например, от качества данных в старой системе или от скорости ответов третьих сторон).

Полезные приёмы:

• Разбивайте работу на задачи размером в несколько дней. Оценка крупных кусков почти всегда оптимистична.
• Закладывайте время на тестирование, исправления по замечаниям и ожидания. Это не запас «на всякий случай», а реальные часы.
• Пересматривайте оценку после каждой итерации. Если скорость отличается от плана, лучше узнать об этом на второй неделе, чем на десятой.
• Отделяйте обязательное от желательного. Если время поджимает, из проекта убирается желательное.

Приёмка и запуск: как не получить сюрприз

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

Перед запуском я проверяю короткий список:

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

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

Коммуникации: как не потерять договорённости

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

Частые вопросы

Нужен ли руководитель проекта в небольшом проекте?

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

Как понять, что проект идёт не по плану?

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

Что делать, если требования постоянно меняются?

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

Кто должен принимать работу: руководитель или пользователи?

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

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