Проектирование мобильного приложения — как грамотно поставить задачу программисту

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

В закладки
Аудио

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

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

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

Джейсон Стетхем
Заказчик маркетплейса

При этом, судя по опросу, программисты ждут чётко сформулированного чеклиста с однозначным пониманием каждого пункта.

Пример задачи на экран создания профиля:

Цель экрана: Дать исполнителю возможность размещаться в списке исполнителей и откликаться на заказы

Реализация: Пользователь заполняет анкету мастера и появляется в списке исполнителей. Поля, заполняемые исполнителем:

  • Выбор категории
  • Фото
  • ФИО
  • Номер телефона
  • Краткая информация о себе
  • Полная информация о себе

Кнопки сохранения и назад.

И так по всем экранам приложения. Программист видит в такой подаче несколько преимуществ:

  • Чёткая задача - при просмотре экрана сразу видно что сделано, а что нет.
  • Лёгкость при разборе правок (если договаривались на дизайн на усмотрение программиста, то правки принимаются только к формату полей ввода и работе кнопок).
  • Ну и дополнительная плюшка - не нужно разбираться в идее бизнеса клиента и нести ответственность за не оговоренные нюансы.
Итоговый результат правильно поставленной задачи

Однако, если работа происходит по вводной, которая описана в формате бизнес-процессов, то программист делает проект так, как его понимает, либо просит написать клиента ТЗ. Самые частые варианты развития событий:

  • Клиент страдает, пишет ТЗ, формализуя свои мысли, но из-за недостатка технических знаний упускает ряд моментов и приходится всё-равно что-то доуточнять в нескольких итерациях
  • Программист берёт в работу задачу «как есть» и, опять же, страдая делает, постоянно уточняя те или иные нюансы у клиента.

Чаще всего, вне зависимости от варианта процесс сводится к тому, что программист недооценил объём работ или клиент в процессе что-то поменял. Поднимается вопрос о доплате и далеко не всегда стороны приходят к компромиссу. Достаточно посмотреть FL.ru и количество проектов на нём в стиле «сделано на 90%, осталось доделать чуть-чуть».

Это было лирическое отступление в стиле «как всё плохо». Давайте теперь поговорим о том, как сделать хорошо.

Проектирование в достаточном объёме

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

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

Пришёл я к достаточно простому выводу, что двум сторонам нужен переводчик. Грубо говоря человек, который переведёт задание клиента с языка бизнес-процессов на язык поэкранной структуры первой версии приложения. С 10-го апреля по 10-е мая я сделал 15 проектов для приложений. Получилась вот такая статистика:

  • 5 клиентов заказали разработку приложения у нас
  • 3 клиента решили, что выгоднее нанять фрилансера за меньшие деньги и дать ему в работу полученный документ
  • 2 клиента передумали запускать проект, получив честный расклад по будущим затратам на развитие
  • 5 клиентов находятся в стадии принятия решения или поиска бюджета на разработку.

Итак, 8 проектов пошли в работу. На данном этапе завершён 1, 4 в середине пути, 3 в начале. Первые выводы которые сделал — документ позволяет чётко разграничить что входило в ТЗ, а что нет. То есть тот самый конфликт может возникнуть только в случае, когда какая-то из сторон захочет откровенно кинуть партнёра, но в 95% случаях, парой кликов, можно определить входила та или иная часть работ в оговоренную сумму или нет.

Структура документа

Цель этой статьи - дать толчок развитию профессионального сообщества и понимания друг друга при постановке задач. Я пришёл к тому, что за основу следует взять такую структуру документа:

Вводная от клиента. Здесь прописывается тот самый базис, полученный от клиента, в формате «как я понял вводную задачу». Если этот блок ошибочен, значит эксперт не понял основной идеи приложения клиента и все следующие блоки нужно переписывать.

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

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

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

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

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

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

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

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

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

