Автор статьи: Сорокин Владислав

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

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

Подписались под всеми сроками нового проекта

IT-команда Сбера начала работу над интересным проектом, который позволял бы хранить и детально анализировать большие объёмы входных клиентских данных в онлайне. Данные — это любая информация, которая будет получена в точках контакта с каждым нашим корпоративным клиентом (юридическим лицом) через разные каналы взаимодействия. Например, стенография его телефонных звонков, переписка с операторами в мессенджерах и корпоративной почте. По задумке бизнеса такое решение должно стать первым на рынке — пока ещё ни у кого нет онлайн-системы, которая бы объединяла в одном месте, хранила и анализировала в реальном времени все клиентские «входящие» с любого канала, через который клиенту удобно взаимодействовать с банком. Идея в том, чтобы видеть всю предысторию обращений клиента и оперативно реагировать на его вопросы. Раз решение должно стать первым — надо работать очень быстро.

Пытаясь «успевать» за бизнесом и соответствовать его требованиям (даже с учётом большой неопределённости), IT-подразделение подписалось под всеми частями проекта, согласилось с предельно короткими сроками, собрало команду и приступило к работе. Здесь надо сказать, что у каждого участника был высокий интерес к проекту: всех увлекла идея, было желание воплотить её быстро и в целом к началу разработки не появилось аргументов к удлинению сроков. Однако по мере работы команда столкнулась с несколькими серьёзными сложностями.

Появились проблемы, много проблем

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

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

«Стоп. Так идти дальше нельзя!»

Нужно что-то менять в процессах. Или где? Команда сначала пыталась найти причины сложившейся ситуации: возможно, ошибка всё-таки в процессах; возможно, виноват кто-то конкретный (куда же без Герцена); возможно, задачу надо выполнять не так, как планировали (и Чернышевского); возможно, вообще ещё «не доросли» до таких задач. Но после долгих попыток понять, стало ясно, что дело вовсе не в том, что команда недостаточно квалифицирована и совершает ошибки. А в том, что надо было своевременно отказываться от потока новых задач.

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

Смелое решение IT-команды, которое помогло оптимизировать работу над сложным проектом

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

Лайфхак от IT-команды Сбера, который поможет, если вы уже «зашиваетесь» с техническим долгом

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

«Коллеги, мы пока не готовы к реализации нового функционала. У нас есть определённые стадии зрелости продукта, и вначале нам надо пройти их».

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

К каким выводам пришла команда и что сейчас происходит с проектом

Команда прошла все этапы зрелости — свои и продукта — и довела проект до той стадии, когда некоторыми его сервисами уже пользуются корпоративные клиенты Сбера. В 2021 году Сбер вышел с этим продуктом в финал национальной премии «Цифровизация». 

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

 После судьбоносного для проекта «нет» были приняты некоторые управленческие решения (нет, никого не уволили, наоборот — команду усилили, но кто-то ушёл на другие проекты), затем сформирован бэклог того, что необходимо сделать (включая техдолг) и утверждён адекватный спокойный план работ.

Для составления адекватного плана работ команда научилась:

• оценивать задачи по реальным трудозатратам;

• формировать все ожидания от продукта (и важные для бизнеса, и технические);

• делать разработку более прозрачной для заказчика, ставя его в известность о процессах и заранее предупреждая о возникающих трудностях (даже если уверены, что их можно решить своими силами), регулярно обсуждая свежие результаты;

• называть заказчику предположительные экспертные сроки с учётом стадий продукта;

• не брать к исполнению задачи, если они не недостаточно проработаны командой, не ясны всем участникам;

• не допускать добавлений задач в уже утверждённый спринт;

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

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

Кратко, к чему может привести боязнь разработчиков сказать «нет» подразделению, ставящему множество задач:  

• Демотивация команды, иногда до такой степени, что проект просто никуда не движется и просвета не видно (хотя он есть);

• Завышенные ожидания «бизнеса», которые если не оправдываются, приводят к естественному негодованию топ-менеджмента, которое в каждой отдельно взятой компании может вылиться в очень разные формы;

• Удлинение сроков разработки с соответствующими финансовыми, а возможно и репутационными потерями для компании или команды.

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

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