Почему работа без ТЗ — это способ сделать то, что действительно нужно заказчику

Принцип «Без ТЗ — результат ХЗ» — чаще всего ерунда.

Привет! С вами Артём Харитонов — основатель GORA Studio. Мы разрабатываем мобильные сервисы и приложения с использованием компьютерного зрения, нейросетей и дополненной реальности (AR) и при этом чаще всего работаем без классического ТЗ. В статье расскажу, как такой подход помогает сэкономить время, деньги и получить продукт, который не устарел еще во время разработки.

Что не так с разработкой по ТЗ

Главная сложность — невозможность предусмотреть в классическом ТЗ все мелочи. Именно они делают мобильные приложения и успешные веб-сервисы удобными и заставляют пользователей возвращаться раз за разом в полюбившееся приложение.

Даже с хорошим аналитиком практически невозможно предусмотреть все, а еще это занимает очень много времени

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

Приложение выходит на рынок позже. Обычно для создания этого масштабного талмуда привлекают аналитика.Чтобы все подробно описать для небольшого проекта, который можно сделать за 3–6 месяцев, аналитику нужно от 1 до 3 месяцев и ≈50–150 тысяч рублей (это без дизайна!). За это время можно было бы сделать треть или даже половину проекта, потратить деньги на саму разработку, подогрев рынка и запуститься на несколько месяцев раньше.

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

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

Доработки — это отложенный запуск проекта, потеря времени и нервов заказчика и увеличение бюджета, а без этого не обойтись, если со старта работы и до конца разработчик опирается только на один текстовый документ

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

Заказчик и разработчик не ломают копья о формулировки громоздких ТЗ, а сразу видят будущий результат

Вот как мы создаем экраны-прототипы:

  • Встречаемся с клиентом в офлайне, в Zoom или Skype. Он описывает своими словами, какое приложение нужно и для чего, что в нем должны делать пользователи.
  • Разрабатываем прототипы, обычно 3-5 экранов в Figma. Первые результаты сразу показывают, насколько хорошо наша команда поняла заказчика, нравится ли заказчику общая стилистика. Клиент видит визуализацию своих хотелок сразу, а не через три месяца после начала работы.
  • Делаем интерактивный прототип. Показываем заказчику, как будут прокручиваться экраны, как будут работать переходы. При необходимости сразу можно показать, какую форму или кнопку передвинуть.
  • Оперативно вносим изменения. Дописываем функциональные особенности рядом с экранами. Поменять расположение иконок в прототипе — пара минут, а если бы заказчик дожидался запуска какого-нибудь MVP, уже пришлось бы переписывать код.

Сравните сами, что понятнее: ТЗ на 50 страниц текстом или дизайн-экраны, которые можно понажимать.

Реальный кейс. Аналитик тратит время на попытки подробно описать все функции словами и перечислить технологии, которые нужно использовать, разработчик пытается в этом разобраться, а клиент вообще ничего не понимает и ему это неинтересно
В дизайн-экранах мы делаем упор на UX/UI — это 70% успеха для будущей разработки

Подробное и хорошее описание того, что вы хотите получить, действительно может нам помочь. Если можете описать это сразу — делайте. Но не стоит тратить время и силы, чтобы прописать в ТЗ, как будет выглядеть датапикер на iOS или Android или что после ввода четвертой цифры из СМС-кода нужно автоматически проверять ввод и успешно авторизовывать, не прося нажать «Далее».

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

Почему заказчику удобнее и выгоднее заказывать приложение без ТЗ

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

Для будущего проекта лучше, если владелец продукта (основатель) будет участвовать в жизни проекта постоянно. Например, каждую неделю-две смотреть у себя на телефоне или в браузере, что уже готово и как оно работает. В случае чего, можно сразу бить тревогу, если что-то не так или появилась новая идея. Часто бывает, что нарисовано красиво, а когда начинаешь нажимать — оказывается неудобно.

Когда разработчики забирают ТЗ и начинают делать приложение, заказчик ничего не контролирует до этапа принятия проекта. Совсем. В итоге результат может очень отличаться от ожиданий

Конечно, в ТЗ тоже делят большие проекты на этапы. Только непонятно, зачем максимально подробно прописывать все 10 этапов и жестко себя ограничивать. Если на втором или третьем этапе концепция может поменяться (привет, пивот) и всю документацию придется переписывать по новой.

Парадокс: составляя ТЗ, мы стремимся к контролю. Но настоящий контроль над проектом мы получаем, только работая без ТЗ.

Запуск не откладывается. За время написания ТЗ можно упустить удачное время для вывода проекта на рынок. Лучше быстро проанализировать требования, сделать функциональную карту с примерами экранов и сразу стартовать. Мы просто утверждаем все нужные функции, экраны и количество подключаемых сервисов, подписываем NDA и сразу начинаем разрабатывать первую версию.

В итоге небольшие проекты стартуют за 2–4 месяца, а средние — за 5–8 месяцев. Да-да, без всяких переписываний и осмысливаний ТЗ, миллиарда уточнений и десятков совещаний на протяжении долгих месяцев.

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

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

x-staticmediagroup.com

Проще контролировать расходы и понимать, на что потрачены деньги. Первое, что отталкивает бизнес от работы без ТЗ, — это отсутствие фиксированной цены. Люди не понимают, как можно работать без этого. В классическом подходе все вроде просто: вот задача, вот цена. Например, за условные 10 тысяч долларов вам разработают готовое приложение. Но! Это будет приложение, которое нельзя выпускать и заливать в сторы. Его сразу нужно дорабатывать под новые требования, потому что в ТЗ что-то не учли и продумали не все или появились новые бизнес-требования.

В результате даже фиксированная стоимость меняется и опять нужно тратить дополнительное время на согласование новых статичных сроков и бюджетов

В случае с работой без ТЗ заказчик оплачивает работу по часам (Time & Material) и контролирует отработанные задачи на каждом этапе. Из-за недобросовестных студий и неумения заказчиков оценивать затраты в часах в нашей стране не очень любят работать с платой за часы.

