Конкурс по машинному обучению
С призовым фондом в 100 млн рублей
Условия

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

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

В закладки

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

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

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

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

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

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

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

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

Объявление на vc.ru
Маркетинг
Как преподнести продукт на сайте и вызвать доверие клиентов: секретная редакторская методика
Привет! Я редактор-маркетолог, делаю лендинги 7 лет. Считается, что успех сайта зависит от текста, дизайна и всяких…

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

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

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

  • Заказчик присылает данные в произвольном формате (специально не ограничиваю брифом, чтобы услышать правильные акценты).
  • Я делаю проектирование с описанием всех экранов
  • Презентую по вотсапу (голосом проходим по каждому экрану и обсуждаем вопросы).
  • Далее идёт 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": 42, "is_advertisement": false, "subsite_label": "life", "id": 78041, "is_wide": false, "is_ugc": true, "date": "Tue, 06 Aug 2019 18:23:04 +0300", "is_special": false }
Финансы
Как бизнесу распознать среди проектов нерентабельные и что с ними делать (отказываться необязательно)
Создатель сервиса Adesk Степан Родионов — о том, как среди десятков проектов найти нерентабельные и что с ними делать…
Объявление на vc.ru
0
2 комментария
Популярные
По порядку
1

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

Ответить
1

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

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

Ответить

Комментарии

null