20 лет на месте: почему ИТ‑проекты продолжают проваливаться

По данным Standish Group (CHAOS Report) - одного из самых авторитетных источников в ИТ-среде - лишь треть ИТ-проектов завершаются успешно. Остальные либо срываются по срокам, бюджету и не реализуют ключевую функциональность, либо вообще не доходят до запуска.

Что еще более и по-настоящему тревожно - эта статистика не меняется уже более 20 лет.

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

Компетенции выросли. Бюджеты выросли. А вероятность запустить успешный проект - нет.

Если десятилетия инвестиций, обучения и технологий не изменили картину - возможно, мы не туда копаем? Решаем не ту проблему? Смотрим не в ту сторону?

По результатам одного из исследований Standish Group были выделены ключевые факторы успеха ИТ-проекта:

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

Действительно:

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

И когда что-то идёт не так, виноват всегда тот, кто «должен был это предусмотреть», т.е. Подрядчик.

Такое положение вещей не могло не повлиять на рынок: он неосознанно подстроился под эти правила игры.

На этапе продаж Подрядчики обещают сделать всё в лучшем виде. А что им делать?

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

Все шаблонные объяснения по типу: «Мы всё сделали по ТЗ», «Это нужно оформлять как отдельную доработку», «Просто скажите, как именно вы хотите — мы всё сделаем»…Заказчик услышит гораздо позднее и придраться не сможет.

В итоге все друг другом недовольны: Заказчик будет думать, что Подрядчик некомпетентен, а ИТ-специалисты снова утвердятся в мысли, что «эти Заказчики сами не знают, чего хотят».

Это стало нормой настолько давно, что никто уже и не думает, что может быть иначе.

Есть предприниматели, которые строят бизнес через маркетинг, упаковку и масштаб. А есть те, кто вырастает из продукта и часто (иногда излишне) переживают за качество. Я из вторых.

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

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

Занимаясь преимущественно внедрением 1С, я долго думал, что описанные выше факторы (участие сотрудников и руководства, качество требований) особенно остро проявляются именно в этой области. В конце концов, стейкхолдеров в ERP больше, чем где бы то ни было.

Однако, когда 7 лет назад мы пошли сначала в интеграции, а затем и в полноценное внедрение «под ключ» иных систем (интернет-площадок, CRM-систем, B2B-порталов и др.), я понял: проблема универсальна.

Из сотен реализованных проектов у меня сложилась личная статистика:

Несколько лет назад, придя к мысли, что качество проекта зависит прежде всего от самого Заказчика, я понял – существующие методологии влияют на это лишь косвенно.

Если представить систему измерения, где любой проект может получить максимум 100 баллов успешности, Подрядчик, каким бы он ни был, может вложить лишь 30 баллов, а оставшиеся 70 - на стороне Заказчика.

Я задал себе вопрос: «Из чего состоят те самые 70 баллов, за которые отвечает Заказчик?». Что именно должна создавать новая, обновлённая методология, чтобы без иллюзий и формализмов действительно двигать проект вперёд?

Я начал, как и полагается аналитику, с формулировки требований: Что именно должно создаваться в поведении, участии и восприятии проекта со стороны Заказчика, чтобы кардинально повысит шансы на успех?

Давайте разберемся.

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

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

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

Методология должна формировать именно такое восприятие — когда проект ощущается как важное, нужное, своё. Когда хочется участвовать, потому что понятно, зачем.

Руководители со стороны Заказчика обычно действительно включены в проект: проводят совещания, контролируют подрядчика - в конце концов, они платят за всё это деньги.

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

Энергия уходит на внешнее давление, а внутренние причины сбоев - не затрагиваются.

Проект движется, совещания идут, но ключевые проблемы остаются не решены.

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

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

До самого запуска сотрудники почти не вникают в то, как устроена система, несмотря на все презентации и обучения. А значит и осознанной обратной связи от них ждать не приходится.

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

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

IT-специалисты, в свою очередь, часто ограничиваются поверхностным пониманием поставленных перед ними задач и делают «как сказали», не задумываясь о бизнес-контексте задачи.

Методология должна формировать «единое пространство общения», где и пользователи, и разработчики говорят на одном языке, понимают контекст и видят партнёров друг в друге.

В критические моменты - подключать «медиаторов», «переговорщиков», которые способны помочь бизнесу и ИТ понять друг-друга на достаточном уровне. Людей, которые способны понять проблему и как руководители и как технические специалисты.

За последние три года, разрабатывая подход, который действительно решает описанные выше задачи, я всё яснее вижу:

ИТ-проекты - это не про технологии. Это про людей.

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

Эта статья - первая в серии, где я буду подробнее раскрывать идеи, заложенные в нашем подходе.

Если вы разделяете мой взгляд - присоединяйтесь к Telegram-каналу. Если сомневаетесь или спорите - тем более приходите. Открытая критика помогает оттачивать метод и делать его по-настоящему работающим.