На самом деле так удобнее не только студии, но и заказчику тоже. Например, ему не нужно замораживать сразу всю сумму. Смотрите сами:

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

Все последующие затраты переносятся на новый этап — в разработку второй версии. И все это без бюрократии, переподписания договоров и приложений к ним, нервотрепки и вечного переноса даты запуска.


В результате заказчик контролирует бюджет на каждом этапе разработки. Сразу понятно:

  • Сколько нужно потратить на запуск новой версии и когда она будет запущена.
  • Во сколько обойдется разработка конкретной фичи и стоит ли ее добавлять вообще.

Работа не застопорится внезапно из-за того, что вдруг потребуются серьезные незапланированные вливания бюджета. Мы в студии используем трекер задач Jira, оттуда заказчик может получить отчеты о выполненных задачах и отработанных часах на любом этапе в понятном виде. Хотя бывают случаи, когда мы комбинируем две модели: выставляем фикс за основной функционал, а доработки добиваем через T&M.

Можно поменять мелочи без бюрократии. В случае с разработкой по ТЗ заказчик принимает проект целиком, со всеми нюансами и недостатками. И часто конкретные части приложения вообще не похожи на то, что представлял себе заказчик.

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

А если заказчик постоянно участвует в жизни проекта, пожелания насчет внешнего вида кнопок выясняются еще на этапе прототипа в Figma. И это сокращает трудозатраты в десятки раз. Ведь не нужно каждый раз готовиться к встрече с разработчиками, как к докладу в ООН. Можно в одном абзаце своими словами описать, что еще хочется, а в студии все посчитают, согласуют и сделают.

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

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

По итогу подход к разработчику «ты просто инструмент» только вредит полезному креативу. Разработка — это не просто составление строчек кода, это творческий процесс. И вот эти рамки ТЗ убивают желание специалиста сделать отлично. В итоге он делает «как написано».

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

Не мучайте разработчиков лишними инструкциями и рамками. Ставьте задачу и контролируйте результат — опытный специалист сам знает, как сделать лучше.

Раньше, чтобы прокрутить галерею, можно просто свайпнуть по экрану, а раньше нужно было нажимать кнопку. Это кажется очевидным и может выпасть из ТЗ. Не пишите многостраничные ТЗ — рисуйте экраны, по ним все понятно

Можно быстро поменять концепцию, если нужно. Есть такой термин — «пивот». Это когда концепция бизнес-модели резко меняется из-за внешних событий или внутренних факторов.

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

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

Ну в смысле вообще без ТЗ?

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

Я совсем не против, если заказчик придет с готовым документом-заданием, где коротко и ясно описан функционал, что ему нужно и что он хочет от пользователя. Это даже хорошо, ведь получается, что задачу уже обсудили внутри компании, перенесли ее на бумагу и не отказались от идеи. Значит, они нацелены на результат, и это отлично!

Проще объяснить разработчику общими словами, что нужно сделать. Он выяснит суть и задачи приложения, а после предложит решение. И вы пощупаете первые результаты уже через месяц, а не будете еще год разрабатывать требования к своему проекту
А что вы думаете про классическое ТЗ и почему?
Старо как ICQ
ТЗ на 100 страниц — наше все
Лучше небольшое ТЗ, чем совсем без него
Одних экранов будет достаточно
Показать результаты
Переголосовать
Проголосовать

А вы разрабатывали или заказывали без ТЗ? Поделитесь, что из этого получилось :)

{ "author_name": "Артём Харитонов", "author_type": "self", "tags": [], "comments": 165, "likes": 14, "favorites": 51, "is_advertisement": false, "subsite_label": "dev", "id": 210496, "is_wide": true, "is_ugc": true, "date": "Fri, 19 Feb 2021 10:04:20 +0300", "is_special": false }
0
165 комментариев
Популярные
По порядку
Написать комментарий...
35

Разработку "сервисов и приложений" можно сравнить со строительством домов. С помощью подходов автора можно рискнуть построить небольшую типовую дачку. Небоскреб так возводить не стоит. Лучше по старинке, с архитектором и проектом.

Ответить
3

И небоскреб и виллу можно построить. Никто не говорит, что не надо делать "фундаментальные" вещи или игнорировать требования к бекенду, например. Мысль очень проста - хотите быстрый запуск, нарисуйте экраны, доверьтесь разработчикам и войдите на рынок с вашей идей раньше остальных!

Ответить
6

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

Ответить
0

Чем точнее формулировка тем бесполезнее результат.

Ответить
4

Вся суть в вашем комментарии, а статью читала дольше. Автор объемный материал подготовил, с интересным подходом к делу, хоть и рисковый.

Ответить
1

🙏 Благодарю

Ответить
1

Вам спасибо, этот сайт живет пока тут есть такие, как вы)

Ответить
22

Работать без техзадания — ну такое. Это какой-то обман ближнего круга, когда ты сам не дурак, вокруг умные люди и в команде тебя понимают с полуслова. И не бесят тебя. А когда ты пытаешься отдать задачу кому-то из вне — начинаешь говорить с людьми на разных языках. ТЗ — это примерный ориентир, на который хотя бы можно опираться. Мало кто способен и почти никто не заинтересован погружаться в задачи больше, чем минимум усилий для заработка денег. Поэтому этот минимум должен быть обозначен. А на счет гибкости в решениях — это уже с тз не связано как мне кажется. Это связано с вовлеченностью и тем, насколько ты сам участвуешь в процессе. Подписать новую тезешку — это 5 минут.

Ответить
2

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

1 раз покажи - вместо 100 раз объясни работает!

Ответить
10

Почему у нас в ТЗ десятилетней давности были и дизайн экраны и ETL процессы и функционал каждой кнопки? Может вы просто ТЗ писать не умеете? 
А как вы без ТЗ архитектуру системы пропишете? Вы открыли Америку и придумали ТЗ с картинками в 2021 году?

