Риски IT-проектов: управление, предупреждение и идентификация | Boodet.online

Стратегия

Риски IT-проектов: управление, предупреждение и идентификация | Boodet.online

Какие риски у ИТ-проектов? Как предупредить эти риски и вовремя идентифицировать? Как управлять рисками? Защитите свой стартап на первых этапах развития.

Поделиться
Запинить
Отправить

Риски IT-проектов и управление ими

IT-проект — это процесс разработки, тестирования и внедрения программного обеспечения, инфраструктуры или информационных систем. Все три этапа ИТ-проектов имеют одинаковые риски, которые надо предвидеть на самом первом — еще до того, как начать писать код. Что может пойти не так и как свести негативные последствия к минимуму — рассказывают специалисты Boodet.Online.

Возможные риски

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

Риски ИТ-проектов делят на три основных типа:

  1. Уже известные.

  2. Потенциально известные.

  3. Неизвестные.

Уже известные

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

Потенциально известные

Вероятные риски IT-проекта, о которых знает команда, но которые не обязательно произойдут. Например, разработку ПО заказал клиент, который известен правками в середине развертывания. Какие-то заказы вы сдавали без проблем, другие пришлось дорабатывать. В этом случае команда предполагает, что существует риск, но не уверена, что он произойдет.

Неизвестные

Неизвестные риски IT-проекта — это те, о которых компания не знает. Они обычно связаны с технологиями или инструментами. Например, изначально в техническом задании было следующее: разработать приложение для Android; потом заказчик решил, что нужно то же самое, но для Mac. Или вначале требовался код на Python, а потом — на C++.

Как управлять рисками IT-проектов

Управление рисками IT проекта — это сложная задача, которая требует специфических знаний и навыков. Мы рекомендуем нанять специалиста, который будет отвечать за риск-менеджмент в команде.

Что должен уметь такой специалист:

  • точно описать событие, которое может произойти;

  • определить вероятность каждого;

  • рассчитать ущерб от события;

  • заранее определить ответственных.

Управление рисками IT-проекта состоит из следующих процессов:

  • идентификация;

  • анализ;

  • планирование;

  • мониторинг.

Идентификация

Чтобы определить риски, которым может подвергаться ваш текущий IT-проект, важно сначала изучить проблемы, с которыми вы сталкивались во время реализации предыдущих. Для правильной идентификации надо изучить план проекта. Лучший способ это сделать — преобразовать его в блок-схему. Потребуется участие всей команды, чтобы выявить все три типа рисков.

Что имеет значение:

  • технические нюансы;

  • детали эксплуатации продукта;

  • политика;

  • юридические нормы;

  • социальные факторы;

  • взаимоотношения внутри команды.

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

  • дата;

  • название проекта;

  • тип задачи;

  • кто обнаружил проблему;

  • как она была решена;

  • вероятность повторения в текущем проекте;

  • как свести вероятность подобного к минимуму;

  • что делать, если эта проблема повторится;

  • кто отвечал за решение в прошлый раз;

  • кто будет отвечать сейчас.

Анализ

На этом этапе риск текущего IT-проекта определяется и классифицируется. После категоризации надо проанализировать уровень (важность), вероятность (в процентах) и влияние.

Как определить вероятность в процентах? Нужно проанализировать все технические условия и принять во внимание возможные последствия.

Технические условия:

  • сложность технологии;

  • технические знания, которыми обладает команда;

  • конфликты внутри коллектива;

  • географическое расположение всех членов команды (повлияет на срочные собрания: если часть сотрудников работает в Москве, а другая — в Лондоне, то их графики будут разные);

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

Возможные последствия:

  • потеря репутации;

  • вред обществу;

  • денежные потери;

  • судебные иски;

  • банкротство.

В итоге вы должны определить все вероятные риски ИТ-проекта как высокие, средние или низкие. Эти данные надо внести в таблицу, которую мы рекомендовали создать на этапе идентификации.

