В начале апреля озаботился вопросом, почему так часто программисты и клиенты не находят общий язык при создании проекта. Стал изучать пожелания к совместной работе обоих «лагерей» и делюсь с вами выводами.
Денис Гордиенко, генеральный директор Bright Mobile рассказывает о постановке задач для программистов.
Давайте вспомним, как обычно происходит, когда клиент обращается в студию или на фриланс. С его стороны обычно идёт некое описание конечной задачи в формате бизнес-процессов. Ко мне, чаще всего, обращаются по вопросам маркетплейсов и примерное описание выглядит так:
В приложении должны быть заказчики и исполнители, клиенты публикуют задания, исполнители откликаются и договариваются о сделке. заказчики выбирают лучшего, а сервис зарабатывает процент от заказа.
При этом, судя по опросу, программисты ждут чётко сформулированного чеклиста с однозначным пониманием каждого пункта.
Пример задачи на экран создания профиля:
Цель экрана: Дать исполнителю возможность размещаться в списке исполнителей и откликаться на заказы
Реализация: Пользователь заполняет анкету мастера и появляется в списке исполнителей. Поля, заполняемые исполнителем:
- Выбор категории
- Фото
- ФИО
- Номер телефона
- Краткая информация о себе
- Полная информация о себе
Кнопки сохранения и назад.
И так по всем экранам приложения. Программист видит в такой подаче несколько преимуществ:
- Чёткая задача - при просмотре экрана сразу видно что сделано, а что нет.
- Лёгкость при разборе правок (если договаривались на дизайн на усмотрение программиста, то правки принимаются только к формату полей ввода и работе кнопок).
- Ну и дополнительная плюшка - не нужно разбираться в идее бизнеса клиента и нести ответственность за не оговоренные нюансы.
Однако, если работа происходит по вводной, которая описана в формате бизнес-процессов, то программист делает проект так, как его понимает, либо просит написать клиента ТЗ. Самые частые варианты развития событий:
- Клиент страдает, пишет ТЗ, формализуя свои мысли, но из-за недостатка технических знаний упускает ряд моментов и приходится всё-равно что-то доуточнять в нескольких итерациях
- Программист берёт в работу задачу «как есть» и, опять же, страдая делает, постоянно уточняя те или иные нюансы у клиента.
Чаще всего, вне зависимости от варианта процесс сводится к тому, что программист недооценил объём работ или клиент в процессе что-то поменял. Поднимается вопрос о доплате и далеко не всегда стороны приходят к компромиссу. Достаточно посмотреть FL.ru и количество проектов на нём в стиле «сделано на 90%, осталось доделать чуть-чуть».
Это было лирическое отступление в стиле «как всё плохо». Давайте теперь поговорим о том, как сделать хорошо.
Проектирование в достаточном объёме
В начале апреля стал продумывать схему как удовлетворить обе стороны - клиенту дать чёткое описание его пожеланий, с честным бюджетом без перезакладывания на «хотелки», а программисту формализированное задание по которому будет удобно работать.
Почему, собственно, я хорошо понимаю обе стороны и их взаимные претензии друг к другу. Начинал свою деятельность как программист (отучился на профильной специальности и 5 лет работал на должностях программиста и системного администратора), затем основал свою первую компанию (в этом году ей будет 10 лет) и всё это время решал, как собственные бизнес-задачи, так и управлял программистами в заказных проектах. Получается работал в обоих лагерях и как разработчик, и как руководитель.
Пришёл я к достаточно простому выводу, что двум сторонам нужен переводчик. Грубо говоря человек, который переведёт задание клиента с языка бизнес-процессов на язык поэкранной структуры первой версии приложения. С 10-го апреля по 10-е мая я сделал 15 проектов для приложений. Получилась вот такая статистика:
- 5 клиентов заказали разработку приложения у нас
- 3 клиента решили, что выгоднее нанять фрилансера за меньшие деньги и дать ему в работу полученный документ
- 2 клиента передумали запускать проект, получив честный расклад по будущим затратам на развитие
- 5 клиентов находятся в стадии принятия решения или поиска бюджета на разработку.
Итак, 8 проектов пошли в работу. На данном этапе завершён 1, 4 в середине пути, 3 в начале. Первые выводы которые сделал — документ позволяет чётко разграничить что входило в ТЗ, а что нет. То есть тот самый конфликт может возникнуть только в случае, когда какая-то из сторон захочет откровенно кинуть партнёра, но в 95% случаях, парой кликов, можно определить входила та или иная часть работ в оговоренную сумму или нет.
Структура документа
Цель этой статьи - дать толчок развитию профессионального сообщества и понимания друг друга при постановке задач. Я пришёл к тому, что за основу следует взять такую структуру документа:
Вводная от клиента. Здесь прописывается тот самый базис, полученный от клиента, в формате «как я понял вводную задачу». Если этот блок ошибочен, значит эксперт не понял основной идеи приложения клиента и все следующие блоки нужно переписывать.
Юзер-кейс. Описание идеального процесса для всех ролей пользователей в приложении. Позволяет дать программисту понимание сценария использования приложения и учесть что является важным, а что обсуждаемым с точки зрения реализации.
Поэкранная структура. Принципиально важный для программиста раздел, в котором указаны все экраны приложения, их функциональная часть и логика работы.
Доп.функционал. Перечень функций не вошедший в экраны, но требующий существенных затрат. Например, подключение платёжного эквайринга, интеграция с сайтом или 1С и т.д.
Смета. Несколько вариантов реализации. Чаще всего два - с индивидуальном дизайном и на базовых шаблонах, с учётом дополнительных часов на минимальную индивидуализацию. Иногда добавляется третий вариант, где есть возможность часть функционала релизовать на готовых платформах.
Рекомендации. То, что эксперт посчитает нужным дополнительно сообщить клиенту. Чаще всего я использую несколько форматов:
- Если у клиента остро стоит финансовый вопрос, прописываю какие экраны можно перенести на следующую версию или не делать вовсе
- Если планируется обширное приложение, указываю, как те или иные задачи решались в аналогичных раскрученных приложениях
- Если стоит вопрос привлечения аудитории, даю рекомендации по раскрутке и примеры.
Пример проектирования для одного из готовых приложений. Можно использовать, как основу.
На данный момент, для следующей статьи, ищу клиента, который в процессе формирования идеи своего приложения. Хочу сделать проектирование бесплатно, с учётом публичного обсуждения и разбора. Кого заинтересовало - пишите по контактам на сайте выше и в профиле.
Денис, а вы слышали про такую специализацию как бизнес-аналитика? Вот аналитики всем этим и занимаются, что вы описали. Спеки под мобилки одни из самых простых.
Да, я знаю про это направление. Тут две проблемы:
1. В низком и среднем диапазоне применяется крайне редко, т.к. БА предполагает комплексный анализ и проектирование всей информационной инфраструктуры. Стоит от 50к и для низкобюджетных приложений вряд ли применима в полном объёме. Проектирование же стоит до 10 тыс и решает главную головную боль - перевести пожелания на язык структуры приложения.
2. Как с бизнес-тренерами и маркетологами, в бизнес-аналитике куча прохиндеев, которые дискредитируют профессию.
по поводу второго пункта - в точку. не жалко заплатить 50тыс, но если будешь уверен в результате. но к сожалению очень много "школьников" ищут легких денег :(
Здесь как раз речь о том, что бизнес-аналитика - это достаточно обширная услуга. Чаще всего, в полном объёме она нужна крупным компаниям типа банков или страховых. В проектирование за 5-10 тыс я выделил только самое необходимое, что поможет чётко донести задачу до программиста и на любом этапе разработки проверить входили те или иные требования в изначальную задачу или это доп.работы
но опять же за 5-10 тыс еще больше "школьников", которые сделают умный вид и будут рассказывать, что они все учли. остается полагаться на отзывы и примеры работ и что они не куплены и не украдены ;)
Денис, хороший подход, у меня есть на это несколько комментариев. Но я хочу предложить коллаб, в каком формате и как - к обсуждению. Я создатель инструмента который снимает ту самую проблему с которой не только я соглашусь двумя руками - ваш пункт первый, и точно также пункт второй, в той части что есть возможность прозрачно видеть результат анализа и всей структуры обсуждаемого / проектируемого продукта.
В общем я недавно на трибуне отписался (https://vc.ru/tribuna/67821-melnir-platforma-dlya-sozdaniya-tehnologicheskih-produktov), если предложение интересно - можем вместе сделать реальный разбор.
Меня беспокоит термин "юзер-кейс", встречающийся и в статье, и в примере.
Может быть use case?
Когда user story встречает use case..
Не толчёк, а толчок. У вас ошибка в статье, Денис. Но сама она интересная.
Спасибо. К сожалению, к 9-и вечера субботы уже окривел и пропустил
Столкнулся с этой проблемой будучи заказчиком, по-сути сам занимался переводом своего проекта с языка бизнес-задач на язык документации. Сейчас понимаю, что готов был бы отдать часть денег за перевод. И немного начал понимать в механике ценообразования на фриланс биржах.
Я как раз об этом и писал. Чтобы грамотно прописать задачу программисту, нужно "прожить" несколько проектов и набить шишки. Как показал мой тест, клиенты готовы на старте оплатить проектирование за 5 тыс, чтобы за них продумали всю архитектуру приложения.
Подход в корне неверен. Стартап нельзя сделать работая с дев студией - необходимо создавать свою команду которой не пофиг. Во вторых, если уж и заниматься проектированием то это должен специальный человек - архитектор ( а ещё лучше, команда ) а не программист и тем более не бизнес аналитик. Т.е. кто-то кто изучает бизнес идею, рынок, конкурентов, работает с клиентом и течении месяца-двух создаёт 100-300 страничный документ со всеми внутренними экранами из которых понятна бизнес логика.
в корне не верный подход - это начинать разработку стартапа с создания за 2 месяца трёхсот страничного документа.
Большенство сложных B2B систем по другому не сделать ( а несложные бизнесу обычно не нужны ). Простые же B2C эппы это множество постоянных итерации и глубокое понимание пользователей и индустрии.
Т.е. поинт в том что у вас на сайте написано что вы сделали 150 эппов. Но я сомневаюсь что хоть один из этих эппов реально успешный и вылез из песочницы. Не потому что вы плохие программисты а потому что сам подход не работает. Нельзя что-то сделать а потом это что-то раскручивать - всё намного намного сложнее. Нужен дух, команда, множество итераций, метрики, деньги, постоянный поиск того что именно нужно делать, общение с пользователями и т.д.
Спасибо, структуру документа попробую использовать в дальнейших проектах. Тот документ который указан в примере, не содержит трудозатраты по часам на реализацию. Так же интересно, трудозатраты на формирование самого документа
Обычно мы закладываем 9 часов на экран на шаблонном дизайне ionic и по 16 часов, если нужно собрать по макету от дизайнера. Понятно, что у разных экранов разная сложность, но в контексте проекта среднее значение примерно такое.
Сам документ пишется, в зависимости от сложности задачи где-то 2,5 часа с учётом презентации клиенту по звонку в вотсапе. Минимум было 1,5 часа, максимум - 4. Стоимость 5 тыс, в особых случаях 10
Очень интересно. В настоящее время вынашиваю идею создания мобильного приложения. Изучаю рынок исполнителей и способы грамотного составления ТЗ для них. Прикидываю интерфейс и способы реализации тех или иных «плюшек» в приложении путём рисования блок-схем с описанием и обоснованием.
напишите мне в вк или на [email protected] помогу с проектированием
По первому скриншоту уже хочется сказать плохой ux у вас) гайдлайны хотя бы соблюдайте
Но статья годная. Даже может пригодиться как материал при переговорах с заказчиками
Присылайте ко мне, верну обратно на просчёт сметы с продуманным проектом.
Отступы у кнопки по 16 с каждого края сделать надо , в остальном более менее.
Нет, кнопка «сохранить» должна быть в правом верхнем углу или как минимум не выходить за рамки лайоута
Это стандартный темплейт 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
На самом деле всё сложнее. Заказчик порой даже теоретически не понимает как составить ТЗ и что туда вписывать. Требовать бессмысленно, проще показать десяток готовых решений со стоимостью.
Например, если вас попросить составить ТЗ на изготовление колбасы, справитесь?) Я - нет.
Я занимаюсь разработкой ПСД и уже давно перестал требовать ТЗ - бесполезно. Шаблон, примеры и беседа с вопросами - дальше сам составляешь ТЗ.
Правда бывает ещё хуже: отказываются читать ТЗ по причине: «Я всё равно в этом ничего не понимаю». Жалею о потраченном времени, но с такими стараюсь не работать.
Вторая сторона проблемы, когда заказчик - я сам. Я считаю себя профессионалом и могу расписать ТЗ до последнего гвоздя. Но субподрядчики не готовы читать. Включается т.н. «клиповое мышление» когда инфа воспринимается на уровне картинок, а после третьего прочитанного предложения наступает ступор. Заметил, что осилить и понять текст, занимающий больше чем А4 народ не в состоянии.
А за ссылку спасибо!
Да, такое тоже бывает. Ещё одна сторона медали - когда присылается ТЗ на 130 стр и на этапе пресейла, когда ты понимаешь, что до договора ещё далеко, чтение идёт по верхам. Постарался как раз в проектировании учесть простоту восприятия, чтобы даже по верхам был понятен объём.
с одной стороны, я в вашей области не раираюсь. с другой - стойкое ощущение, что вы, будучи самоучкой, изобрели велосипед
и по моему, то что вы делаете - и есть составление нормального ТЗ. такого, что ясно программисту, и позволяет проверить что он всё реализовал
Как правило, ТЗ, которые приходят на оценку - это либо описание задачи в свободном стиле на половину странички, либо максимально детализированный документ, на изучение которого нужно потратить 2-3 часа без гарантий заключения договора. Я предложил нечто среднее, где прописывается принципиально важный для проекта функционал, а оценку можно сделать за 15-20 мин
Денис, спасибо за статью - очень хорошо описана "боль". По решению есть несколько идей, как можно дополнить статью:
- ценность user story еще и в возможности заказчика выставить приоритеты, а также выделить промежуточные этапы поставки и оплаты.
- составление такой спецификации может быть одной из задач самой команды- это с одной стороны сразу повышает понимание задач, с другой - вовлеченность.