Ответить
0

А сколько времени такое ТЗ у вас заняло 10 лет назад? Предполагаю, что много.
Никто не говорит, что не бывает хороших и качественных ТЗ - мы их тоже любим, но редко встречаем.
На крупных и мощных проектах - никак без ТЗ.

Смысл статьи в том, что можно работать на небольших проектах и в самом начале без классического ТЗ.

Ответить
2

По разному занимает, в зависимости от уникальности. Если проект стандартный - у нас естественно есть наработки. Как-то мы внедряли новый бухгалтерский стандарт сразу на 50 стран, там базовый ТЗ писали год с юристами, аудиторами и IT материнского концерна и на его основе писали ТЗ под каждую страну от пары месяцев до года. Потом это всё внедрялось, тестировалось и запускалось в эксплуатацию. Проект в среднем на пять лет, участвовали тысячи людей. Вы предлагаете делать это без ТЗ? Начинать без ТЗ? 
Пока ты работаешь без ТЗ - ты работаешь в пустую.
На маленьких проектах, где не надо ничего учитывать и ТЗ пишется быстро. Чего там писать, если учитывать нечего?

Ответить
0

🧘‍♂️

Ответить
6

Для бэкенда, который во множестве систем в разы, иногда на порядки, сложнее МП или сайта, "дизайн-экраны" рисовать бессмысленно. Скорее UML-схемы. Бэкенд - это где большая часть логики, серверная обработка API, процессинг, управление потоками, транзакциями,  база данных со структурами объектов  и взаимосвязями между ними.   ТЗ для бэкенда определяет большую часть системы.  Но сейчас, когда рулит инфоцыганский подход "тестирования гипотез",  когда "ничего нет и все есть", бэкенд не нужен, все засунем в приложение или лендинг, прикрутим firebase тяп ляп....

Ответить
0

Да-да! Бекенд - это отдельный чудный мир, в котором правят схемы, четкие описания задач, алгоритмы и json.
Но мы тут и не про бекенд))

Ответить
3

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

Ответить
1

Мы полюбили серверную часть на Golang и Java
Приложений без бекенда почти не встречаем.

Также иногда смотрим в сторону облачного хранения Firebase Cloud Firestore - для небольших и невысоконагруженных проектов вполне годная история.

Ответить
1

В вашем опыте бэкенд по "часам разработки" больше или меньше фронтенда?  Как объясняете заказчикам, который приносят экраны в фигме и ТЗ с расписанным "цветом кнопок", что тут надо бы еще бэкенд сделать? С трудом?  Просто иногда сталкиваемся с такими проблемами, и сильно фильтруем заказчиков )

Ответить
1

Если бекенд занимает 50%+ во всей разработке - то объясняем конечно и стараемся делать ТЗ именно на бекенд, чтобы было понимание объема во всем проекте

Ответить
1

Ок. Интересно...

Ответить
0

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

Вот вам простой пример: у вас один экран с одним текстовым полем и кнопкой "найти" (и над текстовым надпись - гуголь). Скажите, кому тут все понятно? Тут можно только за этой простой схемой делать на 5 минут работы или на 1 год.

И чтоб не было таких кульпитов по срокам надо писать это самое ненависное вами ТЗ, ибо можно даже по самой простой схеме запороться на мелочах.

Ответить
0

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

Ответить
2

Да. Для "мало кто"  создание систем - это все еще искусство), которое совсем не про "минимум усилий для заработка денег". Для тех, кому хочется  строить красивые системы.  

Ответить
19

Вы просто не умеете готовить ТЗ. Рисование экранов - это тоже часть ТЗ.

Ответить
0

А надо ли в современном мире упарываться на написание ТЗ текстом?

Ответить
6

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

Ответить
0

Альтернативные взгляды пока не запрещены в РФ =)

Ответить
1

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

Ответить
0

Обязательно 🙌🏽 Спасибо!

Ответить
0

Для сомневающихся в принципиальной нужности института ТЗ как такового, попробуйте смоделировать ситуацию в не такой уж далекой области - медицине. Кейс: вам предстоит операция и долгая терапия/рехаб после серьезного диагноза, и ваш врач работает по подходу без ТЗ (т.е. заключения смежных спецов ему не нужны, серьезные анализы и КТ, МРТ не нужны и тп), рентген сделал, мочу и кровь посмотрел и вперёд - после надреза будем на месте уже разбираться... как вам подход ??? :)

Ответить
8

У вас как-то смешалось воедино три аспекта: наличие или отсутствие ТЗ; форма ТЗ: текст или формы; методология разработки: всё от начала до конца или итерационный подход. И к наличию ТЗ вы приписали всё плохое, а к отсутствию ТЗ всё хорошее.

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

Ответить
0

Если все идет хорошо с заказчиком - это хорошо!
Мысль скорее в том - что не стоит тратить время на классическое ТЗ на 100 страниц для небольших проектов, а лучше сразу нарисовать экраны и взять в работу.

Ответить
6

Работал без ТЗ почти три года. Все это время был один заказчик, он никогда не знал что хочет. Был только дизайн. И это не значило что если сделаешь все по дизайну, то что ты сделал что хотел заказчик. Приходилось переделывать фичи чуть ли не каждый раз. А то и несколько раз одну и ту же. И сейчас я точно понимаю что так работать не хочу. Но чисто текстовое ТЗ тоже не решение. Хороший вариант - дизайн + частичное описание ТЗ.

Ответить
2

Нужно ли говорить что проект делается ну очень долго? то что в одних студиях с ТЗ и аналитиками делается за 3 месяца, в той студии делалось 6+ месяцев. А как разработчики при этом выгорают?

Ответить
0

Так в нормальном ТЗ уже есть дизайн. Зачем он отдельно?

Ответить
6

Но разве разработка тех же будущих визуалов, на которые будет ориентироваться разработка - не то же самое ТЗ, только в другом виде?

Ответить
1

Вот этот "другой вид" и есть краеугольный камень. Когда делаешь по ТЗ и показываешь заказчику - чаще всего слышишь "ой! вот так это работает, да? а можно по-другому!"

Ответить
3

Это и есть процесс написания ТЗ, гений вы наш! Вы ТЗ с потолка что ли берёте или всё-таки заказчика спрашиваете чего он хочет? А принимает у вас ТЗ заказчик не глядя?
Ой какое чудное ТЗ на нас с неба упало... Так это по вашему выглядит?

Ответить
0

 гений вы наш!

☺️

Ответить
2

 (Табличка Сарказм)

Ответить
5

«Без ТЗ — результат ХЗ» говорят, когда заказчик сам не знает чего хочет. Или не может внятно объяснить, ограничиваясь «сделайте красиво». Здесь действительно многое зависит от качества работы исполнителя. Если работы делаются спустя рукава, то подробное ТЗ — единственный способ добиться желаемых результатов. Обычно так бывает, когда экономят на исполнителях.

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

Когда понимание есть, но нечёткое, картину помогают прояснить вопросы, возникающие в ходе разработкой: будь то визуализация или уже конкретное воплощение. Собственно, проработка этих вопросов — это и есть работа, аналогичная составлению ТЗ. И от неё никуда не деться, не бывает такого, чтобы получился желаемый результат без прохождения этого этапа.

Ответить
0

Правильная мысль, при этом "сделайте красиво" мы рисуем и утверждаем, чтобы не попасть ловушку "сделайте красиво экран с Профилем" и четким ТЗ где прописаны все Поля этого самого Профиля, а потом заказчик говорит "а почему Аватарка такая маленькая и круглая, я хотел прямоугольную и на весь экран".
К слову и высокооплачиваемые специалисты иногда работают спустя рукава - все зависит от мотивации и атмосфере проекта/компании - но это уже отдельная большая история, возможно даже статья на VC))

Ответить
0

Как у вас заказчик может сказать: я хотел другой интерфейс, если он подписывал ТЗ, где есть макет?

Ответить
4

Не совсем понятно как по вашей схеме понять финансовую целесообразность разработки приложения. Например, мне нужно приложение для страховой компании, которое отслеживает активность пользователя и делает ему скидку тем больше, чем больше он активен в реальной жизни. ТЗ нет. Финальную суммы вы назвать не можете.
Ваш вариант это работать по часам, но так я не могу посчитать насколько оно окупится и стоит ли вообще его делать. Как клиенту принять решение без стоимости и сроков?

Ответить
0

Все очень просто. Вы уже описали функционал основной, остались детали и оценка (коридор) будет.

Давайте попробуйем посчитать в этой ветке комментов ваш проект?

Вопросы:
1. Дизайн, бренд-бук, лого есть?
2. Регистрация через соц. сети и/или СМС/код-звонок?
3. Что именно хотите отслеживать, шаги, километры, подъемы/спуски, кручение телефона в руках? Что вы вкладываете в понятие "активен"?
4. Данные надо хранить на телефоне или на сервере, чтобы потом строить аналитику?
5. Через приложение надо будет оформлять полис или будем уводить на сайт и передавать размер скидки?
6. Можно делиться своей активностью в Инстаграм и ТикТок?
7. Будет чат с техподдержкой?
8. Придумали название?

Ответить
7

Вопрос как принять решение, а не как оценить. Вы написали, что надо работать по часам, потому что нет тз, а сейчас пытаетесь вопросами сформировать ТЗ. Я к вам пришёл без ТЗ. Вы мне сразу финальную сумму называете или говорите "не знаем", у нас 3 тыс в час, работаем по часам, оплата каждые две недели? Потому что мне как клиенту не подходит "мы не знаем", а в конце месяца счёт на 250 тыс руб и ничего не сделали, зато интересно поговорили)

Ответить
0

Мы работаем "за часы". Если бы вы пришли к нам, то мы бы предложили вам договор на исследование задачи, от 100 до 200 тыс. руб. потому как без потраченного на исследование  времени не понять, сколько ПРИМЕРНО реализация проекта будет стоить. Никто не способен  назвать эту стоимость по щелчку пальцев.  Хотя нет... школота так делает ).  Результатом этого договора стал бы "предпроект", "конепция" на паре страничек, с точной оценкой первых итераций в часах и их стоимости в рублях. После первых итераций общую стоимость реализации проекта обычно можно посчитать довольно точно. Да, это риски со стороны заказчика,  что можно заплатить за первые итерации и узнать, что проект слишком дорог и его придется оставить. Но в постиндустриальном мире венчурных инвестиций и проектов это обычные риски, которые несет именно заказчик (или инвестор).  Вы итоге, как мы знаем, у венчурных инвесторов в лучшем случае 19 из 20 проектов проваливаются, а один окупает все затраты. В России проваливается 49 из 50, но об этом ниже.

Эта история не подходит для микро-проектов, стоимостью до 500К руб. . Это для проектов покрупнее. 

Из моего опыта, разумные заказчики соглашаются с таким подходом,  и  впоследствии довольны проектом.  Менее разумные - находят школоту/инфоцыган/недоразрабов которые быстро делают что-то за 3 копейки. Результат немного предсказуем.  49 из 50 на помойку. 

Ответить
2

Школота??? Да я знаю одного пятидесятилетнего мудака, который так делает. Мы так смету и сроки в пять раз превысили с этим любителем работать без ТЗ. 
У клиента карьера в фирме по бороде пошла, а программисты поувольнялись с нервным срывом.
А этот мудак счастлив и продаёт такие проекты дальше.

Ответить
1

Ну да... надо какой-то более точный термин придумать для "опытных"  разрабов, которые ведут себя так, как современные школьники/студенты с нулевым опытом. 

Ответить
0

Вы описываете классическую модель ТЗ + R&D.
К вашим исследованиям за 100-200к у заказчика тоже должно быть доверие, а у вас экспертиза в областях нового проекты (пишете вы всю жизнь софт для СМС-рассылок, а вам заказывают игру на Unity создать - как будете R&D делать?) на небольших проектах эти деньги лучше сразу вложить в фичи!

Ответить
0

Ну вы из крайности в крайность. Мы говорим про классическое ТЗ которое избыточно на небольших проектах.
А без функциональной карты, экранов и описания нельзя, иначе что будет в контракте подписываться!

Ответить
1

Так вот как раз в этом и вопрос - как подписывать, когда нет ТЗ, суммы и сроков. Вы же не одна такая компания. Клиенту нужно что-то сделать, но есть только словесное описание на 2-3 предложения. Он же не будет каждой компании платить 100-200 тыс, чтобы поисследовать. А потом выяснить, что реализация будет слишком дорогая. С таким же успехом проще сказать, что 100-200 тыс это не исследование, а написание ТЗ. Вы пишете, что "работа без ТЗ", но всячески заменяете слово ТЗ другими словами - исследоваение, макеты и т.д. Макеты, которые вы сделаете это ТЗ, результат исследований в виде документа это тоже ТЗ. В итоге получается, что вы говорите, что работает без ТЗ, но просите у клиента условные 100-200 тыс на составление ТЗ и потом уже работаете) То есть ТЗ вам не нужно только на этап составления ТЗ, а потом уже работа по ТЗ. Или не так?)

Ответить
1

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

А статья про то, чтобы неопытных клиентов заманить и там уже как получится.
Это же СТУДИЯ и ПРОДАЖНИКИ :)
Продажники продают.
А там уже как программист ляжет, сможет, а может и нет.
Работа по спринтам или по часам подходит только для клиентов которые сами профессионалы в IT.
Но продажнику это не интересно.

Ответить
0

 независимого профессионала

А что это за люди? Где их искать? Как им доверять?

Ответить
0

А очень просто им доверять.
Независимый экперт сделает черновую оценку, разбивку на этапы, высокоуровневый план рисков по бизнесу и по технике, базовый набор документов (начиная со скоупа).
Выбранным клиентом подрядчикам (обычно 3-5) рассылаются документы для оценки проекта, проводятся сессии клиент-подрядчик по вопросам подрядчика.
Клиент получает несколько оценок проекта и несколько оценок работы эксперта по его проекту.
Никакой магии.

Ответить
0

Надо быть несколько сумашедшим чтобы начинать разработку без малейшего ТЗ на проекте длительностью более 1 недели, ну ладно это проф деформация у меня, просто надо не понимать на сколько всё сложно :)
Клиент не знает сколько будет стоить его проект, если вдруг окажется что бюджет начинает лезть в облака, то клиент остаётся в лучшем случае с куском исходного кода.
Дальше ситуация становится хуже.
Подрядчиков уже просят не сделат новый проект, а доделать по исходному коду. Количество потенциальных подрядчиков сокращается из-за выбранного ЯП, из-за воротящих нос, из-за уже выбанного стека технологий.
В ценник начинают закладывать все риски по изучению и переделке исходников.
Клиенту ещё раз надо всё объяснять новому подрядчику...
И это из-за экономии денег и времени на ТЗ :)
И не найдейтесь что с вами такого не произойдёт.
И про порядочных разработчиков нет смысла. Порядочность разработчиков заканчивается в проценте неустойки в договоре...
Разработка проекта длительностью 1 месяц это от 500тыс рублей, а разработка хорошего ТЗ это 50тыс рублей и неделя.
Экономия на кнопках, а придется кактус кусать.

Ответить
3

Да, замечательно и правильно, когда дело касается юзерфлоу.
Но всё, что описано в статье, точно не серебряная пуля, и не ноухау.

Визуальными прототипами/макетами невозможно или сложно показать, например:
- нефункциональные требования и SLA;
- интеграции;
- системные кейсы-вычисления;
- зависимость состояний элементов от наборов параметров. Точнее можно упороться и накопипастить одинаковых макетов, где будет отличаться единственная строка, но лучше описать в ТЗ.

Способ начинать с макетов/прототипов прекрасен, но совсем без ТЗ жизнеспособен, если есть много если, напр.:
- говорим о стандартных штуках, типа магазинов на битриксе;
- внутри команды есть экспертиза по компонентам, которые затрагиваются в проекте;
- нет необходимости поддерживать проект другой командой.

Ответить
1

Да, согласен, ТЗ нужно по многим причинам. 

Ответить
0

Из 100 ТЗ написанных 100 разными людьми-аналитиками-заказчиками - только 5-10 будут годными для разработки сразу, остальное надо будет докручивать вопросами-уточнениями-экранами, чтобы не сесть в лужу при сдаче проекта.

Ответить
1

А вы видели в своей жизни 100 ТЗ?
У меня стаж десять лет и я почему-то не видел столько. Видел наверное пару десятков, большую часть из которых сам писал или принимал участие в написании. И они в массе своей почему-то были нормальными. С какими мудаками вы работаете, если у вас такая низкая квота хороших ТЗ?

Ответить
0

Мы тут скорее про подход разработки для заказчиков, которые все вот хотят свой проект запустить, но ждут "когда напишется ТЗ", а оно все не пишется.

Когда речь касается SLA и бекенд-штук - то да, без четких требований и логических схем не обойтись.

И мы любим такие проекты, когда заказчик приходит с четким пониманием и требованием 💚

Ответить
0

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

Ответить
3

Даже не представляю как вообще появилось все, что нас вокруг окружает...

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

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

Ответить
2

Небольшое ТЗ + прототипы в figma (moqups) - самый хороший вариант. Без ТЗ не все разработчики могут работать. Многим нужно описание того или иного функционала (+ наглядный пример как это будет работать). Не совсем понятно как вы будете формировать смету имея только экраны

Ответить
2

Мне вот интересно, что сейчас чаще всего является бэкэндом приложений, ну там где сервер, база данных, реализация логики и API? И какая это часть в проекте - большая или меньшая? А то ощущение что разработка начинается и заканчивается в figma... 

