Я не верила в фулстеков.
Когда кандидат писал в резюме “фулстек” — я читала это как “умею всё понемногу, но не умею ничего глубоко”. И очень часто это подтверждалось на интервью.
Фронт и бэк — это два разных мира с разной культурой мышления, разными паттернами и разной болью. Совместить их в одном человеке на высоком уровне казалось честной невозможностью.
Но с приходом AI, и по мере того как я сама набираю опыт работы с ним, — переобуваюсь.
Нейросеть стирает не навыки, она стирает стоимость переключения между контекстами. Раньше фулстек тратил большую часть времени на то, чтобы удерживать в голове оба мира одновременно. Сейчас AI держит контекст за тебя — и ты дирижируешь, а не исполняешь.
Фронт, бэк, база, DevOps — всё это становится доступным одному человеку на одинаково высоком уровне, потому что инструмент изменился.
Фулстек с AI — это уже не миф в резюме. И вопрос на собесе теперь звучит иначе: не “докажи что знаешь оба стека”, а “покажи как ты работаешь с AI”.
Когда кандидат писал в резюме “фулстек” — я читала это как “умею всё понемногу, но не умею ничего глубоко”. И очень часто это подтверждалось на интервью.
Фронт и бэк — это два разных мира с разной культурой мышления, разными паттернами и разной болью. Совместить их в одном человеке на высоком уровне казалось честной невозможностью.
Но с приходом AI, и по мере того как я сама набираю опыт работы с ним, — переобуваюсь.
Нейросеть стирает не навыки, она стирает стоимость переключения между контекстами. Раньше фулстек тратил большую часть времени на то, чтобы удерживать в голове оба мира одновременно. Сейчас AI держит контекст за тебя — и ты дирижируешь, а не исполняешь.
Фронт, бэк, база, DevOps — всё это становится доступным одному человеку на одинаково высоком уровне, потому что инструмент изменился.
Фулстек с AI — это уже не миф в резюме. И вопрос на собесе теперь звучит иначе: не “докажи что знаешь оба стека”, а “покажи как ты работаешь с AI”.
С приходом AI программисты теряют главное преимущество.
В разработке начинает выигрывать не тот, кто лучше пишет код, а тот, кто лучше проектирует систему.
К этому выводу я пришла на собственном опыте в процессе реализации своего продукта в стиле вайбкодинга: ставлю задачу нейросети — она генерирует код.
Казалось бы, идеальная схема: описываешь фичу и получаешь реализацию.
Но долгое время система не складывалась. Нейросеть писала код, интерфейс появлялся, функции работали. Но в какой-то момент каждый следующий шаг начал ломать предыдущий.
Проблема оказалась в архитектуре.
Я фактически отдала нейросети часть архитектурных решений: структуру данных, связи между сущностями и логику взаимодействия компонентов.
Нейросеть может предложить архитектуру, но делает это по своему усмотрению — исходя из вероятностей, а не из требований конкретного продукта. Поэтому её вариант совсем не обязан совпадать с тем, как система должна работать в реальности.
Только когда я остановилась и спроектировала систему целиком — модель данных, границы модулей и связи между компонентами — всё наконец начало складываться.
AI отлично пишет код, но направление системы всё равно задаёт человек.
И в этот момент становится очевидно: в AI-разработке выигрывает не тот, кто быстрее пишет код, а тот, кто лучше проектирует систему.
Значит ли это, что фронтендер, бэкендер, тестировщик, DevOps или дизайнер не смогут сделать свой проект?
Смогут. Небольшой сервис, MVP или проверку гипотезы сейчас действительно можно собрать с помощью AI.
Но когда речь заходит о сложных системах и развитии продукта, одной нейросети уже недостаточно. Кто-то должен держать систему в голове: модель данных, связи между компонентами, сценарии развития и масштабирования.
Нейросеть может писать код, но архитектуру ей всё равно должен объяснить человек.
И похоже, что в эпоху AI архитектурное мышление перестаёт быть узкой специализацией и становится базовым навыком инженера.
Интересно ваше мнение: какой бэкграунд сегодня даёт наибольшее преимущество при работе с AI в разработке?
P.S. Здесь вполне могла бы быть реклама курсов по архитектурному проектированию.
Но её не будет. 🙌
В разработке начинает выигрывать не тот, кто лучше пишет код, а тот, кто лучше проектирует систему.
К этому выводу я пришла на собственном опыте в процессе реализации своего продукта в стиле вайбкодинга: ставлю задачу нейросети — она генерирует код.
Казалось бы, идеальная схема: описываешь фичу и получаешь реализацию.
Но долгое время система не складывалась. Нейросеть писала код, интерфейс появлялся, функции работали. Но в какой-то момент каждый следующий шаг начал ломать предыдущий.
Проблема оказалась в архитектуре.
Я фактически отдала нейросети часть архитектурных решений: структуру данных, связи между сущностями и логику взаимодействия компонентов.
Нейросеть может предложить архитектуру, но делает это по своему усмотрению — исходя из вероятностей, а не из требований конкретного продукта. Поэтому её вариант совсем не обязан совпадать с тем, как система должна работать в реальности.
Только когда я остановилась и спроектировала систему целиком — модель данных, границы модулей и связи между компонентами — всё наконец начало складываться.
AI отлично пишет код, но направление системы всё равно задаёт человек.
И в этот момент становится очевидно: в AI-разработке выигрывает не тот, кто быстрее пишет код, а тот, кто лучше проектирует систему.
Значит ли это, что фронтендер, бэкендер, тестировщик, DevOps или дизайнер не смогут сделать свой проект?
Смогут. Небольшой сервис, MVP или проверку гипотезы сейчас действительно можно собрать с помощью AI.
Но когда речь заходит о сложных системах и развитии продукта, одной нейросети уже недостаточно. Кто-то должен держать систему в голове: модель данных, связи между компонентами, сценарии развития и масштабирования.
Нейросеть может писать код, но архитектуру ей всё равно должен объяснить человек.
И похоже, что в эпоху AI архитектурное мышление перестаёт быть узкой специализацией и становится базовым навыком инженера.
Интересно ваше мнение: какой бэкграунд сегодня даёт наибольшее преимущество при работе с AI в разработке?
P.S. Здесь вполне могла бы быть реклама курсов по архитектурному проектированию.
Но её не будет. 🙌
Почему на собеседования стоит ходить, даже когда не ищешь работу
Несколько лет я проводила собеседования, но сама на них не ходила. Казалось, в этом нет необходимости: проекты шли, работы было много, всё устраивало.
Такую ошибку совершает большинство. Я - не исключение
4 года без собеседований. Была загружена, проекты шли один за другим, всё устраивало. Зачем?
А когда вышла на рынок - столкнулась с реальностью. Сначала нужно пробиться через фильтр HR и AI-скрининга и если это удалось, первые 3–5 собеседований после долгого перерыва могут оказаться провальными не потому, что ты не умеешь работать, а потому, что навык самопрезентации без практики атрофируется.
Приглашения на интервью и так на вес золота каждое, так еще потеря первых и уверенности не добавит и самооценку может уронить ещё ниже.
Поэтому если давно не были на собеседованиях, стоит сначала потренироваться, например:
- с AI-ассистентом: попросить провести карьерный разбор, отыграть интервью, задать вам неудобные вопросы
- с живым человеком — бывшим коллегой, руководителем, если отношения позволяют
- найти карьерного коуча — это тоже инвестиция, а не роскошь в современных реалиях 🙌
Вывод: собеседование раз в полгода — это гигиена карьеры: калибровка с рынком, обмен опытом и поддержание формы.
А вы когда последний раз были на собеседовании до того, как начали искать работу?
Если давно — напишите в комментариях, устроим друг другу тренировочное интервью ❤️
Несколько лет я проводила собеседования, но сама на них не ходила. Казалось, в этом нет необходимости: проекты шли, работы было много, всё устраивало.
Такую ошибку совершает большинство. Я - не исключение
4 года без собеседований. Была загружена, проекты шли один за другим, всё устраивало. Зачем?
А когда вышла на рынок - столкнулась с реальностью. Сначала нужно пробиться через фильтр HR и AI-скрининга и если это удалось, первые 3–5 собеседований после долгого перерыва могут оказаться провальными не потому, что ты не умеешь работать, а потому, что навык самопрезентации без практики атрофируется.
Приглашения на интервью и так на вес золота каждое, так еще потеря первых и уверенности не добавит и самооценку может уронить ещё ниже.
Поэтому если давно не были на собеседованиях, стоит сначала потренироваться, например:
- с AI-ассистентом: попросить провести карьерный разбор, отыграть интервью, задать вам неудобные вопросы
- с живым человеком — бывшим коллегой, руководителем, если отношения позволяют
- найти карьерного коуча — это тоже инвестиция, а не роскошь в современных реалиях 🙌
Вывод: собеседование раз в полгода — это гигиена карьеры: калибровка с рынком, обмен опытом и поддержание формы.
А вы когда последний раз были на собеседовании до того, как начали искать работу?
Если давно — напишите в комментариях, устроим друг другу тренировочное интервью ❤️
Успевает ли рынок онлайн-образования за технологиями?
Российский EdTech вырос за 6 лет в 10 раз. 154 млрд рублей по итогам 2025 года (Smart Ranking, февраль 2026).
Давайте посмотрим на эти курсы глазами тимлидов, к котором придут выпускники этих курсов.
Курсы по вайбкодингу растут как грибы. Учат работать с Cursor, писать промпты, подключать API. Результат за две недели — готовый Telegram-бот.
Архитектура ПО? В лучшем случае шестой месяц полугодовой программы. Бонусом.
Спрос на базовые IT-курсы уже упал на 13% — рынок перенасыщен (Smart Ranking). Но вместо того чтобы поднять планку — рынок просто переклеил этикетку с “junior developer” на “вайб кодер”.
Исследователи это уже зафиксировали: вайбкодинг разрушает механизм формирования системного мышления и понимания архитектуры (TAdviser, 2025). Человек получает работающий код — но не понимает почему он работает и что сломается первым.
Курс по архитектуре ПО должен быть в базовой программе любого вайбкодера. Не бонусом. Не финальным модулем. Стартовой точкой.
Пока этого нет — джуны будут приходить на рынок с красивым инструментом и без понимания как им пользоваться по-настоящему.
По деньгам образование за технологиями успевает. По содержанию — нет.
Давайте поговорим 🙌
Вайбкодер без знания архитектуры — это специалист или дорогой генератор багов?
Российский EdTech вырос за 6 лет в 10 раз. 154 млрд рублей по итогам 2025 года (Smart Ranking, февраль 2026).
Давайте посмотрим на эти курсы глазами тимлидов, к котором придут выпускники этих курсов.
Курсы по вайбкодингу растут как грибы. Учат работать с Cursor, писать промпты, подключать API. Результат за две недели — готовый Telegram-бот.
Архитектура ПО? В лучшем случае шестой месяц полугодовой программы. Бонусом.
Спрос на базовые IT-курсы уже упал на 13% — рынок перенасыщен (Smart Ranking). Но вместо того чтобы поднять планку — рынок просто переклеил этикетку с “junior developer” на “вайб кодер”.
Исследователи это уже зафиксировали: вайбкодинг разрушает механизм формирования системного мышления и понимания архитектуры (TAdviser, 2025). Человек получает работающий код — но не понимает почему он работает и что сломается первым.
Курс по архитектуре ПО должен быть в базовой программе любого вайбкодера. Не бонусом. Не финальным модулем. Стартовой точкой.
Пока этого нет — джуны будут приходить на рынок с красивым инструментом и без понимания как им пользоваться по-настоящему.
По деньгам образование за технологиями успевает. По содержанию — нет.
Давайте поговорим 🙌
Вайбкодер без знания архитектуры — это специалист или дорогой генератор багов?
💯1
В комментариях к моему посту про интервью зацепил коммент: «звёздюки базу знают, а токсины от них в команде, увы самопрезентация не выявит». Абсолютно согласна. И вот почему.
У меня был кандидат, который блестяще прошёл интервью.
Вся команда сказала — берём.
Через две недели — ни строчки кода, зато критики на всю команду. Но знаете что? Команда оказалась взрослее и сами разобрались с назначенными на токсика задачами.
И вот тут важное.
Токсик — это не тот, кто спорит.
Спор — это нормально.
Токсик — это тот, кто:
— не берёт ответственность
— не может сказать “я ошибся”
— объясняет провалы внешними причинами
— обесценивает чужие решения фразами вроде “ну это же очевидно”.
И да, можно отрепетировать “я командный игрок”, но на собеседовании всегда есть стресс, по которым проявляется паттерн.
Опыт плюс интуиция обычно не подводят. Иногда просто чувствую — не моё, а потом понимаю почему.
Я смотрю на всё сразу — и на ответы, и на реакцию:
— что происходит когда уточняешь
— как человек говорит о бывшей команде
— есть ли уважение к тем, кто слабее
Потому что один токсик — это не просто конфликт.
Это падение скорости работы команды.
А скорость — это деньги.
А вы как распознаёте сложных людей на входе? Есть свой приём — или доверяете интуиции? 👇
У меня был кандидат, который блестяще прошёл интервью.
Вся команда сказала — берём.
Через две недели — ни строчки кода, зато критики на всю команду. Но знаете что? Команда оказалась взрослее и сами разобрались с назначенными на токсика задачами.
И вот тут важное.
Токсик — это не тот, кто спорит.
Спор — это нормально.
Токсик — это тот, кто:
— не берёт ответственность
— не может сказать “я ошибся”
— объясняет провалы внешними причинами
— обесценивает чужие решения фразами вроде “ну это же очевидно”.
И да, можно отрепетировать “я командный игрок”, но на собеседовании всегда есть стресс, по которым проявляется паттерн.
Опыт плюс интуиция обычно не подводят. Иногда просто чувствую — не моё, а потом понимаю почему.
Я смотрю на всё сразу — и на ответы, и на реакцию:
— что происходит когда уточняешь
— как человек говорит о бывшей команде
— есть ли уважение к тем, кто слабее
Потому что один токсик — это не просто конфликт.
Это падение скорости работы команды.
А скорость — это деньги.
А вы как распознаёте сложных людей на входе? Есть свой приём — или доверяете интуиции? 👇
💯2🤔1
Где брать цифры для резюме?
Работодатели любят метрики.
Например такие вопросы на собеседованиях тимлидов звучат довольно регулярно:
— Сколько человек в команде владеют критичными частями системы?
— Какой % задач команда закрывает без твоего участия?
Вопросы логичные. Но возникает другая проблема — где брать эти цифры?
Несколько лет я вела метрики команды в Excel. В какой-то момент стало интересно сравнить себя с другими тимлидами. Но чужих данных нигде нет.
На длинных выходных я собрала небольшого бота с помощью Claude Code.
15 вопросов, около 5 минут — и в итоге получаешь:
— персонажа по каждому блоку
— примерную позицию среди тимлидов с командой такого же размера.
Персонажи шуточные, инсайты — иногда не очень 😄
У меня, например, в блоке «Здоровье команды» получился Реаниматолог. Совпало примерно на 70%.
Теперь интересно посмотреть статистику.
Какой вы тимлид?
Пройдите тест и делитесь в комментариях, что получилось.
Можно скрином или просто названием персонажа 🙌
Работодатели любят метрики.
Например такие вопросы на собеседованиях тимлидов звучат довольно регулярно:
— Сколько человек в команде владеют критичными частями системы?
— Какой % задач команда закрывает без твоего участия?
Вопросы логичные. Но возникает другая проблема — где брать эти цифры?
Несколько лет я вела метрики команды в Excel. В какой-то момент стало интересно сравнить себя с другими тимлидами. Но чужих данных нигде нет.
На длинных выходных я собрала небольшого бота с помощью Claude Code.
15 вопросов, около 5 минут — и в итоге получаешь:
— персонажа по каждому блоку
— примерную позицию среди тимлидов с командой такого же размера.
Персонажи шуточные, инсайты — иногда не очень 😄
У меня, например, в блоке «Здоровье команды» получился Реаниматолог. Совпало примерно на 70%.
Теперь интересно посмотреть статистику.
Какой вы тимлид?
Пройдите тест и делитесь в комментариях, что получилось.
Можно скрином или просто названием персонажа 🙌
👍1
Приоритеты в цифрах. Как считать.
Начинаю серию постов про управление приоритетами в команде разработки. Первый пост — про то, как перестать спорить с бизнесом и начать говорить на одном языке.
_
“Всё срочно” — говорит бизнес.
“Всё сложно” — говорит команда.
И обе стороны правы.
Проблема в том, что у каждого своя система координат — и общего языка нет.
Я долго приоритизировала бэклог на ощущениях. Пока не начала переводить это в цифры.
Формула называется WSJF — Weighted Shortest Job First.
Приоритет = (Ценность + Срочность + Риск) / Сложность
Как это работает: просим владельца продукта оценить каждую по ценности, срочности и риску — по шкале 1, 2, 3, 5, 8, 13. Оцениваем (самостоятельно или на грумминге с командой) сложность по той же шкале. Считаем приоритет по формуле выше.
[таблица картинкой в приложении к посту]
Результат часто неожиданный. Самая важная для бизнеса задача — не первая в очереди. Потому что дорогую сложную задачу иногда выгоднее отложить: пока её делаешь, закрываешь три простых с суммарно большей ценностью.
И когда показываешь это бизнесу в цифрах — споров становится меньше.
А как вы договариваетесь о приоритетах — на ощущениях или в цифрах?
Начинаю серию постов про управление приоритетами в команде разработки. Первый пост — про то, как перестать спорить с бизнесом и начать говорить на одном языке.
_
“Всё срочно” — говорит бизнес.
“Всё сложно” — говорит команда.
И обе стороны правы.
Проблема в том, что у каждого своя система координат — и общего языка нет.
Я долго приоритизировала бэклог на ощущениях. Пока не начала переводить это в цифры.
Формула называется WSJF — Weighted Shortest Job First.
Приоритет = (Ценность + Срочность + Риск) / Сложность
Как это работает: просим владельца продукта оценить каждую по ценности, срочности и риску — по шкале 1, 2, 3, 5, 8, 13. Оцениваем (самостоятельно или на грумминге с командой) сложность по той же шкале. Считаем приоритет по формуле выше.
[таблица картинкой в приложении к посту]
Результат часто неожиданный. Самая важная для бизнеса задача — не первая в очереди. Потому что дорогую сложную задачу иногда выгоднее отложить: пока её делаешь, закрываешь три простых с суммарно большей ценностью.
И когда показываешь это бизнесу в цифрах — споров становится меньше.
А как вы договариваетесь о приоритетах — на ощущениях или в цифрах?
👍1
НФТ. Их не видно, пока система не падает.
Нефункциональные требования — это то, что бизнес почти никогда не ставит в приоритет. Их нельзя показать на демо, за них не платят отдельно и в бэклоге всегда есть фичи «поважнее». До первого инцидента.
Один из моих ранних кейсов был как раз про это. Мы не заложили нагрузочное тестирование до старта MVP. Архитектор поднимал вопрос, но в бэклоге были фичи и жёсткий дедлайн. Перед релизом система не прошла нагрузочный тест. В итоге — два спринта рефакторинга и перенос релиза.
Команда понимала, почему так произошло, и это сильно помогло пройти через ситуацию без лишних конфликтов, но время уже было потеряно.
НФТ бывают очень разными: производительность и нагрузка, масштабируемость (особенно когда команда активно проверяет гипотезы), безопасность, наблюдаемость, сопровождаемость. Бизнес часто их не видит, потому что они не в интерфейсе: нет кнопки — нет ценности.
Интересно, как это устроено у вас. Кто в команде держит список нефункциональных требований — архитектор, тимлид или это появляется по мере необходимости?
Нефункциональные требования — это то, что бизнес почти никогда не ставит в приоритет. Их нельзя показать на демо, за них не платят отдельно и в бэклоге всегда есть фичи «поважнее». До первого инцидента.
Один из моих ранних кейсов был как раз про это. Мы не заложили нагрузочное тестирование до старта MVP. Архитектор поднимал вопрос, но в бэклоге были фичи и жёсткий дедлайн. Перед релизом система не прошла нагрузочный тест. В итоге — два спринта рефакторинга и перенос релиза.
Команда понимала, почему так произошло, и это сильно помогло пройти через ситуацию без лишних конфликтов, но время уже было потеряно.
НФТ бывают очень разными: производительность и нагрузка, масштабируемость (особенно когда команда активно проверяет гипотезы), безопасность, наблюдаемость, сопровождаемость. Бизнес часто их не видит, потому что они не в интерфейсе: нет кнопки — нет ценности.
Интересно, как это устроено у вас. Кто в команде держит список нефункциональных требований — архитектор, тимлид или это появляется по мере необходимости?
👍1
Продолжаем тему нефункциональных требований
Наверняка все знают о методологии OWASP — своде самых критичных уязвимостей веб-приложений. Не абстрактная теория, а конкретные места где системы ломаются чаще всего.
Собрала 5 карточек: типичные уязвимости и что закладывать на старте, чтобы потом не переделывать архитектуру.
Очевидно? Да. Но именно это забывают заложить до начала разработки.
Декомпозиция этих пунктов будет зависеть от вашего стека и инфраструктуры — универсального чеклиста нет. Это отправная точка для разговора с архитектором.
А у вас был случай когда безопасность закладывали уже после инцидента?
Наверняка все знают о методологии OWASP — своде самых критичных уязвимостей веб-приложений. Не абстрактная теория, а конкретные места где системы ломаются чаще всего.
Собрала 5 карточек: типичные уязвимости и что закладывать на старте, чтобы потом не переделывать архитектуру.
Очевидно? Да. Но именно это забывают заложить до начала разработки.
Декомпозиция этих пунктов будет зависеть от вашего стека и инфраструктуры — универсального чеклиста нет. Это отправная точка для разговора с архитектором.
А у вас был случай когда безопасность закладывали уже после инцидента?
❤2👍1
Почему НФТ не выживают в отдельном эпике в бэклоге и чему меня научили 2 спринта рефакторинга перед релизом.
После фейла с нагрузочным тестом перед релизом и двух спринтов на рефакторинг я перестала выносить НФТ отдельным эпиком.
Теперь закладываю при декомпозиции прямо внутри задачи на фичу. Отдельный эпик срезают первым, а у подзадачи внутри фичи есть шанс остаться в бэклоге. Но если бизнес смотрит в каждую строку — стоит договориться на берегу о том, что без этих задач никак. Совсем никак.
На такие задачи я закладываю 10–25% времени плюсом к базовой оценке в зависимости от сложности и требований.
Единственное условие: команда понимает что и зачем заложено. Иначе это просто раздутые оценки.
Как закладываете НФТ вы — явно или негласно?
После фейла с нагрузочным тестом перед релизом и двух спринтов на рефакторинг я перестала выносить НФТ отдельным эпиком.
Теперь закладываю при декомпозиции прямо внутри задачи на фичу. Отдельный эпик срезают первым, а у подзадачи внутри фичи есть шанс остаться в бэклоге. Но если бизнес смотрит в каждую строку — стоит договориться на берегу о том, что без этих задач никак. Совсем никак.
На такие задачи я закладываю 10–25% времени плюсом к базовой оценке в зависимости от сложности и требований.
Единственное условие: команда понимает что и зачем заложено. Иначе это просто раздутые оценки.
Как закладываете НФТ вы — явно или негласно?
🤔1
Аналитики и дизайнеры в спринте: в общем потоке или отдельно?
Мы делали и так, и так. Дизайн и аналитика шли в один спринт с разработкой — задачи начинали реализовывать синхронно.
Логично выглядело на бумаге. На практике — опасненько: пока выяснили все требования, пока отрисовали и описали — спринт заканчивался. Разработка шла параллельно с недооформленной документацией и как следствие сопровождалось кучей багов, а фактическое демо таких задач переезжало на следующий спринт.
Позже аналитики и дизайнеры ушли на 1–2 спринта вперёд, но формально всё велось в одном бэклоге. На демо показывали реализованные фичи и макеты проработанных на будущее фич. Но это вызывало много вопросов и негатива на демо - бизнес хочет видеть что уже работает, а не концепцию.
Это частая история и пока демо проводят "для своих", все понимают правила без слов, но при росте продукта и количестве стейкхолдеров, присутствующих на демо, процесс рассыпается.
А как устроено у вас?
Мы делали и так, и так. Дизайн и аналитика шли в один спринт с разработкой — задачи начинали реализовывать синхронно.
Логично выглядело на бумаге. На практике — опасненько: пока выяснили все требования, пока отрисовали и описали — спринт заканчивался. Разработка шла параллельно с недооформленной документацией и как следствие сопровождалось кучей багов, а фактическое демо таких задач переезжало на следующий спринт.
Позже аналитики и дизайнеры ушли на 1–2 спринта вперёд, но формально всё велось в одном бэклоге. На демо показывали реализованные фичи и макеты проработанных на будущее фич. Но это вызывало много вопросов и негатива на демо - бизнес хочет видеть что уже работает, а не концепцию.
Это частая история и пока демо проводят "для своих", все понимают правила без слов, но при росте продукта и количестве стейкхолдеров, присутствующих на демо, процесс рассыпается.
А как устроено у вас?
❤1
Аналитика в спринте: схема, которая работает
И это выделенный спринт на опережение. Пока команда закрывает техдолг — аналитики и дизайнеры уходят вперёд на 1–2 спринта.
Техдолг перестаёт быть простоем и становится окном. Раз в квартал такая синхронизация просто необходима каждой команде.
Плюс мне удобно вести задачи аналитиков и дизов на отдельной доске, изолированной от основного спринта. Никакой путаницы на демо и это "на новый од ещё не готово, это аналитика".
Формально можно держать всё в одном бэклоге, но отдельная доска для аналитики и дизайна — это не про инструмент, это про прозрачность процесса — и бизнесу и команде сразу очевидно, что реально в работе, а что в процессе подготовки.
Как у вас — аналитика живёт на общей доске или отдельно?
И это выделенный спринт на опережение. Пока команда закрывает техдолг — аналитики и дизайнеры уходят вперёд на 1–2 спринта.
Техдолг перестаёт быть простоем и становится окном. Раз в квартал такая синхронизация просто необходима каждой команде.
Плюс мне удобно вести задачи аналитиков и дизов на отдельной доске, изолированной от основного спринта. Никакой путаницы на демо и это "
Формально можно держать всё в одном бэклоге, но отдельная доска для аналитики и дизайна — это не про инструмент, это про прозрачность процесса — и бизнесу и команде сразу очевидно, что реально в работе, а что в процессе подготовки.
Как у вас — аналитика живёт на общей доске или отдельно?
❤1
Рынок сжимается. Бюджеты режут.
Нужен руководитель разработки, но нет бюджета на полную ставку? Подключусь проектно — через ИП, удалённо, приеду в офис, если вы в Краснодаре или Краснодарском крае.
Пять направлений, с которыми помогаю:
🔹 Запуск команды разработки с нуля
Соберу команду под задачу: в штат, из подрядчиков или смешанную (есть проверенные контакты подрядчиков). Настрою процессы и научу ими управлять — чтобы после моего ухода ничего не развалилось.
🔹 Антикризисное управление проектом
Диагностика, стабилизация, устранение блокеров, работа с техдолгом.
🔹 Технический найм
Провожу технические интервью, оцениваю кандидатов, помогаю закрывать позиции. Frontend, fullstack, QA.
🔹 Аудит процессов разработки
Найду, где теряется время, почему сроки не сходятся, что починить первым. Отчёт с рекомендациями.
🔹 Разработаю протопит продукта
От идеи до рабочего прототипа (вайб кодинг) с логикой, базой и интерфейсом.
Подробнее рассказала в карточках 🙌
Нужен руководитель разработки, но нет бюджета на полную ставку? Подключусь проектно — через ИП, удалённо, приеду в офис, если вы в Краснодаре или Краснодарском крае.
Пять направлений, с которыми помогаю:
🔹 Запуск команды разработки с нуля
Соберу команду под задачу: в штат, из подрядчиков или смешанную (есть проверенные контакты подрядчиков). Настрою процессы и научу ими управлять — чтобы после моего ухода ничего не развалилось.
🔹 Антикризисное управление проектом
Диагностика, стабилизация, устранение блокеров, работа с техдолгом.
🔹 Технический найм
Провожу технические интервью, оцениваю кандидатов, помогаю закрывать позиции. Frontend, fullstack, QA.
🔹 Аудит процессов разработки
Найду, где теряется время, почему сроки не сходятся, что починить первым. Отчёт с рекомендациями.
🔹 Разработаю протопит продукта
От идеи до рабочего прототипа (вайб кодинг) с логикой, базой и интерфейсом.
Подробнее рассказала в карточках 🙌
Каждый второй спринт — срыв scope
Это были мои первые полгода в управлении командой.
Не потому, что команда слабая или задачи сложные. А потому что я понятия не имела, сколько работы реально влезает в двухнедельный спринт.
Мне казалось: вот задачи, вот люди, вот дедлайн. Что тут может пойти не так?
Оказалось, всё.
Бизнес уточнит или расширил требования, а команда переоценила свои силы и вот scope и сроки плыли. Но и то, и другое — это навык, который нарабатывается со временем.
Сейчас процент сорванных спринтов меньше 20%. Не ноль, и никогда не будет ноль. Но разница между 50% и 20% — это уже управляемый процесс, а не тушение пожаров.
Что изменилось:
Первое: декомпозиция до старта. Мы перестали брать в спринт задачи формата «сделать фичу Х». Каждая задача дробится до уровня, где можно оценить и проверить по отдельности. Это больно и долго на планировании, зато спринт перестаёт быть чёрным ящиком.
Второе: буфер. 15–20% ёмкости спринта — на незапланированное. Не на конкретные задачи, а просто на то, что обязательно прилетит. Потому что оно ВСЕГДА прилетает.
Третье: защита объема спринта. Когда бизнес приходит с «надо срочно» посреди спринта — я не отказываю, а переключаю разговор на приоритеты: «давай, но скажи что выкинем». И градус давления сразу падает.
Четвёртое: команда стала точнее декомпозировать и оценивать задачи т.к. мы стали разбирать ретроспективы честно. Ошибся в оценке на два дня? Давай поймём почему, без обвинений. Через 3–4 спринта точность выросла как будто сама.
А 20%, которые остаются? Бизнес меняет приоритеты потому что рынок не ждёт и постоянно прилетают уточнения, которых не было на этапе аналитики. Или другие команды задерживают API, от которого зависит твоя задача. Идеальных условий не бывает.
Предсказуемость спринта — одна из метрик, по которой можно понять, как на самом деле работает поставка. Не velocity, которую легко подкрутить размером задач, а именно процент спринтов без срыва scope. Ни Jira, ни Яндекс Трекер эту метрику автоматически не считают — burndown покажет scope change внутри спринта, но накопленную статистику по спринтам придётся вести руками.
А у вас какой процент срывов? И что помогло его снизить?
Это были мои первые полгода в управлении командой.
Не потому, что команда слабая или задачи сложные. А потому что я понятия не имела, сколько работы реально влезает в двухнедельный спринт.
Мне казалось: вот задачи, вот люди, вот дедлайн. Что тут может пойти не так?
Оказалось, всё.
Бизнес уточнит или расширил требования, а команда переоценила свои силы и вот scope и сроки плыли. Но и то, и другое — это навык, который нарабатывается со временем.
Сейчас процент сорванных спринтов меньше 20%. Не ноль, и никогда не будет ноль. Но разница между 50% и 20% — это уже управляемый процесс, а не тушение пожаров.
Что изменилось:
Первое: декомпозиция до старта. Мы перестали брать в спринт задачи формата «сделать фичу Х». Каждая задача дробится до уровня, где можно оценить и проверить по отдельности. Это больно и долго на планировании, зато спринт перестаёт быть чёрным ящиком.
Второе: буфер. 15–20% ёмкости спринта — на незапланированное. Не на конкретные задачи, а просто на то, что обязательно прилетит. Потому что оно ВСЕГДА прилетает.
Третье: защита объема спринта. Когда бизнес приходит с «надо срочно» посреди спринта — я не отказываю, а переключаю разговор на приоритеты: «давай, но скажи что выкинем». И градус давления сразу падает.
Четвёртое: команда стала точнее декомпозировать и оценивать задачи т.к. мы стали разбирать ретроспективы честно. Ошибся в оценке на два дня? Давай поймём почему, без обвинений. Через 3–4 спринта точность выросла как будто сама.
А 20%, которые остаются? Бизнес меняет приоритеты потому что рынок не ждёт и постоянно прилетают уточнения, которых не было на этапе аналитики. Или другие команды задерживают API, от которого зависит твоя задача. Идеальных условий не бывает.
Предсказуемость спринта — одна из метрик, по которой можно понять, как на самом деле работает поставка. Не velocity, которую легко подкрутить размером задач, а именно процент спринтов без срыва scope. Ни Jira, ни Яндекс Трекер эту метрику автоматически не считают — burndown покажет scope change внутри спринта, но накопленную статистику по спринтам придётся вести руками.
А у вас какой процент срывов? И что помогло его снизить?
Штатная команда: когда все свои
Первый пост (и очень длинный) из серии про типы команд. Начну с классики — все в одной компании/группе компаний, один работодатель.
Кажется, это идеальная модель. На практике штатная команда даёт вещи, которые сложно получить в других моделях.
Но у любой модели есть цена. Хотя если команда распределённая — часовые пояса и доступы догонят и тут.
Сначала плюсы)
Всё внутри. Кодовая база, документация, архитектурные решения, экспертиза по продукту принадлежат компании. Единые стандарты качества, CI/CD и инфраструктура под контролем. Решения принимаются быстрее — не нужно согласовывать изменения с внешним подрядчиком. И команда живёт с последствиями своих решений поэтому техдолг не копится бесконтрольно.
Безопасность коммуникации. Вся переписка по продукту — внутри корпоративных средств. Меньше риск утечки, проще контролировать доступы.
Единая среда. Корпоративные мероприятия, общие стандарты разработки, одинаковые праздники и выходные. Снижает трение в ежедневной работе т.к. одни правила для всех.
Долгий и глубокий контекст. Нет резкого переключения между проектами — человек живёт в продукте месяцами. Но дело не только в коде. Корпоративная среда даёт понимание, для кого ты строишь. Я однажды ездила на площадку добычи нефти помогать проводить конкурс профмастерства. После того как познакомилась с мастерами, которые каждый день работают с планшетами — фраза «проектируем интерфейс под крупные руки операторов» перестала быть абстракцией. Всегда есть контекст, который сложно передать в ТЗ. (фото с той самой поездки. 2018г.)
Предсказуемость. Известна скорость каждого члена команды, кто в чём силён, можно планировать спринты точнее. Справедливости ради — в долгосрочных смешанных командах это тоже нарабатывается, но в штатных командах происходит быстрее.
Еще один бонус — имя компании. Правда, не у всех оно работает как магнит для найма, но если работает — закрывать позиции кратно легче.
Менторинг, обучение, рост грейдов — всё это имеет смысл, потому что человек остаётся в компании. По крайней мере, вероятность сохранить сотрудника выше. Риск «научился и ушёл» есть всегда, но в внутри компании есть возможность повлиять на среду, которая удерживает — от корпоративного обучения и ДМС до нематериальных вещей вроде причастности к продукту.
Но у инхауса есть своя цена.
Зависимость. Если ключевой человек уходит — уходит и контекст. Чем глубже погружение, тем больнее потеря.
Стоимость. Штатная команда — это не только зарплаты, это налоги, ДМС, оборудование, обучение. Для бизнеса это долгая инвестиция, и не каждый проект её оправдывает.
Скорость масштабирования. Нужно ещё два разработчика на следующий месяц? Это найм, онбординг и 2–4 месяца до продуктивности. В других моделях может быть быстрее (при определенных обстоятельствах).
А так же наличие штатных разработчиков не гарантирует качество кода. Если процесс ревью слабый/отсутствует, а грейды не калиброваны, то качество будет плавать независимо от модели команды.
Штат — это фундамент. Но фундамент работает, когда на нём строят осознанно, а не "как пойдет".
Следующий пост будет про смешанные команды, где штатные разработчики и подрядчики работают бок о бок.
Какая у вас модель? Полный инхаус, миксуете или полный аутсорс?
Первый пост (и очень длинный) из серии про типы команд. Начну с классики — все в одной компании/группе компаний, один работодатель.
Кажется, это идеальная модель. На практике штатная команда даёт вещи, которые сложно получить в других моделях.
Но у любой модели есть цена. Хотя если команда распределённая — часовые пояса и доступы догонят и тут.
Сначала плюсы)
Всё внутри. Кодовая база, документация, архитектурные решения, экспертиза по продукту принадлежат компании. Единые стандарты качества, CI/CD и инфраструктура под контролем. Решения принимаются быстрее — не нужно согласовывать изменения с внешним подрядчиком. И команда живёт с последствиями своих решений поэтому техдолг не копится бесконтрольно.
Безопасность коммуникации. Вся переписка по продукту — внутри корпоративных средств. Меньше риск утечки, проще контролировать доступы.
Единая среда. Корпоративные мероприятия, общие стандарты разработки, одинаковые праздники и выходные. Снижает трение в ежедневной работе т.к. одни правила для всех.
Долгий и глубокий контекст. Нет резкого переключения между проектами — человек живёт в продукте месяцами. Но дело не только в коде. Корпоративная среда даёт понимание, для кого ты строишь. Я однажды ездила на площадку добычи нефти помогать проводить конкурс профмастерства. После того как познакомилась с мастерами, которые каждый день работают с планшетами — фраза «проектируем интерфейс под крупные руки операторов» перестала быть абстракцией. Всегда есть контекст, который сложно передать в ТЗ. (фото с той самой поездки. 2018г.)
Предсказуемость. Известна скорость каждого члена команды, кто в чём силён, можно планировать спринты точнее. Справедливости ради — в долгосрочных смешанных командах это тоже нарабатывается, но в штатных командах происходит быстрее.
Еще один бонус — имя компании. Правда, не у всех оно работает как магнит для найма, но если работает — закрывать позиции кратно легче.
Менторинг, обучение, рост грейдов — всё это имеет смысл, потому что человек остаётся в компании. По крайней мере, вероятность сохранить сотрудника выше. Риск «научился и ушёл» есть всегда, но в внутри компании есть возможность повлиять на среду, которая удерживает — от корпоративного обучения и ДМС до нематериальных вещей вроде причастности к продукту.
Но у инхауса есть своя цена.
Зависимость. Если ключевой человек уходит — уходит и контекст. Чем глубже погружение, тем больнее потеря.
Стоимость. Штатная команда — это не только зарплаты, это налоги, ДМС, оборудование, обучение. Для бизнеса это долгая инвестиция, и не каждый проект её оправдывает.
Скорость масштабирования. Нужно ещё два разработчика на следующий месяц? Это найм, онбординг и 2–4 месяца до продуктивности. В других моделях может быть быстрее (при определенных обстоятельствах).
А так же наличие штатных разработчиков не гарантирует качество кода. Если процесс ревью слабый/отсутствует, а грейды не калиброваны, то качество будет плавать независимо от модели команды.
Штат — это фундамент. Но фундамент работает, когда на нём строят осознанно, а не "как пойдет".
Следующий пост будет про смешанные команды, где штатные разработчики и подрядчики работают бок о бок.
Какая у вас модель? Полный инхаус, миксуете или полный аутсорс?
Аутстафф: одна команда, два работодателя
Второй пост из серии про типы команд.
Теперь про модель, где часть команды — в штате, а часть — от подрядчика. Пропорция может быть любой: от пары подрядчиков в штатной команде до полного аутстаффа, где в штате только тимлид.
Это самая распространённая модель в крупных компаниях. И самая коварная потому что выглядит как единая команда, а управляется как две.
Зачем вообще миксуют. Бизнесу нужна скорость — штатный найм не успевает. Или бюджет выделен на проект, а не на расширение штата. Или нужна экспертиза, которой внутри нет. Причины разные, результат один — в твоём спринте сидят люди с разными работодателями.
Что работает
Скорость старта. Подрядчики закрывают дефицит быстрее, чем найм в штат. Подрядчик выделяет специалиста из своего штата или ищет на рынке, принимая на себя все риски — вплоть до отказа кандидата на этапе оффера. Но профили ролей и описание вакансии готовит заказчик — это важный момент, который часто упускают.
Гибкость. Нужно усилить команду на три месяца под релиз — подрядчики. Без расширения штата и долгосрочных обязательств.
Свежий взгляд. Люди из других проектов приносят практики, о которых инхаус-команда могла не знать.
Где обычно болит.
Два контекста. Штатные знают продукт глубоко, подрядчики — поверхностно. Со временем разрыв растёт, если с ним не работать.
Разная мотивация. Штатный думает о продукте на горизонте года. Подрядчик — о текущем контракте. Это влияет на решения в коде. Техдолг оставляет тот, кто не будет с ним жить.
Двойное управление. У подрядчика есть свой линейный руководитель, свои процессы согласования отпусков, свои правила. Тимлиду нужно выстроить отношения не только с командой, но и с ресурсными менеджерами на стороне подрядчика. И не формально, а так, чтобы тебя слышали.
Операционка множится. Таблица отпусков, отгулов, контактов на случай экстренной связи, рискует переехать во внешний контур, потому что вести две неудобно, хотя команда как будто одна. Важно с самого начала организовать единый инфраструктурный слой — хранилище кода, CI/CD, трекер, вики. Это можно разместить как на мощностях заказчика, так и на стороне подрядчика. Обычно выбирают где проще и дешевле.
Code review. Стандарты кода у штатных и подрядчиков часто разные. Без жёстких гайдлайнов и линтеров — ревью превращается в бесконечный пинг-понг.
Как с этим жить
Тех-лиды в штат при наличии бюджета. Это люди, которые держат архитектуру и стандарты. Эти же люди потом садятся на третью линию поддержки. Так формируется сильное ядро внутри — что всегда в плюс. Но это не значит, что подрядчики пилят только простые задачи! Распределение должно быть по компетенциям, а не по типу договора.
Единые стандарты кода — не рекомендация, а требование.
Онбординг для подрядчиков — такой же, как для штатных.
Тимлид — в штате заказчика. Это не обсуждается. Человек, который управляет поставкой, должен быть внутри.
Код — заказчику. Об этом договариваются на старте, а не при расставании. Хранилище на стороне заказчика, версионность обязательна и вся экспертиза и кодовая база остаются внутри, даже если пишут её подрядчики.
Остальное — выстраивание коммуникации с ресурсными менеджерами, формат административного взаимодействия, шаблоны и чеклисты — это уже операционный слой, который я раскрываю в закрытых материалах.
Следующий пост про аутсорс — когда проект передают в разработку целиком.
А у вас как — штатные и подрядчики сработались или живут параллельно?
Второй пост из серии про типы команд.
Теперь про модель, где часть команды — в штате, а часть — от подрядчика. Пропорция может быть любой: от пары подрядчиков в штатной команде до полного аутстаффа, где в штате только тимлид.
Это самая распространённая модель в крупных компаниях. И самая коварная потому что выглядит как единая команда, а управляется как две.
Зачем вообще миксуют. Бизнесу нужна скорость — штатный найм не успевает. Или бюджет выделен на проект, а не на расширение штата. Или нужна экспертиза, которой внутри нет. Причины разные, результат один — в твоём спринте сидят люди с разными работодателями.
Что работает
Скорость старта. Подрядчики закрывают дефицит быстрее, чем найм в штат. Подрядчик выделяет специалиста из своего штата или ищет на рынке, принимая на себя все риски — вплоть до отказа кандидата на этапе оффера. Но профили ролей и описание вакансии готовит заказчик — это важный момент, который часто упускают.
Гибкость. Нужно усилить команду на три месяца под релиз — подрядчики. Без расширения штата и долгосрочных обязательств.
Свежий взгляд. Люди из других проектов приносят практики, о которых инхаус-команда могла не знать.
Где обычно болит.
Два контекста. Штатные знают продукт глубоко, подрядчики — поверхностно. Со временем разрыв растёт, если с ним не работать.
Разная мотивация. Штатный думает о продукте на горизонте года. Подрядчик — о текущем контракте. Это влияет на решения в коде. Техдолг оставляет тот, кто не будет с ним жить.
Двойное управление. У подрядчика есть свой линейный руководитель, свои процессы согласования отпусков, свои правила. Тимлиду нужно выстроить отношения не только с командой, но и с ресурсными менеджерами на стороне подрядчика. И не формально, а так, чтобы тебя слышали.
Операционка множится. Таблица отпусков, отгулов, контактов на случай экстренной связи, рискует переехать во внешний контур, потому что вести две неудобно, хотя команда как будто одна. Важно с самого начала организовать единый инфраструктурный слой — хранилище кода, CI/CD, трекер, вики. Это можно разместить как на мощностях заказчика, так и на стороне подрядчика. Обычно выбирают где проще и дешевле.
Code review. Стандарты кода у штатных и подрядчиков часто разные. Без жёстких гайдлайнов и линтеров — ревью превращается в бесконечный пинг-понг.
Как с этим жить
Тех-лиды в штат при наличии бюджета. Это люди, которые держат архитектуру и стандарты. Эти же люди потом садятся на третью линию поддержки. Так формируется сильное ядро внутри — что всегда в плюс. Но это не значит, что подрядчики пилят только простые задачи! Распределение должно быть по компетенциям, а не по типу договора.
Единые стандарты кода — не рекомендация, а требование.
Онбординг для подрядчиков — такой же, как для штатных.
Тимлид — в штате заказчика. Это не обсуждается. Человек, который управляет поставкой, должен быть внутри.
Код — заказчику. Об этом договариваются на старте, а не при расставании. Хранилище на стороне заказчика, версионность обязательна и вся экспертиза и кодовая база остаются внутри, даже если пишут её подрядчики.
Остальное — выстраивание коммуникации с ресурсными менеджерами, формат административного взаимодействия, шаблоны и чеклисты — это уже операционный слой, который я раскрываю в закрытых материалах.
Следующий пост про аутсорс — когда проект передают в разработку целиком.
А у вас как — штатные и подрядчики сработались или живут параллельно?
❤1👍1