Проектирование мобильного приложения. Опыт за год

Денис Гордиенко, генеральный директор Bright Mobile о том, какие выводы сделал по итогу года проектирования приложений, как отдельной услуги.

С марта прошлого года я веду отдельную услугу – проектирование. Понадобилась она ввиду следующих причин.

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

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

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

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

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

Предвкушая комментарии, хочу сразу оговориться. Да, в том, что ТЗ пишет исполнитель ничего нового нет, большинство студий так поступает уже не один десяток лет. Когда у меня была своя веб-студия мы продавали ТЗ клиентам в районе 40 тыс, делали описание страниц и прототипы всех макетов. Это выглядело примерно вот так.

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

В итоге такого подхода терялось драгоценное время, клиенты нервничали – так мы и пришли к тому, что нужно создавать отдельную услугу «проектирование». Изначально, чтобы понять востребованность я продавал её просто по 5 тыс, по факту делая в минус. Тут использовался принцип товара-крючка — убыточная услуга давала понять требовательность клиента и подстраховаться на основном договоре, экономя время программиста на багфиксе.

Разобравшись что и как лучше прописывать для программиста, перевёл проектирование в режим написания по ТМ, т.к. появилось примерно 30% заказчиков, которые берут готовое проектирование и идут с ним на fl. Это, само собой, их право, и никакого обмана меня в таком подходе нет, но для бизнеса это не выгодно.

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

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

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

Рассмотрим проектирование MVP на примере маркетплейса услуг, как я это делал, когда мы создавали RTPlatform. Здесь мы имеем три базовые сущности:

1. Пользователь. Клиент, который заказывает услугу.

2. Мастер. После заполнения специальной формы (профиля мастера) пользователь может стать мастером. Это уже отдельная сущность, которая может откликаться на те или иные заявки.

3. Заявки. Создаёт пользователь, когда хочет найти мастера

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

Пользователь. Он может создавать заявки, просматривать их, удалять, а также редактировать свои собственные. Сам пользователь создаётся при авторизации, просматривать его карточку в мини-версии смысла нет – хотя, конечно, можно дать возможность смотреть его профиль мастеру, но это уже улучшение, в MVP без него можно обойтись. Удалять пользователей может админ, эту функцию можно вынести в базу данных или в панель администратора; редактировать у нас пока по большему счёту просто нечего. Все эти данные к пользователю не относятся, к списку экранов добавляется только «авторизация» — это создание его сущности.

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

Редактирование профиля мастера можно сделать добавив эту возможность на экран создания профиля мастера: все имеющиеся поля будут заполнены ранее введёнными данными, которые можно изменить.

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

Понадобится и редактирование заявок, т.к. всегда возможны опечатки или же просто требуется добавить новые вводные в проект. Поскольку заявок много, то экран редактирования нужно делать отдельно. Удаление заявок можно просто добавить в раздел «моих заявок». Ну и, конечно, просмотр заявки мастером. На этом экране пользователь видит свою заявку и ответы исполнителей, а последние – заявку автора и свой отклик (как правило, отклики других мастеров для просмотра недоступны).

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

Обвязка. Обвязка — это экраны не свзанные с какой-либо сущностью, но так или иначе необходимые в сервисе. Для нашего MVP это будут:

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

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

Экран о сервисе. Тут можно создать слайдер с кратким FAQ как пользоваться нашим приложением.

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

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

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

Отсюда рассчитывается стоимость: количество экранов (в нашем случае – 16) умножается на затрачиваемое время по моему опыту, с учётом каркасов, серверной части и багфикса один экран делается 13 часов. Плюс интеграция эквайринга – возьмём для примера 40 часов. Итого получаем:

16 х 13 + 40 = 248 часов на разработку

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

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

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