Автор статьи: Сорокин Владислав После такого несколько кликбейтного заголовка сразу раскроем свои карты: ИТ просто в один прекрасный день «посмели» сказать «нет» потоку срочных задач от бизнеса, и разработка стала отставать от графика.Теги: #Технологии #Оно #платформа в #сберай #лайфхакНа этом можно было бы и закончить, но тогда лайфхак так и остался бы лишь теорией, которую вы наверняка не раз видели в книгах на тему «уметь говорить «нет»».
Однако на практике применить этот совет в разработке еще сложнее, чем в реальной жизни.
И вырванный из контекста этот совет «так себе».
В этом блоге мы рассказываем нашим потенциальным коллегам о том, какие проекты, технологии и команды сейчас доступны в Сбербанке и что вас ждет, если вы присоединитесь к нам.
Сегодня это история о том, как мы оптимизировали работу ИТ-команды таким образом, что разработчики не сидели до ночи, подписавшись на супер-короткие сроки, установленные «бизнесом», а «бизнес» остался доволен .
Подписался на все условия нового проекта
IT-команда Сбера приступила к работе над интересным проектом , что позволит хранить и подробно анализировать большие объемы входных клиентских данных в режиме онлайн.Данные — это любая информация, которая будет получена в точках контакта с каждым нашим корпоративным клиентом (юридическим лицом) по различным каналам взаимодействия.
Например, стенограмма его телефонных разговоров, переписки с операторами в мессенджерах и корпоративной почте.
По задумке бизнеса, такое решение должно быть первым на рынке — ни у кого пока нет онлайн-системы, которая бы объединяла в одном месте, хранила и анализировала в реальном времени все клиентские «входящие» сообщения из любого канала, по которому они приходят. удобное взаимодействие клиента с банком.
Идея — видеть всю историю обращений клиента и быстро отвечать на его вопросы.
Поскольку решение должно быть первым, работать надо очень быстро.
Пытаясь «не отставать» от бизнеса и соответствовать его требованиям (даже с учетом большой неопределенности), ИТ-отдел подписался на все части проекта, договорились о крайне сжатых сроках, собрали команду и приступили к работе.
Здесь надо сказать, что у каждого участника был высокий интерес к проекту: все были увлечены идеей, было желание быстро ее реализовать, и в целом к моменту начала разработки аргументов для продления сроков не было.
.
Однако в ходе работы команда столкнулась с рядом серьезных трудностей.
Были проблемы, много проблем
Когда команда начала показывать первые MVP, «бизнес», видя отличные результаты, начал генерировать новые функциональные идеи.При этом реализовать и должным образом протестировать уже реализованное, но «сырое» и требующее доработки базовое решение не удалось, так как возникли трудности с реализацией.
Дело в том, что проект был завязан с несколькими другими банковскими продуктами, и команде приходилось постоянно согласовывать изменения с другими командами, разрабатывающими эти продукты, чтобы они тоже вносили в них изменения для нового проекта.
В большой компании, как известно, это сложно и если не долго, то уж точно не мгновенно.
Чтобы не ждать ни дня разрешения на реализацию, разработчики переключили свое внимание на новые задачи, которые из-за своего множества постепенно ушли в большой бэклог — с ними стало трудно справляться.
При этом техническая реализация основного решения еще «хромала», над этим нужно было активно работать — о сроках мы помним! Все эти накопившиеся проблемы привели к единогласному решению:
«Стоп.
Мы не можем так дальше идти!» Надо что-то менять в процессах.
Или где? Команда сначала попыталась найти причины сложившейся ситуации: возможно, произошла ошибка в процессах; возможно виноват кто-то конкретный (будь то без Герцен ); возможно, задача не должна быть выполнена так, как планировалось (и Чернышевский ); возможно, они еще не «доросли» до таких задач.
Но после долгих раздумий стало ясно, что дело не в том, что команда недостаточно квалифицирована и допускает ошибки.
И дело в том, что нужно было оперативно отказаться от потока новых задач .
Это осознание пришло к менеджерам на разных уровнях проекта и поразило их своей простотой и уверенностью в себе, но именно это спасло ситуацию.
Высшее руководство пересмотрело бизнес-задачи, расставило приоритеты и изменило сроки.
С этого момента все было хорошо, и работа шла как надо.
Смелое решение ИТ-команды, которое помогло оптимизировать работу над сложным проектом.
Оглядываясь назад, команда поняла, что прошла несколько моментов, когда важно было сказать «нет» новым задачам со стороны бизнеса, настроить процессы и «доработать» существующую реализацию решения.
Но они не говорили об этом с гордостью.
Например, это был момент, когда первые версии решения уже были выпущены в производство и столкнулись с неожиданно более высокой нагрузкой, чем ожидалось (помним, что это высоконагруженный проект с большими данными).
Еще таким моментом стала ситуация, когда увидели, что хорошей поставки релиза в продажу нет. Это затрудняло работу.
Инвестиции в DevOps позволили бы им сократить затраты (как они и сделали позже), но команда пришла к решению настраивать процессы самостоятельно, параллельно разрабатывая новый функционал на основе поступающих запросов.
Третьим и решающим моментом было понимание того, что сроки безвозвратно сорваны.
Лайфхак от IT-команды Сбера, который поможет, если вы уже боретесь с техническим долгом
Разработчикам свойственна профессиональная самокритика и саморефлексия.Вы, как и мы, можете тратить время и нервы, пытаясь понять, почему развитие идет не гладко или вообще никуда не движется.
Но мы не должны сбрасывать со счетов возможность того, что «бизнес» не знает тонкостей ваших технических процессов и не понимает некоторых естественных производственных ограничений.
Поэтому, если вы чувствуете, что «бизнес» потирает руки, предвкушая хорошую прибыль от нового проекта, и начинает запрашивать все новые и новые интересные возможности, стоит смело говорить :
«Коллеги, мы пока не готовы реализовать новый функционал.Очень важно вовремя честно признаться, если возникли технические проблемы, требующие решения.У нас есть определенные стадии зрелости продукта, и сначала нам нужно их пройти».
Это не будет выглядеть так, будто ты слабый и поэтому не справляешься.
Наоборот, такое озвучивание своей позиции говорит об опыте, о том, что вы умеете работать максимально эффективно, чтобы не накапливать технический долг, который может затормозить развитие всего проекта.
Более того, помимо стадий зрелости продукта, есть еще стадии зрелости команды, которые тоже необходимо пройти.
Если игнорировать этот аспект разработки, то продуктивное взаимодействие и цели проекта могут оказаться долгими и труднодостижимыми.
К каким выводам пришла команда и что сейчас происходит с проектом?
Команда прошла все стадии зрелости — как свою, так и продуктовую — и довела проект до той стадии, когда некоторыми его сервисами уже пользуются корпоративные клиенты Сбера.В 2021 году Сбер с этим продуктом вышел в финал национальной премии «Цифровизация».
Пожалуй, главный полезный вывод, который сделали разработчики: не стоит сразу думать, что бизнес плох, потому что он давит и не слушается.
Велика вероятность, что он понимает, но не слушает, потому что вы ему ничего не говорите.
Точнее, не говорите однозначного «нет».
Вы берете на себя полную ответственность за закрытие накопившегося технического долга и за написание нового функционала, а «бизнес» думает, что все идет нормально — вы соглашаетесь.
Да, трудно признавать проблемы.
Но стоит помнить о презумпции невиновности и для начала предположить, что у вас есть адекватное руководство, которое вас услышит и примет взвешенные решения в концепции «Win-Win» как для бизнеса, так и для разработчиков.
Даже если не сразу.
После судьбоносного для проекта «нет» были приняты некоторые управленческие решения (нет, никого не уволили, наоборот, команду усилили, но некоторые ушли в другие проекты), затем накопился задел того, что нужно было сделать.
сформировался (в том числе технический долг) и был утвержден план работ.
Чтобы составить адекватный план работы, команда научилась:
Когда ИТ-команда своевременно говорит «нет», то у бизнеса есть время расставить приоритеты и перенести график, а у команды есть возможность выдохнуть и улучшить процессы, не накапливая технического долга.
- оценивать задачи, исходя из реальных трудозатрат;
- сформулировать все ожидания от продукта (как важные для бизнеса, так и технические);
- сделать разработку более прозрачной для заказчика, информируя его о процессах и заранее предупреждая о возникающих трудностях (даже если вы уверены, что их можно решить самостоятельно), регулярно обсуждая последние результаты;
- сообщить заказчику ожидаемые сроки выполнения работ с учетом этапов реализации продукта;
- не браться за задания, если они не достаточно проработаны командой и не понятны всем участникам;
- не разрешать добавлять задачи в уже утвержденный спринт;
- не обременять команду разработчиков лишними компетенциями, а привлечь специалистов, которые будут отдельно отвечать, например, за релиз, DevOps, нагрузочное тестирование.
Вкратце, к чему может привести страх разработчиков сказать «нет» отделу, который ставит множество задач:
Хотим отдельно отметить: в данном случае речь не идет о том, что следует отказываться от дела при первой же трудности и не о том, что отказ от новых заданий — правильная тактика.
- Демотивация команды , иногда до такой степени, что проект просто никуда не движется и четкого пути не видно (хотя он есть);
- Завышенные ожидания от «бизнеса» , которые, если их не оправдать, приводят к закономерному возмущению высшего руководства, которое в каждой отдельной компании может выражаться в самых разных формах;
- Продление времени разработки с соответствующими финансовыми и, возможно, репутационными потерями для компании или команды.
Мы все понимаем, что главное в нашей работе — стремление к бизнес-целям проекта и что дополнительные задачи при разработке неизбежны, и это нормально.
Речь идет о ситуации, когда новые задачи превращаются в поток и их срочное выполнение ставит под угрозу как контроль над процессами и результатами в работе ИТ-команды, так и саму основную бизнес-цель.
Надеемся, статья была полезной.
В следующей статье по этому кейсу мы поговорим о том, как именно Сбер технически оптимизировал работу ИТ-команды над этим проектом.
-
Набор Инструментов Для Поисковой Оптимизации
19 Oct, 24 -
Интернет – Мое Личное Пространство
19 Oct, 24
