Принцип «Без ТЗ — результат ХЗ» — чаще всего ерунда.
Привет! С вами Артём Харитонов — основатель GORA Studio. Мы разрабатываем мобильные сервисы и приложения с использованием компьютерного зрения, нейросетей и дополненной реальности (AR) и при этом чаще всего работаем без классического ТЗ. В статье расскажу, как такой подход помогает сэкономить время, деньги и получить продукт, который не устарел еще во время разработки.
Что не так с разработкой по ТЗ
Главная сложность — невозможность предусмотреть в классическом ТЗ все мелочи. Именно они делают мобильные приложения и успешные веб-сервисы удобными и заставляют пользователей возвращаться раз за разом в полюбившееся приложение.
В процессе разработки классического ТЗ заранее продумать все-все требования к приложению и его функциям почти нереально. Нужно как-то предусмотреть поведение пользователя в еще не существующем приложении, особенности работы на десятках видах устройств, анимацию и переходы, нестандартное поведение и приятные уведомления об ошибках. А потом еще и подробно расписать это в документе так, чтобы не было логических затыков и команда разработки все поняла однозначно.
Приложение выходит на рынок позже. Обычно для создания этого масштабного талмуда привлекают аналитика.Чтобы все подробно описать для небольшого проекта, который можно сделать за 3–6 месяцев, аналитику нужно от 1 до 3 месяцев и ≈50–150 тысяч рублей (это без дизайна!). За это время можно было бы сделать треть или даже половину проекта, потратить деньги на саму разработку, подогрев рынка и запуститься на несколько месяцев раньше.
Приложение получается не таким, как его задумал заказчик. Понятия и формулировки в суперподробном ТЗ часто общие и неточные, а важные мелочи и вовсе забывают упомянуть. Разработчики могут читать и реализовывать формулировки из ТЗ по-разному, возникает двусмысленность, а потом вместо запуска начинаются бесконечные круги ада доработок.
Все было бы гораздо проще, если бы на руках была готовая визуализация экранов. Хотя бы примерная и схематичная. Но ни в одном ТЗ нет дизайн-экранов будущего приложения, а ведь именно визуализация будущего проекта и помогает найти ответы на большинство вопросов, возникающих у разработчика.
Чтобы сократить количество переделок и доработок, вместо ТЗ мы разрабатываем функциональную карту: это визуализация дизайн-экранов в Figma, где сразу понятно, что и как будет устроено в приложении, плюс пометки для разработчиков.
Заказчик и разработчик не ломают копья о формулировки громоздких ТЗ, а сразу видят будущий результат
Вот как мы создаем экраны-прототипы:
- Встречаемся с клиентом в офлайне, в Zoom или Skype. Он описывает своими словами, какое приложение нужно и для чего, что в нем должны делать пользователи.
- Разрабатываем прототипы, обычно 3-5 экранов в Figma. Первые результаты сразу показывают, насколько хорошо наша команда поняла заказчика, нравится ли заказчику общая стилистика. Клиент видит визуализацию своих хотелок сразу, а не через три месяца после начала работы.
- Делаем интерактивный прототип. Показываем заказчику, как будут прокручиваться экраны, как будут работать переходы. При необходимости сразу можно показать, какую форму или кнопку передвинуть.
- Оперативно вносим изменения. Дописываем функциональные особенности рядом с экранами. Поменять расположение иконок в прототипе — пара минут, а если бы заказчик дожидался запуска какого-нибудь MVP, уже пришлось бы переписывать код.
Сравните сами, что понятнее: ТЗ на 50 страниц текстом или дизайн-экраны, которые можно понажимать.
Подробное и хорошее описание того, что вы хотите получить, действительно может нам помочь. Если можете описать это сразу — делайте. Но не стоит тратить время и силы, чтобы прописать в ТЗ, как будет выглядеть датапикер на iOS или Android или что после ввода четвертой цифры из СМС-кода нужно автоматически проверять ввод и успешно авторизовывать, не прося нажать «Далее».
Почему заказчику удобнее и выгоднее заказывать приложение без ТЗ
Есть контроль над проектом на протяжении всего процесса разработки. Настоящий контроль — это не попытка прописать все сложности заранее, а возможность в любой момент быть в курсе, на каком этапе проект.
Для будущего проекта лучше, если владелец продукта (основатель) будет участвовать в жизни проекта постоянно. Например, каждую неделю-две смотреть у себя на телефоне или в браузере, что уже готово и как оно работает. В случае чего, можно сразу бить тревогу, если что-то не так или появилась новая идея. Часто бывает, что нарисовано красиво, а когда начинаешь нажимать — оказывается неудобно.
Конечно, в ТЗ тоже делят большие проекты на этапы. Только непонятно, зачем максимально подробно прописывать все 10 этапов и жестко себя ограничивать. Если на втором или третьем этапе концепция может поменяться (привет, пивот) и всю документацию придется переписывать по новой.
Парадокс: составляя ТЗ, мы стремимся к контролю. Но настоящий контроль над проектом мы получаем, только работая без ТЗ.
Запуск не откладывается. За время написания ТЗ можно упустить удачное время для вывода проекта на рынок. Лучше быстро проанализировать требования, сделать функциональную карту с примерами экранов и сразу стартовать. Мы просто утверждаем все нужные функции, экраны и количество подключаемых сервисов, подписываем NDA и сразу начинаем разрабатывать первую версию.
В итоге небольшие проекты стартуют за 2–4 месяца, а средние — за 5–8 месяцев. Да-да, без всяких переписываний и осмысливаний ТЗ, миллиарда уточнений и десятков совещаний на протяжении долгих месяцев.
Каждый новый этап — это версия приложения, которая соответствует текущим задачам и требованиям заказчика. Первую версию уже можно использовать и заливать в сторы. Ведь намного эффективнее не просто придумывать требования к приложению, а делать их на основе обратной связи от настоящих пользователей.
Проще контролировать расходы и понимать, на что потрачены деньги. Первое, что отталкивает бизнес от работы без ТЗ, — это отсутствие фиксированной цены. Люди не понимают, как можно работать без этого. В классическом подходе все вроде просто: вот задача, вот цена. Например, за условные 10 тысяч долларов вам разработают готовое приложение. Но! Это будет приложение, которое нельзя выпускать и заливать в сторы. Его сразу нужно дорабатывать под новые требования, потому что в ТЗ что-то не учли и продумали не все или появились новые бизнес-требования.
В случае с работой без ТЗ заказчик оплачивает работу по часам (Time & Material) и контролирует отработанные задачи на каждом этапе. Из-за недобросовестных студий и неумения заказчиков оценивать затраты в часах в нашей стране не очень любят работать с платой за часы.
На самом деле так удобнее не только студии, но и заказчику тоже. Например, ему не нужно замораживать сразу всю сумму. Смотрите сами:
- Когда мы перед разработкой согласовываем список функций, уже можно предварительно оценить проект по часам, а значит, посчитать его стоимость.
- Заказчик оплачивает каждый этап, а не всю разработку сразу, но при этом уже на первом этапе он получает готовый рабочий продукт.
Все последующие затраты переносятся на новый этап — в разработку второй версии. И все это без бюрократии, переподписания договоров и приложений к ним, нервотрепки и вечного переноса даты запуска.
В результате заказчик контролирует бюджет на каждом этапе разработки. Сразу понятно:
- Сколько нужно потратить на запуск новой версии и когда она будет запущена.
- Во сколько обойдется разработка конкретной фичи и стоит ли ее добавлять вообще.
Работа не застопорится внезапно из-за того, что вдруг потребуются серьезные незапланированные вливания бюджета. Мы в студии используем трекер задач Jira, оттуда заказчик может получить отчеты о выполненных задачах и отработанных часах на любом этапе в понятном виде. Хотя бывают случаи, когда мы комбинируем две модели: выставляем фикс за основной функционал, а доработки добиваем через T&M.
Можно поменять мелочи без бюрократии. В случае с разработкой по ТЗ заказчик принимает проект целиком, со всеми нюансами и недостатками. И часто конкретные части приложения вообще не похожи на то, что представлял себе заказчик.
Например, заказчик просит изменить внешний вид кнопок и уведомлений. Менять в конце означает переписывать сотни или даже тысячи строк кода. А еще же надо подписать дополнительное приложение к договору, а потом и бюджет пересчитать.
А если заказчик постоянно участвует в жизни проекта, пожелания насчет внешнего вида кнопок выясняются еще на этапе прототипа в Figma. И это сокращает трудозатраты в десятки раз. Ведь не нужно каждый раз готовиться к встрече с разработчиками, как к докладу в ООН. Можно в одном абзаце своими словами описать, что еще хочется, а в студии все посчитают, согласуют и сделают.
Разработчики не будут доделывать проект спустя рукава. Смотрите, что происходит с командой добросовестных и профессиональных разработчиков, когда они вынуждены работать по ТЗ:
Разработчик видит, что в документе написана ерунда, и начинает страдать. Он не может сделать шаг влево или вправо, чтобы не нарушить договор. И неважно, что это все написали еще год назад, а за это время многие интерфейсы и решения устарели. Разработчик вынужден сделать плохо.
⟶
По итогу подход к разработчику «ты просто инструмент» только вредит полезному креативу. Разработка — это не просто составление строчек кода, это творческий процесс. И вот эти рамки ТЗ убивают желание специалиста сделать отлично. В итоге он делает «как написано».
Не мучайте разработчиков лишними инструкциями и рамками. Ставьте задачу и контролируйте результат — опытный специалист сам знает, как сделать лучше.
Можно быстро поменять концепцию, если нужно. Есть такой термин — «пивот». Это когда концепция бизнес-модели резко меняется из-за внешних событий или внутренних факторов.
Если делать проекты с классическим подходом, с большим техзаданием, любой пивот приведет к резкой остановке всех процессов и потере денег. Бизнесу придется менять стратегию, а значит, заново создавать ТЗ.
Мы уверены, что сейчас каждый рынок можно назвать турбулентным: все может измениться в любой момент. Поэтому предлагаем клиентам работать по функциональным картам и дизайн-экранам и, в случае чего, быстро и безболезненно менять вектор проекта на лету. Это в любом случае будет дешевле и проще.
Ну в смысле вообще без ТЗ?
Знаю, что многие студии и разработчики буквально требуют от заказчиков ТЗ, но я не видел готовых техзаданий, которые можно было взять в разработку без уточняющих вопросов. Требовать подробное ТЗ с описанием каждой кнопки на экране будет только тот разработчик, который, скорее всего, желает просто «освоить бюджет» и не брать на себя ответственность.
Я совсем не против, если заказчик придет с готовым документом-заданием, где коротко и ясно описан функционал, что ему нужно и что он хочет от пользователя. Это даже хорошо, ведь получается, что задачу уже обсудили внутри компании, перенесли ее на бумагу и не отказались от идеи. Значит, они нацелены на результат, и это отлично!
А вы разрабатывали или заказывали без ТЗ? Поделитесь, что из этого получилось :)
Разработку "сервисов и приложений" можно сравнить со строительством домов. С помощью подходов автора можно рискнуть построить небольшую типовую дачку. Небоскреб так возводить не стоит. Лучше по старинке, с архитектором и проектом.
И небоскреб и виллу можно построить. Никто не говорит, что не надо делать "фундаментальные" вещи или игнорировать требования к бекенду, например. Мысль очень проста - хотите быстрый запуск, нарисуйте экраны, доверьтесь разработчикам и войдите на рынок с вашей идей раньше остальных!
Вся суть в вашем комментарии, а статью читала дольше. Автор объемный материал подготовил, с интересным подходом к делу, хоть и рисковый.
Работать без техзадания — ну такое. Это какой-то обман ближнего круга, когда ты сам не дурак, вокруг умные люди и в команде тебя понимают с полуслова. И не бесят тебя. А когда ты пытаешься отдать задачу кому-то из вне — начинаешь говорить с людьми на разных языках. ТЗ — это примерный ориентир, на который хотя бы можно опираться. Мало кто способен и почти никто не заинтересован погружаться в задачи больше, чем минимум усилий для заработка денег. Поэтому этот минимум должен быть обозначен. А на счет гибкости в решениях — это уже с тз не связано как мне кажется. Это связано с вовлеченностью и тем, насколько ты сам участвуешь в процессе. Подписать новую тезешку — это 5 минут.
А собрать требования, понять что именно хочет заказчик, положить это на читаемый и понятный текст как для заказчика, так и для разработчиков - это уже не 5 минут, а недели.
Дизайн-экраны - это и есть ТЗ нового поколения.
В разработке мобильных приложений только так и получается делать быстро и качественно.
Меньше времени тратишь на объяснение очевидных вещей.
1 раз покажи - вместо 100 раз объясни работает!
Да. Для "мало кто" создание систем - это все еще искусство), которое совсем не про "минимум усилий для заработка денег". Для тех, кому хочется строить красивые системы.
Вы просто не умеете готовить ТЗ. Рисование экранов - это тоже часть ТЗ.
А надо ли в современном мире упарываться на написание ТЗ текстом?
👍🏻
У вас как-то смешалось воедино три аспекта: наличие или отсутствие ТЗ; форма ТЗ: текст или формы; методология разработки: всё от начала до конца или итерационный подход. И к наличию ТЗ вы приписали всё плохое, а к отсутствию ТЗ всё хорошее.
Если у вас всё идёт хорошо и полное понимание с заказчиками, то пускай так и будет. Мой опыт отсутствия нормального описания функционала при экранных формах был негативным.
Если все идет хорошо с заказчиком - это хорошо!
Мысль скорее в том - что не стоит тратить время на классическое ТЗ на 100 страниц для небольших проектов, а лучше сразу нарисовать экраны и взять в работу.
Работал без ТЗ почти три года. Все это время был один заказчик, он никогда не знал что хочет. Был только дизайн. И это не значило что если сделаешь все по дизайну, то что ты сделал что хотел заказчик. Приходилось переделывать фичи чуть ли не каждый раз. А то и несколько раз одну и ту же. И сейчас я точно понимаю что так работать не хочу. Но чисто текстовое ТЗ тоже не решение. Хороший вариант - дизайн + частичное описание ТЗ.
Нужно ли говорить что проект делается ну очень долго? то что в одних студиях с ТЗ и аналитиками делается за 3 месяца, в той студии делалось 6+ месяцев. А как разработчики при этом выгорают?
плюс 100
Так в нормальном ТЗ уже есть дизайн. Зачем он отдельно?
Но разве разработка тех же будущих визуалов, на которые будет ориентироваться разработка - не то же самое ТЗ, только в другом виде?
Вот этот "другой вид" и есть краеугольный камень. Когда делаешь по ТЗ и показываешь заказчику - чаще всего слышишь "ой! вот так это работает, да? а можно по-другому!"
«Без ТЗ — результат ХЗ» говорят, когда заказчик сам не знает чего хочет. Или не может внятно объяснить, ограничиваясь «сделайте красиво». Здесь действительно многое зависит от качества работы исполнителя. Если работы делаются спустя рукава, то подробное ТЗ — единственный способ добиться желаемых результатов. Обычно так бывает, когда экономят на исполнителях.
Профессионалы же могут понимать с полуслова и сами предложить лучшие решения, но такие и стоят дорого. При этом заказчик всё равно должен чётко понимать что он хочет получить в итоге и донести это понимание до исполнителей.
Когда понимание есть, но нечёткое, картину помогают прояснить вопросы, возникающие в ходе разработкой: будь то визуализация или уже конкретное воплощение. Собственно, проработка этих вопросов — это и есть работа, аналогичная составлению ТЗ. И от неё никуда не деться, не бывает такого, чтобы получился желаемый результат без прохождения этого этапа.
Правильная мысль, при этом "сделайте красиво" мы рисуем и утверждаем, чтобы не попасть ловушку "сделайте красиво экран с Профилем" и четким ТЗ где прописаны все Поля этого самого Профиля, а потом заказчик говорит "а почему Аватарка такая маленькая и круглая, я хотел прямоугольную и на весь экран".
К слову и высокооплачиваемые специалисты иногда работают спустя рукава - все зависит от мотивации и атмосфере проекта/компании - но это уже отдельная большая история, возможно даже статья на VC))
Не совсем понятно как по вашей схеме понять финансовую целесообразность разработки приложения. Например, мне нужно приложение для страховой компании, которое отслеживает активность пользователя и делает ему скидку тем больше, чем больше он активен в реальной жизни. ТЗ нет. Финальную суммы вы назвать не можете.
Ваш вариант это работать по часам, но так я не могу посчитать насколько оно окупится и стоит ли вообще его делать. Как клиенту принять решение без стоимости и сроков?
Все очень просто. Вы уже описали функционал основной, остались детали и оценка (коридор) будет.
Давайте попробуйем посчитать в этой ветке комментов ваш проект?
Вопросы:
1. Дизайн, бренд-бук, лого есть?
2. Регистрация через соц. сети и/или СМС/код-звонок?
3. Что именно хотите отслеживать, шаги, километры, подъемы/спуски, кручение телефона в руках? Что вы вкладываете в понятие "активен"?
4. Данные надо хранить на телефоне или на сервере, чтобы потом строить аналитику?
5. Через приложение надо будет оформлять полис или будем уводить на сайт и передавать размер скидки?
6. Можно делиться своей активностью в Инстаграм и ТикТок?
7. Будет чат с техподдержкой?
8. Придумали название?
Поиск подрядчика на разработку надо начинать с поиска независимого профессионала, который может выбрать этого подрядчика, даст понять финансовую целесообразность.
Профессионал сам сделает черновую оценку проекта чтобы были понятны ориентиры, подготовит краткую документацию для рассылки потенциальным подрядчикам на оценку проекта. Дальше куча стандартных шагов выбора подрядчика ...
А статья про то, чтобы неопытных клиентов заманить и там уже как получится.
Это же СТУДИЯ и ПРОДАЖНИКИ :)
Продажники продают.
А там уже как программист ляжет, сможет, а может и нет.
Работа по спринтам или по часам подходит только для клиентов которые сами профессионалы в IT.
Но продажнику это не интересно.
😜
Угу....был у меня тут один проект без ТЗ, в итоге сорванные сроки из-за постоянных "нужно переделать", "давай сделаем иначе" и всё в таком духе, ладно хоть за переработку заплатили.
без ТЗ очень трудно работать. В основном можно столкнуться с этим когда у заказчика только идея и проект начинаем с нуля. Тогда можно столкнуться с постоянными "бесконечными" правками.
Да, замечательно и правильно, когда дело касается юзерфлоу.
Но всё, что описано в статье, точно не серебряная пуля, и не ноухау.
Визуальными прототипами/макетами невозможно или сложно показать, например:
- нефункциональные требования и SLA;
- интеграции;
- системные кейсы-вычисления;
- зависимость состояний элементов от наборов параметров. Точнее можно упороться и накопипастить одинаковых макетов, где будет отличаться единственная строка, но лучше описать в ТЗ.
Способ начинать с макетов/прототипов прекрасен, но совсем без ТЗ жизнеспособен, если есть много если, напр.:
- говорим о стандартных штуках, типа магазинов на битриксе;
- внутри команды есть экспертиза по компонентам, которые затрагиваются в проекте;
- нет необходимости поддерживать проект другой командой.
Да, согласен, ТЗ нужно по многим причинам.
Мы тут скорее про подход разработки для заказчиков, которые все вот хотят свой проект запустить, но ждут "когда напишется ТЗ", а оно все не пишется.
Когда речь касается SLA и бекенд-штук - то да, без четких требований и логических схем не обойтись.
И мы любим такие проекты, когда заказчик приходит с четким пониманием и требованием 💚
Способ начинать с макетов - прекрасен, если у клиента в принципе есть понимание как должен работать софт. Тогда именно на основании прототипирования мы ТЗ и пишем.
Но чаще у клиента в голове есть потребность, то-есть функционал и он понятия не имеет какие кнопочки ему нужны в приложении.
Типичный пример: "нам надо реализовать НДС в услугах нашего банка" и всё и думай теперь. Клиент понятия не имеет, нужно ли ему пользовательское приложение в принципе для реализации этой задачи.
Даже не представляю как вообще появилось все, что нас вокруг окружает...
Как же любят авторы подобных статей считать, что они прямо что-то такое сногсшибательное предложили, а все вокруг жили до этого, в сплошном страдании. Одни делали ТЗ, а другие что-то создавали по этому ТЗ, и все страдали от наличия ТЗ. И вот ведь дураки, ну неужели не могли додуматься, что без ТЗ нужно. Ну не было экранных форм, ну на ватмане, на салфетке, накидали, кивнули друг другу, одни пошли делать, а другие пошли в бухгалтерию, сказать Марии Ивановне, чтобы деньги перевела, цвет кнопочек поменяли, все ок.
Почему-то авторы подобных статей реально считают всех, кто работает по ТЗ, как заказчика, так и исполнителя, какими-то идиотами, которые ничего не меняют, не дорабатывают, не обсуждают в процессе разработки или создания чего-либо, что ТЗ это как в граните отлили, и все, назад дороги нет.
Но рано или поздно, когда возникнет вопрос, который будет стоить серьёзных денег, вот тогда и станет автору, понятно зачем ТЗ, как оно защищает и заказчика и исполнителя в случае претензий друг к другу. И когда дойдёт дело до суда, например, на вас судья так посмотрит из-под очков и скажет "а кроме экранчика, чем вы можете подтвердить достижение согласия с заказчиком о том, что нужно было делать вот так?" И дело будет не в отсталости судьи от прогресса, а в том, что не все так просто, и ТЗ, как бы оно кого-то там не раздражало, не просто описание того, что хочет заказчик.
Небольшое ТЗ + прототипы в figma (moqups) - самый хороший вариант. Без ТЗ не все разработчики могут работать. Многим нужно описание того или иного функционала (+ наглядный пример как это будет работать). Не совсем понятно как вы будете формировать смету имея только экраны
Мне вот интересно, что сейчас чаще всего является бэкэндом приложений, ну там где сервер, база данных, реализация логики и API? И какая это часть в проекте - большая или меньшая? А то ощущение что разработка начинается и заканчивается в figma...
Смета формируется на основе экранов и короткой описательной части к этим экранам-разделам, например:
1. Экран "Регистрация по СМС"
Пользователь вводит телефон в международном формате, код страны определяем автоматически и показываем флаг страны.
Таймаут 59 сек между запросами СМС.
После 3-й неудачной попытки показать кнопку "Не получается? Позвоните по номеру/напишите на почту"
А расписывать этот функционал на 5 листов через ТЗ не стоит
Похоже, что автор просто недавно закрыл пару проектов на очень хорошей ноте и, сохранив настрой, написал статью. Статья спорная. Сначала читал и такой "да, да, Господи, да", а дальше – хуже. Слишком много энтузиазма. Иногда этот энтузиазм просто игнорирует здравый смысл. Сколько времени Вы работаете в этой сфере, Артём?
В IT опыт 15 лет, свою компанию основал 5 лет назад.
Не теряйте энтузиазма и вы 🔥
Комментарий недоступен
Комментарий недоступен
Заказчик не может знать точно, что он хочет, тем более в деталях, потому что не разбирается в "небоскребах". Он жилец. Ему нужно, чтобы было удобно. Покупателям дрелей они на самом деле не нужны, им нужны дырки в стене...
Написание ТЗ аналитиком у вас до скольки месяцев? Такого аналитика надо немножко увольнять. Даже низкоуровневое ТЗ с описанием как фронта так и бэка, со всеми сущностями и апи, совместно с тимлидом не превышает месяца, с учетом всех вычиток и согласований командой. Не говоря про высокоуровневое, для общего сбора хотелок клиента, которое формируется за день-два, вместе с интерактивными прототипами (которые в любое тз входят).
И к разным проектам подходят только свои методики реализации, главное, чтобы всегда были контрольные точки, обозначенные (кто бы мог подумать), в тз, или на крайняк техтребованиях.
Мы не против ТЗ - мы против боязни начинать работать без классического ТЗ!
Аналитик - ценнейший юнит в команде 🏅
У вас там там сельский проект мобильного приложения? Нормальный Global Template команда аналитиков пишет год.
Я только прочитал 1-й абзац, сразу понял, что будете рекламировать работу на почасовке :)
Но если по факту, вы описали ТОЛЬКО все минусы работы ИМЕННО по плохому ТЗ, причём, сильно утрировали их, и описали ТОЛЬКО все плюсы работы без ТЗ (хотя на самом деле, это такое же ТЗ, только на почасовке, в виде проектирования в Фигме с текстовым описанием возможностей фич, где все равно нужно будет back-end логику описывать дополнительно, ибо если приложение не клиент-серверное, то его нечего здесь и обсуждать).
В итоге, главный вопрос который вы здесь «раскрыли», что без ТЗ будет дешевле, быстрее и выгоднее не прозвучало убедительных аргументов, т.к. приведённые примеры написания ТЗ не понятно от куда взяты, либо вы сами их так пишете, долго, дорого с кучей ненужной логики (типа, эта кнопка выглядит вот так и по нажатию на неё открывается вот этот экран ...) либо специально привели именно такие примеры, чтобы ваш подход в глазах «потенциальных клиентов» выглядел «золотой пулей» (скорее это конечно).
И даже если к вам пришли с плохим ТЗ, то ведь его же можно прочитать и дать оценку fix price по приведению в порядок, не так ли кэп?))
Описывать в ТЗ «лишнюю и нудную логику» конечно же это бестолковая трата времени, т.к. стиль и тапы по кнопкам, подробное описание валидаций (если это конечно не логика бизнес-процессов заказчика) отображается как раз на следующем этапе работ, т.е. когда в ТЗ четко прописали функционал и его возможности, дали оценку fix price, можно уже рисовать интерфейс. А какой именно, т.е. проектирование либо сразу дизайн пилить, это уже вопрос индивидуального проекта. Много условий, бэк логики, сценариев «если, то», лучше конечно сначала обойтись проектированием, а потом красотой заниматься. Более-менее типовой проект, вроде онлайн-магазина, можно и сразу в дизайне это все делать.
ИМХО. Не красиво хейтить подход написания ТЗ, когда это делается не с точки зрения объективности и помощи тем, кто хочет разработать аппу, а с точки зрения только рекламы своей студии.
В статье ни слова хейта про классическое ТЗ, даже больше - мы приветствуем хорошие ТЗ и научный подход в разработке.
Также нужно понимать, что речь идет о небольших проектах и стартапах где важнее запуститься быстрее и проверить гипотезу или выйти на новый рынок. Хотя мы практикуем такой подход и на более крупных проектах!
Основная мысль - не нужно бояться разрабатывать Мобильное Приложение или Сервис/Продукт не имея на руках ТЗ или не имея возможности его написать своими силами.
Приведенные примеры взяты из реальной жизни.
к вам пришли с плохим ТЗНу как можно давать оценку по плохому ТЗ, чтобы потом за свой счет дорабатывать/багфиксить неучтенные моменты!!
Оценку всегда можно дать коридором и все наши клиенты знают ориентир по стоимость ДО начала работ.
А вы много в своей жизни встречали толковых ТЗ где все понятно и доступно и можно сразу брать в работу?)
все хорошо, когда клиент толковый попадется, на высококонкуретном рынке, всегда просят цену в лс, если же вы поставляете уникальную услугу, и альтернатив нет, то да, так лучше всего.
Оба варианта использую в работе.
Тз используется, когда заказчик сам не очень понимает, чего хочет, эта бумажка защищает меня. От "я думал, вы все сами понимаете".
Второй вариант, использую для клиентов, с которыми выстроены постоянные взаимоотношения.
Зачастую это выглядит так: сначала первый проект по тз, по требованию самого заказчика, затем если/когда заказчик, становится постоянным отрабатываем почасовку.
В целом вы описали, то - же тз, но разбитое на этапы и в кратком виде. (с размазанным бюджетом) по этапам. Ничего особо нового не изобрели.
А мы не изобретаем - мы просвещать 🎓
Есть методологии разработки, тот же пресловутый agile. На мой взгляд, удобнее всего так - https://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D1%81%D1%82%D1%80%D0%B5%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
Это когда заказчик "в боевых порядках" разработчиков проходит с ними итерации. Если заказчик к такому готов, то все довольно быстро и бесконфликтно.
А если заказчик суровый бизнесмен из реального сектора и не слышал про Agile, скрам и, прости господи, спринты - тогда итерации с клиентом будут больны для разработки и не эффективны!
Ниже написал про это же))) плюсую)
Вы никогда там не слышали про ci/cd, agile и прочее? Зачем писать тома с тз, когда можно написать тз с базовым функционалом и механиками, которые требуются для работы приложения (альфа/бета версии, мвп). Запустить его, прокатать его на ограниченном кол-ве юзеров (например) и потом уже регулярно пилить фичи — которые реально нужны, исходя из данных аналитики, собранной с релиза мвп.
Все правильно говорите, немного текста про функционал и экраны и пилим MVP 🚀
Что за подмена понятий? С чего вы взяли что в ТЗ не должно быть мокапов интерфейсов или полноценных прототипов? Если вы имели ввиду какой-то конкретный ГОСТ, то напишите его, но даже ГОСТы достаточно гибкие.
У ТЗ нет какого-либо жесткого шаблона, вы просто включаете туда ровно столько, сколько нужно для успешного проекта.
В тоже время, как вы поставите ТЗ дизайнеру, будете рисовать картинки?)
Никакой подмены понятий.
Речь и мысль о том, что хорошее ТЗ - это большой труд, а для небольших проектов лучше направить ресурсы на разработку, нарисовав правильные экраны. Так и продукт выйдет в свет раньше и заказчик будет видеть результат почти сразу.
Мы разрабатывали ТЗ для серьезного проекта на 150 страниц с мокапами и прототипами в Axure, смета заняла 10 страниц. Для серьезных сервисов, особенно связанного с биллингом или финансами - это жизненно необходимо.
Не распыляться - вот о чем идет речь!
Артём, хорошая статья, спасибо большое!
🖖
Интересный подход, но мне кажется что работать будет только при уже общеизвестных кейсах. Интернет-магазины, приложения с картами, их уже так много что даже дети были бы в состоянии описать куда какая кнопочка должна вести.
Как только клиентом окажется условная птицеферма, а целью проекта будет создать приложение автоматизирующее управление этой самой птицефермой, то без ТЗ можно полечь в чистом поле.
Но опять таки при проектах поменьше вполне себе :)
Что-то все намешано в куче. Есть плюсы и в ТЗ и без ТЗ. Надо исходить из конкретной ситуации, проекта, задачи, объемов, ресурсов и так далее.
Если вам подходит схема работы без ТЗ - ради бога, работайте. Но мешать все в кучу и методологии и документы - плохая идея.
Если у вас так не любите составлять текстовые ТЗ, заходите к нам на огонек - spexfy.com . Сможете делать ТЗ в один клик!
🔥 Класс! Обязательно посмотрим и изучим ваш сервис!!
По поводу вашего утверджения, что Time & Material - это самый верный подход к разработке mobile app для клиентов. Вы должны знать, что в проектном менеджменте этот подход используется ТОЛЬКО в срочных и "горящих" проектах (см. PMI Book). В планомерных проектах и нормальных условиях оценивают общую стоимость проекта, сроки и т.д. В крупных компаниях и проектах для них вы должны понять менеджера (его основная задача не работающее приложение, а соответствие срокам, бюджету, т.д.). Вообщем там важен процесс, а не результат)
Все подходы хороши, главное найти общий язык с клиентом и выработать оптимальные итерации.
Что-то мне подсказывает, что Клабхаус и, например Инстаграм, на свой заре начинались либо вообще без ТЗ, либо просто экраны на салфетке/фотошопе/sketch/figma.
И речь в статье о том, что не надо ЖДАТЬ и БОЯТЬСЯ начинать разработку без ТЗ, можно начать с экранов в Figma, а дальше грамотный разработчик подскажет и поможет!
И так сказать автору на закуску... Если ваш подход работает, значит гуд. Работа с ТЗ - это как большой секс. А вы нашли позу, которая нравиться вам и вашим клиентам, ну и тр..хайтесь на здоровье и никого не слушайте!
🖖
1. Вы не умеете писать ТЗ, оно просто должно соответствовать задаче
2. Вы не встречали нормального аналитика, он упростит жизнь команде разработки даже на простых проектах
3. Видимо у вас сложность управлять сроками разработки ТЗ
4. Заказчик оказыется в заднице если вы накосячите, это рулетка в которой вы казино
5. ТЗ не должно отвечать на все вопросы, оно должно вести проект в правильном направлении к нужным впоросам
6. Если вы рисуя экраны что-то не поймёте со слов заказчика, бюджет проекта имеет шансы кратно увеличиться, но см п.4
Передёрнуто всё что можно :)
Маркетинг брызжет
Но это прекрасно
1. Кто вам сказал, что мы не пишем ТЗ?)
2. У нас прекрасные аналитики, даже на английском делаем проекты, ТЗ и аналитику бизнес-процессов!
3. С чего вы взяли?
4. Вы тоже можете вызвать Яндекс.Такси и не доехать до дома, попав в аварию или еще по каким-то причинам!
5. На небольших проектах с такими задачами отлично справляются экраны в Figma + описательная часть к ним + функциональная карта. Классическое ТЗ может только затормозить все процессы или вовсе не начать проект.
6. А что, таких рисков с ТЗ нету?
Вы видимо не встречались с порядочными Разработчиками 🦾
Вы только что придумали канбан и развитие продукта - поздравляю!!!
п.с. я тоже так же работаю и всем советую ( но не всем подходит ).
Спасибо, за статью - очень смешно.
По-моему заголовок статьи противоречит содержанию, оно как раз о том что хоть какое-то ТЗ необходимо. Стоило бы добавить определение ТЗ - что автор под этим понимает, видимо что-то вроде нудных нечитабельных ГОСТов, такое конечно никто не любит и (надеюсь) не делает.
А дизайн экранов это уже лучше чем ничего, многие воспринимают их как часть ТЗ или приложение к нему. Но хоть какое-то текстовое описание тоже нужно.
Принцип «Без ТЗ — результат ХЗ» - это те самые грабли на которые наступили многие разработчики после непоняток с заказчиком. И у меня был серьезный факап из-за отсутствия ТЗ, так что тоже не удержался от коммента, статья задела за живое.
ТЗ бывают разной полезности, может быть и 100 страниц унылых и непонятных определений (уже давно устаревших) и 5 страниц прекрасного и понятного Продукта/Сервиса + несколько экранов.
Суть статьи в том, чтобы не бояться начинать проект без написанного ТЗ, достаточно экранов и небольшого понятного описания основных функций.
Не граблите больше 🧹
👍👍👍
🤖