Планирование

Что надо сделать на этом этапе:

  • определить превентивные меры, которые снизят вероятность различных неприятностей;

  • найти меры, которые снизят воздействие, если событие все-таки произойдет;

  • заняться постоянным мониторингом рабочих процессов для максимально раннего выявления проблем.

Мониторинг

Включает в себя:

  • отслеживание любых изменений в процессе работы над продуктом;

  • подготовку отчетов о состоянии проекта;

  • регулярный пересмотр маркеров уровня вероятности рисков (высокие, средние, низкие;

  • постоянный поиск новых неизвестных сложностей.

Возможные последствия

Выше мы рассмотрели последствия рисков IT-проектов для клиента, а что с исполнителем? Какие последствия будут в рамках самого проекта? Их очень много, часть из них влияет только на конкретные задачи, другие — на итоговый продукт в целом. Мы расскажем о самых распространенных последствиях для разработчиков.

Нежизнеспособный продукт

До того как начать писать код, надо ответить на важный вопрос: какую проблему решает продукт? Если на него не ответить четко, есть опасность создать программу или инфраструктуру, которая будет абсолютно бесполезной или неудобной для целевой аудитории. Мы рекомендуем разработать четкие критерии определения успеха продукта. Например, показатели тестирования среди ЦА.

Важно помнить, что цели продукта — это не константа, они могут меняться. Если это не учитывать, ПО будет нежизнеспособным.

Отказ от разработки из-за нехватки бюджета

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

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

COTS вопреки здравому смыслу

Изначально подход COTS (коммерчески готовый продукт) был призван сократить риски IT-проектов. Что пошло не так?

COTS — это когда несколько заказчиков совместно оплачивают разработку универсального ПО, которое потом можно будет настроить для нужд конкретного бизнеса. В теории такой подход обходится дешевле, чем индивидуальная разработка. На практике же задачи заказчиков часто бывают настолько разными, что приходится писать сотни тысяч дополнительных строк кода. В итоге страдают все стороны: клиенты платят по итогу больше, чем если бы заказали индивидуальный продукт; исполнители тратят на доработки больше времени, трудовых и технических ресурсов, чем планировали.

Компания сама виновата в том, что заказчик не принимает проект

Одно из самых неприятных последствий — отказ заказчика принять разработку. Вы потеряли время, потратили деньги на ресурсы, создали условно жизнеспособный продукт, который не нужен в итоге ни вам, ни заказчику, ни целевой аудитории. Почему такое происходит и кто виноват?

Чаще всего риск неполного планирования IT-проекта игнорирует компания-разработчик. Эта опасность относится к заранее известной. План проекта — это своего рода детализированное техническое задание, в котором учтены абсолютно все требования к ПО, запросы целевой аудитории, расчет временных затрат.

Что может быть не так:

  1. План скудный по содержанию. Вместо многостраничного документа — маленькая презентация или таблица с пожеланиями заказчика.

  2. Клиент не вовлекал в предварительные исследования целевые сообщества. А вы забыли ему об этом напомнить.

  3. График важнее требований. В этой ситуации высока опасность оставить важные проблемы нерешенными, лишь бы успеть до дедлайна.

  4. Неполный список требований. Например, не описаны доступность, безопасность, обучающие материалы для пользователей.

  5. Нереалистичный график. Если заказчик требует сдать проект к определенному сроку (иначе он вам не заплатит), объясните, почему это невозможно. Соблюдать сроки нужно. Но и разработчики, и заказчики должны понимать, что есть множество рисков ИТ-проектов, которые повлияют на сроки.

Собственные проблемы

Что произойдет, если команда проигнорирует известные факты и не признает реальные риски IT-проекта? Первое, что пострадает — сроки работы. Они увеличатся. Если в договоре прописаны штрафы за увеличение времени разработки — компания потеряет деньги. Также могут испортиться взаимоотношения внутри команды — сотрудники разделятся на два лагеря, обвиняя друг друга в том, что реальные проблемы были проигнорированы.

Практические примеры

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

С какими рисками чаще всего сталкиваются в IT:

  • токсичная команда;

  • низкая квалификация сотрудников;

  • консерватизм заказчика;

  • отсутствие регулирования.

Токсичная команда

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

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

Например, TechCrunch разорвали контракт с RadiumOne после того, как стало известно о причастности одного из сотрудников компании к домашнему насилию.

Низкая квалификация сотрудников

IT-кадры стоят дорого. У современных специалистов нет повода держаться за конкретную команду, если там мало платят или дают недостаточно социальных бонусов (ДМС, оплата абонемента в спортзал, обеды). Если у вас появляется соблазн нанять недавних выпускников курсов вместо опытных специалистов, чтобы сэкономить — не идите на поводу у этого желания. Даже если проект выглядит простым, помните о неочевидных рисках. Новички могут принимать участие в разработке и тестировании, у них часто появляются интересные идеи, но отвечать за продукт должен специалист с высокой квалификацией.

Консерватизм заказчика

Классический риск любого IT проекта — консерватизм заказчика. Например, клиент заказал приложение для детей. Своего рода Spotify, только вместо музыки — мультфильмы. Ваша команда ответственно взялась за планирование, провела качественное тестирование, определила потребности целевой аудитории, представила и согласовала прототип с клиентом. А потом он сказал, что нужно что-то исключить, например, аниме. Если принять эти абсурдные правки, продукт будет бесполезным. Он станет отвечать потребностям консервативного заказчика, но не целевой аудитории.

Отсутствие регулирования

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

Например, ваша команда создала прекрасный антивирус. Чтобы его продавать, надо получить лицензию у ФСБ и ФСТЭК. Это длительный процесс, на положительный исход которого мало влияют технические характеристики софта. Мы рекомендуем привлекать к разработке опытных юристов, которые имеют положительные кейсы лицензирования ПО — это поможет пройти проверку в органах и выпустить продукт на рынок.

Заключение

Что нужно для того, чтобы распознать риск и разработать план работы с ним:

  • привлекать к процессу идентификации менеджеров из других проектов, заказчиков, пользователей, независимых экспертов, участников проектной команды;

  • использовать для идентификации проблем различные методы;

  • изучать отчеты и проектную документацию ранее реализованных ИТ-проектов.

В процессе идентификации для более эффективного выявления рисков рекомендуется использовать следующие проектные документы:

  • устав — документ, который наделяет менеджера обязанностями и правами задействовать ресурсы для успешного завершения проекта;

  • видение — документ, описывающий цели и задачи, ожидаемые результаты, продукт и основных пользователей;

  • список предложений, ограничений и требований, предъявляемых к проекту;

  • расписание работ;

  • иерархическую структуру работ — формализованные и зафиксированные в документах взаимосвязанные и измеримые части проекта;

  • план финансовых затрат;

  • расписание отпусков и государственных праздников.

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

  • мозгового штурма;

  • делфи;

  • интервью;

  • SWOT-анализ;

  • диаграмму Исикавы;

  • метод «блок-схема принятия решений».

Если вы хотите, чтобы стартап развивался — не экономьте на кадрах. Нанять опытного специалиста по IT-рискам — это означает сэкономить миллионы в будущем. Чтобы узнать больше о том, как вырастить из стартапа успешную компанию — обратитесь к специалистам Boodet.Online. У нас есть много полезных инструментов для разработки, тестирования и внедрения.

Поделиться
Запинить
Отправить

Возможно вам так же будет интересно:

По оценке директора акселерационных программ ФРИИ Дмитрия Калаева, официальная смертность российских стартапов – 90%.

Стартап – это новое предприятие, главная цель которого – выжить. «Долина смерти» никого не щадит и всех проверяет на состоятельность.

Готовьтесь заранее, чтобы не выглядеть глупо.