Привет! СИБУР — не просто одна из крупнейших нефтехимических компаний мира, это в принципе довольно большая компания с кучей разных процессов, множеством людей (как штатных специалистов, так и постоянных внешних подрядчиков). А еще — с большим количеством разных продуктовых команд, которые трансформируются, масштабируются, обмениваются разработчиками и аналитиками, в общем, всё это весьма динамично, быстро и всегда затачивается под конкретную задачу.
В этом посте мы хотим побольше рассказать о том, как у нас всё устроено. Команд у нас много, как и используемых или стеков, так что говорить будет и верхнеуровнево, и на примере конкретной команды CRM.
Потому что CRM – это «скелет» сквозного процесса продажи и обслуживания клиентов. И там, как в едином котле смешиваются воедино и сложные задачи для разработчиков (попробуй всё интегрируй, как надо, и сделай так, чтобы работало), и для аналитиков, а сколько тут чисто бизнесовой части и тонкостей в процессах — вообще туши свет.
Под катом:
как устроено взаимодействие между командами
что ждет новичка, пришедшего работать в СИБУР
какие есть пути развития карьеры в целом и своих навыков в частности
почему круто, когда разраб может просто приехать на завод и лично посмотреть, кто пользуется его продуктом
почему у тестировщика в целях вполне себе может быть конверсия интернет-магазина (и это нормально)
почему B2B-рынок интереснее, чем пресытившийся B2C
Люди
СИБУР всё ещё проходит процесс трансформации, заточенной на данные, цифровизацию, автоматизацию и прочие модные штуки. Для того, чтобы всё это получилось как надо, мы в свое время решили набирать с рынка не просто хороших специалистов, а в том числе и людей, которые могут на самом деле что-то менять, предлагать новое. Ведь зачастую, увы, в тяжелом энтерпрайзе продвинуть новую идею, будучи разработчиком, сложнее, чем пойти и попросить повысить себе зарплату раза эдак в три.
Мы подумали, что нам очень нужны подобные люди, поэтому старались набирать команды из больших компаний, которые славятся своим продуктовым подходом и отличным коммьюнити. Яндекс, Озон, МТС, VK, в общем, вспомните любой бигтех, который сделал что-то значимое за последние пару лет — 100 к 1 у нас есть люди, перешедшие оттуда. И подобное разношерстное сообщество помогает разбавить экспертизу компании чем-то свежим, не дает застояться и окуклиться в рамках своей сферы деятельности.
И что еще важно — это дает нам возможность проверенный не раз и не два B2C-опыт аккуратно переложить на большой B2B, учитывая особенности той или иной отрасли.
Сейчас мы работаем в формате кроссфункциональных команд. Например, наша CRM-команда состоит из 100% выделенных людей (дизайнер, разработчики, скрам-мастер, бизнес-аналитик, системный аналитик, тестировщик и прочие). Такой подход к комплектованию помогает команде end-to-end выполнять свои задачи и отвечать за весь свой продукт. Целиком, под ключ.
Фокус на бизнес
Кроме привычных для каждого метрик и целей, мы запускаем ребят в бизнес и даем им фокус на бизнесовой истории и связанных с ней метриками. Это не просто команда отличных спецов, которые сидят и пилят свои фичи — это люди, которые напрямую влияют на выручку компании. Вот этими руками. Поэтому всегда полезно, чтобы они знали, что и как работает, как к нововведениям относятся люди из бизнеса, что сработало, а что — так себе.
Возьмем для примера тестировщика нашего B2B-онлайн-магазина. У него есть метрика – «конверсия из посетителей сайта в покупку». Вы можете подумать — «Да вы вообще упоролись, это ж тестировщик, с конверсией пусть специально обученные люди занимаются». С одной стороны, здравое зерно есть (как и специально обученные люди). С другой — если тестировщик плохо протестирует какую-то штуку, выкатит ее на прод, а это штука радостно и надолго прод положит — резонно предположить, что конверсии поплохеет. А поплохеет конверсии — поплохеет бизнесу, ведь такой онлайн-магазин и его простои это довольно серьезные убытки.
Но главное тут, что человек понимает: кем бы он ни работал, дизайнером или аналитиком, разработчиком или тестировщиком — он не просто человек-функция. Он без шуток сам, своими действиями, активно влияет на наш бизнес и наши процессы. Всё это обвешано метриками, все это вознаграждается при расчете KPI и премий.
Технологии
Тут у нас такой джекпот, что, думаем, фанату каждого языка программирования или фреймворка нашлась бы задача. Смотрите сами — у нас создают решения для огромных заводов с учетом специфики их работы (ограничения по связи, защищенность и многое другое), у нас делают полезные фичи для смежных тяжелых историй, а ещё разрабатывают вещи фокусно под СИБУР.
React, JS, Битрикс, набор фреймворков для фронтенд- и бэкенд-разработки, Kotlin, Siebel... в общем, проще написать, чего нет.
B2C VS B2B
Одна из главных историй работы у нас, именно в SIBUR Digital, это возможность затащить в B2B-сектор решения, которые отлично прижились и оказались полезными в B2C. С учетом нашего фокуса на цифровизации, здесь вам дадут карт-бланш на подобное. Мы уже успели сделать для B2B-рынка ряд решений, которые никто не делал, и начать их продавать как услугу.
В целом, один из главных вызовов в B2B — это именно идеи. Как что-то оптимизировать, как что-то автоматизировать, какое новое направление бизнеса можно придумать. B2C отчасти перенасыщен этим — тут вам и биометрия везде, где можно, и машинное зрение, и различные отслеживания кризисных ситуаций. И как что-то полезное принести из B2C в B2B, не расплескав по пути смысл — это тоже вызов.
Вперед и вверх (а еще в сторону и на завод)
Карьерный рост для наших команд мы активно поддерживаем любой — вертикальный, горизонтальный, в сторону, в общем, что сам человек выберет. Парадигма развития компетенций в СИБУРе такова, что сотрудник просто может прийти и принести, скажем, ссылку на какой-то курс, который он хочет пройти. Или записаться на митап, сходить на конференцию, послушать лекцию.
Без ограничений типа «Александр, у вас лимит на одну конференцию и две книжки в год от компании» — потому что это не благотворительность и не попытки выбить HR-преимущества, а взаимовыгодная история. У компании есть большой бюджет на обучение и развитие сотрудников, а сотрудники, проходя выбранное ими же обучение, потом возвращают компании сторицей через свою экспертизу, новые навыки и свежие идеи.
Отдельно уделяем внимание и внутреннему обучению — разработчики любят менторить новичков, проводить вебинары для команд и делиться чем-то новым. Особенно занятно срабатывает на людях с разными и почти не пересекающимися компетенциями. Часть внутреннего обучения это высадки в бизнес.
Можно просто сесть рядом с людьми из бизнеса и посмотреть, чего там как. Какие метрики для бизнеса важны, удобно ли какому-нибудь топ-менеджеру пользоваться дашбордом, который ты собирал пару недель, понимает ли он быстрые действия и прочее, прочее, прочее. Это очень хороший способ сбора обратной связи, скажем, из рук в руки. Потому что в самой команде небольшая замыленность и профдеформация может помешать заметить какой-то рабочий момент при живом использовании продукта.
Конечно, никуда и без качественного онбординга. Каждый новичок в нас получает бадди (и еще пару человек, которые и без бадди сами будут ходить и советовать всякое), а количество информации, получаемое с онбордингом реально впечатляет.
Может ли большое и корпоративное быть гибким и шустрым
За всех не скажем, но, кажется, у нас получается. Например, такая важная вещь как график. Официально можно работать по гибридному графику без всяких «С 9 до 18». Команды распределенные, работать можно из любого города страны.
Мы всегда открыты к предложениям вида «А давайте попробуем вот этот стек, он лучше». Если он и правда лучше. Мы проводим максимально доступные встречи, на которых любой может высказаться и оценить то или иное решение. Любой участник процесса, включая непосредственного заказчика, может при желании пойти и поштормить вместе с командой, как же сделать крутое решение, которое всех устроит. Иногда это здорово экономит время, потому что в подробной беседе с разрабами и примерах на пальцах заказчик может осознать, что половина функций ему и не нужна, или их можно делать вообще по-другому.
Это называется PBR (Product Backlog Refinement), и в рамках такой активности у нас генерится примерно 20% идей для беклога.
Ещё сильно помогает проведение демо, когда продакт рассказывает обо всех свежих изменениях и есть возможность получить фидбек из первых рук.
В общем, нам сейчас, спустя несколько лет работы по такому подходу, он все еще кажется довольно выигрышным. Будем рады, если напишете в комментах, чего, на ваш взгляд, не хватает, что хорошо бы добавить, и стоило ли навешивать на тестировщика метрики по конверсии :)