У меня в команде инженерная гильдия только запускается. Пока это проявляется в оперативном обмене кейсами в чатах и первых общих решениях — но до зрелой гильдии с регулярными техтоками и совместной документацией ещё расти.
Формально эффективность пока рано мерить — не хватает метрик, но уже есть хорошие сигналы!
Модель Spotify — это не рецепт, а пример. Я не копирую её, а вдохновляюсь принципами: автономия, общая ответственность и знания как коллективный актив.
Идея с учётом часовых поясов действительно помогает выстроить более эффективную работу как технической поддержки, так и в ближайшем будущем процесс внедрения. Такой подход позволяет сохранять высокую скорость работы, минимизируя простои из-за разницы во времени, и при этом не перегружать сотрудников необходимостью работать в неудобные часы.
Что касается синхронизации между инженерными командами — основной объём рабочей информации фиксируется в единой системе. Каждый сотрудник может ознакомиться с ходом задач в удобное для себя время. В командах внедрён процесс передачи смены, а также используются «окна пересечения времени», когда утро у восточной команды совпадает с концом рабочего дня в центральном регионе (и наоборот). В эти периоды проводятся синхронные встречи: совместные обсуждения, анализ проблем и экстренные совещания при инцидентах.
Найти квалифицированных специалистов за пределами центральных регионов и крупных городов возможно, но это достаточно сложно.
Благодаря слаженной работе с нашей HR-командой, мы за несколько месяцев смогли подобрать сразу несколько специалистов. Процесс занял немного больше времени, чем при поиске в центральном регионе, но в целом оказался реализуемым.
Сейчас, с развитием ИИ и новым толчком, выглядит, что задача решаема, но как и писал выше это скорее новый инструмент для HR, который позволит с них снять рутину и облегчить их работу с фокусом на более важные дела.
Кстати, если я верно понял, то вы работаете РМ (project management) мы прямо сейчас проводим пилот по "карме" проектов, очень интересно получается и вижу сразу много возможностей для автоматизации с помощью ИИ-агентов в процессах управления проектами)
Если говорить о коммерческом применении подобных решений, то на рынке уже существуют аналоги, посмотрим насколько они будут успешны, на данный момент ни одна "машина" не заменит опытный взгляд рекрутера)
А у вас есть примеры таких решений? Или может даже опыт?
Не совсем так, доработки не потребовались, необходимо было внести контекст, а именно настроить способ и схему подключения, но сам код мы не правили.
На текущем этапе развития ИИ я считаю, что не может произойти полноценной замены, но однозначно необходимо менять подход к разработке.
Сегодня ИИ - не замена, а усилитель! Она не просто генерирует код, а сокращает путь от задачи к рабочему решению. То, что у инженера заняло бы 3–4 часа (поиск по API, анализ, написание скрипта), нейросеть делает за 10 минут с минимальными правками.
Что касается "отказа от джунов" — здесь важно не путать инструмент и процесс развития.
Да, рутину, которую раньше поручали джунам, теперь может делать ИИ:
Написание простых скриптов
Документирование
Поиск в базе знаний
Подготовка шаблонов
Но джун — это не тот, кто пишет скрипты. Джун — это тот, кто учится думать как инженер.
Нейросеть не заменит джунов — она освободит их от рутины и позволит быстрее стать настоящими инженерами.
А наша задача как команды — не отказываться от новых специалистов, а перестроить онбординг и развитие под новую реальность.
Будущее — не в том, чтобы не нанимать джунов, а в том, чтобы научить их управлять теми, кто (условно) "пишет код за них".
Я не исключаю, что когда-нибудь мы перейдём на такие БД, но Elasticsearch тоже умеет искать по векторам и пока нам полностью подходит под наши задачи.
В нашем случае пока проблема не в выборе БД, а в том, что мы загружаем, то есть как строим вектора. Более того, мы после поиска в БД ещё и ранжируем результаты, то есть применяем дополнительный фильтр.
Сроки мы не скрываем ни от команды, ни от руководства компании. Есть статистика, есть метрики. То же касается и текучести кадров (менее 10% в год, если интересно), и других аспектов.
Тем не менее, нас есть за что критиковать и нам есть что улучшать. Я не считаю, что у нас все идеально, мы работаем и развиваемся дальше - про это написано в статье. Тем более, в тексте описан первый год, когда проблем было гораздо больше по сравнению с сейчас.
Отличный, важный и честный вопрос. Слово «нам» — не метафора. Я говорю именно о команде PS.
Что изменилось для рядовых инженеров:
1. Меньше рутины и хаоса . Раньше 70% времени уходило на «тушение пожаров». Теперь — на внедрение и развитие.
Меньше стресса, больше смысла в работе.
2. Прозрачность и предсказуемость Стало понятно: . Что делать . Когда . Зачем . Кто за что отвечает
Люди интегрированы в процессы перестали чувствовать себя «винтиками».
3. Рост и развитие Мы ввели: . Онбординг с обратной связью . Запустили матрицу зрелости 2.0 . Регулярные аттестации
Стало понятно, куда расти.
Сейчас в работе карьерная матрица и процедура оценки.
4. Обратная связь и признание Раньше очень редко говорили: «спасибо, ты хорошо сделал». Теперь ретроспективы, благодарности, NPS — всё это часть открытой культуры.
Люди знают, что их слышат и видят.
5. Оклады и нагрузка Да, оклады росли — по результатам аттестаций и рыночной корректировке.
А нагрузка? . Интенсивность осталась высокой, но теперь она осознанная, а не хаотичная. . Люди работают в потоке, а не «выгребают».
Итог: лучше стало не только бизнесу, но и тем, кто этот бизнес делает каждый день.
На самом деле, разработчики — это наши внутренние клиенты, и они могли бы просто сказать: «не будем помогать, это не наша задача», но они пошли навстречу, хотя:
. У них были свои дедлайны . Они не обязаны были обучать нашу команду . Им пришлось тратить время на объяснение базовых вещей
Мы это очень ценим!
И, честно, первые месяцы были не про «я пришёл и всё изменил», а про «я пришёл и попросил помощи».
Теперь, кстати, обратная связь пошла и в другую сторону — PS помогает разработке с тестированием в полях, частично с документированием и обратной связью от клиентов.
Да, субъективность на первых этапах была огромной. Я не пыталась её убрать — я решил её структурировать.
Вот как это делали: Ввели шкалу оценки спринта от 1 до 10: 10 - спринт прошёл чётко, все ключевые задачи выполнены, команда в потоке .. 5 - были сложности, но в целом по плану .. 1 — Всё плохо, хаос, срывы, команда выгорела
Каждая оценка сопровождалась комментарием: что именно пошло не так или что сработало хорошо.
Через 2–3 месяца стали сравнивать оценки и комментарии — и увидели паттерны: например, если 3 человека ставят «3» и пишут про «нехватку времени на онбординг» — это уже не субъективность, а сигнал.
Итог: мы не боролись с субъективностью, а сделали её частью системы сбора данных. Со временем она стала основой для объективных выводов.
У меня в команде инженерная гильдия только запускается. Пока это проявляется в оперативном обмене кейсами в чатах и первых общих решениях — но до зрелой гильдии с регулярными техтоками и совместной документацией ещё расти.
Формально эффективность пока рано мерить — не хватает метрик, но уже есть хорошие сигналы!
Модель Spotify — это не рецепт, а пример. Я не копирую её, а вдохновляюсь принципами: автономия, общая ответственность и знания как коллективный актив.
Идея с учётом часовых поясов действительно помогает выстроить более эффективную работу как технической поддержки, так и в ближайшем будущем процесс внедрения. Такой подход позволяет сохранять высокую скорость работы, минимизируя простои из-за разницы во времени, и при этом не перегружать сотрудников необходимостью работать в неудобные часы.
Что касается синхронизации между инженерными командами — основной объём рабочей информации фиксируется в единой системе. Каждый сотрудник может ознакомиться с ходом задач в удобное для себя время. В командах внедрён процесс передачи смены, а также используются «окна пересечения времени», когда утро у восточной команды совпадает с концом рабочего дня в центральном регионе (и наоборот). В эти периоды проводятся синхронные встречи: совместные обсуждения, анализ проблем и экстренные совещания при инцидентах.
Найти квалифицированных специалистов за пределами центральных регионов и крупных городов возможно, но это достаточно сложно.
Благодаря слаженной работе с нашей HR-командой, мы за несколько месяцев смогли подобрать сразу несколько специалистов. Процесс занял немного больше времени, чем при поиске в центральном регионе, но в целом оказался реализуемым.
Вы знаете, Денис отошёл, но я передам ему ваш вопрос
Сейчас, с развитием ИИ и новым толчком, выглядит, что задача решаема, но как и писал выше это скорее новый инструмент для HR, который позволит с них снять рутину и облегчить их работу с фокусом на более важные дела.
Кстати, если я верно понял, то вы работаете РМ (project management) мы прямо сейчас проводим пилот по "карме" проектов, очень интересно получается и вижу сразу много возможностей для автоматизации с помощью ИИ-агентов в процессах управления проектами)
Если говорить о коммерческом применении подобных решений, то на рынке уже существуют аналоги, посмотрим насколько они будут успешны, на данный момент ни одна "машина" не заменит опытный взгляд рекрутера)
А у вас есть примеры таких решений? Или может даже опыт?
Не совсем так, доработки не потребовались, необходимо было внести контекст, а именно настроить способ и схему подключения, но сам код мы не правили.
На текущем этапе развития ИИ я считаю, что не может произойти полноценной замены, но однозначно необходимо менять подход к разработке.
Сегодня ИИ - не замена, а усилитель! Она не просто генерирует код, а сокращает путь от задачи к рабочему решению. То, что у инженера заняло бы 3–4 часа (поиск по API, анализ, написание скрипта), нейросеть делает за 10 минут с минимальными правками.
Что касается "отказа от джунов" — здесь важно не путать инструмент и процесс развития.
Да, рутину, которую раньше поручали джунам, теперь может делать ИИ:
Написание простых скриптов
Документирование
Поиск в базе знаний
Подготовка шаблонов
Но джун — это не тот, кто пишет скрипты. Джун — это тот, кто учится думать как инженер.
Нейросеть не заменит джунов — она освободит их от рутины и позволит быстрее стать настоящими инженерами.
А наша задача как команды — не отказываться от новых специалистов, а перестроить онбординг и развитие под новую реальность.
Будущее — не в том, чтобы не нанимать джунов, а в том, чтобы научить их управлять теми, кто (условно) "пишет код за них".
Я не исключаю, что когда-нибудь мы перейдём на такие БД, но Elasticsearch тоже умеет искать по векторам и пока нам полностью подходит под наши задачи.
В нашем случае пока проблема не в выборе БД, а в том, что мы загружаем, то есть как строим вектора.
Более того, мы после поиска в БД ещё и ранжируем результаты, то есть применяем дополнительный фильтр.
А почему у вас возник данный вопрос?
Сроки мы не скрываем ни от команды, ни от руководства компании. Есть статистика, есть метрики. То же касается и текучести кадров (менее 10% в год, если интересно), и других аспектов.
Тем не менее, нас есть за что критиковать и нам есть что улучшать. Я не считаю, что у нас все идеально, мы работаем и развиваемся дальше - про это написано в статье. Тем более, в тексте описан первый год, когда проблем было гораздо больше по сравнению с сейчас.
Отличный, важный и честный вопрос. Слово «нам» — не метафора. Я говорю именно о команде PS.
Что изменилось для рядовых инженеров:
1. Меньше рутины и хаоса . Раньше 70% времени уходило на «тушение пожаров». Теперь — на внедрение и развитие.
Меньше стресса, больше смысла в работе.
2. Прозрачность и предсказуемость
Стало понятно:
. Что делать
. Когда
. Зачем
. Кто за что отвечает
Люди интегрированы в процессы перестали чувствовать себя «винтиками».
3. Рост и развитие
Мы ввели:
. Онбординг с обратной связью
. Запустили матрицу зрелости 2.0
. Регулярные аттестации
Стало понятно, куда расти.
Сейчас в работе карьерная матрица и процедура оценки.
4. Обратная связь и признание
Раньше очень редко говорили: «спасибо, ты хорошо сделал». Теперь ретроспективы, благодарности, NPS — всё это часть открытой культуры.
Люди знают, что их слышат и видят.
5. Оклады и нагрузка
Да, оклады росли — по результатам аттестаций и рыночной корректировке.
А нагрузка?
. Интенсивность осталась высокой, но теперь она осознанная, а не хаотичная.
. Люди работают в потоке, а не «выгребают».
Итог: лучше стало не только бизнесу, но и тем, кто этот бизнес делает каждый день.
😄 Да, терпение у них — как у святых.
На самом деле, разработчики — это наши внутренние клиенты, и они могли бы просто сказать: «не будем помогать, это не наша задача», но они пошли навстречу, хотя:
. У них были свои дедлайны
. Они не обязаны были обучать нашу команду
. Им пришлось тратить время на объяснение базовых вещей
Мы это очень ценим!
И, честно, первые месяцы были не про «я пришёл и всё изменил», а про «я пришёл и попросил помощи».
Теперь, кстати, обратная связь пошла и в другую сторону — PS помогает разработке с тестированием в полях, частично с документированием и обратной связью от клиентов.
Это уже не помощь, а партнёрство.
Полностью согласен. На самом деле, именно субъективность — главный источник ценности в оценке командной работы.
Когда инженер пишет:
«Спринт был тяжёлым, но я наконец понял, как работает продукт» — это не просто оценка, это инсайт :)
А когда он пишет:
«Опять всё на последний день, не успеваю» — это не жалоба, это сигнал о проблеме в планировании.
Я сознательно не заменял субъективность метриками, а наоборот — научился её читать.
Теперь мы знаем:
Где люди устают
Где растёт экспертиза
Где нужно вмешаться до кризиса
Человеческий опыт — это не шум. Это сигнал. Главное — научиться его слышать.
Спасибо за вопрос — он очень точный.
Да, субъективность на первых этапах была огромной. Я не пыталась её убрать — я решил её структурировать.
Вот как это делали:
Ввели шкалу оценки спринта от 1 до 10:
10 - спринт прошёл чётко, все ключевые задачи выполнены, команда в потоке
..
5 - были сложности, но в целом по плану
..
1 — Всё плохо, хаос, срывы, команда выгорела
Каждая оценка сопровождалась комментарием: что именно пошло не так или что сработало хорошо.
Через 2–3 месяца стали сравнивать оценки и комментарии — и увидели паттерны: например, если 3 человека ставят «3» и пишут про «нехватку времени на онбординг» — это уже не субъективность, а сигнал.
Итог: мы не боролись с субъективностью, а сделали её частью системы сбора данных. Со временем она стала основой для объективных выводов.