Из найма в консалтинг: почему я сделал этот шаг
Спустя несколько месяцев на позиции Тех.Лида в консалте наконец накопилось достаточно впечатлений, чтобы поделиться мыслями о решении, которое удивило некоторых коллег.
В начале года я завершил свой путь как Senior IT-менеджер в крупной FMCG-компании. Вскоре после моего ухода весь внутренний центр разработки расформировали — лишнее напоминание о том, что даже самые стабильные корпоративные структуры могут измениться за один день.
Вместо того чтобы сразу искать похожую роль, я осознанно ушёл в консалтинг. Хотелось перейти от «владения одним продуктом» к «решению разнообразных архитектурных и бизнес-задач» в разных отраслях.
Устроился в Ай-Теко, чтобы возглавить разработку крупного социального проекта. Мы подхватили проект от предыдущего подрядчика, собрали кросс-функциональные команды с нуля и сейчас выстраиваем предсказуемые процессы поставки, используя сочетание Product-подхода, Kanban, DORA-метрик и микросервисов.
Ключевое отличие консалтинга от найма: В найме ты плотно погружён в бизнес-стратегию и долгосрочное видение продукта. В консалтинге ты работаешь с уже сложившейся ИТ-инфраструктурой заказчика. Это позволяет нам, как вендорам, сфокусироваться на техническом качестве, скорости поставки и ценности платформы — без внутренней бюрократии. Удивительно, но операционные задачи те же самые: — Переезд с монолита на микросервисы. — Обеспечение требуемого уровня доступности. — Построение и развитие CI/CD-конвейеров. — Формирование команд, нацеленных на общий результат.
Чего не хватает? Честно говоря, скучаю по глубоким стратегическим разговорам о ценности и бизнес-процессах с заинтересованными сторонами. Но обратная сторона медали — доступ к новым доменам и адреналин от «спасения» проблемных проектов — бодрит и даёт новый драйв.
А как у вас? Переходили из найма в консалтинг или наоборот? Что вас удивило по ту сторону баррикад? Интересно послушать ваши истории.
· 18.07
Хороший кейс про смену роли: в консалтинге реально иначе меряются успехи - не владение одним продуктом, а скорость входа в домен и качество передачи знаний. Я бы ещё добавил явный контракт на ожидания и метрики по первым 30 дням. Это у вас уже формализовано?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 18.07
Павел, спасибо за комментарий.
По формализации у нас так:
Для рядовых сотрудников прописываем ожидания через призму команды: через N-период их результаты должны быть "не хуже, чем у коллег на аналогичной роли" по базовым метрикам производства + обратная связь.
Для меня договорились сразу о двух приоритетах: стабилизация системы по доступности + репутация со стороны заказчика с точки зрения прогнозируемости и качества итоговой работы. Это две параллельные задачи.
А вот доверие действительно метриками не измеришь, и это, наверное, самое сложное. Но без него все остальные цифры теряют смысл — так что работаем и над этим тоже
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён