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

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

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

1. Почему нельзя полагаться на цифры и статусы

Для начала несколько примеров ключевых параметров IT-проекта:

Реальный статус параметра, это тот, который можно проверить: сдано пользователю (подписан протокол тестовых испытаний), введено в эксплуатацию (акт приема/передачи). Но на этапе доработок тоже надо контролировать процесс. Как? Статус от поставщика решения – это иллюзия контроля.

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

Руководители проекта (РП) с обеих сторон с своих отчетах нередко маскируют реальность. И это также затуманивает реальное положение дел на разных этапах.

• Когда ведется подготовка документации, разработка и тестирование системы, неважно, сколько процентов указано в отчетах. Эти цифры могут быть взяты с потолка, их невозможно проверить изолированно и главное, они не имеют самостоятельной ценности.
• Когда ТЗ сдано и подписано заказчиком, возникает риск, что пользователь, подтверждая исполнение части работы, не примет всю работу целиком. Тогда в дельнейшем переделывать придется и первую (якобы сданную) часть тоже.

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

2. Дисбаланс в выборе IT-решений

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

• Какие направления деятельности проект затрагивает?
• От каких направлений бизнеса зависят автоматизируемые участки?
• Как рамки проекта покрывают структуру департаментов, филиальную сеть?

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

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

• Зрелые бизнес-процессы (регламентированность деятельности подразделений, их взаимодействия, формализация ответственности).
• Наличие IT-стратегии.
• SLA с бизнесом (Service Level Agreement, Соглашение об уровне обслуживания).
• Соответствие уровня внедряемого ПО и используемого ПО (производитель, доля рынка, функциональные возможности, стоимость владения).
• Соответствие уровня выбранного вендора и уровня компании (бюджет вашего проекта не должен равняться годовому обороту вендора).

Маркеры того, что проект шире, чем кажется:

• Полностью не покрыта функциональная область. Например, не проработаны взаимосвязи операционной деятельности и отчетности (управленческой, бухгалтерской).
• В договоре на внедрение не отражена стоимость интеграции в существующую IT-инфраструктуру.
• Временные рамки первых трех частей (формализация требований/доработки/ввод в эксплуатацию) заданы с существенным отклонением от пропорции 35%/45%/20%. Это условный критерий, но если проект рассчитан на шесть-восемь месяцев, а обследование заняло всего две недели – вспомните, что дьявол кроется в деталях.

Также полезно помнить о том, что технологически практически любой IT-проект состоит не из трех, а из четырех основных этапов:

• Обследование/Формализация требований.
• Внедрение/Разработка.
• Ввод в эксплуатацию (развертывание).
• Сервис (дальнейшее сопровождение + доработки).

Договаривайтесь «на берегу» по всем четырем этапам сразу.

3. Что на самом деле нужно РП, когда он просит полномочий

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

Почему я так считаю? Команда проекта состоит из топ-менеджеров. Все остальные (консультанты, программисты, бухгалтера, менеджеры по закупкам, кладовщики) – это только руки. Чтобы РП проекта (например, по внедрению систем класса ERP) был эффективным, ему нужно видеть потребности топов, потому что изменение бизнес-процессов только в их власти. И именно поэтому, РП нужны не полномочия, а вовлеченность тех, у кого эти полномочия есть.

Пример правильно организованного проекта: регулярный проектный комитет, наличие ТЭО (технико-экономического обоснования), зафиксированные исчисляемые бизнес цели и регулярное обновление статусов по ним.

4. IT не драйвер бизнеса, а следствие развития бизнеса

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

В обратном порядке это, как правило, не работает. Потому что самый лучший IT-инструмент в отрыве от реального бизнеса ничего не улучшает. Без проблематики, сформулированной бизнесом, ресурсы IT могут и скорее всего будут направлены не на проблемные участки, а туда где их использовать проще или интереснее, но не обязательно – туда, где наиболее выгодно.

Кстати, эти же соображения дают ключ к ответу на вопрос что лучше – развивать уже имеющееся ПО (программное обеспечение) или разрабатывать «с нуля под ключ»?

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

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

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

5. Чем ТЗ отличается от постановки задачи

Бизнес не мыслит в категориях IT. Прием товара на склад – не то же самое, что и оформление накладной в системе учета. Бизнес-объекты это проводки по счетам, накладные, индексы, а вовсе не таблицы, формы, отчеты.

Примеры KPI в IT:

• Количество транзакций.
• Список форм ввода.
• Количество строк в закупке.

Пример KPI в бизнесе:

• Области автоматизации (бухучет, управленческий учет, склад, закупки).
• Список бизнес процессов.
• Скорость обработки данных (например, регистрация прихода не более 5 минут).
• Время репликации данных по всем системам (отделениям) компании.

Поэтому:

• Технические «айтишные» ТЗ не годятся для формализации задач бизнеса. Они оперируют другими категориями.
• На этапе постановки задачи со стороны заказчика должны быть только ключевые пользователи.
• Сотрудники IT-департамента (консультант, архитектор) должны выступать только аудиторами процесса внедрения для снижения риска ошибок со стороны поставщика решения.

Функциональные требования (ФТ) не помогут без:

• контрольных примеров, они же use-cases,
• описания бизнес-процессов (с формализацией ответственного за каждую операцию, входных/выходных параметров).

6. Когда Scrum приводит к хаосу вместо порядка

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

Как понять, что лучше в конкретном случае? Чего бы не говорили «гуру от сохи», определяющим в выборе методологии внедрения/разработки является возможность зафиксировать требования. Не формализовать, а именно зафиксировать. Например, если ожидается, что количество изменений за срок внедрения составит меньше 20-30% от общего объема работ, лучше выбрать Waterflow. Если изменений будет больше, стоит серьезно рассмотреть методы итеративного программирования.