👀 Долго, дорого, но надо На связи Глеб Скалацкий, руководитель отдела платформы разработки в Яндекс Еде. На TeamLead Conf 2025 я поделился своим управленческим кейсом: рассказал историю о том, как мы превратили проблемную функциональную платформу в полноценный продукт и, что самое главное, изменили подход команды к работе. Сразу оговорюсь, что речь идёт не про Яндекс. Поделюсь этой историей и здесь. 🅰️ Исходная ситуация Наша команда из 15 человек поддерживала фронт-офисную систему (нечто вроде CRM для сотрудников отделений). В отличие от продуктовых команд мы не делали end-to-end-ценность, а разрабатывали отдельные куски для очень разных заказчиков. Работали на .NET, тогда как все остальные переходили на Java, поэтому находились на пересечении множества бизнес-процессов. Всего у нас было 30 стейкхолдеров. ➕ Это создавало проблемы: 🔴 Приоритизация строилась по принципу «кто громче крикнет» 🔴 Разработка была непрозрачной 🔴 Техническая база устаревала, и у команды не было чёткого будущего 🔴 Ответственность за результаты размывалась между нами и другими отделами 🔴 Команда теряла мотивацию, а бизнес — скорость Чтобы решить все эти трудности, мы поставили себе чёткую цель: трансформироваться из внутренней платформы в продукт с понятной зоной ответственности и end-to-end-ценностью. 🅰️ Первый этап: наведение порядка Прежде чем куда-то идти, нужно было остановить хаос. И мы стали искать способ оценивать задачи объективно. Смотрели популярные фреймворки вроде ICE и RICE, но они не подошли. Проблема была в том, что наши задачи слишком разные: вот мы делаем новую фичу, которая принесёт прибыль, а вот — срочное требование от регулятора, которое остановит разработку, но защитит от огромных штрафов. Поэтому мы применили метод взвешенных оценок. Вместе со стейкхолдерами выделили четыре ключевых критерия: доход, NPS, уровень риска и потенциальная экономия. Договорились об их относительной важности и стали оценивать каждую задачу по этим параметрам. Результатом стала единая формула в таблице, которая автоматически рассчитывала приоритет при добавлении новой задачи. 🅰️ Второй этап: проверка гипотезы Чтобы решиться на полномасштабную трансформацию, нужно было доказать себе и бизнесу, что мы способны работать иначе. Мы нашли заинтересованную бизнес-команду и выделили небольшую группу инженеров для создания нового продукта с нуля. Работали короткими итерациями, регулярно демонстрировали результаты и получали обратную связь. За девять месяцев нам удалось не только запустить продукт, но и подтвердить важный тезис: наша команда может мыслить в продуктовой логике, а не просто выполнять технические задания. 🅰️ Третий этап: строительство продукта Мы сформулировали чёткую продуктовую цель, обозначали финансовую модель и границы того, за что теперь отвечаем. С помощью карты развития команды оценили, какие компетенции нужно подтянуть для продуктовой разработки. Стало ясно, что придётся серьёзно усилить команду: для полного цикла требовались специалисты по Java, фронтенду, мобильной разработке, тестированию и дизайну. Теперь в нашей команде около 90 человек. Структура усложнилась: появилось несколько направлений внутри продукта, каждое со своим владельцем и процессом. Чтобы сохранить единство и качество при таком росте, мы сделали ставку на гильдии — сообщества по профессиональным направлениям (разработка, тестирование и так далее). Их лидеры отвечали за развитие компетенций, общие стандарты и обмен знаниями. ⏯ Что в итоге 🔴 Появился единый бэклог. Разработка стала прозрачной, все знают, над чем работаем и почему 🔴 Стали видны зоны ответственности. Команда отвечает за конечный результат продукта, а не за выполнение разрозненных задач 🔴 Вернулась мотивация. У инженеров появилась перспектива, понятная цель и влияние на продукт ⏩️ Смотрите моё выступление целиком на ютубе и в VK Видео. В нём я подробно разбираю, как именно работает метод взвешенных оценок, делюсь правилами формирования гильдий и объясняю, когда трансформация оправдана,