Как я рассказываю заказчику, что он хочет?

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

В конце мая я писал о том, как грамотно ставить задачи программисту. То есть, как перевести идеи клиента на технический язык и почему обычно ТЗ - это страдание для обеих сторон. В качестве решения этой проблемы я решил делать проектирование и использовать его, как техническое задание. Прошло 3 месяца. Опыта набрал много, в этой статье решил им поделиться.

Как обычно составляется ТЗ заказчиком

Сразу хочу оговориться, что цель этого раздела - не унизительное издевательство над документами, которые присылаются на оценку, а указание на проблемы, которые мешают программисту грамотно вникнуть и оценить сроки и стоимость работ. Поэтому, стараюсь быть максимально конструктивным. Для примеров я выбрал ТЗ, которые размещались публично на FL.ru и не находятся под NDA и прочими ограничивающими публичный просмотр условиями.

Принципиально я вижу три типа ошибочной подачи ТЗ:

  1. Максимально детализированное ТЗ на много (70+) страниц и без преамбулы с кратким описанием идеи.
  2. Различная детализация задачи. Очень часто встречается детальное описание типового экрана и буквально парой строчек сложная архитектурная конструкция.
  3. Описание в повествовательном стиле без чёткого разделения на экраны или хотя бы логические блоки.
Логичный вопрос - что Вам нужно сделать? Описание разделов сильно сократило бы время на подбор программиста.
Здесь лучше, но всё-рано не понятна общая идея приложения, просто список функциональных блоков.

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

Первоначально, я считал главной задачей проектирования- сформулировать разработчикам однозначно понятное ТЗ.

Идея делать небольшой документ с use case и описанием всех экранов полностью себя оправдала, программисты рады делать то, что понятно. Удалось решить проблему донесения информации. На 8-12 страницах излагается однозначно понятная структура документа и не нужно читать 70+ страниц или разбираться что имел ввиду заказчик в кратком описании проекта.

Но оказалось, что сам процесс создания проектирования, понимание сути идеи заказчика и согласование итогового документа с ним тоже имеет подводные камни.

Про трудности согласования проектирования

Как выглядел процесс коммуникации с заказчиком:

  • Заказчик присылает данные в произвольном формате (специально не ограничиваю брифом, чтобы услышать правильные акценты).
  • Я делаю проектирование с описанием всех экранов
  • Презентую по вотсапу (голосом проходим по каждому экрану и обсуждаем вопросы).
  • Далее идёт 3-4 итерации улучшений, когда мне или заказчику приходит опосля хорошая мысля и мы вносим её в документ.

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

В лучшем случае процесс занимал 1 рабочий день, в худшем, растягивался на 2-3 недели. Главная сложность была в том, что ТЗ на 6-10 страниц читалось намного проще, чем ТЗ на 70+ страниц, но если приложение содержало 20 и более экранов, то связать их в голове было сложно, особенно, если для заказчика это первый опыт создания приложения.

В общем, с момента завершения первичного проектирования до момента передачи такого ТЗ программисту процесс явно требовал оптимизации, как с точки зрения трудозатрат, так и "серого" времени на создание документа.

Внесение схемы связей между экранами

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

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

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

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

Пример схемы связей

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

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

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

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

Немного статистики

Эти 3 месяца я написал 29 ТЗ для мобильных приложений. Смог их классифицировать следующим образом:

  1. Сервисы поиска исполнителей (одни размещают заказ, другие предлагают услуги) - 15 шт
  2. Корпоративные приложения (личные кабинеты клиента) - 7 шт
  3. Доски объявлений (а-ля Авито) - 3шт
  4. Интернет-магазины (всё что связано с покупкой у одного продавца) - 3 шт
  5. Товарный маркетплейс (интернет-магазин с покупкой у нескольких вендоров) - 1 шт

Такой перекос отчасти связан с тем, что мы 2 года специализировались только на сервисах поиска исполнителей в тех или иных и, само собой, накопилась определённая история. С другой стороны, как показывает статистика, маркетплейсы услуг - это наиболее любимая тема для венчурных фондов.

Из этих 29 проектов :

  • 15 так и остались на бумаге (для кого-то бюджет оказался в 4-5 раз выше ожиданий, кто-то сразу оговорился, что делает на перспективу, кто-то решил найти партнёров),
  • 4 ушли к другим разработчикам,
  • 10 остались с нами для разработки приложения.

Если здесь есть иные разработчики приложений, то будет интересно узнать, какой у вас Топ3 самых часто заказываемых типов приложений.

0
2 комментария
Юрий Корхов

Да, если собирать за 2-3 часа - вполне хороший подход. Нормальный прототип с нуля = часов 40-60 занимает среднего сервиса.
А так получается бесплатно делаете прототип, который потом клиенты показывают другим компаниям для поиска меньшей цены?

Ответить
Развернуть ветку
Денис Гордиенко
Автор

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

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

Ответить
Развернуть ветку
-1 комментариев
Раскрывать всегда