# Samokat.tech / ecom.tech (апрель 2023 — июнь 2025)

Роль по CV: Product Team Lead. Три команды, 18+ разработчиков, запуск трёх потребительских продуктов с нуля.

> Черновик по итогам рассказа (09.10.2026). «уточнить» — открытый вопрос.

## Компания и контекст

- Шла **фаза расширения Самоката**: рост объёмов, интеграция многих команд, рост нагрузки.
- **Сбер купил Самокат и объединил с Мегамаркетом** в одну компанию — **ecom.tech** («ЭкомТех»). Началось инфраструктурное объединение.
- «Мегамаркет» в CV — это не отдельное место работы, а часть этой эпохи: одна из команд Сергея делала продукт под интеграцию ассортимента Мегамаркета в Самокат.

## Вход: ЦМС (контент-менеджмент системы)

- Пришёл в команду **ЦМС** — один из её блоков управлял **каталогом** (плюс промо).
- Продукт был большой и его **собирались разделить на две части**. Там уже был свой тимлид, и Сергей должен был **в паре с ним** возглавить новый элемент.
- Новый элемент по коду лежал в той же **монорепе** и плохо был изолирован — границы ещё предстояло строить.
- В момент прихода у Сергея **ещё не было людей в подчинении**: он только изучал базу, процессы, знакомился с ребятами.

## Роль «в паре с тимлидом» (уточнить)

- Формат: два лида на продукт, разделяемый на две части. Как именно делились зоны ответственности и полномочия — Сергей не рассказывал.
> Уточнить: как был устроен этот тандем, кто что решал, что с ним стало.

## Проект 1: Digital Asset Management (DAM) — свой продукт с нуля

- Возникла задача собрать **новый продукт — Digital Asset Management**. Сергей **сам поднял руку**: «раз новый продукт, идёт найм — давайте я поучаствую: умею, смогу повлиять на архитектуру, собрать команду, всё организовать». Решение одобрили.
- **Собрал команду:** нанял **двух Ruby-разработчиков и тестировщика**. Дальше присоединялись ещё руководители проекта.
- Работал в паре с **product owner** (Татьяна — упоминается позже по «Мольберту»).
- **Долгое время работал без системного аналитика** — системный анализ тоже лежал на нём.
- **Спроектировал систему сам**, заложил несколько решений, которые впоследствии доказали правильность:
  - версионирование — как хранить версии;
  - структура файлов на S3;
  - взаимодействие с клиентами и то, как должна идти загрузка.
- **Ключевое архитектурное решение:** продукт был нацелен на несколько групп пользователей с разными сценариями; нужно было реализовать все и не запутаться в бизнес-логике. Предложил схему: отделить **ядро (просто хранилище)** от **бизнес-слоёв в ограниченных контекстах**, которые ложатся поверх и минимально пересекаются друг с другом. Разрулил через **DDD**.
- **Один из немногих проектов в компании, вышедших в продакшн в срок:** ~4–5 месяцев. При этом сроки начали тикать ещё **до того, как появилась команда** — Сергей начинал с документации и анализа, а дальше вместе с коллегами доделал.

## Проект 2: «Мольберт» — умный редактор фотографий (спасение чужой команды)

- По ходу развития DAM к связке с product owner **добавили ещё один коллектив**: **«Мольберт»** — умный редактор фотографий с элементами AI.
- Была **отдельная ML-команда**, с которой интегрировались: ML делал искусственно-интеллектуальную часть, команда Сергея — сервис вокруг.
- История провала «Мольберта»: проект стартовал примерно тогда же, когда команда DAM выходила в прод; ребята были воодушевлены («сейчас мы всё сделаем»). Прошло полгода и больше — продукт выпустить не удалось; что-то работало, но никуда не годилось: ни стабильности, никто не доволен.
- Руководители оттуда ушли (или их ушли), и **Сергея с Татьяной направили туда выстраивать процесс**.
- **Что сделал:**
  - техническую команду сохранил (стек: **Go, Python**);
  - подкорректировал неудачные архитектурные решения — с учётом уже существующего стека, чтобы Go использовался по делу;
  - **перенёс логику с фронтенда на бэкенд**, изменил зоны ответственности;
  - выстроил **более строгий Scrum**, чтобы всем было понятно;
  - выстроил **спокойствие и понятные ожидания от продукта**;
  - много работал с командой над **корректной оценкой в сторипоинтах**, актуальностью статусов задач, ввёл документацию;
  - расставил всё по репозиторию, настроил пайплайны и сборки.
- **Результат:** команда успокоилась, ожидания от продукта стали понятны, **выпустили первый релиз, затем второй** — дальше «пошло-поехало». Потом наняли ещё разработчика.

