🙂Как один проект научил нас проверять не процессы, а людей

Знаете, в IT есть миф, если прописать процессы, то всё будет идеально. Но жизнь сложнее.

Один из самых болезненных проектов в DNA Team был как раз таким "формально безупречным". Мы разрабатывали платформу для подбора интерьерных решений. Представьте ситуацию, вы приходите к дизайнеру и говорите — хочу сделать обычную кухню. В процессе обсуждения появляются идеи: встроенная техника, подсветка, дополнительные шкафы, умные системы хранения. Вместо простого проекта получается сложный дизайнерский комплекс.

➡️Примерно так же развивался наш проект. Изначально клиент хотел базовый функционал, но в процессе работы постоянно появлялись новые идеи и усложнения. Мы аккуратно всё фиксировали, предупреждали о влиянии на бюджет, предлагали более простые варианты. Казалось, всё под контролем.

Проблема оказалась в том, что менеджер со стороны клиента, с которым мы общались, не обсуждал изменения с инвестором. Когда мы показали итоговую смету, выяснилось, что бюджет вырос на 50%, а ключевой человек, принимающий решения, вообще не был в курсе таких изменений.

Самый сложный момент наступил, когда инвестор отказался платить даже за уже выполненную работу и предложил расторгнуть договор на невыгодных для нас условиях.

Нас спасло только то, что мы с самого дня вели детальную документацию всех обсуждений и постоянно напоминали о влиянии изменений на бюджет. Это позволило хотя бы частично компенсировать потери.

💫Главный вывод, который мы сделали, что любые процессы бессмысленны, если нет прямого контакта со всеми, кто принимает решения. Теперь перед началом каждого проекта мы обязательно спрашиваем у заказчика: кто последний в цепочке решений? Кто имеет право сказать "стоп"? Как вы договариваетесь между отделами?

В IT всегда процессы — это скелет, а доверие и прямые коммуникации — душа.

А вам доводилось быть "заложником" чужих коммуникационных проблем?

🙂Как мы чуть не утонули в бесконечных правках

Бывают проекты, где главной проблемой становятся не технологии, а человеческая неспособность сказать «стоп». Таким для нас стал проект по созданию маркетплейса для благотворительных проектов.

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

❗️Сигналом катастрофы стало полное отсутствие прогресса. Мы работали несколько месяцев, но продукт был всё так же далёк от запуска. Команда работала без мотивации, потому что все понимали, что проект превратился в бесконечную стройку без шансов на завершение.

Самым критичным моментом стало, когда клиент, сам же инициировавший все изменения, предъявил претензию: «Вы не сделали то, за что я платил!» и потребовал вернуть деньги.

Нас спасло только то, что мы вовремя остановились и отказались продолжать работу в таком формате. Мы чётко зафиксировали все запросы и изменения, предложили поэтапный план с приоритизацией функций.

➡️Благодаря этому опыту, мы теперь мы с первого дня определяем MVP — тот минимальный набор функций, без которого продукт не имеет смысла. И жёстко придерживаемся правила: сначала запускаем и проверяем гипотезу, потом добавляем новые функции.

🎓И как говорил один мудрый продуктолог: «Печень важнее, чем рука или нога. Сначала убедитесь, что продукт вообще жизнеспособен».

💡Почему заказчики и разработчики говорят на разных языках?

Давайте представим ситуацию, вы просите мастера сделать розетку для телевизора. В вашей голове — это аккуратное отверстие прямо за экраном, чтобы проводов не было видно.

А мастер устанавливает её у плинтуса, ведь «так надёжнее и по стандартам». Оба по-своему правы, но вместо эстетичной картины получаются висящие провода и испорченный вид комнаты.

Примерно так же выглядит коммуникация между разработчиками и фаундерами. Я прошёл путь от технического директора до основателя бизнеса и видел эту проблему с обеих сторон.

🎥Когда я работал разработчиком, некоторые запросы заказчиков ставили в тупик. «Почему нельзя сделать за три дня? Там же просто три кнопки!» — слышали мы. А за этими «тремя кнопками» скрывались недели работы: проектирование архитектуры, безопасность, интеграции с другими системами, тестирование. Мы мыслили категориями идеального технического решения, тогда как бизнесу часто было нужно простое рабочее решение «здесь и сейчас».

