Антон Тарасенко | IT-ментор для фаундеров

💫Как я сменил роль в IT IT-индустрия устроена парадоксально. Клиенты приходят за продуктом, но часто не готовы к его созданию. Я годами сталкивался с ситуацией, когда честные оценки и глубокое погружение в проект работали против нас. Пока не понял, что почти всем клиентам нужен не исполнитель, проводник. ➡️Мой переход в менторство стал естественным шагом. Сегодня я помогаю основателям: — Создавать реалистичные планы разработки — Формировать адекватные бюджеты — Избегать скрытых расходов и рисков ➡️И уже через месяц работы со мной заказчики отмечают: — Экономию до 70% бюджета на последующих этапах — Сокращение времени на принятие решений — Четкое понимание product roadmap Если вы чувствуете, что ваш IT-проект требует не просто разработки, а стратегического подхода, то приглашаю вас на бесплатную консультацию. Вместе мы создадим четкий план действий, который сэкономит вам время, деньги и нервы. 🔗Напишите мне в Telegram @antontar — обсудим, как вывести ваш проект на новый уровень.

🙂Клиент никогда не признает своей ошибки. Знаете, в работе с клиентами есть горькая правда. Можно сто раз предупреждать о рисках, но если клиент ошибся, виноваты будете вы. У нас был проект, где мы были подрядчиками. Клиент гнался за скоростью реализации и проигнорировал наши предупреждения о всех сопутствующих рисках. То есть в угоду скорости побежал вперед, не стал нас слушать и в итоге оступился. И как обычно бывает, человек понимает, что ошибся, но не готов это признать и начинает искать виноватых. Виноватыми в этой ситуации оказались мы. ⬇️ Мы были правы в этой ситуации и апеллировали всеми фактами, но негатива не удалось избежать. И чтобы спасти проект, нам пришлось сделать огромную скидку и работать себе в убыток. Иначе клиент просто не заплатил бы вообще. Проект мы в итоге запустили, однако осадочек остался. Клиент сохранил ощущение, что это мы его подвели. Хотя вины с нашей стороны не было совсем. А с какими ситуациями несправедливых обвинений сталкивались вы?

Сегодня выступал как спикер на дискуссии конференции TechWeek — обсуждали, что волнует малый и средний бизнес прямо сейчас: как привлекать и удерживать квалифицированных специалистов, какие тренды определяют рынок в ближайшие годы и что реально значит переход на отечественные решения. Вывод простой: да, сейчас непросто — меняется всё, от инструментов до способа работы с командами. Но точно будет хорошо. Ключевой навык — разумно распоряжаться временем, деньгами и вниманием. Когда фокус выстроен, решения находятся быстрее, а любые переходы становятся управляемыми.

Как попытка сэкономить 2 недели стоила нам 3 месяцев работы⬇️ Иногда самые незначительные на первый взгляд решения могут привести к катастрофическим последствиям. Мы с командой согласились упростить процесс согласования логики с заказчиком. Вместо тщательной проработки архитектуры и формализации требований пошли по пути «сделаем сейчас, потом разберемся». Это как собирать самолет, пока он летит. 🎥И пойдя таким путем мы: — Через несколько месяцев обнаружили фундаментальные проблемы с хранением данных — Форматы данных в разных модулях системы оказались несовместимы — Пришлось переписывать значительную часть бэкенда и систему интеграций — Общие потери: 3 месяца работы и несколько миллионов рублей Потеря денег стала болезненной, но настоящей катастрофой оказался разлад в между командой и заказчиком. Возникла классическая ситуация взаимных обвинений: заказчик считал, что команда не доделала, а команда была уверена, что заказчик не донес требования. 🎥Зная это сейчас, тогда бы на старте я: — Провел полноценный воркшоп по проектированию архитектуры — Зафиксировал все соглашения о форматах данных — Не пропускал этап технического проектирования под предлогом «срочности» Этот случай научил нас простой истине: в разработке нет мелочей. То, что вроде бы кажется незначительной оптимизацией процессов сегодня, завтра может превратиться в многомесячный кошмар. А вам приходилось сталкиваться с ситуациями, когда попытка сэкономить время оборачивалась еще большими затратами?

