Петр Третьяк: «Созвоны — самый дорогой способ имитации работы»

В мире ИТ принято считать, что главная угроза проекту – это «кривая» архитектура или баги в продакшене. Мы тратим миллионы на поиск лучших разработчиков и внедрение новых стеков технологий, но продолжаем проваливать сроки и сжигать бюджеты. Почему так происходит? Ответ часто лежит не в области синтаксиса языков программирования, а в плоскости обычного человеческого общения.

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

– Пётр, здравствуйте! Когда мы говорим о провалах в ИТ, первыми на ум приходят технические факапы. Но вы утверждаете обратное. Что на практике чаще ломает проекты, ошибки в коде или все-таки проблемы в общении?

– Здравствуйте! Да, за десять лет я ни разу не видел, чтобы проект закрыли из-за кривого кода или багов. Почти любые технические проблемы можно решить за пару выходных, если нанять толковых специалистов. А вот коммуникационный хаос сжирает бюджеты месяцами. Статистика говорит (данные из Project Management Institute (отчёт Pulse of the Profession 2013, цит. по PMI)), что до 56% проектов проваливаются именно из-за невнятных целей и разрывов в общении.

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

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

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

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

– Звучит угрожающе. А можно ли заметить этот «пожар» на ранней стадии? По каким признакам вы сразу понимаете, что проект начинает «тонуть» именно из-за коммуникаций?

– Определяю «запах» провала еще до открытия таск-трекера.

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

Второй признак – бесконечные цепочки переписок в Slack или Telegram. Если обсуждение задачи занимает больше тридцати сообщений, значит, никто ничего не понимает. Люди начинают «пинговать» друг друга каждые пять минут. На уточнение деталей уходит до 30% рабочего времени команды вместо написания кода.

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

Третий маркер – фраза «я думал, это сделает другой». Это верный знак отсутствия матрицы ответственности. В таких условиях задачи просто проваливаются в черную дыру между отделами. Если у задачи нет одного конкретного владельца, считайте, что задача не будет выполнена.

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

– Часто бывает так, собираются сильные профи, горят делом, а через пару месяцев все превращается в бардак. Почему так происходит?

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

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

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

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

Отсутствие формальных правил при росте команды превращает профессиональный диалог в бесполезный флуд.

– Вы упомянули потерю времени. Давайте переведем это на язык цифр. Как именно эти «разговоры» превращаются в реальные финансовые убытки?

– Математика здесь простая и беспощадная. Основной статьей расходов в ИТ является время специалистов, стоимость которого постоянно растет. Когда из-за криво поставленной задачи разработчик с зарплатой в триста тысяч рублей переделывает фичу трижды, бизнес платит тройную цену за один и тот же результат. Исследование, опубликованное Дэвидом Гроссманом для Society for Human Resource Management (SHRM), показало, что компании теряют в среднем 62,4 млн долларов в год из‑за неэффективной коммуникации между сотрудниками.

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

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

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

Коммуникационные разрывы превращают рабочие часы в прямые финансовые убытки и делают продукт неоправданно дорогим.

– Получается, проблема системная. А есть ли пример, когда техническая часть была на высоте, но проект все равно «сгорел» из-за слов?

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

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

Проблема заключалась в том, что Slack убил ответственность за передачу критически важных данных. Все думали, что «все в курсе», раз сообщение было отправлено. Но чтение мессенджера – это не работа, а иллюзия осведомленности. Люди реагируют на уведомления, но не вникают в суть, если их не тегнули с четким призывом к действию.

Закончилось все жестко. Проект задержали на два месяца для полной переработки ядра. Мы потеряли лояльность ключевого партнера и около 15% прогнозируемой выручки за первый квартал. Этот кейс стал для компании прививкой от «чатозависимости». После него мы запретили принимать любые изменения в работу через мессенджеры без обновления тикета (задачи) в Jira.

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

– Если руководитель понимает, что в проекте уже начался хаос, с чего начинать лечение? Какие шаги дадут самый быстрый эффект?

