Все грани риска. Как управлять ИТ-проектом безопасно

Типы рисков в IT-проектах

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

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

Есть и другие ситуации. Представьте, что вы 6 месяцев инвестировали в запуск MVP, предварительно проверив, что на рынке такого продукта нет. Предугадать, что конкурент на пятый месяц опубликует в сторах аналогичное приложение, невозможно – это неуправляемый риск. 

Обстоятельства, которые не учитывают при риск-менеджменте:

• маловероятные и сложно прогнозируемые, такие как 0,000001%-ный шанс, что на офис упадет метеорит; 
• с малозначимым негативным эффектом. 

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

Непонимание объема задач на старте проекта

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

Компания готовится к выпуску MVP со сложной архитектурой за неделю. Если не учитывать, что только публикация приложения на мобильных площадках займет в среднем 2–7 дней, разработка растянется до 80%, снижая потенциальную прибыль. 

Изменение рынка

Компания уверена, что серьезный долгосрочный проект точно будет отвечать требованиям бизнеса. Не учитывает, что к моменту выпуска – через 2–3 года – ситуация на рынке изменится. Придется вкладывать ресурсы в модернизацию готового продукта под новые запросы потребителей.

Кадровые изменения

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

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

Двусмысленность требований

Похоже на ситуацию, которую легко предотвратить, договорившись с исполнителями. Проблема не обязательно возникает, но если да – ее обнаруживают, когда становится слишком поздно.

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

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

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

Идентификация и оценка рисков как способ бороться с ними

Риск – проблема, которая еще не случилась. Управление рисками связывают со снижением абстрактной опасности до того, как она превратилась в событие. Для этого есть три способа:

• анализ опыта;
• мозговой штурм;
• экспертная оценка.

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

Если мозговые штурмы проводятся регулярно, вопрос «Какие риски нас ждут?» перестанет смущать сотрудников. В ином случае, когда на откровенность трудно рассчитывать, начните собрание с вопроса, который сместит фокус с индивидуумов и уменьшит напряженность. 

Для снижения неопределенности в IT-проекте можно обратиться к эксперту в этой сфере с целью экономии времени.

Практика снижения рисков на этапах разработки IT-проекта

Predevelopment – этап зарождения продукта. Входит в discovery-фазу, необходимую для снижения неопределенности на старте. 

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

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

Работая с подрядчиком, убедитесь, что в договоре отсутствует пункт о предоплате и есть подтверждение передачи прав на проект. Мы в Umbrella IT гарантируем все это.

Команда 

В профессиональной IT-команде каждый отвечает за одно конкретное направление. Помимо руководителя проекта, разработчиков, дизайнеров, костяк должен включать:

• QA-инженера – контролирует качество разработки, проверяет уязвимости проекта, ищет дефекты дизайна, подсвечивает несоответствия спецификациям. Проводит автоматическое и нагрузочное тестирование для выявления потенциальных проблем продукта после выпуска. 
• DevOps – отвечает за эксплуатацию продукта: запуск, настройку серверной инфраструктуры, масштабирование под нагрузку, мониторинг неисправностей. 

Процесс разработки продукта

Чем прозрачнее выстроена работа, тем проще ее контролировать. Чтобы добиться стабильности и гибкости, мы в Umbrella IT рекомендуем:

• делить процесс на короткие спринты (1-2 недели);
• организовать ежедневную отчетность исполнителей с детальным описанием задач, проблем и способов решений;
• в конце каждого спринта проводить демо, где исполнители представят конкретный и измеримый результат. Это важно для оперативной корректировки стратегии без остановки работы.

Контроль

Для оценки работы внутренней или внешней команды подключите ее к тайм- и таск-трекерам. 

• Таск-трекер (Jira, Trello) – инструмент эффективного управления проектами и отслеживания статусов задач.
• Тайм-трекер (Worksnaps) – программа учета рабочего времени. Отображает, сколько человек подключено к задачам, что делает тот или иной разработчик и в течение какого периода.  Изначально мы пользовались таким решением. Потом пришли к выводу, что функциональности приложения не хватает, и разработали собственный тайм-трекер – Attrack. Сегодня им пользуются и за пределами нашей компании.