В моей форме заказа есть поле «Задача своими словами». Рядом нет кнопки загрузки обязательного документа, без которого разговор не начнётся. Я Владислав, делаю Telegram-ботов, и на сайте прямо предлагаю описать работу текстом или голосовым. План составлю сам. Но пустое поле всё-таки предстоит заполнить — хотя бы тем, что сейчас приходится делать руками.
Готовое техническое задание на телеграм бота не требуется, чтобы мне написать, — но между первым сообщением и началом разработки есть разговор, в котором мы согласуем кнопки и сценарии, выберем нужное поведение и назовём результат, подлежащий проверке. Бумажная папка для знакомства не нужна. Общее понимание результата — нужно.
Иначе договорённости нет.
В разделе о порядке работы у меня записано, что сначала вы описываете задачу, потом я задаю вопросы и называю цену и срок. Следом расписываю кнопки и сценарии, показываю готовое в Telegram, после проверки запускаю на сервере. Этот порядок можно прочитать и с другого конца. Если в Telegram нельзя проверить, сделали ли нужную вещь, значит, раньше мы недостаточно точно назвали саму вещь.
Начать описание я предлагаю с пути обращения. Откуда человек приходит, что ему требуется, какой ответ он должен получить. Это совет для подготовки, а не рассказ о состоявшемся заказе. Допустим, нужна заявка на услугу. Тогда полезнее назвать сведения, которые надо передать владельцу, чем требовать современный интерфейс: по слову «современный» нельзя понять, дошло ли обращение и хватает ли в нём данных для звонка.
На сайте есть демонстрационный сценарий мастерской. В нём выбирают работу, время звонка и вводят имя. После этого показана карточка владельца. Ирина из этой карточки — персонаж демо, не клиент, чью историю я выдаю за доказательство. Зато на таком образце видно, о чём говорить до разработки. Не о красоте кнопки вообще, а о том, какое сообщение получит человек по другую сторону.
У заявки есть получатель — про него в описании тоже стоит написать. Если результат нужен вам в Telegram, это один сценарий; если его требуется выгружать в таблицу, появляется ещё одно требование. На моём сайте эти возможности названы отдельно. Не надо заранее знать название библиотеки, чтобы объяснить, где вы собираетесь смотреть обращения. Достаточно назвать место (и не оставлять его подразумеваемым).
Потом можно вернуться к началу пути и представить, что посетитель выбрал не тот пункт. Здесь я предлагаю обсуждать конкретное действие: вернуться в меню, изменить ответ, начать заново. Это возможные варианты поведения, а не обещание, что каждый из них уже включён в любую разработку. Их нужно выбрать и согласовать. Пока этого не сделано, одинаковое слово «заявка» у нас может означать разные вещи.
Так появляются кнопки. Они следуют за действием человека, а не заменяют описание задачи. Красивый ряд названий ещё не сообщает, куда отправится результат, разрешено ли поменять выбор и что произойдёт после последнего нажатия. Если вместо большой инструкции получается небольшой понятный маршрут, я бы сохранил именно маршрут. Его можно пройти на демо и сравнить с тем, о чём договорились.
С записью на услугу разговор будет другим. В демонстрации на сайте есть выбор услуги, дня и свободного времени, затем напоминание. Это уже не просто просьба перезвонить. Поэтому к исходному описанию стоит добавить, что человек получает после выбора времени и как должен понимать, что запись состоялась. Не нужно копировать весь сценарий из чужого образца только потому, что там понравился календарь.
Я не знаю по первому слову «запись», какой порядок нужен именно вам. На сайте для такого случая есть возможность описать задачу, ещё не выбрав вид бота, — рассказ о том, чем вы занимаетесь, полезнее уверенного названия функции, если за названием пока нет понятного действия.
Голосовое здесь — такой же способ начать разговор, как текст. Я принимаю его, но сама запись ничего не согласовывает. Если в ней прозвучали разные варианты, то перед началом работы предстоит выбрать один, закрепить нужные кнопки и сценарии, отбросить отвергнутое — иначе разработчику останется угадывать, на каком именно повороте рассказа вы окончательно определились. Голос может передать растерянность. Поведение кнопки всё равно придётся назвать словами.
Следующий поворот — стоимость. По условиям на сайте я сообщаю её до начала и не меняю без вашего согласия. Правки по согласованному заданию входят в цену. Для меня это причина описывать результат достаточно точно, а для заказчика — возможность сравнить работу с договорённостью, не споря о том, что якобы подразумевалось. Дополнительную функцию можно заказать позднее; её стоимость я тоже называю заранее.
На проверке эту договорённость удобно читать как маршрут. Выбрать пункт, ответить на вопрос, получить результат, посмотреть его со стороны владельца. Если обсуждали исправление ошибочного выбора — пройти и эту ветку. Я описываю здесь способ проверки, а не результаты испытаний чужого проекта. Смысл демо в моём порядке работы именно в том, что вы проверяете бота в Telegram до оплаты, а не принимаете его по картинке.
После запуска код и инструкция остаются у заказчика, бот работает под его токеном на сервере. Согласованный сценарий пригодится и тогда, когда нужно будет что-то добавить с другим программистом. Он объясняет назначение работы без пересказа всей переписки. Старое голосовое при этом можно не превращать в торжественный документ с титульным листом.
В форме первого обращения ещё не обязательно перечислять все ветки. Можно начать с сегодняшней ручной работы, назвать получателя результата и объяснить, что в нынешнем порядке мешает. Для этого там оставлено то самое поле — «Задача своими словами».