Мы свяжемся с вами
Просто заполните форму и мы свяжемся с вами самостоятельно
Мы свяжемся с вами
Просто заполните форму и мы свяжемся с вами самостоятельно
Мы свяжемся с вами
Просто заполните форму и мы свяжемся с вами самостоятельно
Ключевой этап в запуске приложения
Все начинается с технического задания.
эксперт: Игнат Егоров
Любое приложение начинается с технического задания. Более того - на мой взгляд именно качество проработки идеи на этапе технического задания и определяет успех проекта.
Выписывать на бумажку функции может выглядеть скучным, по сравнению с тем, чтобы сразу кинуться делать дизайн или тем более разрабатывать приложение. Но!
Я всегда подхожу к проекту как бизнесу, как к инвестициям, поэтому мне важно понимать, сколько будет приносить каждый вложенный рубль. Если какая-то функция ПРЯМО СЕЙЧАС не будет зарабатывать деньги и не является необходимой для работы всего приложения, то от такой функции лучше временно отказаться и реализовать ее во 2ой или 3ей версии приложения, если на то будет спрос.
За годы работы для меня ТЗ стало уже некой духовной практикой, аскезой, когда нужно сесть и аккуратно, отринув запал и эмоции, дисциплинированно расписать - какие функции должны быть в приложении ПРЯМО СЕЙЧАС.
Эту практику я внедрил и при работе над клиентскими проектами.
Выписывать на бумажку функции может выглядеть скучным, по сравнению с тем, чтобы сразу кинуться делать дизайн или тем более разрабатывать приложение. Но!
Я всегда подхожу к проекту как бизнесу, как к инвестициям, поэтому мне важно понимать, сколько будет приносить каждый вложенный рубль. Если какая-то функция ПРЯМО СЕЙЧАС не будет зарабатывать деньги и не является необходимой для работы всего приложения, то от такой функции лучше временно отказаться и реализовать ее во 2ой или 3ей версии приложения, если на то будет спрос.
За годы работы для меня ТЗ стало уже некой духовной практикой, аскезой, когда нужно сесть и аккуратно, отринув запал и эмоции, дисциплинированно расписать - какие функции должны быть в приложении ПРЯМО СЕЙЧАС.
Эту практику я внедрил и при работе над клиентскими проектами.
Техническое задание в AppBusters
Для нас техническое задание – ключевой и обязательный этап. Даже если клиент самостоятельно “все уже написал” - мы будем садиться и переписывать по-своему. Почему?
Любой запуск проекта - это работа в тандеме. Команда, подрядчики должны “от и до” понимать видение заказчика, чтобы на выходе получилось то, что требовалось.
Любой запуск проекта - это работа в тандеме. Команда, подрядчики должны “от и до” понимать видение заказчика, чтобы на выходе получилось то, что требовалось.
Работа по чужому ТЗ может привести к “искажениям”, а также к дополнительным затратам.
Первая причина:
Очень часто люди пишут в ТЗ все, что “вообще потенциально хотелось бы разработать”. Они не оценивают эти функции в контексте вложений и прибыли, отчего частенько техническое задание раздувается до совсем неприличных бюджетов и сроков.
Вторая причина:
Если ТЗ пишут НЕ программисты, то частенько появляются функции, которые… так просто не работают.
Первая причина:
Очень часто люди пишут в ТЗ все, что “вообще потенциально хотелось бы разработать”. Они не оценивают эти функции в контексте вложений и прибыли, отчего частенько техническое задание раздувается до совсем неприличных бюджетов и сроков.
Вторая причина:
Если ТЗ пишут НЕ программисты, то частенько появляются функции, которые… так просто не работают.
Пример:
Мой любимый пример - авторизация по ТЕЛЕФОНУ и ПАРОЛЮ. Был у меня клиент, который настойчиво хотел сделать такую функцию и вписал ее в свое ТЗ. Но вот в чем суть. В мире разработки существуют 2 шаблонных варианта авторизации: через ТЕЛЕФОН + КОД ИЗ СМС и через EMAIL + ПАРОЛЬ. Для этих авторизаций у нас, у разработчиков, есть уже готовый написанный код, который остается только взять и подключить. Бонусом идет то, что все в мире пользователи приложений тоже уже привыкли именно к этим 2м вариантам авторизации.
Клиент же в своем ТЗ изобретает велосипед. Можно сделать, как хочешь клиент (с авторизацией через ТЕЛЕФОН + ПАРОЛЬ)? - да можно конечно. Только вот:
Клиент же в своем ТЗ изобретает велосипед. Можно сделать, как хочешь клиент (с авторизацией через ТЕЛЕФОН + ПАРОЛЬ)? - да можно конечно. Только вот:
- Это займет больше времени у разработчика, так как делать придется с нуля - следователь весь проект выйдет дороже
- Это будет сбивать пользователей и ронять конверсию в завершение регистрации.
- Для отправки паролей по смс (для смены пароля) клиенту придется отдельно оплачивать еще и каждую смску (письма о смене пароля на email отправляются бесплатно), что повлечет рост расходов на приложение.
Стоит оно того? Окупится ли эта функция когда-нибудь? Думаю вопрос риторический. Это мелочи, но именно такие мелочи и определяют успех проекта.
Именно поэтому мне проще потратить лишнее время на дополнительные созвоны с клиентам, оплатить дополнительную работу своей команде из своего кармана, но четко понимать, что «мы друг друга услышали и понимаем, что делаем и куда идем».
Сколько стоит техническое задание?
Я бы сказал, что ТЗ у нас бесплатное, но на деле это не совсем так - ТЗ стоит символические 5.000 рублей. Мы ввели эту сумму потому, что в определенный момент нас просто завалили люди с праздным интересом, которые просили “написать и посчитать” их идею. Введение такой небольшой платы сильно снизило количество “просто мимо проходящих” людей 😁
Я считаю, что ТЗ для клиента бесплатное, потому что на проработку и подготовку каждого ТЗ мы затрачиваем из своего кармана гораздо больше, чем 5.000 рублей. То есть этот процесс для нас убыточный.
Но небольшие убытки сейчас сторицей окупаются в будущем, когда благодаря правильно проработанной идеи и четкой оценки приложение в срок выходит в стор и начинает зарабатывать клиенту деньги.
Я считаю, что ТЗ для клиента бесплатное, потому что на проработку и подготовку каждого ТЗ мы затрачиваем из своего кармана гораздо больше, чем 5.000 рублей. То есть этот процесс для нас убыточный.
Но небольшие убытки сейчас сторицей окупаются в будущем, когда благодаря правильно проработанной идеи и четкой оценки приложение в срок выходит в стор и начинает зарабатывать клиенту деньги.
Как строится работа по написанию технического задания?
Шаг 1. Зум созвон с клиентом:
Проводим зум-созвон с потенциальным клиентом. В среднем это занимает 40 минут. На созвоне важно без сломанного телефона “услышать”, что хочет клиент и постараться найти “дыры в логике” его проекта. По итогу созвона у технической команды должно сформироваться целостное видение бизнеса клиента, его задач, идеи и понимание, как в эту картину лучше всего вписать приложение.
Порой приходится буквально допрашивать клиента, чтобы точно ничего не забыть.
Порой приходится буквально допрашивать клиента, чтобы точно ничего не забыть.
Пример технического зум-созвона:
Обратился владелец клининговой компании с идей разработать мобильное приложение с "подпиской на уборку".
Шаг 2. Удаляемся на написание тех.задания:
В среднем этот процесс у нас занимает 1-2 дня плотной работы. Что нужно?
В итоге стараемся подружить наш опыт, финансовые ограничения и пожелания клиента в одном продукте)
- На основе полученной на шаге 1 информации нужно по сути придумать с нуля приложение для клиента, которое бы решало его задачи и вписывалось в текущие бизнес процессы
- При этом соблюсти ограничения в бюджете и сроках на работу. То есть понятно, что за “бесконечно долго и бесконечно дорого” можно сделать что угодно, но вот что делать, если клиент прямо сказал, что ждет решения за 750к и 3 месяца? Приходится придумывать приложение с учетом этих ограничений.
- Само собой всегда стоит в работе использовать опыт других людей. Для этого мы ищем похожие приложения на просторе интернета, чтобы “подсмотреть” интересные решения и подходы. Например, у нас есть 7 аккаунтов в google play и app store, зарегистрированные на разные страны, чтобы иметь возможность ставить приложения, которые недоступны в РФ
- Также у нас у самих имеется уже богатый опыт запуска IT продуктов. Если мы понимаем, что функция “опроса перед регистрацией” сработала в похожем по целевой аудитории проекте и дала прирост конверсии в регистрацию, то в новом ТЗ предложим внедрить этот подход.
В итоге стараемся подружить наш опыт, финансовые ограничения и пожелания клиента в одном продукте)
Шаг 3. Формируем техническое задание, где рассчитываем стоимость и сроки:
ТЗ пишем небольшое по объему (обычно 5-10 страниц), где понятным, человеческим языком описываем, какие функции есть в приложении и какие задачи оно выполняет.
Мы не уходим в технические дебри, НЕ прописываем, что “кнопка находится в правом верхнем углу, имеет светлый фон и темный текст”. Мы пишем функции и задачи, чтобы даже не разбирающийся в IT клиент смог прочитать и осознать текст, и принять для себя решение - услышали мы его или нет, работаем или нет.
На наш взгляд визуал, и “где / что будет располагаться”, гораздо проще согласовать на этапе дизайна, чем в переписке, редактируя вордовский документ))
В самом ТЗ рассчитываем общие сроки и стоимость работ - они пойдут в договор и НЕ будут меняться по ходу работы. Мы всегда четко рассчитываем стоимость проекта, чтобы сказать клиенту “на берегу” - почем это все выйдет? Без сюрпризов.
Мы не уходим в технические дебри, НЕ прописываем, что “кнопка находится в правом верхнем углу, имеет светлый фон и темный текст”. Мы пишем функции и задачи, чтобы даже не разбирающийся в IT клиент смог прочитать и осознать текст, и принять для себя решение - услышали мы его или нет, работаем или нет.
На наш взгляд визуал, и “где / что будет располагаться”, гораздо проще согласовать на этапе дизайна, чем в переписке, редактируя вордовский документ))
В самом ТЗ рассчитываем общие сроки и стоимость работ - они пойдут в договор и НЕ будут меняться по ходу работы. Мы всегда четко рассчитываем стоимость проекта, чтобы сказать клиенту “на берегу” - почем это все выйдет? Без сюрпризов.
Вот примеры нескольких ТЗ:
- Приложение по фитнесу: ссылка на ТЗ
- Приложение для школы английского: ссылка на ТЗ
- Приложение по саморазвитию: ссылка на ТЗ
Порой клиенты переживают, как ТЗ в итоге будет переложено на дизайн. Вот несколько примеров, чтобы лучше понять формат технического задания:
Что происходит после сдачи технического задания?
После окончания работ над ТЗ организуем еще одни зум с клиентом, где проходимся по функционалу и убеждаемся, что “все понятно” и что “все друг друга услышали”.
Если находим точки соприкосновения, то приступаем к оформлению договора на разработку.
Написанное тех.задание становится приложением к договору -> клиент переводит оплату -> начинаем работу.
Если находим точки соприкосновения, то приступаем к оформлению договора на разработку.
Написанное тех.задание становится приложением к договору -> клиент переводит оплату -> начинаем работу.
У вас есть идея проекта и откликается наш подход?
Давайте познакомимся