❗️Эти маркеры сэкономят ваш бюджет В прошлом посте я рассказал про три «мемные» ошибки. Сегодня о том, как их заметить на ранних этапах. 🔵 Маркер №1: «Сделаем MVP, потом разберемся» Если у вас нет подтвержденной боли хотя бы от 10-15 реальных пользователей — вы в зоне риска. Не ваших друзей или семьи, а людей из целевой аудитории, которых вы не знаете. Вопрос, который нужно задать себе: Кто эти люди и точно ли я знаю, что у них есть эта проблема? 🔵 Маркер №2: «Возьмем подешевле» Если подрядчик не задает уточняющих вопросов, не предлагает альтернатив и не отстаивает свою техническую позицию — это тревожный сигнал. Качественная команда всегда глубоко погружается в задачу. Всегда уточняйте у подрядчика, какие риски он видит в этом проекте и как предлагает их минимизировать? 🔵 Маркер №3: «Сделаем сразу всё» Если оценка проекта превышает 3-4 месяца — это повод остановиться и пересмотреть приоритеты. Исключения бывают, но для большинства стартапов это красный флаг. За 15 лет в IT я убедился, что лучший способ сэкономить время и деньги, это вовремя задавать правильные вопросы. В следующем посте расскажу, во что нам обошелся самый дорогой «мем» в практике и как его можно было избежать.

ТОП ОШИБОК В IT, КОТОРЫЕ СТАЛИ МЕМАМИ В IT всё циклично. Проекты рождаются, набирают обороты, ломаются — и каждый раз кажется, что «ну у нас-то будет иначе». А потом история повторяется. Я собрал три ошибки, которые вижу чаще всего. Они настолько типичны, что уже превратились в мемы в профессиональных чатах. ➡️Ошибка 1: «Сделаем MVP, потом разберемся, зачем он нужен» Классика жанра, правда в итоге оказывается, что продукт никому не нужен.  Помните мем про «брюки для птиц»? У всех птиц нет брюк, это значит, если они появятся, будет удобно! Логично? Только вот птицы в брюках не нуждаются. Пока вы не поговорили с реальными пользователями и не поняли их боль, всё, что вы создаёте, остаётся просто ещё одной парой «брюк для птиц». ➡️Ошибка 2: «Возьмем подешевле — протестируем гипотезу» Вроде звучит логично, зачем платить много, если можно проверить идею с минимальным бюджетом?  Увы, но на практике выходит иначе. Вы получаете код, который невозможно улучшать, дизайн, который ломается на разных устройствах, систему, которую нельзя масштабировать. В итоге тратите два-три бюджета на переделку, теряете время и упускаете рынок, а в результате получаете продукт, который стыдно показывать. Не редко к нам приходят с запросом «исправить после фрилансера». Как говорится, дешевая рыбка — дорогая уха. ➡️Ошибка 3: «Сделаем сразу всё» Фундаментальный бич стартапов и IT-команд. Желание заложить весь возможный функционал на старте приводит к тому, что у фаундеров и продуктов «переполняется буфер», а команда тонет в бесконечных фичах. Продукт выходит не тогда, когда он нужен рынку, а когда все уже выгорели. Получается, что вы теряете время, деньги и энергию команды, не проверив самое главное. 🔵Как это было у нас Мы сами частично прошли через это с нашим стартапом CoActivity. Оказалось, что не все «гениальные» фичи были нужны пользователям. Пришлось возвращаться и пересобирать продукт, оставляя только то, что решало реальные боли. В следующем посте расскажу, как распознать эти ошибки до того, как они стоят вам денег.

Выступление уже сегодня! Кто не успел зарегистрироваться - еще можно успеть! Приходите, надеюсь будет интересно! ☺️

