Однажды ко мне пришел крупный застройщик, хотел обновить дизайн приложения. Провели два созвона, определились, что будет в дизайне. Делаю простенькое ТЗ на доп. разработку мобильного приложения. Все круто, казалось бы. Потом выяснилось, что нужно интегрироваться с 1С. Это сложная доработка, поэтому с командой делаем полноценное техническое задание. Присылаем им готовое ТЗ, договор и счет — ждем ответа. Проходит день, два… неделя. Мы забили, а потом увидели кейс у коллег по нашему ТЗ.
Тут мы отчасти сами виноваты — не могли остановиться и перелопатили кучу конкурентов, предлагали идеи и записывали их в ТЗ. В итоге потратили чересчур много времени на проект, который не сложился. Теперь делаем отдельный договор под ТЗ, когда видим, что планы меняются и за два созвона тут не порешать.
Содержание:
1. Почему платный бриф для разработки — норма?
2. Как понять, сколько денег брать за техническое задание для приложения?
3. Этапы разработки ТЗ
4. Как понять, какие вопросы задавать на брифе?
Почему платный бриф для разработки — это норма?
Представим ситуацию: к вам пришел клиент с запросом сделать сайт как у Apple. Никакого брендбука, только цвета из логотипа. Сначала проводим 1-2 бесплатных созвона. Если после них не появляется представление о том, какой продукт будет на выходе — нужно брифовать. Брифы займут как минимум 1 месяц. Это еженедельные созвоны, а параллельно ТЗ. Зачем? Чтобы клиент знал, что получит в итоге, а команда понимала, с каким объемом задач придется работать.
И почему такая работа должна выполняться бесплатно? (риторически в пустоту)
Как понять, сколько денег брать за техническое задание для приложения?
Я определяю стоимость ТЗ по часовой ставке менеджера, который будет его писать. В эти часы не включаю брифинг, только работу над техническим заданием.
Эти работы клиент оплачивает отдельным договором сразу.
Этапы разработки ТЗ
- Собираем общую информацию
После первичных созвонов с клиентами заключаем договор на техническое задание на разработку приложения. В течение 1-2 месяцев проводим еженедельные созвоны, менеджер параллельно пишет . Узнаем, что за приложение будет:
— для iOS или Android или и то и то?
— какие языки интерфейса нужны
— на чем будем делать
— какой язык программирования или технологию используем
— кто им будет пользоваться: регион публикации, регион использования.
— где оно будет размещаться: площадка публикации, сервер хранения
— как будем зарабатывать с помощью приложения
По поводу языков программирования — мы это определяем от задач, если у заказчика нет пожеланий. Вот такие есть три варианта:
1. No-code и Low-code приложение по технологии drag-and-drop
Такой вариант подходит, если: денег мало, сроки горят, нужно сразу и Android и IOS, нужны более ли менее стандартные понятные вещи. Для нас меньше мороки, а для заказчика быстрее и дешевле. Конечно, если приложение нельзя сделать помощью конструктора, мы пишем его кодом.
2. Нативные приложения
Отдельно пишем для IOS на Свифте и отдельно для Android на Котлине. Это самый надежный вариант. Его выбирают, когда планируется много анимаций.
3. Кроссплатформенные приложения
Вариант похож на нативные приложения, но его быстрее делать, и стоит он дешевле. Пишется сразу под IOS и Android на Flutter.
Как выбираем сервер хранения?
1. Для международных стартапов — облачные сервера хранения данных. Чаще всего у заказчика нет бюджета на то, чтобы сделать в каждой стране свой сервер. В таком случае мы используем специальные облачные сервисы, которые за нас распределяют данные в юрисдикции нужных стран.
2. Если работаем по России — подбираем по стоимости. Чаще всего пользуемся облаками, либо приобретаем сервер.
- Обсуждаем функционал
Мы описываем действия, которые клиент будет совершать в приложении. Действия должны быть максимально конкретными и с минимальным количеством технических деталей. Мы отвечаем на вопрос: что должен сделать клиент, чтобы совершить то или иное действие.
Например: Я, как пользователь, хочу иметь возможность добавлять товар в список избранных, для того чтобы в дальнейшем быстро находить его. Здесь понятно, что хочет клиент и для чего.
Антипример: я, как пользователь, хочу, чтобы приложение было удобно для использования. Тут непонятно, что конкретно хочет человек и что для него «удобно». Это общие слова и они не помогают понять, какой функционал ожидает пользователь.
Результат обсуждения с заказчиком идет в ТЗ по функционалу:
- Описываем интерфейс
Здесь уже наглядно показываем:
— какие экраны будут в приложении?
— что на каждом экране может сделать пользователь: какие кнопки нажать, куда написать, что перелистнуть?
Такая схема называется User Flow. Она нужна разработчикам и дизайнерам, чтобы видеть, что будет происходить в приложении. Так будет меньше риска, что придется исправлять кучу недочетов и переписывать код.
- Забираем брендбук и все, что с ним связано
Тут мы дорабатываем все требования к интерфейсу: прикрепляем брендбуки, референсы и макеты. По сути — это финальные согласования дизайна всего приложения. Здесь принимаем все оставшиеся правки.
Как понять, какие вопросы задавать на брифе?
Вопросы во многом зависят от ниши — если приложение для интернет-магазина, то будут одни вопросы, а если для агентства недвижимости, то другие. К нам часто обращаются за приложениями для интернет-магазинов, такси, кафе и ресторанов и агентств недвижимости.
Вот примерные вопросы, которые мы задаем:
Что по итогу?
По итогу понятно, что работы тут довольно много. Я пробежался по верхам, но на деле такое ТЗ может быть объемом до 120 страниц. Это супер детальная проработка всего, что будет делаться на сайте: от визуала до внутрянки. И брать за это деньги — логично.
Коллеги, а вы берете отдельные деньги за бриф и ТЗ?
Начал вести тг канал — там раз в неделю выпускаю статьи об IT для предпринимателей. Подписывайтесь, если вам такое интересно.
Занимаюсь проектированием систем умного дома, но за всё беру деньги.
Бесплатно только первичный созвон, чтобы клиент понял что мы ему сделаем и всё процессы по заключению договора. Потом все созвоны, работы, правки и выезды - считаются временные затраты и выставляется счёт.
Даже просто встретиться в Москве - за деньги, потому что 1.5-2 часа туда, 1-2 часа там и 1.5-2 часа обратно. После этого трипа эффективно работать уже не хочется.
Интересно, а конкуренты не предлагают бесплатный выезд?
Все предлагают бесплатный выезд. И пусть катаются, если у них есть на это бюджеты) имхо это бесполезная трата времени, всё можно и в зуме обсудить. А если надо выехать - то извольте заплатить, я не готов кучу часов тратить впустую
Наш клиент так сделал. Лучше прокачивать навыки продаж, чем навыки работы за бесплатно)
Вот обычно с нелюбовью все относятся к продажам, но если посмотреть под этим углом, то это способ получать справедливую оплату
Я так подумала, что мне у других исполнителей хотя бы малую часть от такой проработки не хватало.
Многие фрилансеры говорят: «нет тз - результат хз». А я иногда вообще не могу дать тз, потому что мне не хватает на это масштаба мышления и понимания их деятельности. И вот начинаю объяснять: «мне нужна такая штучка… ээээ… ну такая, лаконичная». А был бы хотя бы хороший бриф - я бы уже дала более-менее нормальное тз
Для этого, на самом деле, и нужны организации, в которых есть проектные менеджеры, работа которых и заключается в том, чтобы понять вашу идею и донести их до разработчиков на понятном и четком языке
У меня этап проектирования и он выглядит так:
1. Собираю функциональные требования (ФТ) к проекту (если для сбора потребуется больше двух-трёх часов моего времени, готовлю КП на этот этап работы);
2. На основе получившихся ФТ делаю оценку проектирования, выставляю КП на создание интерактивного прототипа;
3. Проектирую. Создаю интерактивный прототип в Axure. Сдаю его. Это позволяет согласовать с клиентом перелинкованные макеты, которые понятные простым смертным, а не User Flow или ТЗ, которые понятны специалистам. Выставляю КП на написание функциональной спецификации;
4. Расписываю логику проекта в функциональной спецификации. Вношу правки в прототип, они неизбежны на этом этапе;
5. Отдаю проектную документацию на оценку и в работу дизайнеру, слежу за тем, чтобы прототип, ФС и дизайн соответствовали друг другу.
На этом мой этап заканчивается — и я передаю проектную документацию и дизайн разработчикам на оценку. Весь мой этап ориентирован на разрабов. Как раз сегодня об этом пост писал: https://t.me/normfreelancer/674
Для кого я на самом деле проектирую интерфейсы?
Для разработчиков. Моя задача как проектировщика — пообщаться с клиентом, собрать его идеи и бизнес-запросы, а затем превратить в макеты и сопроводительную документацию для разработчиков. Если я плохо её оформлю или что-то забуду ...
Для кого я на самом деле проектирую интерфейсы?
Для разработчиков. Моя задача как проектировщика — пообщаться с клиентом, собрать его идеи и бизнес-запросы, а затем превратить в макеты и сопроводительную документацию для разработчиков. Если я плохо её оформлю или что-то забуду детализировать — пострадают именно они. Им придётся самим решать, как должен работать тот или иной участок системы.
Часто ли дизайнеры или проектировщики получают обратную связь от тех, кто дальше работает с документацией и макетами? Вопрос открытый. Когда я сам сдаю работу, то не ленюсь и через клиента спрашиваю, что думают разрабы о моих макетах и документации. Ответ обычно такой: «Мы не знаем. Раньше не сталкивались с такой подробной постановкой задачи. Если вопросы и возникали, то решали их сами».
Получается, что проектировщики и дизайнеры готовят задачу для разработчиков, но обычно не интересуются, насколько последним было удобно работать с макетами и документацией. А разработчики не могут адресовать вопросы по проекту дизайнерам и проектировщикам, потому что… Если честно, не понимаю, почему. Но ко мне за 300+ проектов вопросы от разработчиков прилетали всего два раза.
Для клиентов. Если я не сделаю довольным клиента, то результат моей работы может никогда и не добраться до разработчиков. Обычно клиент не в состоянии оценить мои навыки проектирования интерфейсов, зато сразу может оценить уровень сервиса и ответственность. Именно за счёт них я и повышаю уровень доверия к профессиональной составляющей своих услуг. Это первый этап.
Второй этап — сделать так, чтобы разработчики, которым легко и приятно работать с моей проектной документацией, быстрее и эффективнее справлялись бы со своей задачей. Ведь в конечном итоге именно за это клиент и платит проектировщику: сократить издержки на разработку за счёт уменьшения неопределённостей. Если это получилось — клиент будет довольным ещё раз уже через много месяцев после того, как получил от меня проектную документацию и передал своей команде.
Для пользователей. Несмотря на то, что это основа моей профессии, я придаю ей наименьшее значение. Если я не сумею сделать клиента довольным — никаких пользователей не будет. Если я не сумею предоставить грамотную проектную документацию для разработчиков — пользователи увидят не совсем тот интерфейс, который я задумывал.
От результата моей работы больше зависит то, с какой скоростью будет выпущен продукт. И вот когда он будет выпущен — тогда и появится первая обратная связь от пользователей. Если я сделал довольным клиента и разработчиков, то в этот момент я всё ещё буду рядом и смогу получить доступ к статистике и предложить внести изменения в получившийся результат, чтобы сделать его лучше.
Десять-двадцать таких проектов — и каждый следующий будет уже вполне сносным для всех участников процесса. В период обучения знаю только один реальный способ проектировать интерфейсы более-менее сносно: смотреть на уже работающие проекты (которым не меньше двух-трёх лет) и заимствовать их интерфейсы, стараясь понять, почему были использованы те или иные решения.
Итого. Для кого я проектирую интерфейсы?
В первую очередь — для разработчиков. Людей, которые будут брать мою проектную документацию и на её основе выполнять свою работу. От того, что я им предоставлю, будет зависеть качество и скорость разработки.
Во вторую очередь — для клиентов. Несмотря на то, что от них зависит оплата и дальнейшие обращения, клиенты всё-таки будут слушать, что разработчики скажут о результате моей работы. И если они скажут, что давно не работали с такой крутой проектной документацией, то лояльность клиента почти гарантирована.
В третью очередь — для пользователей. Они никогда не увидят мою проектную документацию и будут взаимодействовать с уже готовым проектом, который является результатом коллективного труда. И этот результат будет тем больше похож на задуманный мной изначально, чем больше будут довольны разработчики и клиент.
А как клиенты к такому относятся? Получается, что выставляется куча мелких счетов, а итоговая стоимость всего проекта непонятна. Можно и негатива схватить
Клиент знает для чего нужен каждый отдельный счёт. И понимает, что сделать оценку без последовательного проектирования можно только наугад. Поэтому негатива не встречал.
Конкуренция в программировании похоже скоро приведет к тому, что будут брать деньги даже за отправку КП
В бесплатных брифах расстраивает, когда на их основе потом пилят продукты, бесплатно забирая работу себе.
Кто ж у нас не любит халяву
Особенно не любят платить за идеи)
это совсем некрасиво...
а вы молодцы, отличная проработка
Да тут дело не в програмировании, а в том как часто все стали друг друга на..калывать
Наверное, и раньше так делали
У нас сейчас идет история: бота делаем клиенту... и деньги сказали ориентировочные, и договора пока нет совсем, а схему бота от нас хотят вот уже. А схема бота — это 90% работы. Из плюсов — клиента этого давно знаем... Но ситуация уязвимая
для чего вашему заказчику схема бота? опишите и согласуйте функционал, сроки, стоимость в переписке/на звонке. далее пусть заносит сразу предоплату и в бой. иначе ситуация будет как описано в статье, а лояльность мнимой. сколько ботов уже сделал - никогда не было договора и никто не просил схему, только кейсы, стоимость, сроки. когда проект до 100к рублей накладные расходы на тз,кп и прочие штуки будут сопоставимы с расходами на разработку. это не нужно ни вам, ни клиенту. вот если проект на несколько сотен тысяч или мультов это все необходимо - в больших проектах много деталей, все не удержать в голове + заказчик сам должен понимать как проводить приемку, а это будет понятно из ТЗ.
там заказчик — большая компания — у них там цепочкак согласований огромная на каждый чих. поэтому сначала печатают схему бота и ее добавляют в договор)
Отношения с клиентами решают, конечно
а вы если лично с клиентом встречаетесь, в этой же прическе? Просто любопытно
В этой шапке только если клиент с Кавказа
Только это не прическа, а Папаха))
Хотел возмутиться, но остановился. :)
То, что ты называешь «ТЗ» на самом деле «спецификация продукта», т.е. ты выходишь за рамки «автоматизации»/«цифровизации» и делаешь заказчикам ПРОДУКТ. Поэтому возникает много вопросов, какую работу для клиента выполняет приложение, какие боли устраняет и какие выгоды сулит. Это не разработка (составление) «ТЗ», это уже управленческий консалтинг. Правда, не ты, не заказчик не осознаете (не говорите об этом), что это очень сильно повлияет на весь бизнес. :)
Похоже стоит добавить это в раздел услуги, спасибо!
Процитирую:
"До разработки требуется определить требования и набор функциональности, которое необходимо реализовать в программном обеспечении, для этого предварительно проводится анализ бизнеса, идей и "хотелок" заказчика.
Аналитики изучают бизнес требования и формируют Техническое задание (ТЗ) или Спецификацию, с участием дизайнеров, которое включает:
• функциональные требования – описание основной и дополнительной функциональности, которое требуется реализовать в программном обеспечении;
• не функциональные требования – требования к среде исполнения, производительности, защищенности, наличия мониторинга, логирования и т.п.
• мокапы – схематическое изображение экранов или страниц с графическими элементами представления (надписи, таблицы и т.п.), ввода (поля и окна ввода, таблицы и т.п.) и управления (кнопки, радио кнопки, чек-боксы и т.п.), со схемой переходов между экранами;
• дизайн – графическое представление страниц и экранов программного обеспечения может дополнительно прилагаться к ТЗ (либо создаваться дизайнерами позже).
...
В классическом процессе разработки ТЗ или Спецификация для программиста является исходным документом, используемым в процессе разработки.
На основе Технического задания (или Спецификации) формируется список задач программистам для реализации."
("Профессиональные компетенции разработки программного обеспечения" Д.Черемнов)
Не понимаю, что ты хочешь сказать.
Обрати внимание на список вопросов, которые Никита собирается задать заказчику, и посмотри, сколько из них про организацию бизнеса, а не просто про FS/NFS сайта или приложения.
А спецификация на услуги такси и спецификация на приложение такси — это две большие разницы. :)
Я о том, что нормальное ТЗ (которое становится частью договора) на разработку приложения — это уже и есть спецификация.
Блин, спецификация чего?
Приложение для такси — это приложение для такси, а продукт — это услуги такси, там кроме приложения ещё водители и машины.
Не все что в сети является продуктом и не все продукты существует только в цифре.
Не буду продолжать, потому что не вижу смысла.
И не стоит.
Все верно и правильно. Работал с командами разработки (выстраивали процессы работы с клиентами). По факту - сформированное ТЗ это уже не малая ценность. Это один из субпродуктов проекта позволяющий сэкономить время, деньги и нервы.
Все верно, это по факту полноценная консультация. Если клиент не может ответить на вопрос, от решения которого зависят многие моменты, то нужно ему рассказать что это и почему это важно. Это время. А время стоит денег.
Я больше сторонник страхования, чем переживать о каждой сорвавшейся сделке. Увеличивается ценник для всех, а время на неудачную продажу компенсируется суммой со всех проектов. Для больших брендов и клиентов тендерные задания вообще делаются бесплатно.
Ну это тендер и бренд, у них есть какая-никакая репутация и процесс
а если маленткие - то что им мешает отказаться от вас, взяв готовый бриф, и продать бриф тем кто сделает дешевле?
Что мешает пользователю отказаться от моего платного брифа и уйти к тем, кто сделает еще дороже, но с бесплатным брифом. Тут не угадаешь. Просто закладывать время на продажи, это включает время ведения своих соцсетей/сайтов, составление шаблонов и пр. Тут не вопрос составления 40-страничного тз. Это отдельный пункт. Нужно минимальными усилиями дать клиенту адекватное кп, возможно с какой-то вилкой.
Ой, потерял месяц согласований, ну и ничего!
Согласен, ну умер и умер
Комментарий удален модератором
Почему в статье бриф противопоставляется тз?
Зачем делать платный бриф? Бриф это бриф, просто пожелания заказчика — он не решает задачи, которые должно решать ТЗ. ТЗ и вообще этап проектирования за деньги, причем в идеале по TM, потому что требования могут разрастаться, и часы на проектирование будут расти следом.
Мы брифуем клиента на протяжении всего составления ТЗ. То есть бриф это часть ТЗ. Как у вас получилось разделить эти этапы?
Комментарий удален модератором
Комментарий удален автором поста