Со стороны бизнеса я осознал, что фаундер часто не может объяснить, ЗАЧЕМ ему та самая «розетка». Он видит конечную цель — красивый интерьер без проводов, но часто не знает, как донести эту картинку до разработчика.

И моя роль сейчас, быть переводчиком между этими двумя мирами.

Я помогаю:

➡️Фаундерам сформулировать не просто «что», а «зачем» и «для кого»
➡️Разработчикам понять бизнес-контекст и предложить варианты реализации
➡️Найти баланс между идеальным техническим решением и бизнес-реалиями

Без такого взаимопонимания проекты превращаются в поле битвы. Команда выгорает, сроки срываются, бюджет растёт, а в итоге получается не то, что нужно бизнесу.⬇️

Если вы сталкиваетесь с подобными ситуациями в своих проектах, то давайте обсудим на бесплатной консультации. Помогу навести мосты между технической и бизнес-частями вашей команды.

🔗Напишите мне: @AntonTar и мы вместе найдем решение!

ТОП ОШИБОК В IT, КОТОРЫЕ СТАЛИ МЕМАМИ

В IT всё циклично. Проекты рождаются, набирают обороты, ломаются — и каждый раз кажется, что «ну у нас-то будет иначе». А потом история повторяется.
Я собрал три ошибки, которые вижу чаще всего. Они настолько типичны, что уже превратились в мемы в профессиональных чатах.

➡️Ошибка 1: «Сделаем MVP, потом разберемся, зачем он нужен»

Классика жанра, правда в итоге оказывается, что продукт никому не нужен. 
Помните мем про «брюки для птиц»? У всех птиц нет брюк, это значит, если они появятся, будет удобно! Логично? Только вот птицы в брюках не нуждаются. Пока вы не поговорили с реальными пользователями и не поняли их боль, всё, что вы создаёте, остаётся просто ещё одной парой «брюк для птиц».

➡️Ошибка 2: «Возьмем подешевле — протестируем гипотезу»

Вроде звучит логично, зачем платить много, если можно проверить идею с минимальным бюджетом? 
Увы, но на практике выходит иначе. Вы получаете код, который невозможно улучшать, дизайн, который ломается на разных устройствах, систему, которую нельзя масштабировать. В итоге тратите два-три бюджета на переделку, теряете время и упускаете рынок, а в результате получаете продукт, который стыдно показывать. Не редко к нам приходят с запросом «исправить после фрилансера». Как говорится, дешевая рыбка — дорогая уха.

➡️Ошибка 3: «Сделаем сразу всё»

Фундаментальный бич стартапов и IT-команд. Желание заложить весь возможный функционал на старте приводит к тому, что у фаундеров и продуктов «переполняется буфер», а команда тонет в бесконечных фичах. Продукт выходит не тогда, когда он нужен рынку, а когда все уже выгорели. Получается, что вы теряете время, деньги и энергию команды, не проверив самое главное.

🔵Как это было у нас

Мы сами частично прошли через это с нашим стартапом CoActivity. Оказалось, что не все «гениальные» фичи были нужны пользователям. Пришлось возвращаться и пересобирать продукт, оставляя только то, что решало реальные боли.

В следующем посте расскажу, как распознать эти ошибки до того, как они стоят вам денег.

❗️Эти маркеры сэкономят ваш бюджет

В прошлом посте я рассказал про три «мемные» ошибки. Сегодня о том, как их заметить на ранних этапах.

🔵 Маркер №1: «Сделаем MVP, потом разберемся»

Если у вас нет подтвержденной боли хотя бы от 10-15 реальных пользователей — вы в зоне риска. Не ваших друзей или семьи, а людей из целевой аудитории, которых вы не знаете.
Вопрос, который нужно задать себе: Кто эти люди и точно ли я знаю, что у них есть эта проблема?

🔵 Маркер №2: «Возьмем подешевле»

Если подрядчик не задает уточняющих вопросов, не предлагает альтернатив и не отстаивает свою техническую позицию — это тревожный сигнал. Качественная команда всегда глубоко погружается в задачу.
Всегда уточняйте у подрядчика, какие риски он видит в этом проекте и как предлагает их минимизировать?

🔵 Маркер №3: «Сделаем сразу всё»

Если оценка проекта превышает 3-4 месяца — это повод остановиться и пересмотреть приоритеты. Исключения бывают, но для большинства стартапов это красный флаг.
За 15 лет в IT я убедился, что лучший способ сэкономить время и деньги, это вовремя задавать правильные вопросы.

В следующем посте расскажу, во что нам обошелся самый дорогой «мем» в практике и как его можно было избежать.

Как попытка сэкономить 2 недели стоила нам 3 месяцев работы⬇️

Иногда самые незначительные на первый взгляд решения могут привести к катастрофическим последствиям.

Мы с командой согласились упростить процесс согласования логики с заказчиком. Вместо тщательной проработки архитектуры и формализации требований пошли по пути «сделаем сейчас, потом разберемся». Это как собирать самолет, пока он летит.

🎥И пойдя таким путем мы:
— Через несколько месяцев обнаружили фундаментальные проблемы с хранением данных
— Форматы данных в разных модулях системы оказались несовместимы
— Пришлось переписывать значительную часть бэкенда и систему интеграций
— Общие потери: 3 месяца работы и несколько миллионов рублей

Потеря денег стала болезненной, но настоящей катастрофой оказался разлад в между командой и заказчиком. Возникла классическая ситуация взаимных обвинений: заказчик считал, что команда не доделала, а команда была уверена, что заказчик не донес требования.

🎥Зная это сейчас, тогда бы на старте я:
— Провел полноценный воркшоп по проектированию архитектуры
— Зафиксировал все соглашения о форматах данных
— Не пропускал этап технического проектирования под предлогом «срочности»

Этот случай научил нас простой истине: в разработке нет мелочей. То, что вроде бы кажется незначительной оптимизацией процессов сегодня, завтра может превратиться в многомесячный кошмар.

А вам приходилось сталкиваться с ситуациями, когда попытка сэкономить время оборачивалась еще большими затратами?

🙂Клиент никогда не признает своей ошибки.

Знаете, в работе с клиентами есть горькая правда. Можно сто раз предупреждать о рисках, но если клиент ошибся, виноваты будете вы.

У нас был проект, где мы были подрядчиками. Клиент гнался за скоростью реализации и проигнорировал наши предупреждения о всех сопутствующих рисках.

То есть в угоду скорости побежал вперед, не стал нас слушать и в итоге оступился.

И как обычно бывает, человек понимает, что ошибся, но не готов это признать и начинает искать виноватых.

Виноватыми в этой ситуации оказались мы. ⬇️

Мы были правы в этой ситуации и апеллировали всеми фактами, но негатива не удалось избежать.

И чтобы спасти проект, нам пришлось сделать огромную скидку и работать себе в убыток. Иначе клиент просто не заплатил бы вообще.

Проект мы в итоге запустили, однако осадочек остался. Клиент сохранил ощущение, что это мы его подвели. Хотя вины с нашей стороны не было совсем.
А с какими ситуациями несправедливых обвинений сталкивались вы?

💫Как я сменил роль в IT

IT-индустрия устроена парадоксально. Клиенты приходят за продуктом, но часто не готовы к его созданию. Я годами сталкивался с ситуацией, когда честные оценки и глубокое погружение в проект работали против нас. Пока не понял, что почти всем клиентам нужен не исполнитель, проводник.

➡️Мой переход в менторство стал естественным шагом. Сегодня я помогаю основателям:
— Создавать реалистичные планы разработки
— Формировать адекватные бюджеты
— Избегать скрытых расходов и рисков

➡️И уже через месяц работы со мной заказчики отмечают:
— Экономию до 70% бюджета на последующих этапах
— Сокращение времени на принятие решений
— Четкое понимание product roadmap

Если вы чувствуете, что ваш IT-проект требует не просто разработки, а стратегического подхода, то приглашаю вас на бесплатную консультацию.
Вместе мы создадим четкий план действий, который сэкономит вам время, деньги и нервы.

🔗Напишите мне в Telegram @antontar — обсудим, как вывести ваш проект на новый уровень.

Сделайте мне Wildberries за 300 тысяч.

Фаундеры нередко приходят ко мне с примерами крупных сервисов. Airbnb, Wildberries, Avito, то что они сами используют каждый день.

И у многих в голове это выглядит просто: «Ну там же карточки, поиск, фильтры. Значит, можно собрать быстро и недорого. Бюджет 500 тысяч, уложимся?».

➡️Только вот когда мы начинаем обсуждать продукт глубже, сразу видно, насколько у людей нет ощущения масштаба. Они видят внешний слой – кнопки, карточки и интерфейс.

А всё, что находится внутри, просто не замечают. Логику, которая связана между десятками сценариев, инфраструктуру и системы, которые работают параллельно.

Риски, которые появляются через полгода. Поддержку, которую никто даже и не думает закладывать в бюджет.

Конечно, человек не обязан знать устройство продукта. Но из-за этого появляется ощущение, что сложный сервис можно собрать как лендинг — быстро, легко и желательно вчера.

➡️Когда я объясняю реальную структуру, у фаундера часто меняется выражение лица. Он вдруг понимает, почему сервисы, которыми он пользуется каждый день, стоят сотни миллионов и развиваются годами.

✔️Для меня это и стало одним из поводов заняться менторством. Помогать людям увидеть проект таким, какой он есть на самом деле, прежде чем они войдут в разработку и обожгутся на тех же местах, где уже обжигались сотни команд.

Если у вас есть идея продукта и вы не уверены в бюджете, сроках или масштабе, то давайте обсудим это вместе.

🎥За одну встречу мы разберём, что реально можно сделать, где вы рискуете деньгами и временем, и какой формат запуска оптимален именно для вашей задачи.

Напишите в личку @antontar, договоримся о времени.

🔗Первый релиз начинается не с фич, а с боли.

Обычно первый релиз всегда упирается в то, что именно человек пытается решить с помощью вашего продукта. CustDev-исследования как раз помогает увидеть реальную проблему пользователя, а не свою фантазию о ней.

Например, если это сервис такси, то человек хочет быстро найти машину. Или если приложение с анализами, то он хочет увидеть результаты и понять, что с ними делать. Это и есть ядро релиза.

Но стоит учитывать, что сейчас уже нельзя выпускать MVP «на коленке».

Пользователи в России привыкли к хорошим сервисам. И если интерфейс совсем простой или нет базовых функций, то впечатление о продукте сильно падает, даже если он несет ценность.

Получается задача на стыке, нужно оставить только самое важное, но при этом довести это важное до приемлемого уровня. И ещё один важный момент, который часто помогает экономить ресурсы. Одну и ту же функцию можно реализовать по-разному.

➡️Пример из практики.

У всех сервисов рано или поздно появляется поддержка. Кто-то сразу делает внутри приложения полноценный чат, как в банках, но это дорого и долго. А можно сделать кнопку «Написать в Telegram», и пользователь всё равно получит помощь. Только без огромного объёма разработки.

И так можно делать со многими функциями, которые не являются основой продукта.

Первый релиз — это не про то, чтобы «втиснуть всё». Это про то, чтобы дать человеку решить свою главную задачу.

📎Если хотите разобрать ваш стартовый релиз и понять, что действительно должно попасть в первую версию, то пишите в личку @antontar, обсудим.

🙂Шаги до живого MVP

Перед тем как что-то разрабатывать, важно проверить саму идею. Но люди часто путают, идея — это не разработка. MVP — уже да. И если пропустить шаги перед ним, можно потратить деньги на то, что никому не нужно.

➡️Все начинается с понимания людей, для которых вы вообще делаете продукт. Идея может нравиться вам, но это не делает вас её целевой аудиторией. Нужно точно понять, кто эти люди и почему именно им это может быть полезно.

➡️Дальше важно прояснить саму проблему. Не общими словами, а конкретно, что человеку неудобно, что занимает у него время, где у него «болит». Когда проблема начинает проясняться, то решением должен стать ваш продукт.

➡️После этого проводят CustDev. Здесь может оказаться, что проблема есть, но не такая, как вы думали. Или возможно решение нужно другое. Лучше понять это сейчас, чем через миллион рублей разработки.

➡️ И только когда картина сложилась, можно садиться и составлять список того, что точно должно быть в MVP. Уже не «всё подряд», а только то, что помогает человеку справиться с его задачей.

Иногда на этом шаге выясняется, что полноценная разработка вообще не нужна. Можно протестировать идею через заглушки, прототипы, сторонние инструменты — и по факту получить те же выводы, только в разы быстрее и дешевле.

Главная цель всей этой цепочки понять, что вы делаете, для кого и зачем. А уже потом, как именно это упаковать в MVP.

📎Я помогу вам пройти эту цепочку и проверить идею на прочность — напишите мне в личку @antontar, обсудим ваш проект.

Наш корабль идёт ко дну или как не утонуть в операционке.

Есть состояние, которое многие фаундеры переживают, но редко говорят об этом вслух. Это утопание в операционке, своего рода форма предпринимательского выгорания.

🔵Первый звоночек, это спад мотивации.
Предприниматель, он же фаундер, по своей природе любит создавать, получать результат, видеть рост выручки, чувствовать, что приносит ценность. Операционка же – это рутина, которая неизбежна, но когда её слишком много, тогда появляется раздражение. И проекты уже начинают ассоциироваться не с ростом, не с возможностями, а с бесконечной текучкой.

🔵Второй звоночек, это туманность.
Это то состояние, когда ты словно идёшь вперёд, но не понимаешь, куда именно. Нет ощущения направления, нет понимания, к чему ведут эти усилия. Просто поток задач, в котором трудно увидеть смысл.

Все эти признаки говорят о том, что фаундер просто тонет в операционке и теряет стратегический фокус.

🔥Поставьте реакцию, если хотите видеть пост на тему какие процессы наладить в первую очередь, чтобы вернуть себе 30-40% времени и перестать тонуть в задачах.

Чем может быть полезен IT-ментор?

Ментор помогает фаундеру быстрее принимать более качественные продуктовые и техрешения, снижать риск фатальных ошибок и превращать «хаос идей» в понятный план развития продукта и команды.

➡️Вы понимаете:
- Куда уходит бюджет и на чём можно сэкономить без потери качества
- Как не потратить лишние миллионы на разработку
- Что нужно делать сейчас, а что отложить на второй этап

Но экономия денег, это не единственный результат. Вы экономите время на переговорах, согласованиях и бесконечных уточнениях. Вы перестаёте думать только о коде и начинаете видеть всю картину запуска продукта — от команды до маркетинга.

➡️Что я делаю как ментор:
Разбираю вашу ситуацию, помогаю составить план, показываю, как избежать ошибок, отвечаю на вопросы «как» и «почему».

➡️Что я не делаю:
Не пишу код за вас, не работаю как подрядчик и не решаю операционные задачи.

Менторство — это как консультация у фитнес-тренера. Он объяснит технику, составит программу, но качать железо вместо вас не будет.

Иногда после менторства клиенты просят взяться за конкретные задачи уже как подрядчик. Но это всегда отдельная история.

Если хотите также чётко видеть бюджет, сроки и этапы вашего IT-проекта — обращайтесь.

🔗Напишите мне в личку @antontar — обсудим, как я могу помочь вашему проекту.

P.S. Первая консультация — бесплатно. Иногда одного разговора хватает, чтобы сэкономить месяцы работы.

КАК ТЕСТИРОВАТЬ ИДЕИ В 2026?

В 2026 будет болеть:
🔵 рост затрат продолжится
🔵давление на маржу сохранится
🔵НДС, здравствуйте
А ещё: проверки, осторожные инвесторы и клиенты, которые думают дольше, чем раньше. Больше не прокатит логика "гениальной" идеи, которая точно стрельнет.

Хорошая новость — есть инструмент для казни иллюзий, и это прототип.

