Продолжает ли еще существовать такое понятие, как провал ИТ-проекта, в эпоху agile-разработки, DevOps и новых методов управления? Увы, да.
В прошлом провалы ИТ-инициатив выражались в сильном перерасходе средств, когда реализация крупномасштабных программных систем длилась гораздо дольше, чем было запланировано. Такого рода провалы могут происходить и происходят по-прежнему. Недавний пример – проект IBM, предусматривавший модернизацию системы учета пособий по безработице в Пенсильвании, обошедшийся в 110 млн долл. и так и не завершенный.
Но сегодня провалы ИТ-инициатив отличаются от провалов прежних времен, так как agile-методы, DevOps, непрерывная доставка и принцип мгновенной регистрации сбоя (fail-fast) изменили способы осуществления проектов. Современные итеративные методики управления призваны свести к минимуму шансы масштабных провалов, однако провалы по-прежнему происходят, причем по-новому и иногда даже с еще более неприятными последствиями.
Вот что думают эксперты о современном положении дел с провалами ИТ-инициатив.
История-предостережение
В одной компании в течение полутора лет внедряли SaaS-систему управления взаимоотношениями с клиентами, при этом сотрудники ИТ-службы поддерживали контакт с руководством отдела продаж, чтобы разобраться в потребностях бизнеса и определиться с требованиями.
В отделе ИТ были уверены, что добились необходимой степени участия заинтересованных лиц и поняли, какой результат желателен, однако, когда проект был завершен, специалисты по продажам его не приняли и наотрез отказались работать с системой. В итоге облачную систему CRM объявили неудачной и отказались от нее. Вывод: даже когда проекты укладываются в график и бюджет, они независимо от широты предоставленного функционала могут окончиться провалом, если не дадут тех результатов, на которые рассчитывают конечные пользователи.
Даже когда проекты укладываются в график и бюджет, они независимо от широты предоставленного функционала могут окончиться провалом, если не дадут тех результатов, на которые рассчитывают конечные пользователи
По мнению участников проекта, успех был бы более вероятен, если бы в службе ИТ, теснее объединив усилия с бизнесом, больше сосредоточились на пропаганде преимуществ новой системы, чем на ее реализации.
Этот провал – далеко не единственный. Согласно отчету Project Management Institute от 2017 года, подготовленному по результатам опроса 3 тыс. специалистов по управлению проектами, 28% стратегических инициатив, которыми они руководили, оказались абсолютно провальными. Примерно 37% опрошенных причинами провала назвали отсутствие четко определенных и достижимых вех и задач, используемых в качестве оценки степени завершения проекта. Далее в ряду причин шли нехватка информационного обмена (19%), отсутствие откликов от высшего руководства (18%), сопротивление сотрудников (14%) и недостаточное финансирование (9%).
Исследование также выявило, что из-за неудач потери на каждый вложенный в проекты миллиард долларов сейчас составляют в среднем 97 млн долл., а годом раньше – 122 млн долл.
Факторы, ведущие к провалу
Несмотря на новые методологии, призванные предотвратить неудачи, многие факторы, традиционно ставившие проекты под угрозу, по-прежнему присутствуют на предприятиях. К провалу проекта могут привести недостаток ресурсов, чересчур сжатые сроки, недооценка затрат, упущенные из виду требования, непредвиденные осложнения, непрофессиональное руководство и ошибки человека, в том числе в коде.
В рамках исследования Global Digital IQ Survey, проведенного компанией PwC в 2017 году, были опрошены более 2 тыс. бизнес- и ИТ-руководителей, вопросы касались факторов, сдерживающих цифровую трансформацию. Около 64% опрошенных указали на отсутствие взаимодействия между службой ИТ и бизнесом, 58% – на негибкость и медлительность процессов, 41% – на отсутствие интеграции между новыми и существующими технологиями, 38% – на устаревшие технологии, а 37% – на недостаточную квалификацию проектных команд.
Между тем критерии оценки успеха или провала проекта расширяются, отражая значимость современных технологических инициатив. Так, в отчете PMI говорится: «Определение успеха сегодня меняется: большое значение приобретает то, удалось ли в результате осуществления проекта получить ожидаемые преимущества». К числу лидеров по уровню успеха авторы отнесли организации, которым удается 80% проектов завершать вовремя, в рамках бюджета и с выполнением первоначальных целей и задач бизнеса. В отчете также отмечается, что в таких организациях инвестируют в определенные области, такие как наем специалистов по управлению проектом с высокими лидерскими качествами, управление реализацией преимуществ, создание центров управления проектами и внедрение agile-методов.
По оценке аналитика IDC Стивена Эллиота, сегодня 30-35% ИТ-проектов можно считать провальными, и многие неудачи связаны с изменениями целей и приоритетов бизнеса. Это значит, что сама технология работает нормально, но не обеспечивает результатов, которых на момент завершения проекта ожидает бизнес. В таких случаях причина потопления ИТ-проектов связана с отсутствием эффективного обмена информацией и взаимодействия – «когда бизнес-решения принимаются, но не передаются».
В современном клиентоориентированном мире провал можно определить как потерю репутации или выручки компании, добавляет аналитик: «Провалы по-прежнему могут случаться, но связаны больше с бизнес-процессами, чем с техническими ошибками, когда, например, кто-то не проверил настройки главного маршрутизатора».
В других случаях проект может уложиться в срок и бюджет, но это не имеет значения, если он не дает результатов, ожидаемых клиентами или пользователями.
.jpg)
Спасение – в agile и автоматизации?
Некоторые тенденции, особенно переход на agile и DevOps, помогают уменьшить вероятность глобальных провалов в современных ИТ-отделах.
«Теоретически новый способ написания кода небольшими фрагментами, автоматизация тестирования и повторение циклов, пока не будет достигнуто нужное качество, обеспечивают определенную страховку, – говорит Эллиот. – Вы чаще выполняете проверку на ошибки, поэтому результат должен быть лучше. Можно быстрее разрабатывать новые функции и уменьшать вероятность неудач».
Этому же способствует рост автоматизации разработки и тестирования. Как отмечает аналитик, большинство провалов сегодня по-прежнему обусловлены ошибками человека: неудачным кодом, неверными настройками сети, плохой балансировкой нагрузки. С учетом уровня сложности современных систем, ошибки неизбежны. Но по мере роста степени автоматизации число ошибок человека должно уменьшаться, особенно в скриптах для развертывания приложений и конфигурирования сетей.
Снизить риск помогут также изменения организационной иерархии. Руководители различных отделений должны работать в партнерстве, действовать быстро и вносить изменения «на лету»; по свидетельству аналитиков, в лидирующих компаниях, чтобы добиться такой слаженности, проектным командам предоставляют больше свободы в корректировке курса. Существенное отличие от проектов 20-летней давности заключается в том, что сегодня требования могут переопределяться в ходе проекта.
Ограничить риск провала можно, фокусируясь на ожидаемых от проекта результатах. Согласно принципам DevOps, работа разбивается на небольшие этапы, в рамках которых проблемы могут быть обнаружены быстрее; проводятся пилотные внедрения, позволяющие безопасно выявлять недостатки новых идей и осуществлять инновацию без большого влияния на бизнес. Кроме того, ИТ- и бизнес-руководители должны более четко разъяснять цели проекта и то, к чему он не должен привести.
Польза от неудач
Тенденция изменения самого отношения к провалам помогает менять и отношение к рискам. «Сегодня провал – это норма, если вы извлекаете из него урок, – подчеркивает Эллиот. – Есть компании, в которых провалы ценят, если благодаря им происходят улучшения за счет того, что исполнители учатся на ошибках».
Разумеется, в таких организациях также активно работают над тем, чтобы снизить риск масштабных провалов, пользуясь средами-«песочницами», пилотными внедрениями и методами итеративной разработки для ограничения ущерба, возможного в случае упущений.
Это дает положительные результаты, но нужно понимать, в каких случаях провалы допустимы, а в каких – нет. Когда, к примеру, в колледже Westmont внедряли новую платформу управления процессом приема абитуриентов, провал, выразившийся в невыполнении требований пользователей или в срыве сроков сдачи, был бы недопустим. В итоге систему успешно запустили летом 2015 года. Другой проект предусматривал развертывание социальной сети для выпускников. Попытка создать защищенную и удобную для пользователей платформу провалилась: были проблемы с аутентификацией пользователей и заполнением профилей. Но руководители проекта признают, что в провале были свои плюсы, поскольку за два года, пока шел проект, было извлечено немало уроков, в частности, связанных с обеспечением баланса безопасности и удобства использования. Новые знания были задействованы при сотрудничестве с внешним исполнителем, который в итоге блестяще справился с созданием системы.
Многие рассматривают готовность к провалам как ключевой фактор, подстегивающий инновации и способствующий сохранению конкурентоспособности. Постоянное обучение и совершенствование неизбежны без неудач, поэтому нужно отходить от разработки по методу водопада и осуществлять проект небольшими группами, обеспечивающими непрерывный выпуск мелких новшеств, чтобы масштабы провалов, когда они происходят, не были катастрофическими.
Риск провала сохраняется
Новые тенденции организации разработки, разумеется, не гарантируют успеха и не защищают от провала. Более того, некоторые особенности современных отделов ИТ способны даже усугубить вероятность проблем, могущих потопить проект.
Взять, к примеру, agile и DevOps: вы решаете небольшие задачи, а затем строите крупные интегрированные системы, в которых глобальные проблемы не видны, пока не будет достигнут определенный масштаб. Может оказаться, что новые функции ПО по отдельности действуют, но когда приложение развернуто целиком, в комплексе оно не работоспособно.
Риск провала проекта может возрасти также из-за размывания границ между бизнес-подразделениями и ИТ-службой, поскольку бизнес-руководители начинают осваивать технологии и стараются пользоваться возможностями самых новых, не всегда хорошо разбираясь в них и не проводя анализа альтернатив.
Как подчеркивают в PwC, в последнее время затраты бизнес-подразделений на ИТ растут быстрее, чем в самих отделах ИТ. Согласно исследованию PwC Global Digital IQ за 2015 год, 68% расходов на ИТ поступают не из бюджета ИТ-служб.
Сегодня бизнес-руководители, стремясь действовать быстрее и более целенаправленно, самостоятельно заключают договоры с провайдерами SaaS и операторами облаков. Облачные сервисы ускорили доступ к новым технологиям, но они же становятся причинами провалов. Приобретая облачные продукты самостоятельно, бизнес-руководители затем выясняют, что им нужен доступ к корпоративным данным или каким-то элементам инфраструктуры ИТ, вследствие чего проект затормаживается, отменяется или подвергается перепланированию.
Судя по аналогичным исследованиям PwC за последние три года, главная причина провала проектов – «негибкие или медленные процессы». Среди других распространенных причин – отсутствие квалифицированной команды и проблемы с третьими сторонами.
И хотя усовершенствование инфраструктуры ИТ, особенно оборудования, помогает уменьшить риск катастрофических неудач, по-прежнему существуют унаследованные системы, технический долг и ручные процессы, в которых ошибки различных масштабов могут привести к провалу проекта уже после ввода в эксплуатацию.
«Риск все еще есть, – напоминает Эллиот. – Даже если новое приложение нормально работает, когда его вводят в общую среду со сложной паутиной новых и старых технологий, могут возникнуть проблемы. Из-за того что приложения глобального масштаба работают на оборудовании третьих сторон, сбои возможны где угодно».
Следует также соблюдать предельную осмотрительность, поскольку в конечном счете в случае провала проекта, независимо от реальной причины, виновником неудачи будут считать службу ИТ.
− Mary K. Pratt. Why IT projects still fail. CIO. August 1, 2017