Ответить
1

Стейкхолдерам чаще всего удобней обсуждать мокапы с исполнителями. Они любят красивые интерактивные картинки. Иногда это вырождается в figma-driven-development. К сожалению вся заказная разработка построена вокруг удовлетворения заказчика.

Ответить
2

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

Ответить
2

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

Ответить
1

Да, согласен

Ответить
0

Видимо @Олег Тиньков сам принимал участие при разработке их Мобильного Приложения банка - поэтому оно получилось невсратым и передовым, что подтянуло все остальные МП банков в отрасли в РФ и ими хоть стало небольно пользоваться.

Ответить
0

А у нас были случаи когда очень обеспеченные заказчики любили Процесс разработки и обсуждения, а до прибыли не было никакого дела (когда ты в Forbes - видимо это уже не так важно).

Ответить
0

Что плохого в удовлетворении заказчика?
Мудрый разработчик и заказчика удовлетворит и приложение сделает прибыльным 🚀

Ответить
1

Плохого ничего. Я лишь написал "вокруг чего...."

Ответить
1

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

Ответить
0

Бекендщики - тоже люди 🤖 Они тоже пользуются Figma, чтобы понимать реальные сценарии и поведение пользователей.
По бекенду всегда возникает больше технических вопросов и уточнений - тут мы делаем понятную документацию по проекту.
При этом очень много вопросов отпадает при просмотре дизайн-экранов у бекендщиков сразу.

Ответить
2

Не знаю откуда в России деление на бэкендщиков и фронтэндщиков, в мире есть простое понятие https://en.wikipedia.org/wiki/Software_architect

A software architect is a software development expert who makes high-level design choices and tries to enforce technical standards, including software coding standards, tools, and platforms.

Но это по-взрослому,  для нормальных зданий.  При постройке дачных домиков  и туалетов типа  "дырка в полу" это все не нужно )

Ответить
1

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

Ответить
0

Смета формируется на основе экранов и короткой описательной части к этим экранам-разделам, например:
1. Экран "Регистрация по СМС"
Пользователь вводит телефон в международном формате, код страны определяем автоматически и показываем флаг страны.
Таймаут 59 сек между запросами СМС.
После 3-й неудачной попытки показать кнопку "Не получается? Позвоните по номеру/напишите на почту"

А расписывать этот функционал на 5 листов через ТЗ не стоит

Ответить
4

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

Ответить
2

Хорошо описано.  Буду приводить в пример заказчикам, которые приносят "готовые проекты" мобильных приложений со словами давайте за недельку сделаем новое МП )

Ответить
4

ОМГ, ну не является ваша тема золотой пулей.  Можно по пунктам раскатать все картинки, и дое-ца даже к спринтам, где типа "дешевле и вообще всем хорошо". Хорошо это только в первую очередь командам тк горизонт планирования не полгода или год, а неделя или 2. Но как и писали выше, вилку все равно надо иметь на руках.
 
Пример
Хочу чтобы регистрироваться могли только жители Анголы, чтобы я мог регулировать по маске телефоны, чтобы для разных регионов разные шаблоны приветствия. Чтобы если чел не подтвердил регистрацию еще 3 попытки автоматом скинули, почему 3 кстати - хочу настраивать количество
Потом я хочу рассылку только от определенного оператора, тк  остальных обычно блокируют. Там только проблема - они расписдяи, поэтому чтобы подключиться надо получить их внутреннее апи, а они рожают неделями (это на основе реальной истории так-то)

В итоге если вы благородно не считаете часы на "уточнения" то контора попадает в рабство на постоянных уточнениях, те вы фактически пишите тоже самое ТЗ только на ходу. 

Надо ли рисовать - надо, но если более менее проект большой надо все пояснять, если клиент сложный - надо также детально пояснять.  

PS я не говорю про гостовские темы, там, субъективно, - треш и угар, но я не буду голословно писать что "осваивают" что-то, тк не специализируюсь на госах.

Ответить
1

точно-точно

Ответить
0

Вы описываете частный случай и знаете много подробностей, о таких подробностях ни заказчик, ни разработчик не знают на старте.
И никто не говорит про "золотую пулю" 🔫
Если есть четкое и классное ТЗ - супер.
Нету - ничего страшного, главное есть идея и умение говорить её)

не считаете часы на "уточнения"

Мы как раз считаем по T&M и всегда есть понятие R&D на новые фичи и неизвестности!

Ответить
2

Ок, есть идея, пример из реальной работы. Надо внедрить НДС в банковские услуги. Всё. Вот вся идея. Не в пользовательское приложение банка, а в принципе в весь банк. До принятия соответствующего закона НДС в банке в принципе не существовал. Как вы реализуете это пользовательскими экранами?

Ответить
0

 внедрить НДС в банковские услуги

Это же больше техническая реализация, и без ТЗ в таких задачах не обойтись. Давайте не мешать всё в один котёл, сваримся 🍳

Ответить
3

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

Ответить
0

Я не знаю где работаете вы

Вначале статьи же написано, вы читали?)

Ответить
0

Ахахаха, единственное что вы смогли ответить это вылепить мне минус? Вот это я понимаю - горящий бэкэнд :)

Ответить
–1

Какая-то гора. Мне это ни о чем не говорит, скорее всего вы мелкая сошка. Ваши типовые проекты я из статьи не вижу. Поэтому пишу: "не знаю где работаете вы." 

Ответить
2

Для вас частные. А так более менее нормальное идет с требованиями которые как бы не особо в интернетах описываются (собсенно одно из конкурентных преимуществ)

По картинкам - это фактически конструктор, нарисовал, накрутил rest на обычную базу без интеграций или с интеграциями которые гуглятся за 5 минут и понеслось. Для стартапов,  mvp - норм. Я сам топлю за картинки с подписями или скрины аналогов, но крупняк периодически с легаси подкатывает и всегда с требованием оценки. Там темы -  а давайте ка вмести поскрамим не очень заходят. Одно дело потратил пару дней перевел хотелки в ТЗ -  получил вилку, оговорил риски, другое дело с условным  рейтом заказчика в 500$ в час
решаешь каждый пук с командой ) А если там у чела поток мвп идет и тп и тд 

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

