Риски на проектах: как предотвратить «пожар»

При разработке IT-решения нужно выстроить процессы таким образом, чтобы свести к минимуму возможные риски  — например, нарушение сроков выпуска продукта в прод или его несоответствие бизнес-задачам. За время существования компании мы реализовали более 900 IT-проектов. Основываясь на накопленном опыте, мы в SimbirSoft проанализировали некоторые возможные инциденты и делимся собственным чек-листом по настройке процессов работы в команде.

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

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

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

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

Почему важна документация?

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

Особенно удобно, что можно восстановить детали и уточнить, как должна работать та или иная функция, даже спустя некоторое время после реализации системы.

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

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

На что обратить внимание

Таск-трекер

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

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

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

В качестве примера хотим поделиться собственным кейсом. Мы участвовали в реализации проекта, где команда из 50 человек работала над большим приложением около 8-9 лет. Когда дорабатывали и изменяли одну из фич, нашли достаточно странное решение в коде. Пришлось поднимать информацию и просматривать трекинг задач. Мы выяснили, что это изменение появилось около 5 лет назад и было связано с определенным бизнес-ограничением, которое сейчас уже не действует. Мы смогли найти причину благодаря выстроенному процессу трекинга и избежали дополнительных трудозатрат, а, соответственно, и удорожания продукта.

Workflow

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

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

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

Коммуникации

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

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

Для примера — ситуация, которая отлично подчеркивает процесс передачи информации от одного члена команды к другому.

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

Метрики

Метрики  — это показатели разработки продукта, которые позволяют контролировать процесс его создания. Они подбираются индивидуально под каждый проект.

Как правило, к базовому набору метрик относят следующие:

План-факт  — позволяет выявить отклонения в данных в большую или меньшую сторону от намеченного результата и вовремя скорректировать действия команды.

Burndown  — демонстрирует, какой объем работы уже выполнен и сколько задач осталось решить до завершения спринта/проекта. Помогает отслеживать темп работы и понимать, когда следует ускориться.

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

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

С помощью метрик можно уже на ранних стадиях разработки проверять соответствие срокам, бюджету и требованиям качества. Например, если у вас метрика возврата задач превысила 20%, нужно разобраться в причине и, возможно, дополнительно обсудить ТЗ с участниками команды.

Как мы работаем с инцидентами

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

Для предотвращения инцидентов мы создали инструмент «Дашборд здоровья», который содержит уникальный набор метрик. Ежедневно мы проводим мониторинг около 15 показателей (сроки, качество, бюджет и т.д.). Таким образом мы видим все «движения» в организации и можем вовремя заметить отклонение. Благодаря этому подходу, процессы в компании соответствуют требованиям международного стандарта ISO 9001:2015.

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

— Екатерина Ремизова, директор по качеству.

Как «мелочи» влияют на результат

В процессе разработки каждая деталь так или иначе влияет на конечный результат. Сотруднику может показаться, что если один раз не сменить статус задачи, не прийти на митинг, не списать время в таск-трекере  — это неважно. Возможно, что для одного человека это действительно так, но что будет, если каждый в команде позволит себе не выполнить один из пунктов? Здесь хорошим примером будет теория «разбитых окон»: «Если в здании разбито одно стекло и никто его не заменяет, то через некоторое время в этом здании не останется ни одного целого окна».

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

Узнайте больше о процессах работы в компании.