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

Денис Гордиенко, руководитель студии разработки мобильных приложений 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 самых часто заказываемых типов приложений.

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Денис Гордиенко", "author_type": "self", "tags": [], "comments": 2, "likes": 11, "favorites": 41, "is_advertisement": false, "subsite_label": "life", "id": 78041, "is_wide": false, "is_ugc": true, "date": "Tue, 06 Aug 2019 18:23:04 +0300" }
{"average":26592,"one":95,"ten":75}
Сколько денег вы откладываете в месяц?
Ответьте и узнаете, сколько копят другие.
0 ₽
70 000+ ₽
0 ₽
{ "id": 78041, "author_id": 127886, "diff_limit": 1000, "urls": {"diff":"\/comments\/78041\/get","add":"\/comments\/78041\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/78041"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199123, "last_count_and_date": null }
2 комментария

Популярные

По порядку

1

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

Ответить
0

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

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

Ответить
0
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Хакеры смогли обойти двухфакторную
авторизацию с помощью уговоров
Подписаться на push-уведомления
{ "page_type": "default" }