Портал №1 по управлению цифровыми
и информационными технологиями

В чём причины провалов ИТ-проектов

В эпоху Agile, DevOps и других управленческих техник, неужели мы все еще сталкиваемся с провалами ИТ-проектов? К сожалению, да.

В прошлом, неудачи в ИТ, как правило, означали серьёзные материальные издержки, когда масштабные проекты по внедрению ПО реализовывались слишком медленно и сильно выходили за рамки бюджета. И такие ситуации происходят до сих пор. Пример: IBM так и не завершила модернизацию стоимостью 110 миллионов долларов США для системы пособий по безработице в штате Пенсильвания.

Но ИТ-неудачи сегодня зачастую отличаются от тех, что были в прошлом, поскольку Agile, DevOps, непрерывная поставка (continuous delivery) и отказоустойчивые изменения привели к переменам в подходе к разработке ИТ-проектов. Эти итеративные методологии и философии призваны свести к минимуму вероятность появления крайне неудачных проектов, но факт в том, что ИТ-проекты всё ещё терпят фиаско, только уже в новых и иногда гораздо более коварных аспектах.

Говоря о деньгах, в том же отчете установлено, что из-за неэффективных проектов организации тратят в среднем 97 миллионов долларов на каждый инвестированный 1 миллиард долларов. Этот показатель лучше, чем в 2016 году – 122 миллиона долларов потерь, но всё еще представляет собой значительную величину.

Факторы отказа

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

Компания PwC в своём исследовании 2017 Global Digital IQ Survey задавала вопрос о том, что мешает цифровым преобразованиям. В опросе приняли участие 2216 бизнес- и ИТ-лидеров из 53 стран. Около 64% респондентов заявили, что виноват недостаток совместной работы ИТ и бизнеса, 58% указали на негибкие или медленные процессы, 41% отметил отсутствие интеграции новых и существующих технологий, 38% винят устаревшие технологии и 37% отсутствие квалифицированных команд.

В исследовании были определены организации, 80 и более процентов проектов которых были завершены вовремя и уложились в бюджет, а также соответствовали первоначальным целям и задачам бизнеса; они были классифицированы как «чемпионы». В отчете также подчеркивался тот факт, что чемпионы инвестировали в несколько смежных областей, включая лидерские навыки специалистов проекта, управление реализацией преимуществ, проектный офис, активное вовлечение руководства и практики Agile.

Agile и автоматизация в помощь?

Некоторые направления, в частности, методологии Agile и DevOps, помогают снизить вероятность неудач проектов в современных ИТ-компаниях.

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

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

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

«Быстрый» сбой, как инструмент

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

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

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

Риски провала остаются

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

Существуют потенциальные проблемы, связанные с Agile и DevOps-методологиями. Вы решаете небольшие задачи, где крупные проблемы не видны до тех пор, пока нет соответствующего масштаба. Затем, при переходе к разработке больших интегрированных систем, они появляются во весь рост.

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

Убирание стен между бизнес-подразделениями и ИТ может также увеличить риски неудачи проекта, поскольку руководители бизнес-подразделений используют технологии и стремятся извлечь выгоду из последних и крупнейших, независимо от того, полностью ли понимают принципы их использования и тщательно ли проверяют свои возможности. Всё больше и больше трат на ИТ приходится на бюджеты бизнес-подразделений, а не ИТ. Согласно отчёту PWC 2015 Global Digital IQ Survey 68 процентов расходов на технологии приходится на не ИТ-бюджеты.

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

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

На основе Why IT projects still fail, Мэри К. Пратт (Mary K. Pratt)

«Трансформация ИТ в традиционных компаниях»
Учебный курс о кратном ускорении за счёт новой организации работы