10 ноября я выступаю в Московской бизнес академии! На открытой встрече Open Talk «От найма к предпринимательству: как строить команду и запускать цифровые продукты» поделюсь личным опытом перехода из корпорации в собственный бизнес, расскажу, как собирать сильные команды и запускать проекты, которые реально работают. Поговорим о том, — как превратить идею в востребованный цифровой продукт, — какие ошибки совершают стартаперы, — и почему без системного подхода не вырастить бизнес. Формат открытый, будет возможность задать любые вопросы и разобрать реальные кейсы. 10 ноября, 19:30–21:00 Регистрация по ссылке

💡Почему заказчики и разработчики говорят на разных языках? Давайте представим ситуацию, вы просите мастера сделать розетку для телевизора. В вашей голове — это аккуратное отверстие прямо за экраном, чтобы проводов не было видно. А мастер устанавливает её у плинтуса, ведь «так надёжнее и по стандартам». Оба по-своему правы, но вместо эстетичной картины получаются висящие провода и испорченный вид комнаты. Примерно так же выглядит коммуникация между разработчиками и фаундерами. Я прошёл путь от технического директора до основателя бизнеса и видел эту проблему с обеих сторон. 🎥Когда я работал разработчиком, некоторые запросы заказчиков ставили в тупик. «Почему нельзя сделать за три дня? Там же просто три кнопки!» — слышали мы. А за этими «тремя кнопками» скрывались недели работы: проектирование архитектуры, безопасность, интеграции с другими системами, тестирование. Мы мыслили категориями идеального технического решения, тогда как бизнесу часто было нужно простое рабочее решение «здесь и сейчас». Со стороны бизнеса я осознал, что фаундер часто не может объяснить, ЗАЧЕМ ему та самая «розетка». Он видит конечную цель — красивый интерьер без проводов, но часто не знает, как донести эту картинку до разработчика. И моя роль сейчас, быть переводчиком между этими двумя мирами. Я помогаю: ➡️Фаундерам сформулировать не просто «что», а «зачем» и «для кого» ➡️Разработчикам понять бизнес-контекст и предложить варианты реализации ➡️Найти баланс между идеальным техническим решением и бизнес-реалиями Без такого взаимопонимания проекты превращаются в поле битвы. Команда выгорает, сроки срываются, бюджет растёт, а в итоге получается не то, что нужно бизнесу.⬇️ Если вы сталкиваетесь с подобными ситуациями в своих проектах, то давайте обсудим на бесплатной консультации. Помогу навести мосты между технической и бизнес-частями вашей команды. 🔗Напишите мне: @AntonTar и мы вместе найдем решение!

🙂Как мы чуть не утонули в бесконечных правках Бывают проекты, где главной проблемой становятся не технологии, а человеческая неспособность сказать «стоп». Таким для нас стал проект по созданию маркетплейса для благотворительных проектов. Клиент постоянно добавлял новые функции, то дополнительную систему рейтингов, то сложные инструменты аналитики, то интеграции с непонятными сервисами. Каждая новая идея казалась ему гениальной, а мы всё дальше уходили от первоначальной цели. ❗️Сигналом катастрофы стало полное отсутствие прогресса. Мы работали несколько месяцев, но продукт был всё так же далёк от запуска. Команда работала без мотивации, потому что все понимали, что проект превратился в бесконечную стройку без шансов на завершение. Самым критичным моментом стало, когда клиент, сам же инициировавший все изменения, предъявил претензию: «Вы не сделали то, за что я платил!» и потребовал вернуть деньги. Нас спасло только то, что мы вовремя остановились и отказались продолжать работу в таком формате. Мы чётко зафиксировали все запросы и изменения, предложили поэтапный план с приоритизацией функций. ➡️Благодаря этому опыту, мы теперь мы с первого дня определяем MVP — тот минимальный набор функций, без которого продукт не имеет смысла. И жёстко придерживаемся правила: сначала запускаем и проверяем гипотезу, потом добавляем новые функции. 🎓И как говорил один мудрый продуктолог: «Печень важнее, чем рука или нога. Сначала убедитесь, что продукт вообще жизнеспособен».

Вчера был интересный и насыщенный день: я выступал как основной спикер на комиссии Фонда содействия инновациям и защищал наш проект, чтобы получить грант. Это была не совсем классическая НИР, а заявка на НИОКР по одному из наших стартапов, так что мы знали технологию и бизнес-план вдоль и поперёк. Но даже с таким фундаментом всё равно пришлось столкнуться с каверзными вопросами и строгой экспертизой, где нужно было оперативно сориентироваться. В общем, несмотря на сложность и напряжённость, я считаю, что мы сделали максимум. Интересно, что эксперты подсветили некоторые моменты, на которые стоит обратить внимание, и мы обязательно их учтём, когда (а я уверен, что когда, а не если) проект будет одобрен. Отдельное спасибо всей нашей команде — вы крутые, и без вашей подготовки и поддержки было бы ещё сложнее. Дальше — больше, и как-нибудь в следующих постах расскажу подробнее, что это за проект, когда сможем уже говорить о нём открыто. Если кому-то будет полезен мой опыт подготовки к подаче и защите проекта перед Фондом — пишите, с удовольствием поделюсь.

🙂Как один проект научил нас проверять не процессы, а людей Знаете, в IT есть миф, если прописать процессы, то всё будет идеально. Но жизнь сложнее. Один из самых болезненных проектов в DNA Team был как раз таким "формально безупречным". Мы разрабатывали платформу для подбора интерьерных решений. Представьте ситуацию, вы приходите к дизайнеру и говорите — хочу сделать обычную кухню. В процессе обсуждения появляются идеи: встроенная техника, подсветка, дополнительные шкафы, умные системы хранения. Вместо простого проекта получается сложный дизайнерский комплекс. ➡️Примерно так же развивался наш проект. Изначально клиент хотел базовый функционал, но в процессе работы постоянно появлялись новые идеи и усложнения. Мы аккуратно всё фиксировали, предупреждали о влиянии на бюджет, предлагали более простые варианты. Казалось, всё под контролем. Проблема оказалась в том, что менеджер со стороны клиента, с которым мы общались, не обсуждал изменения с инвестором. Когда мы показали итоговую смету, выяснилось, что бюджет вырос на 50%, а ключевой человек, принимающий решения, вообще не был в курсе таких изменений. Самый сложный момент наступил, когда инвестор отказался платить даже за уже выполненную работу и предложил расторгнуть договор на невыгодных для нас условиях. Нас спасло только то, что мы с самого дня вели детальную документацию всех обсуждений и постоянно напоминали о влиянии изменений на бюджет. Это позволило хотя бы частично компенсировать потери. 💫Главный вывод, который мы сделали, что любые процессы бессмысленны, если нет прямого контакта со всеми, кто принимает решения. Теперь перед началом каждого проекта мы обязательно спрашиваем у заказчика: кто последний в цепочке решений? Кто имеет право сказать "стоп"? Как вы договариваетесь между отделами? В IT всегда процессы — это скелет, а доверие и прямые коммуникации — душа. А вам доводилось быть "заложником" чужих коммуникационных проблем?