Прототип — это черновик идеи, который помогает быстро показать, как должна работать логика продукта, и проверить, понятна ли она со стороны.
Например, вместо разработки приложения вы собираете экраны в Figma, показываете их потенциальным инвесторам и смотрите, где люди теряются и задают вопросы.

➡️Но чем он отличается от MVP?

MVP — следующий уровень, но всё ещё не продукт с миллионом инвестиций. Это рабочая версия с минимумом функций, которую дают реальным людям, чтобы увидеть, купят ли они её и будут ли вообще пользоваться.

Понимание того, как работают прототип и MVP, позволяет выстроить совсем другую логику запуска.
Сначала — проверить идею и логику, потом — проверить спрос и ценность. И только после этого масштабироваться.

Реалии заставляют бизнес считать шаги заранее. Поэтому именно здесь прототип и MVP превращаются не в «теорию из стартап-курсов», а в инструмент выживания.

Тем более, что сегодня есть десятки ИИ-инструментов, которые позволяют делать это быстро и почти за 0 шекелей рублей. Поговорим о них чуть позже. Be in touch 🫵

💡ЧТО ЖДЁТ IT В 2026 ГОДУ?
Уже сейчас старые подходы начинают возвращаться счетами и потерями. В новой реальности останутся только те, кто умеет быстро адаптироваться.

Чего именно ждать?

➡️ИИ становится основой всей IT-логики
Если раньше нейронки были чем-то вроде доп кнопочки, то сейчас они будут вшиваться во всё, во что не лень: в разработку, аналитику, поддержку клиентов, персонализацию и автоматизацию. Продукты без ИИ будут проигрывать конкурентам.

➡️ Гипотезы должны проверяться быстрее
Многостраничные ТЗ, месяцы разработки и надежда, что «потом поправим», начинают стоить слишком дорого. Поэтому для этого будут активно использовать mini-apps, low-code и разработку с ИИ-ассистентами. Логика простая: сначала быстро проверить, потом инвестировать.

➡️Разработчики, ориентированные на продукт
Писать код уже недостаточно. Рутину забирает ИИ, а ценность в компаниях смещается на людей, которые не тупо умеют писать код, а уметь понять, что именно нужно делать и зачем.

➡️Правила работы с данными и ИИ становятся жёстче
ИИ больше нельзя использовать вслепую. Прозрачность алгоритмов, безопасность и ответственность за решения ИИ начинают напрямую влиять на то, как проектируются продукты и принимаются технические решения.
Эти требования начинают влиять на архитектуру продукта уже на старте.

«И так сойдёт» — фраза, на которой теряются миллионы.

Её обычно говорят в момент, когда хочется побыстрее выкатиться и не тратить лишние деньги. Но, увы, на практике это почти всегда выходит фиаско.

Основатель и команда видят продукт изнутри. Они знают «правильный» путь. Пользователь — нет. Он нажмёт не туда, введет дату рождения в поле «сумма платежа» и бросит процесс, когда вам это больнее всего.

Но так вы практически летите вслепую.

🔵Архитектурная ошибка, которую дешево было поправить на 2-й неделе, а на 20-й она требует переписать половину ядра.
🔵Критичный сценарий оплаты, который «падает» в день запуска для первых 10 клиентов. Репутация похоронена раньше, чем вы успели её построить.
🔵Упущенная выгода, потому что 70% пользователей не находят ключевую кнопку — и вы никогда об этом не узнаете.

Без тестирования эти места остаются слепыми зонами. Их не видно до релиза. И речь здесь не про внутреннюю проверку «сами потыкали».
А про тестирование с реальными пользователями: пилот, закрытая бета, фокус-группа, внешние сценарии.

Поэтому тестирование — это самый крутой способ заранее понять, выдерживает ли продукт реальное использование, а не идеальный сценарий в голове команды.

Не ждите, пока фраза «и так сойдёт» превратится в счет на переделку.

🔗Напишите мне @antontar — подскажу, как провести внешнее тестирование продукта и внедрить его как систему финансовой безопасности, а не как статью расходов.

Пока ваши конкуренты думают, что экономят, вы будете знать точную цену каждого решения.