Антон Тарасенко | IT-ментор для фаундеров
Open in Telegram
Связаться: @antontar Менторство для фаундеров и бизнеса: от идеи до релиза. Помогаю основателям избежать дорогих ошибок в разработке, выстроить процессы и сэкономить нервы. Здесь личный опыт, разборы кейсов и ответы на вопросы.
Show moreThe country is not specifiedThe category is not specified
182
Subscribers
-124 hours
No data7 days
No data30 days
Posts Archive
Пятница - отличный день вспомнить одну из моих любимых историй из ИТ.
В 2011 году команда Netflix придумала очень необычную практику: Chaos Monkey. Это специальный инструмент, который… ломает их систему в продакшене. Причём специально и в рабочее время.
Да-да, он просто случайным образом «вырубает» сервисы, и команда должна быстро восстанавливаться. Логика у них была простая: если всё будет падать только «по-настоящему» и неожиданно, это всегда будет стресс и проблемы. А если падения происходят постоянно и предсказуемо команда учится держать систему устойчивой.
Сначала идея казалась безумной. Но потом именно благодаря такому подходу Netflix сделал свою инфраструктуру настолько надёжной, что сбои стали редкостью.
📌 Для меня в этой истории есть хороший урок: иногда лучше потренироваться на «мини-хаосе» и научиться работать с проблемами, чем ждать, когда настоящий хаос застанет вас врасплох.
И да, пятница - тоже неплохой день, чтобы проверить, насколько система готова к неожиданностям 🙂 Хотя лить на продакшен все-таки не стоит.
🔥 ГЛАВНЫЕ ИНСАЙТЫ эфира с Антоном Тарасенко
Сооснователем YotaPhone, экс-CTO Yota Devices, создателем DNA Team
🚀 О старте и философии YotaPhone:
«Ничего невозможного нет» — ключевой принцип, который Антон вынес из работы над первым российским смартфоном с двумя экранами.
Идея родилась на выездной сессии с участием всех отделов — от бухгалтерии до дизайнеров. Сняли все ограничения: «Что может быть через 20 лет?».
Были и другие концепты — например, телефон без единого разъема (беспроводная зарядка тогда только зарождалась).
💡 Почему YotaPhone не стал «российским Apple»:
Ключевая ошибка заключалась в том, что проект перестали финансировать и развивать. Вместо того чтобы продолжать инвестировать в продукт и российские команды, создавая и укрепляя внутренние компетенции, финансирование было остановлено. В результате не удалось сформировать устойчивую экспертизу и экосистему для дальнейшего роста
Возможность была: создать экосистему устройств (планшеты, роутеры, USB-донглы) и компетенции для импортозамещения не в виде «переклеивания бирок», а реальной разработки.
🤝 Как заходить в крупные компании (ВТБ, Касперский, Aviasales):
Важно быть открытым к общению, не пренебрегать небольшими задачами, не ждать сразу крупных проектов и не стремиться сразу взобраться на Эверест. Сначала стоит пройти путь с малого — попробовать свои силы на небольшой высоте, постепенно наращивая опыт и компетенции
Глубокий бесплатный пресейл: 3-4 созвона, чтобы выявить боли, предложить решения «в стол» и стать своим.
⚠️ Топ-3 ошибки в IT-стартапах (на примере своего провала):
Создавать продукт без проверки гипотез — «нужен ли он кому-то, кроме тебя?».
Делать сложное MVP — вместо минимальной версии, которая закрывает боль.
Не искать ментора — особенно если нет опыта в разработке. Иначе — слив денег и времени.
🛡️ Как не наступать на грабли в tech-бизнесе:
Технологическая часть — главный риск: юридические вопросы, права на код, передача продукта между командами.
Ищите того, кто уже прошел этот путь — иначе рискуете утонуть в «невидимых» проблемах.
Time to market должен быть минимальным — но без потери качества.
💬 Финальный совет от Антона:
Если вы хотите создать tech- или IT-продукт, начните с максимального упрощения идеи. Определите, какое именно ключевое решение вы предлагаете и какую проблему оно закрывает. Отбросьте всё второстепенное и прежде, чем приступать к реализации, пообщайтесь с целевой аудиторией, чтобы убедиться: проблема действительно существует, а предложенное вами решение востребовано. И только после этого начинайте разработку. Оптимально — найти опытного IT-наставника, который поможет избежать лишних затрат и облегчит прохождение этого пути.
🚀 Через 20 минут встречаемся на прямом эфире!
Говорим о том, как делать технологичные продукты мирового уровня в России
📅 Дата: СЕГОДНЯ
⏰ Время: 19:30 (по Москве)
🎙 Ведущий: Роман Дусенко — консультант, психолог, экс-банкир. Разбирает бизнес-стратегии и психологию принятия решений.
💡 Гость: Антон Тарасенко — Экс-CTO Yota Devices, со-изобретатель первого в мире смартфона с двумя экранами, основатель студии DNA Team (ВТБ, Касперский, Aviasales, Эрмитаж).
На эфире разберем по косточкам:
✔️ Создание иконы: Как рождался YotaPhone — самый необычный российский гаджет, покоривший мир.
✔️ Работа с гигантами: Секреты сотрудничества с ВТБ, «Лабораторией Касперского» и Aviasales. Как попасть в их число подрядчиков?
✔️ Запуск своих сервисов: Честно о взлетах и падениях с CoActivity и LookLink.
✔️ Менторство: Как технологическому предпринимателю не наступить на грабли и решать сложные операционные задачи
🔗 Подключайтесь к эфиру по ссылке: https://t.me/DuLinksBot
Всем привет!
Хочу поделиться важной новостью — мы в DNA team запустили новое направление, о котором меня часто спрашивали последние месяцы.
Мы сделали ставку на внедрение ИИ под ключ. Это ИИ-агенты, цифровые ассистенты, RAG-решения, которые реально разгружают команды и приносят экономию.
Сначала мы считаем выгоду, исследуем бизнес, и только потом начинаем разработку. Такой подход уже позволяет существенно снизить риски пустых затрат.
Более подробно и красочно рассказали здесь:
https://dnateam.ru/ai
На сайте можно пройти тест и получить мой крутой авторский PDF-материал «Внедрение ИИ: от идеи к измеримым результатам»
Если вы долго думали с чего бы начать внедрение ИИ в свой бизнес — там для вас есть готовые шаги и пример с кейсом.
Для нас это новый этап, а для вас — возможность за 4 недели увидеть, как ИИ работает именно в вашем бизнесе.
🔥 ПРЯМОЙ ЭФИР: Как запустить технологичный продукт и не сгореть?
📅 Дата: 21 августа
⏰ Время: 19:30 (МСК)
🎙 Ведущий: Роман Дусенко — бизнес-консультант, психолог, экс-банкир. Автор стратегий для предпринимателей.
💡 Гость: Антон Тарасенко — экс-CTO Yota Devices, один из создателей легендарного YotaPhone, основатель DNA Team (проекты для ВТБ, Касперского, Aviasales, Эрмитажа).
🔗 Жми, чтобы получить ссылку на эфир
🎙 ПРЯМОЙ ЭФИР: Психология решений + Технологии = Устойчивый IT-бизнес
📅 21 августа
⏰ 19:30 (МСК)
📌 Ведущий: Роман Дусенко — бизнес-консультант, психолог и коуч. Знает изнутри мир финансов и управленческих решений.
📌 Гость: я, Антон Тарасенко — экс-CTO Yota Devices, один из создателей YotaPhone, основатель студии разработки DNA Team (проекты для ВТБ, Касперского, Aviasales, Эрмитажа).
💬 Почему я очень хочу, чтобы вы посмотрели этот эфир
Роман — не просто раскрывает гостей, а помогает людям глубже понять себя, выстраивать личные стратегии и находить точки роста. С ним разговор уходит за рамки «как сделать продукт» и затрагивает то, что реально влияет на успех — наши решения, мышление, внутренние установки и ресурсы.
📌 О чём поговорим:
• Как психология принятия решений помогает создавать устойчивые технологичные продукты.
• Мой опыт создания YotaPhone — что стояло за первым российским смартфоном с двумя экранами.
• Кейсы DNA Team и работа с крупнейшими брендами.
• Как не выгореть в стартапе и сохранить энергию на длинной дистанции.
• Какие советы я даю как ментор IT-бизнеса.
🚀 Эфир будет полезен, если вы:
• Запускаете или развиваете технологичный продукт.
• Хотите работать с крупными клиентами и понимать, как они выбирают подрядчиков.
• Ищете баланс между ростом бизнеса и своим ресурсом.
Есть у меня одно наблюдение - самые сложные и важные переговоры часто лучше назначать на пятницу.
Почему?
В пятницу люди как будто становятся мягче. Рабочая неделя позади, планы на выходные уже где-то в голове, кофе вкуснее обычного, а категоричность… растворяется.
Чаще слышишь «давайте попробуем» вместо «нет, так не пойдёт». И даже если обсуждаешь сложные условия, спорные моменты или цифры в договоре - всё идёт как-то спокойнее.
Не знаю, есть ли этому научное объяснение, но в пятницу у людей в среднем выше готовность искать компромисс и договариваться. Наверное, просто потому что впереди два дня, когда можно выдохнуть.
Хотя бывали ситуации, когда важные встречи и звонки были в пятницу и после 19:00. Но тут, как говорится, надо смотреть в цель - иногда лучше со всем разобраться до выходных, чем тащить в понедельник тот же вопрос, но уже с потерянным темпом.
Так что если на горизонте важный разговор - возможно, лучше дождаться пятницы. Шанс выйти из переговорки с результатом сильно выше.
Но все равно, старайтесь такие вещи не назначать на пятницу после 18:00 - там уже не переговоры, а планёрка по выбору пиццы. Поэтому может возникнуть обратный эффект - вроде договорились, а в понедельник все окажутся как в фильме Люди в черном (да такого не было!)
Всем хорошего вечера пятницы и выходных!
Я давно тянулся к музыке — играю на гитаре, но петь всегда хотелось отдельно. И при этом был страх: зажимы, неуверенность, ощущение, что «это не моё».
В итоге решился пойти на вокал. И оказалось, что всё не так плохо, как я себе рисовал.
Сначала было вообще непонятно, как можно контролировать голос только дыханием и какими-то микродвижениями. Но постепенно, с каждой репетицией, начинают появляться новые нейронные связи — и вдруг ты уже чувствуешь то, что раньше не ощущал.
Очень многое зависит от преподавателя. Мне повезло: спокойно объяснили, как быть, на что обратить внимание, что важно, и путь стал гораздо легче.
А ещё я заметил параллель с запуском IT-проекта. В начале — ничего не понятно, слишком много деталей, страшно ошибиться. Но если партнёр опытный, он объяснит, как действовать, на чём сосредоточиться, что критично, а что подождёт. И тогда с каждым днём проект двигается вперёд, а пазл постепенно собирается.
Ищите тех, с кем ощущаете с самого начала, что паззл обязательно соберется 😌
Сегодня воскресенье, для большинства день отдыха и расслабления.
А я вот хочу поделиться одной мыслью, которая в последнее время меня часто сопровождает. Когда-то у какого-то иностранного блогера (уже и не вспомню, у кого именно) я увидел интересный подход к возрасту. Он воспринимает каждый свой год как версию. Например, 37 лет — это версия 3.7, 38 лет — 3.8.
Смысл простой — перестать воспринимать возраст как нечто грустное или ограничивающее, а думать о новой версии как о более продвинутой, улучшенной, переработанной. Как с приложениями: в апдейте всегда есть улучшения, исправления багов, иногда — полное переосмысление функций.
Конечно, появляются и новые баги (куда уж без них), но всё же это новый этап — с опытом, с изменениями, с какими-то внутренними апгрейдами.
В этом году у меня вышел релиз 4.0. До этого были версии 3.1, 3.2, 3.3… и вот теперь — переход на новую «ветку». Как мы знаем из мира технологий, если релиз большой и заметный, то почти всегда вскоре выходит версия 4.0.1, 4.0.2 — чтобы поправить то, что сразу не предусмотрели. У меня примерно так же: глобальные изменения есть, но в связи с ними, очень много багов еще в работе.
Наверное, поэтому мне этот подход так близок. В ИТ-продуктах мы тоже редко делаем что-то «и навсегда». Всегда идёт доработка, улучшение, исправление.
Если вам откликается — попробуйте посмотреть на свой возраст так же. Не бойтесь думать о растущем номере версии.
Думайте о том, что с каждым годом вы становитесь интереснее, глубже, опытнее. А баги — их мы всегда поправим в следующем апдейте.
Всем привет!
Последнее время постов было немного.
То проекты сдаём, то новые запускаем. Где-то баги, где-то презентации, где-то срочные звонки вечером в пятницу. Вроде бы ничего необычного - обычная операционка. Но зато ежедневная и довольно плотная.
Плюс у большинства проектов NDA. Причём не просто подписали и забыли, а такие настоящие, когда даже намеками сложно делиться.
Иногда, если подумать, можно рассказать про подход или решение в отрыве от названия клиента, но времени вычленить это всё не так много.
Подумал вот о чём, а интересно ли вам было бы читать про айтишную «бытовуху»?
Что-то из закулисья разработки: как люди сдают проекты, какие возникают мелкие (и не очень) ситуации, как выбираются инструменты, где автоматизируем процессы, а где наоборот — возвращаемся к ручной работе?
Если интересно - напишите. Может, буду делать такие «бытовые» посты
А пока снова иду в Zoom 😩
Сегодня искусственный интеллект стал модным словом.
Каждый второй говорит о «революции», «нейросетях», «будущем».
Но если приглядеться, то очень многие проекты (сразу уточню - далеко не все, но многие!) заканчиваются одинаково:
генерировать симпатичные картинки или собирать примитивных чат-ботов,
которые в лучшем случае повторяют заскриптованное «чем могу помочь?» -
и даже не пытаются быть чем-то большим, а являются банальной пересылкой запроса в ChatGPT.
Мы в DNA Team тоже делаем ИИ проекты.
Но для нас это не про красивые слова.
Не про волшебные технологии ради презентаций.
Мы всегда ищем простое место в бизнесе, где ИИ может быть по-настоящему полезен здесь и сейчас.
Такое место, где результат виден не «когда-нибудь», а уже через месяц - в цифрах, времени, деньгах.
На первой встрече мы обычно не рассказываем про «тренды» и «видения».
Мы показываем, как помогли другим:
где именно нашли слабое звено, использовали там ИИ (точнее набор методов и технологий) -
и через пару недель люди видели, что их работа стала проще, а бизнес - эффективнее.
Никакой магии. Никакой показухи.
Просто настоящая работа технологии там, где она действительно нужна.
Искусственный интеллект - не про мечты.
Он про здравый смысл и результат.
И в этом он гораздо красивее любых картинок.
Если интересно - напишите, покажем как мы всего за месяц и очень небольшой бюджет внедрили ИИ решения клиентам, и они уже стали эффективнее как в плане трудозатрат, так и расходов.
Как проверить, что ваш подрядчик понимает задачу так же, как и вы
Частая история: проект стартует бодро, все улыбаются, «мы всё поняли, приступаем». А через месяц выясняется, что под «сделать чат» клиент имел в виду одно, а команда - совсем другое. И начинается: «так мы же это не обсуждали», «а мы думали, что вы это имели в виду» и так далее.
Чтобы таких ситуаций не было - вот 5 простых вещей, которые помогут на старте:
✅ Попросите подрядчика своими словами сформулировать задачу и результат. Даже если вам кажется, что всё очевидно. Иногда формулировка уже выдаёт недопонимание.
✅ Попросите показать этапы работы и критерии готовности. Если они мутные или общие, значит, дальше тоже будет «на глазок».
✅ Попросите примеры «а как вы это делали в других проектах?». Хороший подрядчик сможет хотя бы в общих чертах показать, как он решал похожие задачи.
✅ Зафиксируйте приоритеты. Часто заказчик называет 10 хотелок, но 2 из них критически важны, а 8 только «если успеем». Лучше сразу это проговорить.
✅ И наконец - договоритесь, как будете вносить изменения. Потому что в любом проекте они будут. И важно заранее обсудить, как считать время и бюджет на доработки.
Всё это совсем не про «бюрократию». Это про то, чтобы потом не тратить силы на споры и переделки.
Лучше 2 часа на старте на уточнения, чем 2 недели на «это не то, что мы хотели».
Когда ИТ-продукт работает не только в будни
Есть такая категория проектов — когда ИТ-продукт не просто «запустился и живет», а поддерживает реальное оффлайн-мероприятие.
И вот тут особенно важна не только сама разработка, но и готовность команды быть вовлечённой и на связи не по графику, а когда это действительно нужно — в выходные, вечерами, в «боевом режиме».
Мы делали один из таких проектов для Недели московской моды (BRIKS Fashion Summit).
Разрабатывали сайт и приложение для сбора заявок на участие.
Казалось бы — функционал понятный: регистрация, анкеты, проверка данных.
Но весь проект был завязан на конкретные даты и живую работу с людьми.
На момент старта мероприятий было очевидно — любые сбои или даже небольшие ошибки могут сорвать процесс.
И да, проблемы, конечно, возникли (а куда уж без них), но мы быстро их находили и оперативно устраняли прямо на месте.
Технический менеджер от нас был на площадке лично, держал связь между клиентом и командой и помогал решать все вопросы «в бою».
📌 Вот почему в таких проектах важно:
• заранее продумывать, кто из команды будет на связи и где
• учитывать, что у мероприятия нет «переноса на завтра»
• помнить, что поддержка — это не только про код, но и про ответственность
• проговорить с клиентом (а клиенту - с подрядчиком), что такая помощь в принципе нужна, это далеко не очевидно, и должно быть учтено в процессах и договоре
Такие истории хорошо показывают: быть настоящим партнёром — значит быть готовым вовремя подхватить, когда что-то идёт не по плану. А еще понимать истинные задачи того, что ты делаешь.
Что такое ИТ-менторство и кому оно нужно?
ИТ-менторство — это формат, когда вы привлекаете опытного технологического эксперта, чтобы:
• понять, что именно нужно разрабатывать
• понять, какими ресурсами создать тот продукт, который вы хотите получить (собственная команда, аутсорс, фриланс)
• оценить реальные бюджеты и сроки
• избежать лишних трат и ошибок
• правильно выстроить работу команды или подрядчика
Но тут есть один важный нюанс:
👉 настоящий эффект будет, если ментор сам предприниматель, у которого есть действующий бизнес, реальный опыт разработки, запуска, провалов и успехов.
А не просто «технарь-теоретик».
Кому это нужно:
🔹 У вас есть идея, но не понимаете, с чего начать и сколько это может стоить
🔹 Проект уже идёт, но нет уверенности — как построить дальше, где риски
🔹 Хотите защититься от внезапных и необоснованных трат
🔹 Готовитесь к запуску и хотите всё продумать: фичи, архитектуру, бюджеты
🔹 Планируете привлекать инвестиции — и нужно грамотно обосновать трату средств
Какая польза:
• Экономия 200 000 – 1 000 000 ₽ на старте (по опыту)
• Чёткая поэтапная стратегия запуска продукта
• Решения не в отрыве от бизнеса — а с учётом реального опыта и продуктовой насмотренности.
Если актуально — напишите. Первая встреча — без каких-либо коммерческих обязательств.
Сегодня рассказывал про наш проект LookLink - сервис для качественного нетворкинга.
Это первые публичные питчи проекта и по окончанию сразу понимаешь, о чем не сказал, а где надо было использовать другой термин.
В любом случае - очень здорово!
Спасибо FranchCamp и Косте Урванцеву за приглашение)
PS. Это был не стендап, а стартап)))
Одна из самых частых ошибок при запуске IT-продукта - пытаться охватить всё и сразу.
Очень знакомая сцена: клиент приходит и говорит “Мы хотим и авторизацию, и каталог, и аналитику, и чат, и реферальную систему, и веб, и мобайл, и чтобы красиво. И чтоб всё на старте”.
Понимаю это желание. Особенно когда проект важный, амбициозный. Кажется, лучше сразу сделать максимум, чтобы не доделывать потом. Но правда в том, что такой подход - это прямой путь к выгоранию команды, просадке бюджета и… очень часто к тому, что продукт просто не выходит.
Запуск “всё и сразу” нерабочая стратегия.
Потому что:
• пока делаете всё, рынок уже уехал
• гипотезы не проверены
• деньги уходят не туда
• фичи могут вообще не пригодиться
• отношения с подрядчиками рушатся
И наоборот: запуск с минимальным, но сфокусированным набором функций позволяет протестировать идею, собрать обратную связь и только потом наращивать функционал.
В моей практике были проекты, которые мы запускали с очень базовым функционалом, и они отлично отработали. А были и те, где клиент полтора года откладывал релиз, потому что “надо ещё кое-что добавить”. В итоге не добавилось и не запустилось.
Есть и очень известный всему миру пример: Dropbox.
В самом начале у них даже не было работающего продукта. Была просто видеозапись, где демонстрировался пользовательский сценарий - как будто бы всё уже работает. Это был MVP не продукта, а идеи. Видео разошлось по сообществам, люди выстраивались в лист ожидания, и только потом началась полноценная разработка. Так компания поняла, что делает не “ещё один облачный сервис”, а то, чего действительно не хватало пользователям.
В наши времена конечно такого уже мало, но есть другие способы сделать меньше, чтобы понять, чтл не надо делать больше :)
Так что если на старте вы выбираете между “сделать всё красиво” и “выпустить самое главное”- я всегда голосую за второе.
Быстрее выведем, раньше поймём, проще улучшить.
У нас тут вакансия. Если это вы или вы знаете таких людей - пишите. Берем официально в штат.
Объявляется рубрика - полезная среда!
Постараюсь в эти дни давать какие-то практически-полезные моменты, которые вы можете просто взять и использовать, проверить себя.
Вы планируете запускать проект с IT-подрядчиком?
Есть несколько простых шагов, которые стоит сделать до старта, чтобы потом не было мучительно дорого, долго и непредсказуемо.
По опыту в студии я видел, как одни проекты взлетают с первых дней - а другие буксуют ещё на старте, потому что к запуску не были готовы.
Что важно сделать до начала работ:
✅ Понять, какую проблему должен решать продукт - и для кого
✅ Сформулировать ключевые сценарии - хотя бы в виде текста
✅ Определиться, кто будет принимать решения и утверждать работу
✅ Прописать, какие есть ограничения - сроки, бюджет, технологии
✅ Понять, кто будет вовлечён со вашей стороны (заказчика)
✅ Продумать, как проверять гипотезы и метрики успеха
✅ И главное - быть готовыми к диалогу, изменениям и уточнениям по ходу работы
Это не про «идеальное ТЗ» - его почти никогда нет. Но когда есть базовая проработка, команда быстрее вникает, принимает более точные решения и экономит ваши же ресурсы.
И ещё - важно заранее обсудить, как будете взаимодействовать: как часто созвоны, где обсуждать задачи, как принимать итоги спринта. Такие мелочи - это как шестерёнки, которые либо крутятся вместе, либо начинают скрипеть уже через неделю. И создается ощущение, что проект начался, и с первых дней что-то пошло не так.
Лучше такого избегать)
Всем привет!
Сейчас появилось чуть больше времени, чем обычно, поэтому - небольшой анонс.
Я открыт к менторству - особенно для тех, кто только на старте в ИТ-проектах.
Если вы давно носите в голове идею IT-продукта, но не знаете, с чего начать? Страшно тратить деньги, непонятно, кому довериться и как не наломать дров? Да и вообще, сколько все может стоить, надо ли идти к фрилансерам, или нанимать студию. Или вообще кодить не надо, соберете все самостоятельно.
А может у вас уже традиционный бизнес, но хочется внедрить ИТ-решения, чтобы сэкономить, улучшить процессы и т.и.
Я здесь, чтобы помочь - как технологический и бизнес ментор. Без лишнего пафоса, но с глубоким опытом.
Коротко обо мне:
• ex-CTO Yota Devices (создавали и запускали на рынок тот самый YotaPhone: телефон с двумя экранами и все сервисы на нем).
• Со-основатель и CEO студии заказной разработки DNA Team: мы уже 10 лет на рынке, проекты для ВТБ, Касперского, Авиасейлз, Эрмитажа и т.п.
• Со-основатель CoActivity - платформа для создания и проведения бизнес-квестов, победитель акселераторов.
• Со-основатель LookLink - AI-сервис для качественного нетворкинга и решения бизнес-запросов.
• Сертифицированный ментор и бизнес-трекер (CCE ICF).
• Много пройдено - и успешного, и ошибочного. Второе, кстати, иногда даже полезнее.
Чем помогу:
• Разложим идею на понятные шаги
• Подскажу, с чего стартовать и как не потратить лишнего
• Обсудим форматы MVP, бюджеты, команду, архитектуру
• И просто посоветуем - честно, без воды
Более подробное описание опыта и имеющейся экспертизы здесь.
Первая встреча - без каких-либо коммерческих обязательств, просто чтобы вы поняли: “да, это мой вектор”.
Пишите в личку (тг в профиле канала) или отвечайте на этот пост, если на старте - или просто хотите услышать мнение.
Иногда одного разговора достаточно, чтобы начать.
