Согласно отчету CHAOS компании Standish Group, основанному на анализе 50 000 проектов по всему миру, 66% технологических проектов завершаются частичной или полной неудачей. При этом, как показало исследование PwC с участием 200 компаний из 30 стран, только 2,5% организаций успешно завершают 100% своих проектов. Неудачные IT-проекты обходятся американским компаниям в $260 миллиардов ежегодно, согласно отчету CISQ. Но что особенно удивительно — большинство техлидов винят в провалах технологии, бюджеты или сроки, совершенно не подозревая о собственной роли в этих катастрофах. Денис Рябченко, технический руководитель калифорнийской Aparavi (компания разрабатывает решения для управления корпоративными данными), за 13 лет карьеры работал в командах от харьковских стартапов до международных корпораций уровня Ahrefs и видел одни и те же паттерны саморазрушения снова и снова. Имея статус Expert-Vetted на Upwork (1% лучших из 18 миллионов фрилансеров), семь научных публикаций и опыт судейства международных хакатонов, он наблюдал, как талантливые разработчики превращаются в токсичных лидеров, повторяя одни и те же ошибки.

Ошибка № 1: Техлид остается программистом

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

«Я вижу это постоянно при найме в Aparavi, — говорит Денис. — Кандидат решает алгоритмические задачи на отлично, но когда прошу объяснить решение стажеру, начинает мямлить. В удаленной команде это смертельно.»

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

Особенно болезненно это бьет по распределенным командам. Когда техлид в Лос-Анджелесе пишет ключевой код в два ночи, коллеги в Европе просто не могут продолжать работу. Проект встает намертво.

Решение психологически болезненное: перестать быть лучшим программистом и научиться выращивать других, считает Денис Рябченко. Но большинство не готово отпустить то, что раньше приносило признание.

Ошибка № 2: «Невидимая» работа не приносит славы

Программисты любят код, так как он осязаемый, его можно показать, за него хвалят. А вот code review, документация, автоматизация тестов кажутся скучными. Техлиды часто относятся к этому как к рутине «для галочки».

Денис в 2020 году работал над Meet on Bubble, платформой для виртуальных офисов. Изначально это была игрушка для креативщиков, но когда мир ушел на удаленку, продукт за недели превратился в корпоративное решение.

«Мы не утонули в техническом долге только потому, что не экономили на „скучной“ работе, — вспоминает он. — Короткие спринты, постоянные демо, нормальная документация. Конкуренты не смогли так быстро перестроиться.»

Результат впечатляющий: продукт внедрили Shell, саудовская Ithra и множество школ для онлайн-обучения. Но успех был возможен только благодаря заложенным процессам, а не гениальному коду.

Ошибка № 3: Процессы вместо людей

IT-лидеры обожают автоматизировать проблемы. Плохо общается команда? Добавим еще один трекер. Люди не понимают задачи? Усложним планирование. Конфликты между разработчиками? Больше митингов!

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

«Хакатоны открыли мне глаза, — признается Денис, который судит соревнования PyWeb Creators и GameForge AI. — За 72 часа команды сами находят эффективные способы работы. Никто не вводит бюрократию — нет времени. Зато есть открытое общение, ясные роли, честная обратная связь.»

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

Ошибка № 4: Интуиция вместо данных

«Мне кажется, React подойдет», «По опыту знаю, что этот подход сработает». Большинство техлидов принимают архитектурные решения на ощущениях. Пока проекты маленькие, это работает. Но при масштабировании интуиция начинает подводить.

Денис совмещает практику с наукой. В 2025 году представил исследование «Automated selection of architectural solutions based on ML analysis» на конференции в Ванкувере. Также подает документы на статус senior member в IEEE, организации, которая устанавливает мировые технологические стандарты для 400 000 инженеров.

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

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

Ошибка № 5: Люди не масштабируются как серверы

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

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

Axi не просто брокер, а партнер Manchester City, который обслуживает трейдеров по всему миру. Интеграция маленького стартапа в такую машину — квест повышенной сложности.

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

Что дальше: люди важнее алгоритмов

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

Денис сейчас параллельно работает над стартапами World Monitor (анализ новостей и прогнозирование через ИИ) и Mente Medical (оптимизация хирургических инструментов с RFID). Оба требуют координации международных команд и молниеносной адаптации к изменениям.

«Раньше лидер был лучшим программистом. Теперь он создатель среды, где каждый может расти, — резюмирует Денис. — Технологии объединяют нас, но успех зависит от понимания людей.»

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