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

Точки влияния на бюджет разработки

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

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

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

Среди частых проблем, с которыми приходят к нам клиенты, отметим:

  • Постоянный рост дефектов на продакшене. Это влияет на отношение потребителей к продуктам, а также требует временных и финансовых затрат со стороны службы поддержки, команды разработки и тестирования.

  • Постоянный срыв сроков релизов важных фич. Это также увеличивает временные и финансовые затраты, а также расходы на работу команды из-за частых овертаймов.

  • Отсутствие метрик для оценки команд разработки и тестирования, а также качества продукта. А это значит, что руководитель будет лишен возможности оптимизировать её работу.

Первым шагом для изменения ситуации на проекте часто становится аудит процессов. В него входит:

  • Анализ существующих процессов аналитики, разработки, тестирования.

  • Анализ запросов пользователей в службу поддержки.

  • Анализ текущего workflow проекта, задач, дефектов и документации.

  • Фиксация рисков и их приоритизация.

  • Формирование предложений по снижению рисков и устранению проблем.

  • Разработка и внедрение метрик для контроля за улучшениями.

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

А что потом?

Спустя некоторое время (от двух недель до двух месяцев — в зависимости от сложности проекта) после аудита, бизнес может добиться: 

  • Снижения времени вывода ПО на рынок (time-to-market).

  • Сокращения количества и критичности дефектов.

  • Выявления дефектов на самых ранних стадиях разработки.

  • Роста лояльности клиентов к приложению за счет повышения качества и стабильности его работы.

  • Увеличения скорости разработки и попадания в оценку, благодаря снижению рисков.

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

 Рассмотрим один из примеров. Основная проблема, с которой к нам обратился заказчик, – сдвиг заранее запланированных сроков на проекте, перерасход бюджета. Команда была полностью на стороне клиента. Во время аудита выявили слишком долгое ожидание процесса код-ревью. Это провоцировало задержку передачи работ на тестирование и простаивание команды, сдвиг срока релиза и прочее. Потеря времени отражалась в перерасходе бюджета. Для решения этой проблемы мы сформировали ряд предложений. По результатам их внедрения попадание по срокам в оценку составило 85%.

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

Подготовка к аудиту

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

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

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

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

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

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

  • проектной документации, регламентам разработки;

  • тестовой документации: чек-листам, тест-кейсам, отчетам;

  • тестовым стендам;

  • таск-трекеру и чату службы поддержки.

 Аудиторами могут стать как внешние компании, так и сотрудники, обладающие необходимой экспертизой. Решить, что вам подойдет лучше, поможет таблица.

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

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

Как оценить результаты?

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

Рассмотрим несколько метрик, которые были внедрены на одном крупном проекте из банковской сферы после проведенного аудита:

Метрика

Какие риски отражает

Отклонение запланированной даты релиза от фактической

Тенденцию к задержке и откладыванию релиза – срыв сроков и риск потери клиентов

Общее количество дефектов в системе – в разрезе критичности

Временные траты на багофикс

Количество дефектов, пропущенных на продакшн

Тенденцию к пропуску багов и эффективность тестирования до релиза

План/Факт

Отклонения фактического от запланированного времени

Внедряя метрики, важно опираться на следующие правила:

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

  • Оценку метрик важно проводить на постоянной основе.

  • Если собранные метрики не отвечают заданным планам, действия по исправлению должны быть разработаны и применены как можно скорее.

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

Нужен ли вам аудит?

Чтобы оценить, нужно ли вам проведение аудита процесса, предлагаем ответить на следующие вопросы:

  1. Как часто команда не укладывается в сроки?

  2. Какое количество дефектов выявляется после стадии тестирования?

  3. Насколько интенсивно работает саппорт-команда после того, как произошел очередной релиз продукта?

  4. Есть ли у вас на проекте метрики, благодаря которым понимаете, уложитесь ли в запланированные ресурсы (бюджет, время)?

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

Бонусом мы предлагаем наш чек-лист по экспресс-аудиту. Он позволит быстро оценить ситуацию на проекте и текущие процессы.

Также напомним, что, помимо аудита процессов, сэкономить бюджет разработки помогут:

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

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

  • QA-консалтинг. Многие риски можно снизить не только за счет выстраивания процесса, но и путем повышения квалификации QA-команды.

  • Discovery Phase («дискавери-фаза»). Проработка оптимального способа реализации бизнес-идеи или усовершенствования готового продукта.

Все эти мероприятия нацелены на сокращение time-to-market и снижение вероятности возникновения рисков, которые могут значительно увеличить бюджет. Поэтому, инвестируя в организацию процессов, качественную документацию и тестирование, вы можете сэкономить бюджет в будущем.

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

Больше кейсов и полезных материалов – в наших ВК и Telegram.

Комментарии (0)