Компании обновляют и создают новые ИТ-продукты или услуги, автоматизируют бизнес-процессы: ИТ-служба стала частью ядра бизнеса, а не вспомогательным подразделением. Бизнесу постоянно нужно осваивать специфику ИТ-проектов, включая такую сложную и важную часть, как проектные риски. О том, как эффективно управлять проектными рисками при реализации ИТ-проектов, рассказывает операционный директор Umbrella IT Михаил Меньшинский.
Практически во всех отраслях экономики крупные игроки стали digital-компаниями и предлагают своим пользователям обширный функционал. Параллельно появляются риски цифровизации, связанные с новыми направлениями деятельности. При этом отсутствие действия — тоже решение, которое несет в себе определенные риски: упущенную выгоду, опоздание с выходом товара на рынок, увеличение затрат из-за того, что вовремя не внесены изменения, и прочее.
Качество, сроки, бюджет — на что влияют риски в ИТ-проектах
Риски при реализации ИТ-проектов можно разделить на три группы:
-
риски, связанные с качеством разрабатываемого продукта;
-
риски, связанные со скоростью разработки;
-
риски, связанные с бюджетом, выделенным на разработку.
Смещение акцента на одну группу вызывает изменение в двух других. Хотите проект быстро и недорого, готовьтесь к соответствующему качеству. Нужно быстро получить качественный результат, обеспечьте необходимый бюджет.
Сроки
Сроки сжимаются. ИТ-проекты становятся масштабнее и глубже интегрируются в экосистему бизнеса. Фокус сегодня уже не просто на том, чтобы автоматизировать бизнес-процессы, а чтобы сделать их максимально эффективными в короткие сроки. Бизнес не только разрабатывает цифровые продукты — он стремится создать уникальные предложения для заказчиков и выпустить их на рынок быстрее конкурентов. На этом фоне сроки реализации проекта приобретают все большую важность: если конкуренты выпустят аналогичный продукт раньше — все усилия окажутся потраченными впустую.
Пример
Создатели удобного фото-сервиса точно знали, что нужно пользователям: нам всем знакома ситуация, когда накопилось большое количество фотографий и некоторые из них мы уже не то что не будем просматривать, мы просто никогда не вспомним о них. Удобная организация снимков по годам и датам, автоматический выбор наиболее качественных фото из серии, напоминание о фото, сделанных в определенный день в прошлом, безлимитный объем хранилища — команда действительно сделала свой продукт максимально полезным и удобным, и пользователи это оценили. В августе 2013 г. продукт был назван лучшим в категории выбора пользователя по версии авторов TheVerge1. Но, к сожалению, факты — вещь упрямая. Отсутствие стратегии продвижения и монетизации работает против любого продукта. Создатели были вынуждены закрыть приложение, и их страница сегодня встречает пользователей грустным посланием: We gave it our all. Thank you, again. We’ll miss it dearly (Мы отдали все. Еще раз всем спасибо. Мы будем очень скучать)2.
Качество
Требования к качеству постоянно растут. Сегодня качественный продукт подразумевает не только удобный UI/UX, высокую производительность, безопасность и доступность. На фоне все более тесной интеграции ИТ и бизнеса специалистам уже нужны как сильные технические навыки, так и отраслевые знания. Чтобы сделать качественный продукт, нужно понимать его логику и место в общей экосистеме компании или рынка и учитывать его перспективы. Рынок меняется, появляются новые сервисы, развиваются технологии, и, если в продукт не заложена возможность развития, интеграции или обновления, есть риск, что в определенный момент времени он устареет и не будет востребован.
Примеры
Самой дорогостоящей ошибкой ПО в истории считается авария ракеты-носителя «Ариан-5» — и в такой точной области, как ракетостроение, случаются просчеты. Причин аварии называют несколько. Одной из основных стал программный модуль, который тестировался для предыдущей модели, «Ариан-4», и повторно использовался в новой среде, где условия работы были другими. Модуль не проходил тестирование ни на уровне оборудования, ни на уровне системной интеграции.
Если вернуться к более земным проблемам, то можно вспомнить открытие пятого терминала Лондонского аэропорта Хитроу3, которого все ждали с нетерпением. Несколько дней бесконечных проблем для сотрудников и гостей аэропорта, конечно, были вызваны не одной ошибкой, но не последнюю роль сыграло отсутствие интеграции между старой и новой автоматизированными системами: не была обеспечена передача идентификаторов сумок из старой багажной системы в новую. Не нужно объяснять, что означает блокировка работы багажной системы для седьмого по загруженности аэропорта в мире.
Бюджет
Бюджеты на ИТ даже на фоне непростой экономической ситуации растут или по крайней мере остаются на прежнем уровне. Согласно исследованию Spiceworks 89% компаний ожидают, что в 2019 г. их ИТ-бюджет будет расти или останется на прежнем уровне4. При этом основным фактором, влияющим на увеличение бюджета, была названа необходимость обновления устаревшей ИТ-инфраструктуры. Малый бизнес увеличит выделение бюджетных ресурсов на аппаратное обеспечение, в то время как крупные компании будут больше инвестировать в облачные решения. Соответственно, бизнес будет ждать финансовых результатов от этих вложений, и риски, которые связаны с перерасходом бюджета, привлекают все больше внимания. Бизнес-стейкхолдеры не хотят вкладывать в «черный ящик» или бесконечно продолжать инвестиции в проекты, которые «уже почти» доделаны, им нужно четкое понимание того, как распределяется бюджет: какие специалисты задействованы, какие технологии применяются, как учитывается объем и время работ. Рынок сегодня предлагает большое количество программных инструментов, которые обеспечивают возможность мониторить все параметры проекта, вовремя распознавать тенденции и корректировать ход проекта.
Предупредить нельзя исправить: этапы управления рисками
Говоря о том, как управлять рисками при реализации ИТ-проектов, мы понимаем, что полностью исключить риски из проектной деятельности невозможно. Поэтому работа по управлению рисками ведется в двух основных направлениях: уменьшить вероятность возникновения (предупредить) и минимизировать последствия (исправить). Выделим основные этапы управления рисками, они классические и присутствуют в любой сфере приложения по управлению рисками:
-
идентификация рисков;
-
оценка рисков;
-
предупреждение рисков;
-
исправление.
1. Идентификация
Чтобы эффективно управлять, нужно сначала разобраться, чем именно мы будем управлять. Поэтому работу следует начинать с выявления потенциальных проблем и факторов, которые могут повлиять на ход и результат проекта. Узнать о таких потенциальных опасностях помогут интервью заинтересованных в проекте лиц об их ожиданиях в отношении результатов, аудит процессов управления и технический аудит проектов, мозговые штурмы, анализ предыдущего опыта разработки подобных решений, привлечение мнения технических экспертов. На этом этапе в результате сбора информации формируется реестр рисков: полный перечень потенциальных факторов риска, с которым команда будет работать на протяжении всего проекта.
2. Оценка
На следующем этапе необходимо ответить на два вопроса: насколько высока вероятность реализации риска и каковы будут масштабы его последствий. Каждый фактор риска получает свой вес в рамках проекта. На основе этого анализа происходит расстановка приоритетов в реестре рисков. В противном случае пришлось бы работать над всеми факторами риска одновременно, что предполагает серьезные временные и финансовые затраты с низкой эффективностью.
Разделить управление рисками в рамках реализации ИТ-проекта на четко фиксированные этапы можно лишь условно. По сути, анализ рисков необходим при принятии каждого решения, и связано это с неопределенностью и скоростью изменений, характерных для ИТ, о которых уже говорилось выше.
3. Предупреждение
После того как менеджер ИТ-проекта разрабатывает список рисков, которые распределены в порядке приоритетности, можно начинать продумывать план действий для предотвращения или снижения негативного влияния в случае, если риск-фактор сработал.
В первую очередь следует максимально предотвратить потенциальные ситуации риска. При этом, планируя работу с рисками, всегда лучше иметь в резерве два плана: есть вероятность, что первый план не сработает.
Например, при интеграции продукта со сторонними сервисами всегда существует риск столкнуться с неприятными «сюрпризами» со стороны этого сервиса: не окажется необходимого API, он окажется нестабильным или лимитированным или подведет по срокам реализации, поэтому рекомендуется поступать следующим образом.
План А: начать с интеграции главного функционала, завязанного на этом сервисе, как можно раньше, чтобы понять, с какими проблемами придется столкнуться.
План Б: если оказывается, что проблемы действительно существуют, в запасе уже есть другие аналогичные сервисы.
План В: если по каким-то причинам срабатывают все риски и невозможно завершить интеграцию до релиза, настраиваем встроенные резервные варианты (англ. fallbacks) для этого функционала, позволяющие какое-то время использовать продукт без привлечения стороннего сервиса (например, логирование и ручная обработка запросов).
Варианты того, каким образом можно предотвратить предварительно идентифицированные риски в проектной деятельности, могут быть самыми разнообразными. Они отличаются тем объемом усилий, который нужен для их реализации: сколько нужно потратить средств, как долго будет длиться подготовка, сколько человек необходимо привлечь.
Поэтому прежде чем принять решение о дальнейшем плане действий, необходимо сравнить затраты и оценить, какой вариант будет наиболее разумным для конкретного проекта.
Цена страховки не должна быть дороже, чем то, что ты страхуешь. Никто из нас не станет тратить на страховку автомобиля сумму больше его стоимости. То же самое относится и к ИТ-проектам: можно застраховаться от всех известных рисков, но тогда сработает один самый страшный для бизнеса риск — цена проекта взлетит до небес.
4. Исправление
Если бы существовал метод профилактики, способный избавить проект от всех рисков на 100%, жизнь менеджеров и стейкхолдеров проектов существенно облегчилась бы. Но поскольку такую универсальную методику еще не придумали, на проекте всегда должны быть предусмотрены мероприятия, направленные на то, чтобы реализация риска нанесла проекту наименьший урон.
Простой наглядный пример: допустим, что по каким-то причинам была допущена ошибка в обработке платежей в рамках разрабатываемого приложения; должен быть заранее продуман способ восстановить историю всех платежей вручную для их повторной обработки.
Практические рекомендации по управлению рисками ИТ-проектов
Проектные риски требуют индивидуального рассмотрения и анализа, однако в индустрии уже выработан набор практик, позволяющих снизить вероятность основных риск-факторов.
На фоне быстрых темпов и одновременно высокой неопределенности и непредсказуемости результатов на первый план выходят не столько технические или организационные риски, сколько риски, связанные с расхождением в ожиданиях: бизнеса и ИТ-команды, пользователей и бизнеса, бизнеса и партнеров, ИТ-команды и пользователей.
Технологичный мир развивается очень быстро, инициатор проекта зачастую изначально сам не до конца понимает, что именно получит по завершении проекта, потому что видение конечной цели формируется после череды экспериментов и проверки гипотез. Если не наладить взаимодействие бизнеса с ИТ-командой, вырастет объем работ, увеличатся сроки разработки, раздуется бюджет. То есть полученный результат по всем параметрам разойдется с ожиданиями заказчика. Чтобы предупредить разочарование, рекомендуется учитывать следующие моменты:
1. Необходимо точно определить всех стейкхолдеров проекта, то есть все заинтересованные стороны и лица, которые имеют определенные требования и ожидания в отношении проекта и, что не менее важно, могут на него повлиять (с финансовой, организационной, регулятивной точки зрения). Основная задача заключается в том, чтобы выявить их ожидания и опасения. Так вы исключите ситуацию, когда на завершающем этапе работ вдруг окажется, что все, что было сделано, не устраивает одного из ключевых стейкхолдеров, который до этого момента не принимал активного участия в проекте.
2. Для стейкхолдеров и участников проекта необходимо создать единое информационное поле. Вся исходная информация и договоренности по проекту должны быть зафиксированы, и лучше сделать это визуально. Во-первых, потому, что визуальная информация лучше воспринимается. Во-вторых, всегда можно будет вернуться к зафиксированной исходной версии в случае спора или сомнений. Дорожная карта проекта, отражающая задачи и очередность их выполнения и находящаяся в общем доступе, будет обеспечивать единое представление о проекте у всех, кому эта информация нужна, быстро даст ответы на многие вопросы, что сэкономит время на коммуникации для выяснения деталей.
3. Выполнить разбивку проекта на небольшие итерации (циклы работы). Работа в режиме коротких итераций позволяет оперативно выявить риски, блокеры, проблемы и скорректировать их. Чем больший объем работы будет сделан до того момента, когда станет известно о проблеме, тем дороже обойдется исправление ситуации. За счет коротких периодов такие дополнительные расходы существенно уменьшаются.
4. Наладить регулярную обратную связь. Такая связь обеспечивается за счет ежедневных отчетов руководителя проекта, еженедельных демонстраций прогресса и результатов работ. В результате все заинтересованные лица регулярно получают информацию о том, что происходит на проекте. Но такая отчетность полезна и для самой команды. Например, в случае возникновения тенденции к увеличению бюджета, которую можно явно проследить по дорожной карте и отчетам, менеджер проекта заранее может продумать варианты оптимизации расходов и предложить их стейкхолдерам.
И еще один совет: всегда нужно начинать с самого важного и сложного, с того, что критично для проекта в целом. Это позволит еще на ранних этапах проекта идентифицировать потенциальные риски и скорректировать стратегию.
Особенности рисков в ИТ-сфере
Вышеперечисленные риски во многом обусловлены спецификой отрасли: они связаны не столько с возникновением форс-мажоров, сколько с расхождением ожиданий и неопределенностью результатов. Кроме того, необходимо учитывать особенности этой отрасли:
1. ИТ — молодая индустрия.
2. Исследования осуществляются постоянно, инновации внедряются быстро.
3. Темпы роста очень высокие.
Как отрасль сфера ИТ относительно молода, по сравнению с другими отраслями. Стоит вспомнить, что компания IBM выпустила первый жесткий диск в 1956 г., а концепт первого смартфона был представлен в 1992 г. Индустрия развивается, пусть и стремительными темпами, а это означает и определенные риски: нехватку наработанного опыта, дефицит высококвалифицированных специалистов, недостаток унифицированных отраслевых стандартов.
Если говорить о недостатке единых стандартов, то, с одной стороны, быстрое развитие технологий приводит к тому, что на данный момент нет единых требований, которые учитывали бы актуальную специфику ИТ-продуктов и унифицировали бы их создание. С другой стороны, такие требования со стороны регуляторов появляются и будут продолжать появляться, и представителям сферы ИТ необходимо быть к ним готовыми.
Вторая особенность ИТ тесно связана с первой: взаимодействуя с другими отраслями, молодая индустрия ищет новые решения и новые возможности. Проект в сфере ИТ — это постоянное прикладное исследование. Разработка прототипов, тестирование гипотез, создание MVP: все это нужно, чтобы получить на выходе продукт, который будет эффективно работать и приносить прибыль. Но любое исследование таит в себе риски, связанные с неопределенностью и непредсказуемостью.
Такой исследовательский характер связан с тем, что современные пользователи избалованы многообразием, которое предлагает им рынок. Они привыкли к тому, что цифровые продукты и услуги доступны здесь и сейчас, удобны в использовании и безопасны. К тому же на восприятие цифровых продуктов влияет глобализация. Международные гиганты Facebook, Amazon, Uber, Netflix предлагают новые технологичные решения, и пользователь ждет такого же подхода от всех поставщиков ИТ-услуг.
Третья особенность, которую нельзя не упомянуть — это высокие темпы развития ИТ-индустрии. Многие кадры фантастических фильмов, которые удивляли нас несколько лет назад, сегодня стали реальностью: интерактивное телевидение, умные города, общение в искусственной реальности, биометрическая идентификация и многое другое. Сегодня те технологии, которые существуют два-три года и не раз успешно использовались, могут потерять интерес потребителей на фоне других новых решений. И такие скоростные изменения означают, что всегда есть риск опоздать.
В первом квартале 2019 г. в Google Play насчитывалось 2,1 миллионов приложений, а в Apple App Store — 1,8 миллионов5. При такой конкуренции неправильная оценка ситуации на рынке, задержка в выпуске на рынок или недостатки, влияющие на качество, могут стать для продукта губительными.
***
Особенности ИТ-индустрии таковы, что и разработчикам ИТ, и их компаниям-клиентам при реализации ИТ-проектов необходимо действовать быстро и при этом учитывать как специфические отраслевые риски ИТ, так и особенности взаимодействия команды разработчиков и всех заинтересованных сторон проекта.
К сведению
API (сокр. от англ. application programming interface) — программный интерфейс приложения, интерфейс прикладного программирования: описание способов (набор классов, процедур, функций, структур или констант), при помощи которых одна компьютерная программа может взаимодействовать с другой программой. Используется программистами при написании приложений.
1 https://www.theverge.com/2013/8/29/4560364/best-cloud-storage-photo-apps.
2 Ссылка на страницу Everpix: https://www.everpix.com/.
3 http://apt.ua/heathrow-terminal5-failure/.
4 https://www.spiceworks.com/marketing/4state-of-it/report/.
5 https://www.statista.com/statistics/276623/number-of-apps-available-in-leading-app-stores/.