Комментариев: 7

  • Игорь

    мне вот всегда было интересно: а как при гибкой методологии, при разработке непродуктовых решений (не с нуля, а доработке какой-либо платформы), оценивать адекватно стоимость?

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

    что мы имеем в сухом остатке: мы делали, делали, переделывали, достигли за установленный срок идеальных результатов, но… реализовали всего 10% от заказанной функциональности.

    это ли не провал? почему этот разрыв всегда тактично обходится при навязывании итеративного подхода? почему все так старательно замалчивают эту область?

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

    • Игорь, я понимаю откуда берётся Ваш вопрос. Сама заметка к нему подводит. Это хорошо, что на портале стали появляться такие провокации, помогают думать.
      В моей картине мира (не претендую на истину) всё довольно просто. Словосочетание “проект по Agile” является оксюмороном, примерно как “живой труп” или “вежливое хамство”. Не бывает проектов по Agile. Никогда и никаких. И тем более не бывает управления проектами по Agile.
      В теме, которую Вы поднимаете, главное расхождение заключается в принципе финансирования. Конкурсы, провалы проектов, IBM снова не справились и прочее – это финансирование проектов. Дали определённых денег чтобы получить в конечный срок чётко специфицированный результат.
      В Agile же финансирование продуктов. Начали давать деньги отсюда и пока интересно на создание примерно такого продукта в ближайшие примерно 6-12 месяцев. Дорогу поймём по ходу движения, на скорость выйдем постепенно, исходя из новой, постоянно появляющейся информации будем корректировать и продукт, и способы работы.

      • Ольга

        Олег, не поясните, почему “Не бывает проектов по Agile. Никогда и никаких. И тем более не бывает управления проектами по Agile”? Есть ведь даже компании, проводящие курсы Agile Project Management, вроде и международные сертификаты ICAgile Certified Professional – Agile Project Management (ICP-APM) выдают. На всякий случай: вопрос без провокаций 🙂

        • Ольга, я опираюсь на своё субъективное и, скорее всего, искажённое понимание реальности. Это понимание, в частности, складывается из истории возникновения Agile, Agile Alliance, Scrum и далее по списку вплоть до SAFe и проч.
          Там ведь как – есть официальная версия, и это больше маркетинговые тексты, направленные на пропаганду или продажу чего-либо. А есть то, что, судя по всему, случилось в реальности, и оно немного другое. Вот Роберт Мартин, один из авторов манифеста, вспоминает примерно так (привожу по памяти):
          Мы устали от водопада и потому сформулировали некоторые принципы “как можно иначе”. Написали манифест, сделали страничку, и удивились множеству сторонников. Тогда мы сделали Agile Alliance, чтобы продвигать идею (Роберт был первым председателем). А следующим председателем стал Кен Швабер, и он уже решил, что это отличный способ заработать. Сделал курс “Certified Scrum Master Class” – и народ повалил. И чем выше были цены, тем выше был спрос. Почему бы не сделать экзамены и сертификацию? Так появился Scrum Alliance. Кто же побежал на эти курсы и экзамены? Нет, не разработчики ПО. Побежали менеджеры проектов. Потому что они а) боялись остаться без работы, б) нуждались в чём-то новом, отличающим их от других. Оставаясь при этом функционерами. В то время как Scrum Master – полная противоположность менеджеру проекта. Но это размывается, так как машина по зарабатыванию денег работает исключительно хорошо и ориентирована на спрос.
          Вот так, на мой взгляд, идея финансирования продуктов возвращается к идее финансирования проектов. То, как устроено финансирование, сильно влияет на остальные принимаемые решения.
          Опять же, возможно, что я очень неправильно понимаю светлые идеи, и Agile – это про управление проектами 🙂

        • Игорь

          соглашусь во многом с Олегом и его пониманием. кроме одного нюанса: проектом может быть разработка продукта, проектом без фиксированного срока. если, конечно, упираться в суть определения термина “проект”, то тогда да, Олег бесспорно прав. однако продуктовая разработка тоже может быть проектом, проектом, в котором срок определяет объем финансирования, стартапы примерно так работают: есть деньги – работаем, нет денег – сворачиваемся и разбегаемся.

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

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

  • Андрей

    На 200% поддерживаю Олега. Сегодня только дискутировали на данную тему с коллегами. Когда строим линкор или космический корабль – аджайл слабо подходит – продукт имеет четкий скоуп и оценку стоимости. При этом если говорить об ИТ-среде, в частности программной разработке, тут больше гибкости и изменений в требованиях, желаниях со временем.
    Итог – все, где создается “железное” (сиречь физическое) решение – больше склонно к управлению проектами, тогда как “софтверное” (сиречь “интеллектуальное”) – гибко и аджайлово.
    И как высказался в статье мой бывший руководитель – банки без “банков” могут быть, а вот трубы без заводов – пока еще нет)

    • Сергей

      Андрей, есть достаточно примеров, когда и железное создаётся по принципам Agile.
      IMHO: если мы однозначно понимаем необходимый конечный продукт и полностью понимаем технологию его получения – (вероятно) лучше Waterfall. Когда этого нет – (вероятно) лучше Agile.
      И неважно, готовишь ты ПО или не ПО – в условиях неопределённости с Agile’ом (вероятно) ты раньше вернёшься на правильный курс, получишь продукт, сэкономишь и т.п.

      Согласен с Олегом, что большинство сертификаций по Agile, DevOps – не более чем возможность заработать денег на шумихе вокруг этой темы.
      Любой сотрудник, руководитель с головой понимает это. Но он также понимает и преимущества/обоснованность Agile.
      Например, вот хорошая статья на эту тему: http://hbr-russia.ru/management/upravlenie-izmeneniyami/a23661/

      Также, как человек давно знакомый с Agile применительно к разработке ПО, советую бородатую (но актуальную) книгу для понимания Agile.
      https://www.ozon.ru/context/detail/id/1315535/
      Ценность книги в том, что в ней описаны/раскрыты основные принципы (психологические, социальные, организационные), которые объясняют, почему гибкая (Agile) разработка ПО полезная вещь. Где книга тяжела, смело прилистывать – главного не упустите)


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM