По данным LinkedIn, 70% проектов по созданию ПО терпят неудачу. Основная причина заключается в том, что изначально риски программных проектов не оценивались или недооценивались. Я опишу главные правила по управлению рисками в нашей команде.

Высокая мотивация — низкие риски

В разработке программного обеспечения существует пять основных рисков: неточные оценки, изменение масштаба, взаимодействие с конечным пользователем, некачественный код и низкая производительность. Мы в нашей команде рассматриваем эти риски неразрывно от работоспособности самих сотрудников. Ведь на этапе разработки, когда каждый день на счету, потерять  ценного сотрудника, а затем найти и адаптировать нового — очень дорого. Поэтому лучше очень чувствительно относиться к своим кадрам. Желательно, чтобы HR периодически спрашивал, как дела, как настроение, вообще нравится ли сотруднику продукт или нет. Ведь если человеку не нравится то, что он делает, то он просто «отбывает повинность», а не создает продукт. Такие люди создают негативную обстановку в команде, и их лучше отпустить или найти ту работу, которая им нравится.

Реестр и матрица рисков — первые документы на проекте

Управлять рисками на проекте помогает прописанная заранее стратегия. В ней можно указать конкретные методологии и инструменты, роли участников, категории рисков и другие детали, помогающие формализовать подход к управлению рисками. Это очень полезный документ, который сможет ответить на многие вопросы в ходе проекта. Но если вы раньше не писали риск-стратегию, первые разы на ее создание придется заложить дополнительное время.

Составьте сначала реестр рисков, которые могут возникнуть. Опирайтесь на опыт уже завершенных аналогичных проектов. Реестр рисков удобно держать в формате таблицы с несколькими столбцами или десятками столбцов, в зависимости от требуемого уровня проработки рисков. Для удобства также можно добавлять столбцы с обозначением даты выявления, ответственных за работу, добавить комментарий и стратегию ответа на риск (принять, избежать и т. д.), тип риска (угроза\возможность), категорию, возможную стоимость влияния и еще множество других атрибутов, которые вы хотите контролировать.

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

Далее я выделил основные действия, которые помогают нашей команде снижать риски на проекте.

6 действий по снижению рисков программного обеспечения

1. Отслеживайте риски до того, как они обострятся и станут проблемами, которые могут свести на нет проект развития.

Следует понимать основное отличие понятия риска от понятия проблемы:

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

Всегда помните, что даже самый большой список никогда не будет полным — что-то всегда будет упущено.

2. В первую очередь займитесь наиболее рискованными частями процесса разработки.

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

Меры реагирования на риски:

3. Немедленно устраняйте риски, используя гибкий подход к разработке.

Гибкий подход к разработке разбивает процесс на небольшие куски, оставляя место для корректировок при столкновении с непредвиденными рисками. Обычно фронтенд-команда работает двухнедельными спринтами. На каждый публичный релиз приходится 6-8 таких спринтов.

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

Источник изображений: скришноты канала проекта inqoob

4. Делитесь всеми рисками с клиентами, чтобы быть прозрачными.

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

5. Отслеживайте настроение команды разработчиков и команды клиента, а также сроки, бюджет и объем проекта.

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

Задайте своим клиентам и разработчикам два вопроса:

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

Не каждый руководитель может задать вопросы команде так, чтобы каждый смог развернуто ответить. Отдайте эту задачу HR’у, часто он может целостнее увидеть картину. Айтишники часто работают по нестандартному графику:  в ночь, на выходных, в отпуске — в итоге сами не замечают нарушение режима. Поэтому лучше всегда смотреть со стороны, регулярно собирать обратную связь от них. И смотреть, насколько человек в ресурсе. Предлагать разные решения: выходные, бонусы, услышать их предложения по разработке.

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

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

Чтобы стимулировать общение:

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

Постоянная практика

Работа с рисками — это постоянная практика. Есть пять уровней зрелости компании с точки зрения риск-менеджмента:

1. Problem stage —  работа с рисками не ведется до тех пор, пока они не станут проблемами.

2. Mitigation stage — сотрудникам знакомо понятие «риск», однако никто не знает, как управлять рисками на регулярной основе.

3. Prevention stage — управление рисками становится активностью команды в целом, а не только задачей менеджмента. Эта стадия является поворотной точкой от реактивного к проактивному методу управления рисками.

4. Anticipation stage — в компании налажен сбор и анализ метрик, для того чтобы предугадывать будущие проблемы и предсказывать определенные события на проекте. В процесс управления рисками вовлекается и заказчик, что дает возможность более аккуратно проводить количественную оценку рисков, а также верно расставлять приоритеты.

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

Свою компанию я вижу на этапе Anticipation, нам есть над чем еще поработать. Оцените, на какой стадии ваша организация, и прокачивайте свою риск-культуру. Теоретическую часть можно почерпнуть из стандартов по управлению проектами (например: PMBOK, PRINCE2) или пройдя специализированные курсы. Практической же частью следует заниматься самостоятельно, каждый день. Учитесь на ошибках и улучшайте свой продукт.