## Проект 3: интеграция DAM (уточнить)

- Начали **интегрировать DAM** — «первый проект с этим»; здесь тоже **скрещивали команды**.
- Наблюдение Сергея: когда приходилось отвлекаться на вторую команду, в первой нужно было **больше делегировать ребятам**.
> Уточнить: с чем именно интегрировали DAM, что это был за третий продукт, чем закончилось.

## Найм

- **DAM:** нанял двух Ruby-разработчиков и тестировщика (личный найм).
- **Go-разработчики:** найм был устроен через **практику** (не через Сергея). Он участвовал **на финальных стадиях** (несколько советов), техническую часть проводил не он.
- За кадром (по CV): найм и формирование команд с нуля — уточнить общее число нанятых лично.

## Люди: кейс «вайб-кодера» (лето 2024) — сильный современный кейс

- В команде была девушка-разработчица на испытательном сроке.
- **Баддинг:** её бадди был другой разработчик на проекте; Сергей регулярно синкался с ней, спрашивал у бадди, как дела, время от времени встречался с ней напрямую. Она говорила, что всё замечательно; бадди выказывал лёгкие сомнения, но «в целом в рамках нормы».
- **Как вскрылось:** когда второй разработчик (Александр) ушёл в отпуск, Сергей остался с ней один на один, нужна была задача — а она не двигается. Он начал входить в детали, смотреть, что она делает, провёл несколько встреч и сессий **парного программирования**.
- Оказалось: **не понимает базовых концепций** — как устроен продукт, как его запускать, что такое аутентификация, над чем работает. На вопросы «теперь понятно, можешь задать вопрос?» отвечала «нет, всё понятно» — а результат нулевой.
- Выяснилось: она **много общалась с другими разработчиками из практики** (не из команды), просила у них код-ревью, они подсказывали. Складывалось впечатление, что она **«вайб-кодер»**: не понимала код, который за неё производил AI, что-то делала, не работало — и с помощью других доводила до приемлемого. **Самостоятельно программировать не могла.**
- **Решение:** провёл сессию, затем подключился системный аналитик, и на обсуждении задачи стало понятно, что она не понимает, что делает. Сергей указал: не понимает базовых вещей — ни синтаксиса, ни структуры проекта, хотя на проекте больше месяца. Сказал, что это **не соответствует уровню команды**, сформулировал претензии **в письменном виде** и направил в практику.
- **Итог:** через несколько недель она написала заявление (ещё в рамках испытательного срока). Сергей вышел на **HRBP**, вопрос порешали; девушка сильно не сопротивлялась, подписала документы.

## Мегамаркет

- После объединения с Мегамаркетом (Sber) в ecom.tech одна из команд делала продукт под **интеграцию ассортимента Мегамаркета в Самокат**.
> Уточнить: какая это была команда и как встроилось в хронологию (до/после «Мольберта»).

## Повышения (ключевой people-блок)

- **Общий принцип:** видя ключевых сотрудников, Сергей **сам** предлагал компании их повысить — не ждал, пока человек попросит.
- **Но:** если сотрудник сам не двигал инициативу, повышение получалось **ниже** — «хоть какое-то». Формулировка, с которой он выходил: «этот человек рассматривает варианты, думает об этом — надо подумать о повышении».
- **Два разработчика повышены по итогам года** (фронтенд и бэкенд):
  - было окно для подачи на премии;
  - Сергей **заранее, в течение года** говорил ребятам, что нужно готовиться: собирать достижения в файл/список;
  - помогал им **составить отчёт о достижениях**;
  - в итоге как ключевые сотрудники получили повышение, порядка **10–15%**.
- **Кейс «юный бэкенд-разработчик, которая ушла»:** пришла совсем юным разработчиком, начала показывать результат. Сама пришла и сказала, что ей нужно повышение — повышение сделали. Но она уже настроилась уходить: пришла с **кросс-оффером** и сказала, что не останется. Ушла на повышение туда; компания не смогла подтвердить — там сделали почти **в 2 раза**. Рефлексия Сергея: она хорошо выросла в компании, но такие повышения (в 2 раза за раз) на практике не делаются, такого он не видел.
- За кадром (по CV): 5 повышений + преемник. Часть цифр — уточнить, какие именно 5.

> Уточнить: как устроен формальный процесс повышения (грейды, комитет, кто решал), какую роль играл Сергей в защите кандидатуры, был ли отказ в повышении.

## Отказ в повышении — два кейса

### Кейс A: сильный человек, но в компании фриз (фронтенд)

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

### Кейс B: бэкенд-разработчик с накопленными претензиями

- Человек пришёл просить повышение, но у Сергея было **много накопленных претензий** к нему.
- Аргументация просившего была не про результат, а про **сложную жизнь**: живёт в Европе, семья, развод, жизненные проблемы.
- **Ответ Сергея:** компания платит за ценность, которую ты приносишь — доказывать нужно именно в этом компоненте. Объяснил конкретные претензии (в т.ч. предсказуемость) и что нужно показывать результат.
- Человек принял. Дополнительно сказал, что ищет другую технологию — хочет переходить на **Elixir**. Сергей всячески поддерживал: «развитие классное, давай обсудим; в компании востребовано вот это, задачи вот такие; но если ищешь развитие — это классно, буду рад, если у тебя в Европе всё получится».
- Одновременно **подсвечивал менеджеру**, что человек в зоне риска; при этом риск оценивал спокойно: если бы он ушёл в моменте, это не было бы суперпроблемой — Сергей знал, что мог бы подхватить бэкенд сам.
- **Итог:** человек ускорился, показал хорошую работу, **лучше встроился в команду** (Сергей донёс ожидания команды: стабильность, коммуникация внутри команды, предсказуемость — и он многое поправил). **Повышение получил** — не 50%, как хотел, но **10–15%**.

## Грейды и матрица компетенций

- **В Самокате** повышения обычно происходили **«на глаз»** — формальной матрицы не было.
- **В Баланс Платформе** (как руководитель Ruby-практики) Сергей **расписывал матрицу компетенций**: что требуется для такого-то грейда в знаниях.
- **Матрица осталась в теоретической части:** методическую часть проработал, но как процесс до внедрения не доехала — **никто через неё не прошёл**. Были пилоты: проводили некоторых разработчиков через матрицу, тестовые ассессменты. Но **процесс повышения через неё не завели**.
- Ощущение Сергея: компания скорее **защищалась ассессментами от повышений** — «игровая механика», а реальной мотивации повышать со стороны компании не было.
- **Где матрицы уже были приняты** (ассессменты): Сергей **курировал процесс** — спрашивал, что не получилось, мотивировал.
- **Отдельная ценная практика:** некоторые ребята прошли ассессмент год назад, сидели в грейде и **не предпринимали новых попыток**. Сергей мотивировал пробовать снова: **сама попытка — это опыт**; сталкиваешься с проблемой, понимаешь, чего не хватает, и готовишься дальше. Иначе в своём коконе можно сидеть очень долго.

## Позиция: как говорить «нет» на просьбу о повышении

- **Принцип:** важно, чтобы компания понимала ценность сотрудника. Если понимает — захочет его оставить и повысить. Значит, **надо доносить эту ценность**.
- «Надо становиться специалистом по промоушену себя»: рассказывать про свою ценность, выступать на внутренних митапах, проявляться, активно участвовать в переговорах, брать инициативу, исполнять принятые в компании практики и методологию.
- **«Нет» никогда не окончательное:** надо скорректироваться и продолжать путь. **У каждого «нет» есть причины/векторы, что именно надо изменить** — отказ всегда сопровождается советами, что менять.
- **Аргумент для оставшихся после ухода коллеги** (см. предупреждение ниже): «ваша удельная ценность для компании возрастает: было 5 разработчиков, стало 4 — ваша доля выросла с 20% до 25%. Вы становитесь носителями знаний, ваша потеря для компании дороже. Оставайтесь дольше, проявляйтесь — это ваш путь к промоушену».

> ⚠️ **Замечание для интервью.** Формулировка «ваша ценность выросла, потому что ушёл коллега» — двойственная: по смыслу это про концентрацию знаний и bus factor (что верно и полезно), но звучит как «твоя ценность относительна — она растёт, когда другие уходят». На собесе лучше переформулировать: «вы стали ключевым носителем знаний по этой части — давайте зафиксируем это в зоне ответственности и расти в ней», без арифметики долей.

## Открытые вопросы

1. Как был устроен тандем «два тимлида на один продукт» (ЦМС).
2. Что за третий продукт и интеграция DAM — с чем, каким продуктом, чем закончилось.
3. Пять повышений: кто, за что, как добивался.
4. Преемник-тимлид: кто, как растил.
5. AI-агент для code review: как пришла идея, как делали, что дало (по CV — отдельный кейс).
6. DDD как архитектурный стандарт: как закреплял, было ли сопротивление.
7. Управление техдолгом в новых командах.
8. Общее число нанятых лично за период; сколько людей было в трёх командах.
9. Почему ушёл в июне 2025 (в Райф).
10. Как вёл себя найм в эпоху AI — выводы из кейса «вайб-кодера».