Привет! Меня зовут Антон Тарасенко Кто я вообще такой и чем занимаюсь? Давайте по порядку⬇️ Я помогаю бизнесу и стартапам создавать IT-продукты, которые действительно работают. Более чем за 15 лет в IT-сфере я был ex-CTO Yota Devices — мы создали первый российский смартфон с двумя экранами YotaPhone, который отмечали на выставках в Испании и Лас-Вегасе. После стал со-основателем студии DNA Team, где мы делаем проекты для ВТБ, Касперского, Авиасейлз и других компаний, а также запустил несколько собственных стартапов и получил сертификацию ментора. Говорю об этом не для галочки, а чтобы вы понимали, что я знаю IT-разработку и изнутри, и снаружи. И сейчас помогаю другим избежать ошибок, через которые прошел сам. Если вы только начинаете свой IT-путь — или хотите добавить технологии в уже работающий бизнес, то я открыт к менторству и консультациям. Помогу: ➡️Перевести идею в конкретные шаги и цифры ➡️ Сэкономить на старте, избежав типичных ошибок ➡️ Разобраться с MVP, командой и архитектурой ➡️Подсказать честно, что работает, а что — нет. Работаю без расплывчатых обещаний. Сначала разберусь в вашей ситуации, а потом скажу прямо: стоит ли игра свеч и как действовать дальше. 💫Первая встреча — без обязательств, просто чтобы понять, совпадает ли наш вектор. Пишите в личку (контакты в профиле) или оставляйте комментарий, ведь иногда одного разговора достаточно, чтобы начать. 📎Полезное по теме: — Что такое MVP в мире IT — Почему копировать Wildberries дороже, чем кажется — Интервью для ВТБ: Как научиться делегировать — Исследование HH × DNA Team: спрос на дизайнеров в России — Kaspersky × DNA Team на фестивале креативных индустрий

Всем привет! Часто замечаю, что в начале любого IT-проекта появляются почти всегда одни и те же вопросы: с чего стартовать, сколько это реально стоит и кому доверять — подрядчику или своей команде. За годы я видел десятки разных исходов и понимаю, где чаще всего теряются месяцы и бюджет. И как раз у меня новый вышел подкаст👇 Коротко о чём там: — как мы запускали YotaPhone и что в итоге пошло не так; — почему продукт с сотнями людей и десятками сервисов может не удержаться; — как подходить к MVP за три месяца без лишних ожиданий; — когда уместнее подрядчик, а когда — своя команда; — реальный кейс из мобильной разработки (косметологическая клиника). 👉🏻Посмотреть можно тут И хотел бы узнать,какие темы особенно интересны вам? Хочу, чтобы канал был полезным в первую очередь вам.

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

Как усилить команду, не потратив месяцы на найм В DNA team мы запустили ещё одно важное направление — аутстаффинг IT-команд. Это решение для бизнеса, которому нужно ускоряться здесь и сейчас — без долгого найма и без компромиссов по качеству. Когда у компании запара — релиз завтра, а разработчиков не хватает — мы подключаем свою команду. Так работает наш аутстаффинг: быстро, гибко и с полным включением в ваш процесс. В чём сила формата: – Реальный опыт. Мы отбираем тех, кто уже работал с похожими стеками и задачами. – Гибкость. Можно взять одного разработчика, можно — команду с лидами и QA. – Скорость. Подключение за 1-3 дней. – Прозрачность. Понятные ставки, отчётность и результат. Примеры? — Московская биржа. Подключили разработчиков и аналитиков в продуктовые команды B2B. Клиент получил непрерывную доработку сервисов и сэкономил на найме. — VK. Наши UX-специалисты помогли доработать интерфейсы VK Клипов. Всё внедрялось быстро и без перегрузки основной команды. Мы не просто даём людей. Мы берём ответственность за результат: отбор, адаптацию, контроль качества и сроки. 👉 Подробнее — на сайте

Небольшой эксперимент с форматом постов в канале! «Как вам такое?» 😌

Записали подкаст «Как выйти из тёмного леса при разработке ИТ-продуктов» Обсудили: - Почему ИТ-разработка до сих пор похожа на алхимию - Как MVP становится фонариком в «тёмном лесу» - Где выбрать развилку — подрядчик или in-house команда - Кейсы успехов и фейлов — и чему они учат - Как ИИ меняет подход к созданию продуктов Разговор получился очень живым, драйвовым и с реальными историями. Большая благодарность ведущему — Роману Калашникову. Он не просто интервьюер, а настоящий коуч основателей и визионер: помогает раскрыть глубину и найти неожиданные смыслы. 🎧 Эпизод скоро выйдет, и я обязательно поделюсь ссылкой.