– Первым делом ввожу жесткий запрет на постановку задач в мессенджерах. Любая просьба в Telegram без ссылки на тикет считается несуществующей. Это правило моментально снижает уровень информационного шума. Однажды я просто удалил Slack у всей команды на три дня. Сначала ребята паниковали, но потом начали писать вменяемые комментарии в трекере. Фокус вернулся, а скорость закрытия задач выросла почти в полтора раза.

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

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

Дисциплина в использовании инструментов и обязательная фиксация итогов встреч быстро возвращают проекту управляемость.

– Часто в ответ на хаос руководители требуют «больше созвонов» или «задокументировать каждый шаг». Почему эти популярные методы обычно проваливаются?

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

Такие «летучки» создают лишь иллюзию контроля, пока реальные задачи стоят. На практике до 40% времени на созвонах тратится на пересказ того, что уже написано в почте.

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

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

Многие верят, что количество коммуникаций переходит в качество. Это опасное заблуждение. Чем больше каналов связи, тем выше вероятность ошибки. Если задача обсуждается одновременно в Jira, Slack и на созвоне, фрагментация смыслов неизбежна. В итоге каждый участник процесса уносит с собой свою версию правды.

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

– Не могу не спросить про хайп вокруг нейросетей. Как AI повлияет на командную работу: он поможет навести порядок или только добавит шума?

– Искусственный интеллект станет либо спасательным кругом, либо топливом для костра коммуникационного безумия. С одной стороны, нейросети отлично справляются с ролью «цифрового секретаря».

Они могут автоматически собирать выжимку из часовой встречи, выделяя конкретные поручения и сроки. Это экономит до 20% времени менеджера, которое раньше уходило на рутинную писанину. Внедрение ИИ-ассистентов позволяет превратить рыхлый поток слов в структурированный список задач.

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

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

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

ИИ станет эффективным инструментом только в руках тех, кто уже умеет выстраивать лаконичные и понятные процессы.

– В завершение нашей беседы вопрос о главном. Что сегодня важнее для успеха, умение писать безупречный код или способность договариваться?

– Навык договариваться сегодня критичнее умения писать код. В эпоху нейросетей и развитых библиотек написание рабочих строк превращается в товар массового потребления. Сгенерировать функцию может и машина, но она не способна понять, решит ли этот код боль живого пользователя. Мы вступили в эпоху, где успех продукта на 80% зависит от точности попадания в ожидания рынка и лишь на 20% от чистоты реализации.

Я часто вижу команды, которые закапываются в рефакторинг, пока бизнес горит. Они пишут идеальный код для задач, которые давно потеряли актуальность. Умение вовремя остановиться, задать вопрос «зачем?» и передоговориться с заказчиком экономит миллионы. Без внятной коммуникации разработка превращается в стрельбу с закрытыми глазами: патронов много, но цель давно сместилась.

ИТ-индустрия долго жила в парадигме «умных одиночек», которые делают магию в подвале. Сейчас время прошло. Современный софт – это коллективное творчество огромного количества людей с разным бэкграундом.

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

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

Код – это только инструмент реализации, а коммуникация – это фундамент, без которого любая постройка рухнет.

Итоги встречи

Главные риски ИТ-проектов лежат не в области технологий, а в культуре взаимодействия. Хаос в коммуникациях – не простое неудобство. Это прямой финансовый убыток, который может исчисляться миллионами рублей. Основной вызов для современного лидера заключается в умении фильтровать информационный шум и превращать разрозненные чаты в жесткую систему ответственности.

Три главных вывода из интервью:

1. Приоритет смыслов. Договоренности на берегу и фиксация требований важнее чистоты программного кода.
2. Гигиена общения. Запрет на постановку задач в мессенджерах и сокращение пустых митингов возвращают команде до 30% рабочего времени.
3. Роль ИИ. Технологии должны помогать структурировать информацию, а не множить бесконечные отчеты.

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