Ответить
0

Спасибо за фидбек!
А так хотелось Оскара 🏆 в номинации "Работаем дальше без ТЗ"

Ответить
2

Похоже, что автор просто недавно закрыл пару проектов на очень хорошей ноте и, сохранив настрой, написал статью. Статья спорная. Сначала читал и такой "да, да, Господи, да", а дальше – хуже. Слишком много энтузиазма. Иногда этот энтузиазм просто игнорирует здравый смысл. Сколько времени Вы работаете в этой сфере, Артём?

Ответить
2

В IT опыт 15 лет, свою компанию основал 5 лет назад.
Не теряйте энтузиазма и вы 🔥

Ответить
1

Только лишь потому, что у меня много энтузиазма и в чем-то схожие взгляды, я довольно лояльно отнесся к Вашим мыслям)

Я тоже владелец агентства (кстати мы тоже работаем чуть больше 5 лет – с 2015), и подход у нас похожий – клиент нам говорит своим языком базовые потребности проекта, а мы делаем его лучше, чем клиент представлял. Нам не нужно подробное ТЗ, но подробное обсуждение проекта – обязательно. Я думаю, для задач, лишенных творческого подхода, ТЗ очень даже хорошая штука. А для нас свобода действий и объективная смета хорошая штука.

Ответить
1

Рад знакомству с коллегой по цеху 🤜🤛

подробное обсуждение проекта – обязательно

Абсолютно поддерживаю!!

Дадите ссылочку на вашу студию?

Ответить
2

Взаимно, Артём🤜🏼🤛🏼
Давайте я отправлю ссылку на презентацию наших ключевых проектов – https://cloud.mail.ru/public/PXWx/gYmQxhgrk, так как наш сайт (https://studio-direct.ru) устарел, а новый еще не готов (http://51.222.30.188:8000), а наш промо-сайт (https://shark.studio-direct.ru), наверное, не совсем уместен.

Ответить
1

почему работа без ТЗ 

То, что нужно заказчику 

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

Ответить
5

Причем чем подробнее ТЗ, тем дешевле проект обойдется заказчику. Предлагать кому-то работать без ТЗ = кидать его на бабки 

Ответить
0

А вам не кажется, что работать по ТЗ - это способ засейвиться недобросовестным исполнителям. К нам попадают проекты после таких "исполнителей" и мы читаем ТЗ, а там написано "Сделать регистрацию через соц. сети" и всё! А какие это соц. сети и как будет выглядеть экран не написано, вот Заказчик и получает "то что подписывал" а не "то что хотел".

Всё сильно зависит от качества ТЗ, но качественные ТЗ в дикой природе встречаются крайне редко (это дорого и долго).

Ответить
4

Не кажется. Часто сталкиваюсь с ТЗ, написанным школотой. Это из разряда юмор).  Но  хороший процессинг, группой  разрабов не написать без проекта. Например такой - https://bil24.pro// Думаю, мы сейчас о разных классах проектов.  Дачи это одно, небоскребы - другое. 

Ответить
1

Хороший процессинг и не Figma строиться) Вы правы - задачи разного калибра и подхода.
Из 100 проектов - 99 это что-то небольшое и быстрое, попробовать идею, зайти на рынок, добавить технологичности в устаревшее приложение, показать лицо или мускулы компании и тд.

Инстаграм и Фейсбук я думаю перестраивали в небоскреб неоднократно из соломенного домика (привет Рефакторинг!)

Ответить
3

Это у вас 99% проектов - мелочь. А у людей имеющих понятие о Project Management, основные проекты - крупные. Мелочь нам даже создание своей песочницы не окупит, про обучение персонала я вообще молчу

Ответить
2

Еще локализация и интернационализация,  написание документации ко всему созданному, типа такой  https://bil24.pro/editor.html , на двух языках. Часы улетят очень быстро...  Это все дорого. Но это другой класс проектов, статья скорее про инфоцыганские варианты быстрой проверки гипотез. 

Ответить
2

Угу. Если есть ТЗ (а оно скорее всего динамическое, где отражаются все правки и актуальные версии), то имея его на руках у нас студент-практикант за неделю пишет User Manual. Как его писать пез проектной документации я хз. Это получается надо по новой анализировать весь готовый софт.

Ответить
0

Точно

Ответить
0

Бомбические вы ребята, судя по всему 💣

Ответить
1

Ошибки на этапе проектирования тяжелее всего исправляются, особенно, когда они внесены в фундамент здания и на них построено несколько этажей, которые потом приходится разбирать и перестраивать.  Поэтому лучше месяц подумать, и за неделю сделать, чем неделю думать, и полгода переделывать. Ну и с развитием системы растет Legacy.  Тут разность подходов в том, что кто-то за 20 лет делает 4 проекта (3 успешных), а кто-то быстро "тестирует", например,  50 проектов в год (1 успешный). И тот и другой подход имеет право на существование.   

Ответить
0

Четырем проектам за 20 лет предшествовали 50 мелких проектов и обкатка идей, иначе в такие крупняки без понимания рынка и рисков не вписываются.

Ответить
2

Без понимания рынка - да. А с пониманием - легко. Поэтому хороший заказчик тот, кто давно и успешно работает на своем рынке. Говорю о своем опыте работы с заказчиками - https://kernel.group/

Новичков просто много набегает, вот и кажется, что все надо быстро тестировать. Ну и инфоцыгане же увеличивают свое "поголовье" со своими маркет фит или не фит ))

Ответить
1

Классный у вас сайт и проекты 💪

Инфоцыгане, к слову, очень интересные проекты придумывают и знают цену дорогим игрушкам 🏎

Ответить
1

Этого у инфоцыган не отнять )

Ответить
2

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

Ответить
3

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

