Обо мне
Александр Литвинчук
Руководитель разработки в CSI. Работаю с несколькими командами и инженерным направлением как с одной системой.
7–10 инженерных команд · до 100 специалистов · Санкт-Петербург
Сейчас
Текущая роль
Я руководитель разработки в CSI. В моей зоне ответственности — 7–10 инженерных команд и до 100 специалистов: разработчики, тестировщики, DevOps, технические писатели, архитекторы и технические эксперты.
На этом масштабе большая часть сложных задач уже не помещается внутрь одной команды. Решение может зависеть одновременно от структуры взаимодействий, процесса, технологического ограничения, распределения ответственности и того, какие данные видит руководство.
Поэтому моя работа постепенно сместилась от управления отдельными задачами к устройству системы: как несколько команд вместе производят результат, где возникают зависимости и какие изменения действительно имеют смысл запускать.
Опыт
Не одна специализация, а несколько слоёв одной системы
Мой опыт не складывается вокруг одной темы. В разные годы я занимался техническими системами, качеством разработки, процессами, метриками, организацией нескольких команд и новыми способами работы. Для меня это не отдельные специализации, а разные слои одной инженерной системы.
Техническая основа
Разработка, SQL и базы данных, MS SQL Server и PostgreSQL, высокодоступные и On-Premise-системы. Технический контекст для меня остаётся частью управленческих решений, а не отдельным слоем, который можно не учитывать.
Качество и способ работы
Качество разработки, процессы, организация работы команд, прохождение изменений от идеи до production. Здесь я постепенно перешёл от отдельных практик к вопросу о том, как устроена система производства software целиком.
Несколько команд
Зависимости между командами, границы ответственности, распределение решений, взаимодействие руководителей и общая способность инженерного направления производить результат.
Изменения
Перестройка процессов и схем работы, запуск новых подходов, работа с метриками и данными, организационные изменения и темы, где технология требует менять не только инструмент, но и сам способ работы — например AI.
Подход
Разобраться до того, как менять
В сложной ситуации я стараюсь не принимать заявленную проблему за диагноз. Если «команды не успевают», это ещё не означает, что нужно ускорять команды. Если «процесс не работает», это ещё не означает, что нужен новый процесс.
Обычно я сначала разбираю систему на части, отделяю наблюдения от предположений, проверяю несколько объяснений и ищу то, что реально ограничивает результат. После этого можно проектировать другую схему работы и переводить её в конкретные изменения.
Разобраться в системе → отделить симптомы от причин → найти ограничение → проверить альтернативы → спроектировать изменение → запустить первые шаги → посмотреть на результат.
Для проверки гипотез я использую разные сигналы: фактический путь работы, зависимости между командами, технический контекст, данные и метрики, наблюдения руководителей и обратную связь от результата. Ни один из этих источников сам по себе не является диагнозом.
На что смотрю
Результат
Что должна производить разработка и как выглядит хороший результат на уровне направления, а не отдельной локальной функции.
Команды и зависимости
Где проходят границы, кто от кого зависит и какие организационные решения создают лишнее ожидание или ручную координацию.
Ответственность
Кто может принимать решения, где ответственность размыта и где система компенсирует конструктивные проблемы героизмом отдельных людей.
Поток работы
Как работа проходит от идеи до production, где теряется контекст и где локально правильные действия замедляют систему целиком.
Данные и метрики
Какие сигналы помогают проверить гипотезу и принять решение, а какие только создают ощущение наблюдаемости или контроля.
Изменения
Как проверить гипотезу небольшим реальным изменением и понять по результату, стоит ли двигаться дальше.
Граница роли
Мне важнее найти рабочую конструкцию, чем месяцами владеть трансформацией
Мне близка работа, в которой сначала нужно поставить диагноз, затем спроектировать решение, помочь запустить первые изменения и убедиться, что механизм работает.
Дальнейшее исполнение при этом должно оставаться внутри организации. Я не хочу подменять руководителя, становиться внешним project manager или строить работу вокруг постоянных статус-митингов.
Это важная граница и для внешних разговоров: полезность для меня начинается там, где есть сложная инженерная ситуация и неопределённость, а не просто потребность во внешней паре рук.
Траектория
Техническая база Разработка, SQL и базы данных, MS SQL Server и PostgreSQL, высокодоступные и On-Premise-системы. Эта база помогает обсуждать организационные решения без отрыва от технической реальности.
Команда и delivery Качество разработки, процессы и организация работы команды. Постепенно объектом работы стала не отдельная техническая задача, а способ, которым команда превращает идею в работающий результат.
Несколько команд Зависимости, общие процессы, метрики, распределение ответственности и технологические решения, которые уже нельзя оптимизировать по одной команде независимо от остальных.
Сейчас Руководство разработкой на уровне инженерного направления и запуск изменений, которые затрагивают систему целиком: от новой схемы поставки до применения AI как части нового способа создания продукта.
Образование
Санкт-Петербургский государственный политехнический университет — техническая кибернетика, магистр с отличием.
Второе высшее юридическое образование — вуз, сегодня известный как Санкт-Петербургский государственный экономический университет.
В разные годы также проходил профессиональную подготовку Scrum Alliance, ICAgile и SAFe. Для меня это часть профессиональной истории, а не отдельное позиционирование.