Петр Третьяк: «Бизнес и IT говорят на разных языках — и переводчик тут не всегда спасает»

— Петр, почему между бизнесом и IT почти всегда возникает разрыв — это неизбежность или управленческая ошибка?

Это неизбежно, как дождь в Петербурге. Просто потому, что они по-разному устроены. Бизнес думает про выручку, клиентов, конкурентов. Ему надо, чтобы работало и приносило деньги. IT думает про то, как это все не уронить, как база выдержит нагрузку, как связать сервисы, чтобы они не развалились через полгода. Это два разных мира. И это нормально. Ошибка — делать вид, что это не так. Когда никто не переводит с одного языка на другой, разрыв начинает расти с первой же встречи.

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

— В какой момент проекта обычно начинается это непонимание — и почему его редко замечают сразу?

Начинается на первом же созвоне, где обсуждают, что будем делать. Бизнес говорит: «Нам нужна система лояльности, чтобы баллы начислять гибко». Все покивали. IT отвечает: «Мы сделаем микросервисы, чтобы независимо». Бизнес слышит умное слово и тоже кивает. Все расходятся довольные. А через месяц выясняется, что под «гибко» бизнес имел в виду три варианта, а IT заложило архитектуру под тридцать. Или наоборот — заложили жестко, а бизнес через месяц захотел все переиграть.

Почему не замечают? На старте энтузиазм зашкаливает. Хочется же классный продукт сделать, конфликт никому не нужен. Первые звоночки маленькие, на них машут рукой: «Ну, рабочий момент». А когда разрыв становится виден невооруженным глазом, он уже съел и время, и деньги. Еще момент: многие менеджеры думают, что раз все покивали на встрече, значит, договорились. Но кивок — не подтверждение одинакового понимания. Это просто знак вежливости.

— По каким ранним признакам можно понять, что бизнес и IT уже «разошлись в ожиданиях»?

Три верных маркера.

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

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

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

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

— Какие типичные ошибки допускает бизнес при работе с IT-командой?

Первое — приходят с готовым решением, минуя проблему. Говорят: «Сделайте личный кабинет с историей заказов». А на самом деле человеку надо просто повторить прошлый заказ в два клика. Это может решаться без всякого кабинета. Но раз бизнес уже «заказал» фичу, команда делает. И получается функционал, который есть, но проблему не решает.

Второе — бизнес пропадает. Участвует на старте, рисует макеты, а потом — тишина до приемки. Через три месяца видит результат и выдает: «Мы не это имели в виду». А если бы раз в две недели смотрели живую демку, курс можно было поправить сразу. Тут еще проблема в том, что бизнес часто не выделяет на это время, считая, что его дело — дать задание и принять готовое.

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

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

— А в чем главная ошибка самой IT-команды в этой коммуникации?

Уходить в технологический снобизм. Когда бизнес спрашивает: «А можно вот так сделать?», а ему отвечают: «Вы не понимаете, это архитектурно неправильно». И тишина. Бизнес чувствует себя идиотом и закрывается. Дальше диалога нет. А надо объяснить: «Если сделаем так, приложение ляжет под нагрузкой через месяц. Но мы можем сделать чуть иначе — и вашу задачу решим, и ничего не ляжет». Это другое.

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

Третья — обещать сроки, не подумав. Под давлением говорят: «За две недели сделаем». А потом героически не спят и все равно срывают. Лучше честно сказать: «Я дам точную оценку, когда мы проработаем макеты и поймем объем интеграций». Это не слабость, это профессионализм.

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

— Можете привести пример проекта, где из-за этого разрыва были потеряны деньги или сроки?

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

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

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

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

Иллюзия начинается, когда Agile превращают в набор ритуалов. Стендапы, ретро, демо — все по расписанию, галочки ставятся, а суть уходит. На демо показывают «оптимизировали запросы к базе», а бизнесу это ни о чем. Ему надо видеть пользовательские сценарии. А не тикеты в Jira.

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

— Почему стандартные решения вроде «нанять более сильную команду» или «внедрить новые инструменты» часто не работают?

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

Корень проблемы не в слабости команды и не в отсутствии инструментов. А в том, что никто не сводит картины мира в одну. Это не лечится наймом очередного сеньора-разработчика или переездом с Jira на YouTrack. Это лечится тем, что кто-то берет на себя роль синхронизатора: управляет ожиданиями, переводит требования и постоянно проверяет, что все одинаково понимают результат. Инструменты и люди — лишь проводники, а ключ в коммуникационной дисциплине.

— Кто на самом деле должен быть «переводчиком» между бизнесом и IT, и почему эта роль часто проваливается?

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

Проваливается обычно по двум причинам. Первая — переводчик сам не понимает одну из сторон. Если PM вышел из бизнеса и в разработке не разбирается, он просто ретранслирует хотелки, не фильтруя. Если PM вырос из разработки, он может закопаться в технические детали и так и не ответить бизнесу на главный вопрос: «Когда оно начнет приносить деньги?».

Вторая причина — человеку не дают полномочий. Бизнес говорит: «Я буду общаться с командой напрямую». Команда говорит: «Мы лучше сами с заказчиком поговорим». Менеджер становится лишним. Но прямой контакт без модерации как раз и плодит недопонимание. Чтобы переводчик работал, обе стороны должны его признавать и доверять ему. И важно, чтобы он не становился «почтальоном», а имел право задавать вопросы и оспаривать решения, если они противоречат целям продукта.

— Если дать бизнесу один практический совет: что нужно изменить уже завтра, чтобы начать говорить с IT на одном языке?

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

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

Что мы поняли

Разрыв между бизнесом и IT — это не вина кого-то одного. Просто люди смотрят на мир через разную оптику. Но если этим разрывом не управлять, компания теряет деньги, время и людей. Решение не в новых инструментах и не в «усилении» команды. Оно в живом, регулярном и переведенном на оба языка диалоге. Роль переводчика сложна, но без нее любые методологии и красивые доски станут просто декорацией. Благодарим Петра за откровенный разговор и ценные наблюдения.