Ответить
2

Опять же точно и наглядно сформулировано, плюсую )

Ответить
0

При этом картина, которую вешают по ТЗ может стоить дороже здания в котором она висит. И рисуют её без ТЗ.

Ответить
0

Угу. Будет очень обидно, когда эта картинка из-за вашей кривой дыры, которую вы без ТЗ как-то непонятно пробурили, упадёт на пол, сломается и прекратит существование. Обосратушки будут.
К примеру если пользовательские данные утекут из-за того что вы об этом не подумали и в ТЗ не вписали. Можно в лёгкую хапнуть проблем на миллионы долларов из-за вашего вшивого приложения за 500к рублей

Ответить
0

Еще многие заказчики очень любят игнорировать/пропускать  такой этап как нагрузочные испытания. Этим сейчас вообще мало заморачиваются. А то "нагрузишь", и MySQL не выдержит )). Школота вообще обещает обслуживать в секунды  миллиарды пользователей. Очень малому числу людей удается объяснить зачем существует ACTIAN NoSQL Object Database, за большие деньги.  При том что Postgres бесплатный. Пришлось даже перевести некоторые примеры - https://kernel.group/actian.html

Ответить
2

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

Ответить
2

без ТЗ очень трудно работать. В основном можно столкнуться с этим когда у заказчика только идея и проект начинаем с нуля. Тогда можно столкнуться с постоянными "бесконечными" правками.

Ответить
1

Если проект разрастается и появляются сложно-технические сущности - написание ТЗ неизбежно на отдельные микро-сервисы.
Также важно вести документацию по проекту и поддерживать все в актуальном состоянии - любое ТЗ устареет через год - это факт!

Ответить
2

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

И к разным проектам подходят только свои методики реализации, главное, чтобы всегда были контрольные точки, обозначенные (кто бы мог подумать), в тз, или на крайняк техтребованиях.

Ответить
0

Мы не против ТЗ - мы против боязни начинать работать без классического ТЗ!

Аналитик - ценнейший юнит в команде 🏅

Ответить
1

Аналитик, способный родить тз за 3 месяца, имеет немножко сомнительную ценность, тем более, если речь идёт про не большой проект). Хотя, даже если и большой, столько месяцев не уходит, даже если тз и гипотезы ты перед стартом у инвесторов защищаешь.
Без классического тз в рамках т&м можно работать при наличии очень проработанной структурированной дорожной карты (что клиент предпочитает иметь не на стадии основной разработки, а уже после, на улучшении системы) + обязательного ведения детального лога разработки, иначе это все очень уязвимо для самого клиента, ставит в зависимость от текущего разработчика, дюже болезненно передавать другим, если потребуется.
И разработка карты занимает времени ещё больше, чем классическое тз. А ведение лога, вместо описи механик в тз, тормозит выпуск в продакшн, что однофигственно получается по итогу, что тз сразу написать, что лог потом / в процессе разработки.
Обжигались уже, мало кто просто так без мапа сливать бабло даст, сначала 145 кругов согласования, составление карты, угодной всем направлениям, а потом уже вперёд, с еженедельными отчетами, пилите.

Ответить
2

Я только прочитал 1-й абзац, сразу понял, что будете рекламировать работу на почасовке :)

Но если по факту, вы описали ТОЛЬКО все минусы работы ИМЕННО по плохому ТЗ, причём, сильно утрировали их, и описали ТОЛЬКО все плюсы работы без ТЗ (хотя на самом деле, это такое же ТЗ, только на почасовке, в виде проектирования в Фигме с текстовым описанием возможностей фич, где все равно нужно будет back-end логику описывать дополнительно, ибо если приложение не клиент-серверное, то его нечего здесь и обсуждать).

В итоге, главный вопрос который вы здесь «раскрыли», что без ТЗ будет дешевле, быстрее и выгоднее не прозвучало убедительных аргументов, т.к. приведённые примеры написания ТЗ не понятно от куда взяты, либо вы сами их так пишете, долго, дорого с кучей ненужной логики (типа, эта кнопка выглядит вот так и по нажатию на неё открывается вот этот экран ...) либо специально привели именно такие примеры, чтобы ваш подход в глазах «потенциальных клиентов» выглядел «золотой пулей» (скорее это конечно).
И даже если к вам пришли с плохим ТЗ, то ведь его же можно прочитать и дать оценку fix price по приведению в порядок, не так ли кэп?))

Описывать в ТЗ «лишнюю и нудную логику» конечно же это бестолковая трата времени, т.к. стиль и тапы по кнопкам, подробное описание валидаций (если это конечно не логика бизнес-процессов заказчика) отображается как раз на следующем этапе работ, т.е. когда в ТЗ четко прописали функционал и его возможности, дали оценку fix price, можно уже рисовать интерфейс. А какой именно, т.е. проектирование либо сразу дизайн пилить, это уже вопрос индивидуального проекта. Много условий, бэк логики, сценариев «если, то», лучше конечно сначала обойтись проектированием, а потом красотой заниматься. Более-менее типовой проект, вроде онлайн-магазина, можно и сразу в дизайне это все делать.

ИМХО. Не красиво хейтить подход написания ТЗ, когда это делается не с точки зрения объективности и помощи тем, кто хочет разработать аппу, а с точки зрения только рекламы своей студии.

Ответить
–2

В статье ни слова хейта про классическое ТЗ, даже больше - мы приветствуем хорошие ТЗ и научный подход в разработке.

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

Основная мысль - не нужно бояться разрабатывать Мобильное Приложение или Сервис/Продукт не имея на руках ТЗ или не имея возможности его написать своими силами.

Приведенные примеры взяты из реальной жизни.

к вам пришли с плохим ТЗ

Ну как можно давать оценку по плохому ТЗ, чтобы потом за свой счет дорабатывать/багфиксить неучтенные моменты!!

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

А вы много в своей жизни встречали толковых ТЗ где все понятно и доступно и можно сразу брать в работу?)

Ответить