Авторы: Алексей Янчук, Константин Кондратюк

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

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

А с точки зрения бизнес-процесса? Тут успех тоже якобы очевиден: новое средство автоматизации запущено и работает в допустимых рамках.
Мы не будем сильно оригинальны, указав на то, что большинство коллег в программной индустрии путаются в двух понятиях: целях и задачах. Нам часто приходится слышать, что целью проекта является поставка заказчику программного продукта. Увы, это не совсем точное и тем более не полное определение. Что представляет собой полный жизненный цикл любого ИТ-решения? Не вдаваясь в подробности, его можно разбить на четыре этапа:

1. Задумка: определение, чем ИТ-решение может помочь потенциальным пользователям;

2. Проектирование: составление требований и выработка решения, удовлетворяющая им;

3. Эксплуатирование: извлечение той пользы, ради которой решение задумывалось;

4. Списание: выведение решения из эксплуатации.

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

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

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

Вот и получается, что поставленные задачи выполнены на крепкую ”четверку” с плюсом, а цель оказалась безнадежно упущена. Когда это становится очевидным, кого-то, кто руководил проектом, вызовут дать объяснения, как вообще такое произошло, и кто за весь этот хаос должен отвечать. Два извечных вопроса: можно ли было что-то предпринять раньше, и если нет, то как выходить из такой ситуации?

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