Без рубрики

Оценка IT-проекта и его эффективности

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

Hand using laptop with database reports and online work concept

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

Зачастую, оценкой эффективности продукта занимаются менеджеры по продажам, инвесторы и любые другие заинтересованные лица. Однако, внести свои мысли в этот процесс может каждый член команды. Рассмотрим эффективность проекта с точки зрения QA-лида команды.

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

  • Конфликт интересов бизнеса и конечного пользователя

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

  • Ориентированность на функциональность в ущерб проектированию UI-интерфейсов.

Иногда возникают такие ситуации, когда бизнес не ставит в приоритет UI/UX-дизайн приложения, так как считает важным именно конечный функционал. Например, в приложении строится отчет за выбранный временной период. Однако, никто не задумывался о том, что нужно вручную с клавиатуры вводить дату в формате ДД.ММ.ГГГГ — а как же выбор из календаря?

  • Медленная работа приложения.

Никому не понравится пользоваться “медленным” приложением, в котором отображение результатов на экране занимает более 5-10 сек. В данном случае, нужно проводить итерационное нагрузочное тестирование с определением планируемого количества пользователей по мере нарастания функциональности приложения, сделать код масштабируемым.

  • Прирост функционала приложения происходит крайне “медленно”

С каждым днем на рынке появляется все больше различных приложений. Все это порождает конкуренцию и “борьбу” за пользователя. Чтобы этот процесс был эффективным, необходимо получать новую стабильную сборку приложения как минимум раз в месяц. Обновление должно содержать не только новые фичи, но и исправление дефектов.

  • Пользователи наталкиваются на дефекты в приложении

Меня как QA-специалиста всегда особенно сильно “раздражают” баги в различных приложениях. Обычно, я всегда пишу в техподдержку с подробным описанием баг-репортов и прикладыванием скринов (а иногда даже гифок). Но рядовой пользователь этого делать не станет и просто уйдет в поисках другого приложения, оставив негативный малоинформативный отзыв. Крайне важно понимать, какие дефекты пользователь точно не должен найти. Например, в приложении Яндекс.Музыка я неоднократно сталкиваласьсталивалась с проблемой отображения двух прелоадеровпреалодеров на экране при низком уровне связи. Является ли этот баг критичным? Разумеется, нет. Но сам факт его наличия говорит о том, что пользователи с ним живут и приложение не развалилось.

  • Существующий аналог значительно удобнее

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

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

Приведем краткий чек-лист:

  • Фиксация целей, задач проекта
  • Определение сроков реализации проекта
  • Составление плана, определение необходимых ресурсов, трудозатрат
  • Подбор команды и компетентных специалистов
  • Раннее тестирование
  • Метрики проекта и продукта
  • Грамотное планирование и управление командой
  • Управление рисками
  • Сбор отзывов, анализ и улучшения продукта
  • Получение стабильной сборки приложения итеративно

Рассмотрим каждый пункт чек-листа подробнее на примере старта нового IT-продукта.

  • Фиксация целей, задач проекта

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

  • Определение сроков реализации проекта

Здесь необходимо ответить на ряд вопросов:

Когда команда должна выпустить первый релиз?

Какие ресурсы необходимы для сокращения сроков?

  • Составление плана, определение необходимых ресурсов, трудозатрат

Какой объем работ должен быть выполнен?

Сколько сотрудников для этого нужно?

Какие технологии должны быть у них в арсенале?

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

  • Подбор команды и компетентных специалистов

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

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

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

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

  • Раннее тестирование

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

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

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

  • Метрики проекта и продукта

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

Приведем примеры метрик, которые помогут оценить эффективность проекта и продукта:

  • Time-to-market
  • Оценка трудозатрат (план и факт)
  • Оценка сроков (план и факт)
  • Количество пропущенных дефектов на продуктив (факт)
  • кол-во известных дефектов в системе, с которыми выходим в прод
  • Процент пере-открытых задач
  • Плотность дефектов по модулям
  • Разбивка дефектов по критичности
  • Соотношение новых и закрытых дефектов
  • Грамотное планирование и управление командой

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

  • Управление рисками

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

  • Сбор отзывов, анализ и улучшения продукта

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

  • Получение стабильной сборки приложения итеративно

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

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

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

Как провести оценку эффективности вашего проекта? Взглянуть на ключевые критерии, определяемые как “эффективность”. Для каждого проекта они могут быть разными, как и для разных типов домов, но суть остается одна…

0 0 vote
Article Rating
Подписаться
Уведомление о
guest
0 Комментарий
Inline Feedbacks
View all comments