Как я рассказываю заказчику, что он хочет?
Денис Гордиенко, руководитель студии разработки мобильных приложений Bright Mobile, о том, как проектировать приложения с наименьшими трудозатратами.
В конце мая я писал о том, как грамотно ставить задачи программисту. То есть, как перевести идеи клиента на технический язык и почему обычно ТЗ - это страдание для обеих сторон. В качестве решения этой проблемы я решил делать проектирование и использовать его, как техническое задание. Прошло 3 месяца. Опыта набрал много, в этой статье решил им поделиться.
Как обычно составляется ТЗ заказчиком
Сразу хочу оговориться, что цель этого раздела - не унизительное издевательство над документами, которые присылаются на оценку, а указание на проблемы, которые мешают программисту грамотно вникнуть и оценить сроки и стоимость работ. Поэтому, стараюсь быть максимально конструктивным. Для примеров я выбрал ТЗ, которые размещались публично на FL.ru и не находятся под NDA и прочими ограничивающими публичный просмотр условиями.
Принципиально я вижу три типа ошибочной подачи ТЗ:
- Максимально детализированное ТЗ на много (70+) страниц и без преамбулы с кратким описанием идеи.
- Различная детализация задачи. Очень часто встречается детальное описание типового экрана и буквально парой строчек сложная архитектурная конструкция.
- Описание в повествовательном стиле без чёткого разделения на экраны или хотя бы логические блоки.
Обычно проблема в том, что заказчики доносят идею, как они планируют реализовать процесс, то есть описывают бизнес-модель приложения. Программисты же хотят четких заданий, что и как должно быть на каждом экране.
Первоначально, я считал главной задачей проектирования- сформулировать разработчикам однозначно понятное ТЗ.
Идея делать небольшой документ с use case и описанием всех экранов полностью себя оправдала, программисты рады делать то, что понятно. Удалось решить проблему донесения информации. На 8-12 страницах излагается однозначно понятная структура документа и не нужно читать 70+ страниц или разбираться что имел ввиду заказчик в кратком описании проекта.
Но оказалось, что сам процесс создания проектирования, понимание сути идеи заказчика и согласование итогового документа с ним тоже имеет подводные камни.
Про трудности согласования проектирования
Как выглядел процесс коммуникации с заказчиком:
- Заказчик присылает данные в произвольном формате (специально не ограничиваю брифом, чтобы услышать правильные акценты).
- Я делаю проектирование с описанием всех экранов
- Презентую по вотсапу (голосом проходим по каждому экрану и обсуждаем вопросы).
- Далее идёт 3-4 итерации улучшений, когда мне или заказчику приходит опосля хорошая мысля и мы вносим её в документ.
Были случаи, когда проектирование уже готово, но мы приходили к выводу, что либо экранов получалось слишком много и проект не подходил по бюджету, либо упирались в технические ограничения сторонних сервисов. Изменение идеи приводило к тому, что нужно было бы начинать всю работу сначала.
В лучшем случае процесс занимал 1 рабочий день, в худшем, растягивался на 2-3 недели. Главная сложность была в том, что ТЗ на 6-10 страниц читалось намного проще, чем ТЗ на 70+ страниц, но если приложение содержало 20 и более экранов, то связать их в голове было сложно, особенно, если для заказчика это первый опыт создания приложения.
В общем, с момента завершения первичного проектирования до момента передачи такого ТЗ программисту процесс явно требовал оптимизации, как с точки зрения трудозатрат, так и "серого" времени на создание документа.
Внесение схемы связей между экранами
Оптимизацию того или иного процесса всегда нужно начинать с самой большой проблемы. Такой проблемой в текущем контексте была сложность "устаканить" экраны приложения в голове и понять взаимосвязи между экранами.
Пара заказчиков, чтобы донести свою идею до меня, при первоначальном разговоре, присылали схемы, где в Excel делали указатели между ячейками. Каждая такая ячейка - это экран приложения. Было намного понятнее, чем текстовая подача сплошным потоком и я решил взять такой метод на вооружение.
Важно было учесть, что ТЗ продаётся по демпинговой цене и, в терминологии продаж, является товаром-крючком, от которого нельзя отказаться в хорошем смысле этого слова. То есть ценность, которую получает клиент на порядок выше цены. В связи с этим, каждое дополнительное увеличение трудозатрат ещё сильнее перевешивает весы, но критичнее для экономики услуги.
Ради теста, до каких-либо изменений предложил ряду клиентов услугу по стоимости в 2 раза выше. Сильных отклонений конверсий не было, поэтому принял решение увеличить сумму и добавить разработку вот такой схемы в услугу:
При этом, для экономии времени, используются скрины экранов иных приложений, в целом похожие (регистрация для экрана регистрации, списочный экран для вывода списка новостей и т.д.), но время на них не тратится и такая схема делается в Figma за 2-3 часа. Наличие той или иной кнопочки в данном контексте не принципиально, а прототипы для конкретного проекта разрабатываются уже после согласования ТЗ.
После создания такой схемы мы созваниваемся с заказчиком, я рассказываю какой в приложении будет юз-кейс и движение пользователя по экранам.
Эта схема служит визуальным материалом, с помощью которого заказчику проще понять, логику работу приложения и как с ним будет взаимодействовать пользователь. Заказчик по ходу демонстрации сразу задает вопросы, говорит комментарии. И, если мы приходим к тому, что нужно внести стратегические изменения в архитектуру проекта, то сделать это гораздо проще, чем менять уже написанное текстом ТЗ.
Соответственно, текстовое описание пишется уже после создания такой схемы и согласования архитектуры. Если на этом этапе и есть изменения, то они носят локальный характер и вносятся за 30 минут. Таким образом, незначительно увеличив стоимость, получился более очевидное и понятное для клиента ТЗ, а для меня проект стал более очевидным с точки зрения трудозатрат и прогнозируемости результата.
Немного статистики
Эти 3 месяца я написал 29 ТЗ для мобильных приложений. Смог их классифицировать следующим образом:
- Сервисы поиска исполнителей (одни размещают заказ, другие предлагают услуги) - 15 шт
- Корпоративные приложения (личные кабинеты клиента) - 7 шт
- Доски объявлений (а-ля Авито) - 3шт
- Интернет-магазины (всё что связано с покупкой у одного продавца) - 3 шт
- Товарный маркетплейс (интернет-магазин с покупкой у нескольких вендоров) - 1 шт
Такой перекос отчасти связан с тем, что мы 2 года специализировались только на сервисах поиска исполнителей в тех или иных и, само собой, накопилась определённая история. С другой стороны, как показывает статистика, маркетплейсы услуг - это наиболее любимая тема для венчурных фондов.
Из этих 29 проектов :
- 15 так и остались на бумаге (для кого-то бюджет оказался в 4-5 раз выше ожиданий, кто-то сразу оговорился, что делает на перспективу, кто-то решил найти партнёров),
- 4 ушли к другим разработчикам,
- 10 остались с нами для разработки приложения.
Если здесь есть иные разработчики приложений, то будет интересно узнать, какой у вас Топ3 самых часто заказываемых типов приложений.
Да, если собирать за 2-3 часа - вполне хороший подход. Нормальный прототип с нуля = часов 40-60 занимает среднего сервиса.
А так получается бесплатно делаете прототип, который потом клиенты показывают другим компаниям для поиска меньшей цены?
Не совсем. Цена проектирования 10 тыс. По факту, это продажа 8 часов проектировщика, который описывает понятную структуру для программиста. В ходе работ и клиент к нам присматривается с точки зрения адекватности и мы к клиенту. Далее уже принимается решение о дальнейшем сотрудничестве.
Само собой, с итоговым документом, клиент может обратиться и к другим разработчикам, никаких подводных камней здесь нет.