Как получить от оценки максимум пользы

Как получить от оценки максимум пользы

SimbirSoftMobile

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

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

Как оцениваем

Оценка — это не просто примерные цифры, а целый процесс.


Анализ

Подключаем эксперта, имеющего опыт разработки проектов разной сложности: от небольших магазинов до порталов и внутренних систем. Даем ему на изучение всю информацию, которая есть у клиента: детальное техническое задание, описания, прототипы, сценарии использования (кликнул иконку «корзина» --> появилось окно заказа).

Уточнение

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

Непосредственно оценка

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

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

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

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

Определяем состав команды, сроки и готово.

Упс, что-то пошло не так...

По данным исследования агентства Standish Group, 3% больших проектов и около половины небольших идут так, как запланировано.

SimbirSoftMobile

Значит ли это, что разработчики не умеют оценивать?
Не совсем. Часто разработчик делает оценку в уверенности, что все пойдет идеально. Или очень хочет проект и готов занизить оценку, чтобы она понравилась. На практике выходит по-другому: сервер “отвалился”, документация потерялась или стала неактуальной, ответственный за проект заболел или уволился, и новому специалисту приходится срочно вникать в проект. Это увеличивает первоначальные оценки, ведь на момент их подготовки исходные данные были другие. Растет цена, уменьшается удовлетворенность от сделанного. К тому же, всем хочется прикрутить дополнительные фичи в оговоренную стоимость, хотя изначально они вообще не оценивались. Так стоимость разработки приложения тоже растет.

Зачем вообще оценивать

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

  1. Примерные сроки и стоимость того конкретного функционала, который мы оценивали;
  2. Адекватность компании: налажены ли процессы и коммуникация, сколько займет подготовка оценки;
  3. Профессионализм технических специалистов: какие вопросы задают, есть ли релевантный опыт, заинтересованы ли в проекте;
  4. Скорость реакции: если уже сейчас отвечают с задержками в неделю, что же будет дальше?

Как получить максимум от оценки

  • Просите указать часовую ставку специалистов: одна сумма в коммерческом предложении мало что вам даст. Если у компании выше часовые ставки, но ниже общая сумма оценки, возможно, какую-то часть не оценили;
  • Просите расписать оцениваемый функционал: так становится понятно, что именно было изучено и оценено, никакой важный функционал не забылся;
  • Смотрите на команду разработки: есть ли тестировщики, аналитики, руководители. Написать код — еще не все, важно собрать в единое целое написанный код.

А что, если есть только общее представление о будущем продукте?

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

SimbirSoftMobile

Схема работы приложения.

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

SimbirSoftMobile

Список базовых функций приложения и предварительный дизайн.

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

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

Еще статьи

На старте каждого проекта наша первоочередная задача – понять потребность, проблему заказчика и конечных пользователей продукта. Если вам нужен, например, редизайн уже существующего приложения, то мы начинаем с определения его бизнес-целей – увеличить продажи, привлечь больше посетителей на свой сайт.
Разработчик популярных сервисов заказа еды, компания mobile.SimbirSoft - о том, как угнаться за рынком и повысить продажи. Foodtech на рынке мировых технологий растет огромными темпами, все больше людей выбирают готовую еду, чтобы не тратить время на походы по магазинам и дежурство у кухонной плиты.
Понятие UX перестало быть «хайповым», а стало качественным инструментом обеспечения комфорта работы с приложением и удовлетворенности пользователей. Пользователи должны без труда находить необходимую информацию, выполнять желаемое действие с минимальными временными затратами.
Mobile.Simbirsoft довольно часто сталкивается с задачей спасти продукт. Одним из вызовов для нашей команды экспертов стала доработка приложения iSimple, путеводителя по миру вина и других благородных напитков, с помощью которого легко определиться с выбором, совершить покупку или узнать адреса ближайших магазинов
Каждое разрабатываемое в mobile.SimbirSoft мобильное приложение уникально и создается с нуля. Каким бы сложным оно ни было, прежде всего, оно должно быть удобным. В данной статье речь пойдет о том, как мы проектируем и создаем понятный и удобный интерфейс мобильных приложений на примере системы для подбора машинных масел.

Расскажите нам вашу идею

При отправке данной формы Вы подтверждаете, что ознакомились с нашей политикой конфиденциальности.

Напишите нам

Константин Каменский
Константин Каменский
Иван Игонин
Иван Игонин