С чего начать, чтобы разбираться в Telegram MiniApp и чётко ставить задачи разработчикам?
Всем привет
Хочу посоветоваться по теме MiniApp (Minihub) в Telegram.
Недавно я заказывал разработку Telegram-бота. В техническом задании я подробно описал основной функционал, но не указал некоторые важные вещи — например, необходимость документации и админ-панели. Эти моменты мы проговаривали устно, и разработчик понимал, что они нужны, но формально в ТЗ их не было, поэтому в итоге он их не сделал.
Сейчас, анализируя ситуацию, я понял, что для моего проекта MiniApp (Minihub) подходит гораздо лучше, чем обычный бот. Хочу в дальнейшем избегать подобных недопониманий и научиться формировать чёткие ТЗ и требования, чтобы при работе с разработчиками ничего не упускать.
Отсюда вопросы:
1. Сколько сейчас по рынку стоит создание качественного, продвинутого MiniApp (не базового, а с интерфейсом, авторизацией, интеграциями и т.д.)?
2. Можно ли за пару месяцев разобраться в базовых принципах MiniApp-разработки, чтобы понимать архитектуру, этапы и грамотно ставить задачи?
3. Может быть, кто-то подскажет хорошие курсы или ресурсы, с которых стоит начать человеку без опыта программирования, но с желанием вникнуть в тему?
Хочется стать более компетентным заказчиком и не повторять ошибок, когда важные детали теряются просто потому, что я их не знал.
1. Сколько сейчас по рынку стоит создание качественного, продвинутого MiniApp (не базового, а с интерфейсом, авторизацией, интеграциями и т.д.)?
MiniApp - это по сути сайт. Стоимость от бесплатно до миллионов. Всё зависит от ТЗ и бюджета.
2. Можно ли за пару месяцев разобраться в базовых принципах MiniApp-разработки, чтобы понимать архитектуру, этапы и грамотно ставить задачи?
Заказчику не нужно разбираться в принципах разработки. Ему нужно грамотно составить ТЗ. Своими словами, но так чтобы его понял исполнитель (если употребляются термины - они должны быть объяснены).
И помнить - всё, что не указано в ТЗ будет не сделано или сделано на усмотрение разработчика.
И конечно определится с бюджетом
Эти моменты мы проговаривали устно, и разработчик .. в итоге он их не сделал.
Вот поэтому я против устной болтовни. Всё важное только письменно. И желательно по электропочте.
Устно можно обговорить мелкие детали, дать/получить объяснения непонятного. Но по итогу всё должно быть зафиксировано письменно. Даже если это не будет в ТЗ - будет в переписке и не потеряется.
