Transcription
Всем привет. Мы сегодня записываем новое видео для наших потенциальных клиентов и тех, кто собирается заниматься разработкой цифровых продуктов самостоятельно. И у нас сегодня провокационная тема: а нужно ли вообще техническое задание для разработчиков? И мы сегодня об этом будем разговаривать.
А с вами Мария Галиева, SEO и кофounder студии IT Production или в наших новых реальностях IT Prodдаction. и Данил Рябов, сетево компании Кофаундер.
А, ну что, Данил, у нас тема такая про технические задания. Мы её очень давно, ещё года два или три назад записывали про то, как составлять техническое задание. У нас получилось с бизнес-аналитиком у нас получилось очень большое видео, но вот каждый раз, когда я смотрела, и оно до сих пор там популярно и все смотрят, каждый раз, когда я смотрю, я понимаю, что реальность-то уже за 2-3 года изменилась. И та информация, которую мы давали в старом, ну вот видео на сегодняшний день, вот для меня кажется она неактуальная, потому что это вообще большая, а, большой-большой вопрос вообще, нужно ли это техническое задание для разработчика? Вот ты как разработчик скажи, пожалуйста, поделись своим опытом, как вот на сегодняшний день ты относишься к тому, что клиенты приходят к тебе со своим там готовым техническим заданием?
Угу. Ну, чаще всего клиенты приходят не сколько с техническим заданием, а либо списком функционала, либо списком пожеланий.
Вот это небольшая такая небольшой такой документик с тем функционалом, который они хотят видеть в своём проекте. И это действительно не техническое задание. То есть техническое задание всё-таки это мостик между бизнесом и технологиями там, условно, в первую очередь, да, и оно помогает, скажем так, соединять это всё. Вот. Ну и также это, ну, не знаю, не второстепенная задача, но тем не менее это контроль выполнения, что тот функционал, который был запланирован, обсуждён, он будет реализован, реализован именно так, как мы это обсуждали.
Назови два-три признака, а-а, так скажем, списка функций от технического задания. Чем они отличаются?
Вот техническое задание всё равно оно хотя бы должно быть полноценным. То есть мы там не берём какие-то прямо очень там здоровые технические задания, где описывается буквально всё, но хотя бы минимально, чтобы там были функциональные требования, которые говорят, что вот есть такая-то функция и то, как она работает. В каждой функции там есть, например, определённые сценарии использования, есть роли, есть правила. Вот. Ну и отдельным пунктом там можно вынести интеграции. Вот. Можно также написать нефункциональные требования, то есть с какой скоростью у вас должны загружаться данные, э там условно какие-то другие условия, вот, которые описываются. Ну и этого уже, ну, можно сказать, достаточно для того, чтобы, ну, сделать хороший продукт.
Как считаешь, может ли сам клиент написать это техническое задание? Вообще, способен ли он?
Чаще всего нет. Вот, как правило, да? То есть бывает действительно исключительные люди, которые хорошо прорабатывают функционал, в целом глубоко погружаются, но чаще люди без экспертизы в этой области, ну, достаточно сложно написать даже с искусственным интеллектом.
Почему нет? Ну, то есть чего не хватает или в чём трудности, что клиент сам не может написать ТЗ?
Ну, как я и говорил, э чаще люди не могут соединить себе, скажем так, компетенцию технологий и бизнеса. Чаще всего это всё-таки со стороны бизнеса. Я вижу такую функцию, то есть там, например, я хочу там авторизацию по номеру телефона.
Ну и в целом всё, да? То есть а нюансы и точности, тонкости, которые, ну, действительно всплывают при разработке, люди, которые технически знают об этом, то есть их, ну, сложно даже догадаться о том, что они нужны, на самом деле.
Угу. Да. Вот тут мы, конечно, с тобой сейчас немножко перескочим. Я так предполагала в конце это обсуждать, но всё-таки сейчас разговор сюда зашёл. А мы с тобой, когда работаем вместе над заданиями клиентов, над проектами клиентов, давай так, не задания, а мы с собой делаем техническое задание. Э и вот раньше особенно мы делали его в конце, после того, как у нас в конце подготовки к разработке, а у нас сначала шёл этап такого некого проектирования продукта, этап дизайна. Мы отрисовывали все экраны и уже на последней стадии подготовки мы делали, описывали весь функционал, как он работает. А, но вот сейчас, да, особенно вот по последним проектам, я тоже вот вижу шаг в сторону улучшения этих процессов, потому что каждый раз, когда мы с тобой пишем техническое задание, у нас ещё возникают по дороге различные изменения в продукте. Иногда бывает, что нам надо поменять userflow, да, путь пользователя, что а мы вот сделали вот так, что клиент должен нажать там первую кнопку, вторую, третью, грубо говоря, а для технической там реализации проще сделать, что он сначала нажимает третью, а потом первую, вторую. И, соответственно, это меняет последовательность там экранов или иногда переходы между экранами. А вторая история, которую вот мы с тобой последний раз тоже анализировали, это периодически бывает такое, что мы в дизайне забываем некоторые технические экраны и какие-то мелкие процессы. Вот ты даже сейчас привёл пример про телефоны, и мне сразу это вспомнилось, что не всегда там бывает, что были моменты, когда мы там, например, забывали, что ой, а после там нам надо дать возможность пользователю поменять номер телефона, если у нас вот способ авторизации. А где он зайдёт в этот процесс, а как он будет отображаться, это немного другие экраны. А что, если у него не будет приходить эсэмэска, он будет нам писать в техподдержку? А если это на этапе регистрации, а мы же ещё не знаем его контактов, значит нам нужно дополнительное поле, в котором надо спросить контакт, по которому нам надо связаться с ним, чтобы помочь ему зарегистрироваться. То есть вот такие вот все моменты, а это уже более глубокая проработка проектов, которую, ну, на мой взгляд, большинство клиентов, во-первых, они её не должны делать, а это всё-таки должна делать команда разработки. Во-вторых, это правда очень сложно. То есть даже специалисты с опытом в ходе работы, мы пока работаем там 2-3 месяца над каким-то проектом, у нас глаз замыливается, у нас меняется процесс, и мы сначала думали вот так, потом вот так, потом вот так. То есть это такой рабочий живой организм, проект.
И мы, правда, даже сами можем иногда что-то подзабыть. И для этого у нас там есть несколько рэперных точек. Вот вчера мы, например, с тобой проводили установочную встречу, а, по передаче проекта из направления подготовки проектов, да, моего направления в твоё направление разработки. Вот мы проговаривали вроде уже ИТЗ и дизайн, который мы там видели последние 2-3 месяца на 33 раза его перепроверяли, всё описывали. И вот мы проводим обязательную встречу, когда мы передаём этот проект разработчику. Всё. И убеждаемся, что разработчик всё понимает. всё, всё правильно увидел, всё правильно прочитал в техническом задании.
И вот даже вчера мы такие: "Ой, блин, как так? А вот это поле лишнее". И тут же быстро внесли правки, потому что, да, оно, а-а, нелогичное и вроде бы, казалось бы, простой проект и долго на него смотрим и опыт, и насмотренность большая, но всё равно пропускаем. Поэтому вот в этом случае я вот тоже думаю, что написание ТЗ - это не просто сделать документ там технический даже, но это и про процесс проверки, доработки продукта и дизайна.
То есть для меня это сейчас такие три кита: дизайн, продукт >> и техническое задание.
Вот поэтому >> я вот >> Да, ну я то я тоже я не знаю, как мысль тоже возникла. всё-таки, когда мы с, скажем так, погружены в процесс там ТЦ, описание и так далее, то есть мы на самом деле намного лучше понимаем процессы, когда мы их сами конструируем и делаем. То есть это тоже немаловажный фактор вот погружения команду в сам проект.
Ну, по крайней мере, основных участников этого проекта.
Да, точно, точно. Да, и вообще и всех и всех сотрудников. То есть, э, ну, мне сложно представить себе проект, когда клиент приходит и говорит: "У меня готов уже и дизайн, и ТЗ". У нас такого никогда не было. Да, ведь?
Ну да, да.
У нас были проекты, когда которые приходили, я, кстати, вспомнила наш проект Актуса. Ребята приходили с готовым дизайном, >> то есть они уже проработали весь продукт. И всё равно мы со своим взглядом увидели очень много там неточностей, моментов неправильных, некорректных там в логике.
А я ещё вспомнила, да, ещё такой же важный момент был у нас вот вот конкретно в этом проекте. возникнут трудности с публикацией, особенно мобильных приложений в сторах. Вот я как раз мы в Таксе вспомнила, там не хватало функционала обязательного, без которого бы потом в приложении не пропустили сторы. И тогда пришлось бы его откатывать, дорабатывать, менять дизайн, добавлять кнопки, там переходы. Вот я вот этот момент тоже сейчас впомнила. То есть помимо того, что ты можешь продумать свой продукт, но тебе ещё надо быть в курсе последних требований для публикации приложения, ну там, >> Угу. >> наше любимое законодательство последнее время очень сильно меняется. Тебе тоже надо знать, где можно хранить данные, где нельзя, какие слова можно на английском писать, какие нет. Да, более текущего рынка в реалиях марта месяца двадцать шестого года. Вот поэтому вот это тоже, то есть технические специалисты это, кто работают регулярно с проектами, они это всё отслеживают, все эти тренды изменения и в законодательстве в том числе. А клиент как бы не обязан это всё знать, а искусственный интеллект врёт, >> да, >> с этими моментами >> очень сильно врёт, на самом деле, да. Ну вот, кстати, переходя вот к искусственному интеллекту, на самом деле, часто сейчас, если раньше люди приходили именно просто с описанием функционала, что мне нужен набор функций вот таких-то, то сейчас уже люди иногда приходят прямо условно, ну, вроде с неплохим ТЗ, ну, грубо говоря, просто расписанным ТЗ, что там какой-то функционал, он работает так и так. И то есть тут, наверное, вот тоже второй вопрос: а вот может ли искусственный интеллект написать хорошее техническое задание? Я думаю, что там часть людей, которые нас смотрят, конечно, может верить в то, что искусственный интеллект - это Бог. Но на деле, конечно, искусственный интеллект без человека не может сделать хорошую, качественную работу. Он может создать основу, и обязательно его надо использовать в работе, но он конечный продукт всё равно не сделает. Я вот просто в технических заданиях, которые иногда присылают нам клиенты, я просто вижу ещё такую проблему. слишком жёстко заданы рамки по стекам, по технологиям, по тому, как должно быть реализован продукт. А ты со своей стороны опытный видишь, что этот продукт мо можно было сделать бы дешевле, проще и вообще технологию лучше использовать другую. Вот чтоб не попасть вот в эту ловушку, когда искусственный интеллект тебе задаст какие-то жёсткие рамки, как тебе как разработчику в том числе, да? А а это на самом деле во вред проекту. Вот как ты работаешь и что бы ты посоветовал на практике?
Ну, на самом деле, на пра, да, вот стоит сказать, что я использую искусственный интеллект для того, чтобы как бы, ну, как инструмент для написания технического задания. Это много решает вот эту проблему белого листа, когда ты сидишь, тем более кучу писанины, которую тебе нужно описать. Но вот в первую очередь, что немаловажно для искусственного интеллекта - это контекст. То есть всё-таки перед тем, как мы переходим к техническому заданию, у нас очень много идёт обсуждений того, какой функционал должен быть, да? Мы часто рисуем UX, то есть уже базовых экранов для того, чтобы клиент уже на, скажем так, не просто говорить, да, он уже видел, как это выглядит и так далее. То есть всё-таки в первичную очередь для искусственного интеллекта нужен контекст. Контекст не только описание вот тех самых функций, которые должны быть в мобильном приложении, ну или там в любом другом проекте. Но и помимо этого, то есть в целом полная информация о том, что это что и как должно работать. Поэтому, как бы, я загружаю очень много контекста. Вот, то есть это расшифровки звонков, это там экраны скажем так, икса, это там моё личное описание того, как и что, какие нюансы стоит учесть, какие моменты там не договорили. Вот. И после этого нужно написать, ну, условный промо. Потому что даже когда я загружаю этот контекст первые времена я вообще сталкивался с тем, что зачем-то в техническое задание искусственный интеллект тащит большое описание, а, вообще элементов экрана. То есть тут тоже не нужно вот создавать вот эту лишнюю, э, скажем так, звено конфликта, да, что вот в ТЗ написано так, а в дизайне отрисовано так. То есть всё-таки UI в техническом здании не должен присутствовать. должен присутствовать, ну, в каком-то виде, да, там описание, но ни в коем случае, что там вот такой-то текст, такой-то цвет. Это всё должно быть в дизайне. Вот, соответственно, в промте я задаю, что должно присутствовать в техническом задании, то есть те же самые функциональные требования, что обязательно нужно прописать роли, которые должны быть в этом проекте. Это пользовательские сценарии. Какие? Ну, то есть функционал, пользовательские сценарии, интеграции немаловажно, а, и бизнес-правила.
А давай прямо проговорим, что есть роли, что есть пользовательский сценарий чуть-чуть, потому что не все могут нашей терминологией разговаривать.
У. Угу. Да. Ну, смотри, по сути, роль это участник, скажем так, ну, по сути, кажется, как будто пользователь и пользователь, да, пользователь там мобильного приложения, пользователи сайта, но часто этих пользователей можно поделить на разные категории. То есть самая базовая, которая нужна - это там пользователь и администратор. То есть человек, который может больше иметь функционала, в том числе модерирование контента или там каталога, да, который может, соответственно, управлять. Возможно, в мобильном приложении более сложном, не знаю, там представим какую-нибудь Яндекседу, где у нас есть роль пользователь, есть роль курьера, есть роль там службы поддержки, то есть очень большое количество ролей. И часто помимо того, что это может влиять на функционал конкретного проекта, это может вообще быть в итоге отдельный там, скажем так, отдельное мобильное приложение, отдельно административная панель.
Давай я добавлю от себя, что роли они отличаются, как правило, по функциональности, то есть, грубо говоря, доступом к каким-то функциям. Например, тоже базовый есть пользователи авторизованные, неавторизованные, то есть у них разные пути. Ээ, там иногда в приложениях, если ты не зарегистрировался, ты можешь какой-то функционал видеть, выполнять, там, переходить между какими-то экранами, но информация, которую ты будешь видеть, она не полная. А после регистрации авторизации ты получаешь полный доступ. То есть, соответственно, в техническом задании обязательно должны быть прописаны все эти роли, а-а, все виды пользователей, которые обладают там разными доступами к информации, к функциям и при и, соответственно, описано, а что они могут, а чего они не могут, что они видят, чего не видят.
Вот. То есть вот Данил сейчас роль ему вот так вот прямо подробно развернули, чтобы точно всё было понятно, >> да? сценарии, то есть, ну, базово можно разделить, то есть функционал там, например, авторизации может влиять там на разные сценарии. То есть сам сам то есть, например, пользователь сценарий, когда он регистрируется, то есть что он должен делать, да? Там заходит на отдельный экран или в этом же экране вводит номер телефона, его перекидывают на заполнение профиля. Там другой сценарий - это когда он авторизуется, то есть заходит, например, в свой аккаунт, то есть он уже пропускает какой-то этап, там восстановление пароля, там обращение в службу поддержки. То есть вот это вот все сценарии, которые должны быть описаны в в функционале авторизации. по сути >> вариации развития событий внутри приложения, >> да, это это тоже боль это одна из самых сложных вещей, потому что наш мозг такой предпринимательский, я имею в виду, он обычно прописывает сценарий от точки А до точки Б. Вот такой идеальный. Иногда может быть там разветление, что а если он захотел там один товар, то это вот такой сценарий, а если три товара, то вот такой сценарий. Это мы ещё как-то можем в своей голове представить. Сложнее всего представить сценарии, когда пользователь идёт не по тому пути, который мы предполагаем. Один из примеров - это когда пользователь не закончил там, например, оформление заказа >> и закрыл, закрыл приложение, отвлёкся, вышел. Что происходит с ним тогда? А что происходит, когда он возвращается обратно в приложение? на каком экране он должен, а, появиться или где у него там, э, должно быть уведомление о том, что ты не закончил заказ, давай пойдём, заверши его и так далее. То есть вот эти вот все сценарии очень тяжело предпринимателю предусмотреть, а уж тем более, когда выскакивает какая-то техническая ошибка, но тоже один из примеров. А у пользователя нет интернета и ты нс ээ прерывается сценарий, не прошла оплата, там не случилось э ожидаемого результата. Что тогда будет происходить в приложении? Ну или там даже на сайте, не суть важно, в любом цифровом продукте. Вот, соответственно, сценарии вот эти все, они тоже должны быть описаны в техническом задании. И вот это тоже одна из сложностей, которую прямо тяжело самостоятельно проработать без команды.
То есть бизнес-правила - это условно призаданные условия. То есть, например, мы должны там минимальную сумму заказа сделать там от 500 руб. То есть это определённо влияет на функционал, который там должен дальше отображаться, что у нас, например, дальше мы оформление заказа не можем продолжить, пока сумма корзины не достигла 500 руб. Вот, соответственно, как бы это бизнес-правило. А вот интеграции - это когда ваша, скажем так, ваш проект там, ну, представим приложение, то есть взаимодействует с другим с какой-то другой системой. Там самое базовая - это какая-нибуд платёжная система, например, там касса, да, Cloud Payments или, например, какая-то уже там ваша система. То есть, если там представить какой-то ресторанный бизнес, >> да, или сеть, то есть, соответственно, это там комтеркипер или Айка, вот, на котором, соответственно, базируется. И на самом деле хоть и интеграции, как бы вот так объяснить, но это очень сложная история, потому что у каждой системы есть свои собственные ограничения, есть собственная там документация. И очень важно поисследовать вообще эту систему, как она работает, для того чтобы, ну, понять, а вообще можем мы этот функционал реализовать, который придумали или не можем. Конечно, делает не клиент, а это делают разработчики и проверяют, читают документацию, смотрят всё, да, и потом ещё и настраивают эту интеграцию. То есть учат, как я обычно привожу пример, это как вставить вилку в розетку. У тебя есть определённый стандарт по вилкам, по розеткам. Они должны подходить и передавать друг другу ток. Вот. Ну, иногда в обе стороны, на иногда в одну сторону. Ну, то есть, э, это всё действительно надо продумывать и правильно встраивать.
Угу.
Давай так. Мы с тобой, конечно, сейчас говорим про некую такую идеальную систему, да, но ведь ээ мы начали с тобой разговор с того, что вообще, а нафиг нужно это техническое задание. Мы вернёмся к тому, что у клиента пока ещё там потенциального там клиента на разработку ещё нет ни команды, ни специалистов. Вот он так вот у него опять этот эффект белого листа, да, чистого листа, как ты ска говоришь. У >> аа всё-таки нужно ему в на этой стадии делать техническое задание, ну или даже давайте так, у нас появился ещё второй термин >> описание функциональное цифрового продукта, так скажу. Угу. >> Вот нужно ли ему это делать или можно сразу идти в разработчиков? Ну, скажем так, из-за того, что вот возникает такой, ну, скажем так, парадокс, что разработчики не могут оценить ваш проект. То есть вы приходите в основном с оценкой, что нужно понять, а какой бюджет нужен на реализацию. Разработчики говорят, что нужно ТЗ.
Приходит человек, смотрит, например, наше видео, да, и понимает, я не напишу это ТЗ. Вот и возникает как бы сложность. Ну и в основном всегда получается так, что изначально важно выбрать, ну, команду, с которой вы будете работать, по крайней мере, которая, ну, скажем так, вы сходитесь, да, вам всё нравится и уже непосредственно с потом работать с этой командой и уже писать техническое задание. Да, хорошо иметь описание вашего проекта, какой функционал вы хотите. Вот. Но на этом этапе невозможно получить точную оценку вот до заключения, да, там в разработку. А нужно всегда идти в первый этап. Это отрисовка дизайна, ээ, там, не знаю, икса и написание технического задания.
Да, кстати, будет интересно. Напишите в комментариях, когда вы ходили в к разработчикам с каким-нибудь проектом, там делали ли его техническое задание, а и там какой разбег у вас по стоимости был оценок? Ну то есть всё равно, что скорее всего вы в несколько студий там обращались или к нескольким разработчикам, там сайты или что-нибудь там приложения или ещё какие-нибудь цифровые продукты, которые делали. Вот насколько у вас был, по вашему опыту, разброс в ценах и было ли у вас в этот момент техническое задание? А так, о'кей, мы с тобой поговорили про терминологию. Давай тогда вернёмся ещё к вопросу того, что как использовать искусственный интеллект для написания технических заданий, ну или даже функциональных требований.
Ну да, по сути, то есть помимо того, что подготовка и так далее, даже когда он пишет итоговую версию, да, она требует большого, то есть самое затратное время - это то, когда ты редактируешь этот текст. Ты проверяешь каждый пункт, смотришь, сверяешь сценарии, всё ли это учтено, всё ли это корректно, прорабатываешь этот текст, то есть правишь там мы с тобой часто, да, то есть как бы я тебе присылаю на вычитку, ты смотришь, вносишь свои комментарии.
Поэтому вот это самая важная вообще работа вот, которая занимает больше всего времени, а не само вот написание, скажем так, технического, ну, как бы а не генерация, скажем так, текста в искусственном интеллекте. Поделись каким-нибудь лайфхаком, что написать искусственному интеллекту, чтобы он чуть лучше сделал черновую версию технического задания.
Ну поделись. Ну давай скажи что-нибудь интересное. Вот явно у тебя есть секретики.
Ну нет, ну какие-то секретики есть, как бы я чуть-чуть уже там рассказал, вот. Но по сути это не, ну как бы вам это не сильно поможет. Вот, если честно. То есть в итоге написать техническое задание, ну всё же сложно. самостоятельно. Вот это должна писать команда разработки. Ну, на практике, ну, ладно, давайте, если конкретно, то есть после того, как вот вы собрали весь этот контекст, э, который вы передали, соответственно, в нейронку, вот, то есть она ознакомилась с этим контекстом, всё прочитала, там, скажем так, сформировала. После этого нужно задать промпт, а, о том, что нужно, скажем так, написать. Ну, промт, по сути, сообщение в нейрон, вот так скажем. Угу.
Вот, соответственно, вы всё описываете, что нужно прописать роли, нужно прописать сценарии, бизнес-правила. И причём бизнес-правила вы должны сами передать, потому что нас за вас не напишет бизнес-правила. Вот. И интеграции. Но при этом интеграцию нужно учитывать, даже если она опишет эти интеграции. То есть не нередкий случай, когда там Неронка берёт первую ссылку документации там какой-то системы, а это вообще прошлая там версия, например, этой интеграции. Вот. И в итоге она даже неправильно это всё описывает. Вот, э, описывайте вот это.
А что наоборот исключить?
Исключить обязательно это различное описание UI элементов, соответственно, проекта. Это важно исключить.
Мм,
это всё должно быть в дизайне по сути адресовано. И тексты, название кнопок там все этих переходов, все эти тексты тоже должно быть в Ui, не в техническом задании.
Да. Ну, в целом.
А по стекам что ты думаешь? Может ли Иишка подобрать хороший стек для проекта?
Подобрать может хороший. Тут другой вопрос. Э, скорее, неронка же. Ну, если вы ей напишите вопрос: "Мне нужно быстро разработать проект", она подберёт вам один стек. Если вы говорите, там, мне нужно, э, там дёшево, например, реализовать, оно подберёт другой стек. Всё зависит от предустановленных условий. А часто вот эти условия, ну, человек сам до конца не понимает, нужно ли ему быстро или дёшево, потому что, ну, это нужно садиться, ресёрчить, понимать, вот, нежели чем просто спросить у человека, который уже компетентен в этом вопросе и может сказать, что, например, вот на таком стеке можно там у него такие выгоды, у такого стека такие-то выгоды.
Я я сама сказала, сама себя сейчас отловила. Надо уточнить, что мы сейчас не про мясо говорим, а про технологию, на которой будет вестись разработка, грубо говоря, язык, на котором это всё будет делаться.
Вот. И я вот тут ещё добавлю от себя, что иногда, >> а очень сильно тоже технология влияет от условий, в которых вы делаете разработку. Возможно, вам нужны какие-то более
бюджетные варианты. Возможно, вы делаете не запуск продукта на много лет вперёд, а тестовый запуск MVP. А-а, так называемый, когда мы хотим проверить рынок, проверить нашу идею, готов, ну, насколько она жизнеспособная, насколько рынок готов её покупать, платить за неё. А в таких случаях есть смысл использовать какие-то более дешёвые, простые технологии. А есть проекты с низким бюджетом там, или нужно очень быстро запустить проект, тогда это другие технологии. Ну, то есть, и это всё тоже надо учитывать.
Если не дать правильный контекст искусственному интеллекту, он тоже не даст хороший, грамотный ответ. Вот поэтому в любом случае, как мы с тобой говорили, что искусственный интеллект — это всё-таки не Бог, на которого там можно молиться, это инструмент в руках человека. Вопрос какого человека и тоже насколько можно, а, насколько человек обладает критическим мышлением, чтобы оценить правильность ответа и вообще развёрнутость его и не и и найти момент, где искусственный интеллект явно тебе может врать. Ну вот мой любимый пример, когда я его спросила, можно ли в Свердловской области работать вот с таким акведом по патенту, он мне сказал: "Нет, нельзя". На самом деле можно. Я его поймала за хвост, сказала: "Слушай, на самом деле можно". Он такой говорит: "Типа, ой, ну я там посмотрела в соседнем регионе, какое оно там там что-то такое". В общем, ещё и оправдываться стал. Так что вещей надо искусственному интеллекту иногда раздавать, чтобы он не терял бдительность. Поэтому вот.
Возвращаясь к вопросу технического задания, тоже насколько возможно, а-а, ну вот тут вопросы, насколько возможно прямо написать идеально чистое, чистое техническое задание с ИИшкой. Я считаю, что абсолютно нет. Ну давай так, очень примерно, чтобы представлять, а-а, какую долю, а там технического здания у нас пишет искусственный интеллект, а какую долю пишем мы. Ну вот прямо если чисто тезировать файл. Я бы, да, говорил не конкретно про тексты, символы, вот, а по количеству затраченного времени, которое требуется. То есть процентов, ну, 20, наверное, может там 20-30, грубо говоря, там в зависимости от размера, оно может сэкономить. Вот оставшиеся 60-70, соответственно, это всё равно наша работа, которую, соответственно, мы там делаем, перепроверяем, описываем, меняем и так далее. >> Да. Ну и как показала там у нас тобой анализ по времени, да, распределения, а где-то около 10% у нас ещё это отрабатывает дизайнер, а, по-моему, где-то около там 30-40% моя продуктовая часть ещё тоже в работе над техническим заданием и оставшаяся часть там почти половина и чуть больше — это твоя работа как технического специалиста. То всё равно у нас такое есть с тобой комбо, да? А искусственный интеллект нам помогает по большей части решить проблему чистого листа. Мне эта очень фраза понравилась. Я думаю, что это действительно идеально описывает работу.
То есть, как в конечном счёте у нас получается, как вот там я говорила в начале, это такое три кита для в подготовке продукта к разработке. Должен быть проработан продукт, должен быть проработан там техническое задание для разработчиков и проработан визуал того, как этот продукт будет выглядеть глазами пользователя. И всё вместе оно должно быть единым целым. У них не должно быть конфликтов. Это очень частая проблема в проектах, что дизайн, а, отрисован вот так, техническое задание описано вот так, а они друг с другом не дружат. Вот, конечно, в этом плане потом >> страдают разработчики, которым на конечном этапе надо это всё реализовать. Вот. А на самом деле проблема была ещё на стадии подготовки.
У нас с тобой вообще по практике получается, что мы иногда даже проект готовим к разработке столько же времени, сколько и разрабатываем. Да ведь, >> ну, бывает и такое, да, >> то нет такого, что разработка — это очень долгий процесс. Как иногда бывает даже, что и подготовка к разработке дольше. Зато, если всё хорошо сделано, разработка идёт намного быстрее. >> Да, именно так. >> Вот я что-то я просто сейчас вспоминаю проекты даже за двадцать пятый год у нас и двадцать четвёртый, и двадцать пятый у нас прямо подготовка была долгая, но зато быстрая, быстрая разработка. >> Ну да, >> по-моему, так вот плюс-минус получается. Интересно. >> Примерно так.
Слушай, ну давай тогда в итоге, э, вернёмся к изначальному нашему вопросу. А нужно ли вообще техническое задание клиенту на стадии идеи именно? То есть как она вообще нужно ли его писать? Потому что из нашей с тобой речи понятно, что это большая объёмная работа, даже не одной головы, а как минимум трёх. Вот. И вряд ли клиент может в себе совмещать вот все эти компетенции. То есть, может, вообще тогда его не писать и ничего не делать? >> Ну, ничего не делать совсем нет. Но всё равно, если у вас есть там проекты, вы условно приходите, да, то есть техническим заданием приходить не нужно. Хотя парадокс в том, что оно нужно для того, чтобы оценить, потому что чаще всего клиент приходит всё-таки ээ для того, чтобы понять бюджет, какой нужен, для того, чтобы реализовать тот или иной проект. Вот. И соответственно, ну вот я говорю, парадокс для оценки нужно техническое задание, да? Техническое задание, как мы поняли, написать достаточно сложно. Вот одному вот и всё, ну, скажем так, упирается в то, что, э, в первую очередь это, скажем так, выбор команды, ээ, на этом этапе намного важнее. Вот, ээ, для того, чтобы, скажем так, проект был успешным.
Мы попросим в комментариях наших слушателей написать, вот если у вас был опыт запроса, оценки стоимости, разработки с ТЗ, без ТЗ, без ТЗ, а, напишите вот какой у вас был вообще диапазон, разброс цен по проектам, сколько вам там предлагали. Ну, может быть, у многих опыт был с разработкой сайтов, вот от до сколько был разбег. И уточните, пожалуйста, отправляли ли вы техническое задание разработчикам, а или нет. Есть просто гипотеза, что, ну, и вообще даже не гипотеза, там мой опыт подсказывает, что когда оценка делается без технического задания, разброс цен намного выше, когда есть техническое задание. Ну, давайте так назовём в кавычках техническое задание, потому что это всё-таки правильнее было бы сказать описание функциональных требований, то есть как должно работать приложение, какие функции в нём должны быть, но без технического углубления подробностей и там прямо расписывания всех сценариев. То есть вот этот документ, он в целом помогает сократить вот этот разброс цен и, ну, делает проект чуть более понятным разработчикам для оценки. Ну, то есть вот вот эту задачу, мне кажется, что техническое задание, а, которое делает в черновом виде клиент, оно должно помогать. Вот. Но вообще в целом, да, я с тобой согласна, что очень важно выбрать команду. Я не знаю, у кого есть ещё такая проблема с выбором разработчиков. Мне кажется, это вообще отдельно интересная тема. Если интересно и хочется её разобрать, тоже напишите в комментариях. Может быть, мы действительно с Данилом снимем видео, как мы бы выбирали, а, команду для разработки проекта. Вот у меня, правда, нет очевидного ответа, вот прямо каких-то, но я думаю, что какими-то советами можно было бы поде поделиться хочется >> порассуждать это точно будет интересно. Причём я даже не знаю, какой у тебя был бы ответ на этот вопрос. Давайте, если если мы наберём там лайки и комментарии на эту тему, то мы обязательно разберём это в отдельном видео.
А заканчивая техническим заданием, давай тогда всё-таки скажем вот минимальный базовый какой-то что дол минимально, что должно быть в описании там проекта для того, чтобы разработчику было проще оценить проект. М, ну, прийти буквально можно хотя бы просто с проработанной идеей в плане того, что есть продукт, ну, нет продукта, да, но есть представление об идее, вот, и есть представление о том, какой функционал есть. Ну, потому что разбираться прямо полностью с чистого листа можно, но это намного дольше там на первичном времени. Если уже есть хотя бы какая-то наработана база, там вот есть такая-то идея, а там примерно, ну, условно, в таком-то проявлении, вот есть такой функционал, это там мобильное приложение там или это сайт, вот, ну, с этим уже можно работать.
Давай я тогда чуть развёрнуте скажу. То есть вот как я себе представляю, то есть если бы я пошла к кому-нибудь с оценкой проекта, то есть как минимум надо очень кратко и сжато передать саму идею. Ну чтобы человек понял вообще, что это, для кого это, обязательно для кого, потому что, ну, вот мне, если я не понимаю, кто будет пользователем продукта, у меня могут возникнуть свои фантазии на этот счёт. А про функционал, про который говорит Данил — это про описание, а что можно сделать внутри нашего продукта. И тут тоже можно так подойти с с такой стороны, задать себе вопрос: что пользователь должен увидеть, открывая мой цифровой продукт? Что он может сделать в нём? А что система должна сделать? То есть вот, грубо говоря, вот эти три базовых вопроса: что я вижу, что я могу сделать, а что система сделает для меня, чтобы я вот это увидел. То есть это могут быть какие-то формулы, калькуляторы, соответственно, как эта формула калькулятора работает. Это некая бизнес-логика, бизнес-процесс вот этого продукта. А, ну, конечно, в идеале, если есть возможность подумать, а если идеальный сценарий не работает, что тогда? То есть, если можно, можете расписать этот функционал, это тоже будет здорово. А про роли мы с тобой говорили. Я думаю, что это в целом вполне посильная идея, история. А как какие роли будут в моём приложении? не забывать про кабинет администратора, что должен иметь в доступе администратор, там, чем он должен управлять, а потому что это самая там любимая часть наша на стадии там начала работы проектом. Приходит проект и вот хочу мобильное приложение, а админку не хотите управлять этими данными информации не хотите. А куда это всё будет передаваться? Вот. Да, это это ещё один тоже момент, там хотим получать заявки. Хорошо, эти заявки куда должны приходить? Вот клиент внутри приложения вам заполнил форму заявки, а дальше что происходит? И такие: "А, ну да, мы хотим, чтобы это у нас CRM-система попадала. А, ну так вам нужна ещё интеграция с CRM-системой. А с какой CRM-системой? То есть вот эти вот все моменты, их желательно всё описать. И чем более развёрнуте, подробнее будет информация, тем проще будет разработчикам сделать оценку предварительную. Ну или как минимум, а вам меньше вопросов будут задавать по проекту, когда там вы хотите оценку, а разработчик не понимает, а тут как будет работать, а тут как будет работать. То есть вот эту а проблему можно максимально решить путём описания функционала. Вот. А ещё, наверное, знаешь, я вот сейчас вот подумала, я бы посоветовала следующим образом поступать. То есть, если есть, ну, в первую очередь, проработать вот это вот, э, техническое здание, функциональные требования самостоятельно сходить в одну компанию, аэ, поговорить с ней, не отсылать его сразу в 10, потому что первая компания может дать сразу развёрнутую информацию, задать правильные, нужные вопросы, и эти вопросы есть смысл внести снова в техническое задание. И тогда уже последующие 10 компаний там вы уж рассылаетесь, рассылайте по всем специалистам запросы на оценку, то хотя бы последующие будут задавать вам меньше вопросов, но они всё равно будут. У нас нет такого, чтобы не было вопросов потом. >> Да. Те есть ещё что добавить? >> Да нет, как будто мы уже подводим итоги, скажем так, уже много наговорили, много сказали. Вот это важно, наверное, переварить. >> Вот. И, наверное, >> к завершению, ну, скажем так, в итоге, отвечая на вопрос: а нужно ли вообще это техническая здания, да, нужно, вот, но не на этапе, когда у вас есть только идея. Вот. И может ли искусственный интеллект написать техническое задание? Нет, не может. Вот. Но может очень сильно помочь в этом, но при этом только в умелых руках, ээ, которые могут проанализировать вообще результат этого искусственного интеллекта. Ну, это вот лично мои тезисы.
>> Да, я бы тоже так сказала, но вот я единственное, что опять же сакцентировать, мне кажется, даже в нашем с тобой диалоге можно услышать, что термин техническое задание он очень плавающий, и каждый под ним тоже понимает разные вещи. документ просто с описанием проекта. Вот. И это, конечно, там не совсем правильно называть это техническим заданием, поэтому даже я постоянно оговариваюсь. Вот. И вот описание проекта, оно обязательно нужно. Техническое задание терминологии разработчиков нереально написать на стадии. Вот только черновую версию.
Ну что, тогда мы с тобой завершаем наш созвон. Пишите в комментариях, какие вопросы ещё остались. Может быть, мы где-то не ответили там полно развёрнуто на какую-то тему в рамках технического задания. Мы обязательно в комментарии это можем ответить. Ну и также у нас с Данилом открытые Telegram-чаты наши. У нас легко можно найти и на сайте IT продакшна Prodдаction. на сайте можно найти наши контакты, написать нам напрямую. А и в том числе проводим бесплатные консультации, если кому-то нужна помощь, как раз с описанием этого функционального, а документа. А мы тоже это можем сделать, можем помочь. Ну и в том числе, если у вас есть какая-то идея, которую, правда, надо проработать прямо с макетами, прототипами, а мы умеем это, в том числе, быстро собирать в такой некий кликабельный прототип без какого-то глубокого дизайна. чтобы посмотреть, проверить, протестировать гипотезу до разработки, потому что мы в целом топим в то, чтобы не тратить лишние деньги на разработку. Вот я всех клиентов призываю, а до того, как сливать миллионы в какие-то сложные системы, проверьте, протестите гипотезу какими-то более дешёвыми, быстрыми способами, а чтобы быть уверенными, что это тот продукт, и он работает так, как нужно рынку, и они готовы за это платить. Даже если это внутренние сотрудники, это тоже ваши потенциальные пользователи, что действительно это решает ваши бизнес-задачи. Поэтому приходите, мы это всё поможем разобрать, а определиться с целями, с метриками, бюджетами и помочь начать разрабатывать этот продукт с проработки таб. А всё, мы ждём ваших комментариев, надеемся, что мы вам были полезны, потому что нам как раз это наш наш мотиватор снимать эти видео, которые мы не очень привыкли делать. >> Ну да, >> не очень мы это любим. Вот. Но поговорить с клиентам за проекта, это всегда очень интересно. Поэтому пишите, звоните, а оставляйте комментарии, лайки, мы будем очень рады. Всем пока. Всем >> счастливо.