В эпоху 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)
мне вот всегда было интересно: а как при гибкой методологии, при разработке непродуктовых решений (не с нуля, а доработке какой-либо платформы), оценивать адекватно стоимость?
все прекрасно в итеративном подходе, кроме того, что невозможно объективно оценить сроки, а соответственно и стоимость грядущего проекта. в то же время, заказчик всегда имеет фиксированный бюджет, который крайне нежелательно расширять. все конкурсы проводятся с фиксированным бюджетом и сроком, весь подбор подрядчиков производится с учетом стоимости и сроков.
что мы имеем в сухом остатке: мы делали, делали, переделывали, достигли за установленный срок идеальных результатов, но… реализовали всего 10% от заказанной функциональности.
это ли не провал? почему этот разрыв всегда тактично обходится при навязывании итеративного подхода? почему все так старательно замалчивают эту область?
может это только я такой глупец и просто не умею готовить аджайл и иные вариации методологии гибкой разработки?