Web-студия «Ананас»: как правильно заказать разработчику приложение для бизнеса

Добрый день, уважаемые читатели VC.RU! В последние несколько лет активно растет число компаний, желающих запустить web или мобильное приложение: это может быть сервис доставки еды или других товаров, интернет-магазин, маркетплейс и прочие подобные проекты. Успех разработки зависит от множества нюансов на разных этапах, но в этом материале вместе с совладельцем web-студии «Ананас» из Екатеринбурга (Евгений Гавриляк) расскажем об основных подводных камнях при написании технического задания.

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

Евгений Гавриляк: могу привести примеры плохих формулировок, с которыми мы сталкивались в реальных ТЗ

Мало того, что человеческий и машинный интерфейс – вещи диаметрально противоположные (для человека важна графика, анимации и акценты, а для машины структура данных); при такой формулировке возникает еще и широкое поле для оценочных суждений. Удобным получился интерфейс или нет, решает только сам заказчик. «Нам кажется, что интерфейс неудобный – давайте переделаем» - и разработка уходит на новый цикл. А затем на еще и еще один. Когда у разработчика нет никаких критериев, он вынужден опираться на собственные представления или опыт, которые в большинстве случаев не совпадают с мнением заказчика.

Здесь та же проблема – отсутствие четких критериев и примеров. Какие браузеры считать современными? Мы, например, не относим к таковым Internet Explorer, хотя заказчик может считать наоборот и выставить претензию, если этого браузера не будет в списке поддерживаемых.

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

Евгений Гавриляк: разработка «супер-приложения» по огромному ТЗ – процедура сама по себе очень долгая. К тому же в таких ТЗ часто встречаются взаимоисключающие формулировки, затрудняющие работу. Так, в начале документа указывается, что пользователь должен вручную вводить данные для регистрации в приложении. А ближе к концу регистрация становится уже автоматической. Подобных моментов может быть очень много, и далеко не факт, что разработчик сможет их отследить на старте.

Гораздо более эффективной является предварительная встреча с разработчиком и обсуждение будущего продукта. Разработчик поможет составить ТЗ и донесет всю необходимую информацию до программистов.

К тому же первоначальны объем ТЗ лучше сократить, если оно слишком большое. Стоит начать с автоматизации одного конкретного бизнес-процесса, а уже потом развивать проект до уровня «суперприложения». Бывает, что после запуска базового функционала у заказчика меняются приоритеты, представление о том, нужно ли ему приложение и т.п. Если не меняются, можно разработать улучшенную версию: с дополнительным функционалом, более простым интерфейсом пользователя и т.п.

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

Евгений Гавриляк:

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

Иногда подобные проблемы всплывают уже во время разработки, и тогда ситуация осложняется. Один из клиентов заказал приложение по управлению лидами в производственной компании. Мы выступали в качестве субподрядчика, с самим заказчиком напрямую не взаимодействовали. Получив продукт на согласование, клиент не увидел там системы взаимодействия со складом и был страшно возмущен. Однако этой системы не было и в техзадании. Стали разбираться и выяснили, что работа со складом в приложении подразумевалась, но обозначать ее наличие клиент не посчитал нужным. «Это же очевидно», - вот его дословное высказывание. Однако это не было очевидно нам, потому что мы:

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

Будучи субподрядчиком не погружались глубоко в продукт. Это не имело смысла – как знать, может, мы делаем только MVP продукта? Закладываем каркас, дорабатывать который будет уже другая команда? Поэтому мы просто согласовали ТЗ и объем работ. Были уверены: если в ТЗ не содержится разработка системы поиска и учета товара, формирования накладных и т.д., то ничего в этом направлении делать не нужно

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

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

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

Не стоит полагаться на то, что разработчик додумает проект самостоятельно. Если там есть критически важные нюансы – они должны быть обязательно отражены в ТЗ. Иначе приложение может просто не дожить до рабочей версии, но предварительно съест весь бюджет на разработку.

Евгений Гавриляк: страховкой от рисков служит и выбор профессиональной web-студии, которая не просто делает все как указано в ТЗ, а имеет в штате бизнес-аналитиков. Эти сотрудники могут проанализировать ТЗ, приехать к заказчику, изучить его бизнес-процессы, понять, как адаптировать их к переводу в IT-формат (часто для этого приходится сильно менять бизнес-процесс), пообщаться с персоналом, работу которого нужно будет автоматизировать через приложение и т.п. Это глубокое погружение в продукт, после которого составляется грамотное ТЗ и осуществляется успешная разработка продукта.