Написать
{ "author_name": "Денис Гордиенко", "author_type": "self", "tags": [], "comments": 30, "likes": 34, "favorites": 310, "is_advertisement": false, "subsite_label": "life", "id": 67894, "is_wide": false, "is_ugc": true, "date": "Sat, 18 May 2019 20:39:29 +0300" }
{ "id": 67894, "author_id": 127886, "diff_limit": 1000, "urls": {"diff":"\/comments\/67894\/get","add":"\/comments\/67894\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/67894"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199123, "last_count_and_date": null }

30 комментариев 30 комм.

Популярные

По порядку

Написать комментарий...
5

Денис, а вы слышали про такую специализацию как бизнес-аналитика? Вот аналитики всем этим и занимаются, что вы описали. Спеки под мобилки одни из самых простых.

Ответить
4

Да, я знаю про это направление. Тут две проблемы:
1. В низком и среднем диапазоне применяется крайне редко, т.к. БА предполагает комплексный анализ и проектирование всей информационной инфраструктуры. Стоит от 50к и для низкобюджетных приложений вряд ли применима в полном объёме. Проектирование же стоит до 10 тыс и решает главную головную боль - перевести пожелания на язык структуры приложения.
2. Как с бизнес-тренерами и маркетологами, в бизнес-аналитике куча прохиндеев, которые дискредитируют профессию.

Ответить
1

по поводу второго пункта - в точку. не жалко заплатить 50тыс, но если будешь уверен в результате. но к сожалению очень много "школьников" ищут легких денег :(

Ответить
1

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

Ответить
0

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

Ответить
0

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

В общем я недавно на трибуне отписался (https://vc.ru/tribuna/67821-melnir-platforma-dlya-sozdaniya-tehnologicheskih-produktov), если предложение интересно - можем вместе сделать реальный разбор.

Ответить
5

Меня беспокоит термин "юзер-кейс", встречающийся и в статье, и в примере.
Может быть use case?

Ответить
0

Когда user story встречает use case..

Ответить
2

Не толчёк, а толчок. У вас ошибка в статье, Денис. Но сама она интересная.

Ответить
0

Спасибо. К сожалению, к 9-и вечера субботы уже окривел и пропустил

Ответить
2

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

Ответить
0

Я как раз об этом и писал. Чтобы грамотно прописать задачу программисту, нужно "прожить" несколько проектов и набить шишки. Как показал мой тест, клиенты готовы на старте оплатить проектирование за 5 тыс, чтобы за них продумали всю архитектуру приложения.

Ответить
1

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

Ответить
0

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

Ответить
4

Большенство сложных B2B систем по другому не сделать ( а несложные бизнесу обычно не нужны ). Простые же B2C эппы это множество постоянных итерации и глубокое понимание пользователей и индустрии.

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

Ответить
1

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

Ответить
0

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

Сам документ пишется, в зависимости от сложности задачи где-то 2,5 часа с учётом презентации клиенту по звонку в вотсапе. Минимум было 1,5 часа, максимум - 4. Стоимость 5 тыс, в особых случаях 10

Ответить
1

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

Ответить
0

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

Ответить
1

Но статья годная. Даже может пригодиться как материал при переговорах с заказчиками

Ответить
0

Присылайте ко мне, верну обратно на просчёт сметы с продуманным проектом.

Ответить
1

Отступы у кнопки по 16 с каждого края сделать надо , в остальном более менее.

Ответить
0

Нет, кнопка «сохранить» должна быть в правом верхнем углу или как минимум не выходить за рамки лайоута

Ответить
0

Это стандартный темплейт Ionic. В примере как раз две сметы - с отрисовкой и вёрсткой "пиксель в пиксель" индивидуального дизайна или экономия трудозатрат с использованием иониковского шаблона. Если стоит задача проверить идею в целом, то имеет смысл делать дизайн по-проще и сэкономить 40% денег, а если идея проверена, то можно и накатить в обновлении дизайнерский интерфейс. Вот пример приложения по заказу услуг, которое запустили с готовыми темплейтами сильно дешевле 100 тыс за обе системы:
https://play.google.com/store/apps/details?id=help.kubera.app
https://itunes.apple.com/us/app/kubera/id1460117918?l=ru&ls=1&mt=8

Ответить
0

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

На самом деле всё сложнее. Заказчик порой даже теоретически не понимает как составить ТЗ и что туда вписывать. Требовать бессмысленно, проще показать десяток готовых решений со стоимостью.
Например, если вас попросить составить ТЗ на изготовление колбасы, справитесь?) Я - нет.
Я занимаюсь разработкой ПСД и уже давно перестал требовать ТЗ - бесполезно. Шаблон, примеры и беседа с вопросами - дальше сам составляешь ТЗ.
Правда бывает ещё хуже: отказываются читать ТЗ по причине: «Я всё равно в этом ничего не понимаю». Жалею о потраченном времени, но с такими стараюсь не работать.
Вторая сторона проблемы, когда заказчик - я сам. Я считаю себя профессионалом и могу расписать ТЗ до последнего гвоздя. Но субподрядчики не готовы читать. Включается т.н. «клиповое мышление» когда инфа воспринимается на уровне картинок, а после третьего прочитанного предложения наступает ступор. Заметил, что осилить и понять текст, занимающий больше чем А4 народ не в состоянии.
А за ссылку спасибо!

Ответить
0

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

Ответить
0

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

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

Ответить
0

Как правило, ТЗ, которые приходят на оценку - это либо описание задачи в свободном стиле на половину странички, либо максимально детализированный документ, на изучение которого нужно потратить 2-3 часа без гарантий заключения договора. Я предложил нечто среднее, где прописывается принципиально важный для проекта функционал, а оценку можно сделать за 15-20 мин

Ответить
0

Денис, спасибо за статью - очень хорошо описана "боль". По решению есть несколько идей, как можно дополнить статью:
- ценность user story еще и в возможности заказчика выставить приоритеты, а также выделить промежуточные этапы поставки и оплаты.
- составление такой спецификации может быть одной из задач самой команды- это с одной стороны сразу повышает понимание задач, с другой - вовлеченность.

Ответить
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" }