О чем канал
Про управление командами, технический менеджмент и AI — без теории, только живой опыт и немного личной жизни
Про меня
15 лет в индустрии, 5 из них руковожу командами до 13 человек. Прошла путь от инженера до тимлида внутри корпоративной среды и знаю изнутри, как ломаются процессы, выгорают разработчики и буксуют релизы, т.к. сама через это проходила и училась чинить.
Работаю как внешний руководитель:
— Беру команду в кризисе и за 2–3 месяца возвращаю в рабочий ритм
— Запускаю разработку с нуля: технический найм, процессы, первый релиз
— Тюнингую процессы в действующих командах: аудит и точки роста
За плечами 400+ технических интервью, вывод продуктов в продакшен с нуля, перехват проектов у внешних подрядчиков. Работала в нефтегазе, финтехе, интерактивных инсталляциях.
Открыта к сотрудничеству с фаундерами и СЕО, которым нужен опытный технарь-управленец на парт-тайм или проектно.
Активно работаю с AI-ассистентами в разработке и помогаю командам встроить их в рабочий процесс без хаоса и потери качества.
Где нахожусь
Краснодар
Про управление командами, технический менеджмент и AI — без теории, только живой опыт и немного личной жизни
Про меня
15 лет в индустрии, 5 из них руковожу командами до 13 человек. Прошла путь от инженера до тимлида внутри корпоративной среды и знаю изнутри, как ломаются процессы, выгорают разработчики и буксуют релизы, т.к. сама через это проходила и училась чинить.
Работаю как внешний руководитель:
— Беру команду в кризисе и за 2–3 месяца возвращаю в рабочий ритм
— Запускаю разработку с нуля: технический найм, процессы, первый релиз
— Тюнингую процессы в действующих командах: аудит и точки роста
За плечами 400+ технических интервью, вывод продуктов в продакшен с нуля, перехват проектов у внешних подрядчиков. Работала в нефтегазе, финтехе, интерактивных инсталляциях.
Открыта к сотрудничеству с фаундерами и СЕО, которым нужен опытный технарь-управленец на парт-тайм или проектно.
Активно работаю с AI-ассистентами в разработке и помогаю командам встроить их в рабочий процесс без хаоса и потери качества.
Где нахожусь
Краснодар
10 лет в одной компании. Двое детей. И вот — «мы в ваших услугах больше не нуждаемся.»
Узнала об этом в середине отпуска. Прямо в тот момент, когда должна была отдыхать.
Я прошла все стадии — отрицание, злость, торг, депрессию. Тревожность никуда не делась, но в какой-то момент я поняла: можно бояться и действовать одновременно.
Самым сложным оказалось не профессиональное — не срываться на детях и не показывать близким насколько страшно внутри. Справилась. Почти.
Но именно эта ситуация заставила меня сделать то, что я откладывала годами — честно разобраться кто я и чего стою на рынке.
Оказалось, что я сильно себя недооценивала. 10 лет, 9 проектов, 400+ интервью — это не “ну я просто тимлид”. Это опыт, за который платят нормальные деньги.
Параллельно я вспомнила про идею которая родилась год назад — своя разработка. CRM для байеров которые закупают товары в Китае. Я сама прошла обучение закупкам и увидела боль: нормального инструмента учёта просто не существует.
6 месяцев с ChatGPT — сложно, бросила. 4 месяца дозревания. 2 дня с Claude Code — и MVP живёт. Когда оно заработало — я почувствовала азарт. Тот самый, который давно не чувствовала на работе
Я Engineering Manager, которая прошла путь от нуля в IT до тимлида — через frontend разработку уровня синьор. Именно этот бэкграунд даёт мне возможность понимать продукт изнутри, мыслить системно и ставить задачи так, чтобы они работали и не останавливаться когда страшно.
Буду строить продукт и писать про это честно — про ошибки, инсайты и то каково это, когда тебе 39, двое детей и ты начинаешь что-то своё с нуля.
Если интересно — подписывайтесь. Скучно не будет. 😏
Узнала об этом в середине отпуска. Прямо в тот момент, когда должна была отдыхать.
Я прошла все стадии — отрицание, злость, торг, депрессию. Тревожность никуда не делась, но в какой-то момент я поняла: можно бояться и действовать одновременно.
Самым сложным оказалось не профессиональное — не срываться на детях и не показывать близким насколько страшно внутри. Справилась. Почти.
Но именно эта ситуация заставила меня сделать то, что я откладывала годами — честно разобраться кто я и чего стою на рынке.
Оказалось, что я сильно себя недооценивала. 10 лет, 9 проектов, 400+ интервью — это не “ну я просто тимлид”. Это опыт, за который платят нормальные деньги.
Параллельно я вспомнила про идею которая родилась год назад — своя разработка. CRM для байеров которые закупают товары в Китае. Я сама прошла обучение закупкам и увидела боль: нормального инструмента учёта просто не существует.
6 месяцев с ChatGPT — сложно, бросила. 4 месяца дозревания. 2 дня с Claude Code — и MVP живёт. Когда оно заработало — я почувствовала азарт. Тот самый, который давно не чувствовала на работе
Я Engineering Manager, которая прошла путь от нуля в IT до тимлида — через frontend разработку уровня синьор. Именно этот бэкграунд даёт мне возможность понимать продукт изнутри, мыслить системно и ставить задачи так, чтобы они работали и не останавливаться когда страшно.
Буду строить продукт и писать про это честно — про ошибки, инсайты и то каково это, когда тебе 39, двое детей и ты начинаешь что-то своё с нуля.
Если интересно — подписывайтесь. Скучно не будет. 😏
400+ интервью. Я научилась закрывать позицию за 5 минут
Звучит жёстко. Но когда проект нужен вчера, тратить 1,5 часа команды на человека который не подходит — непозволительная роскошь.
Схема простая: самопрезентация + один вопрос. Если человек не отвечает — пишу в командный чат, сворачиваемся.
Вопрос должен быть не про опыт и не про резюме — про hard skills. Тот минимум который кандидат не имеет права не знать на своём грейде.
Вот мои вопросы для кросс-функциональной команды веб-разработки:
Аналитик (мидл): Спроектируй базу — авторы, книги, магазины, продажи. 5 таблиц. Сразу видно — человек думает системно или рисует таблицы наугад.
Тестировщик (джун): Как определяешь — баг на фронте или на бэке? Простой вопрос, но сразу понятно есть ли понимание архитектуры.
Frontend (джун): Что такое OPTIONS-запрос и почему браузер его отправляет? Если не знает CORS — первый совместный дебаг с бэком превратится в часовой квест.
Backend (синьор): Что такое идемпотентность и почему это важно в API? Один вопрос который делит кандидатов на тех кто проектирует системы и тех кто просто пишет эндпоинты.
Дизайнер (джун): Бизнес просит аккордеон. Твои действия? Правильный ответ начинается не с Figma — а с вопроса “зачем”.
И универсальный для любой роли в 2026 году:
Ты используешь AI в работе. Как проверяешь что результат правильный? Ищу не инструмент — ищу того кто думает, а не доверяет слепо.
Это не про жёсткость. Это про уважение к времени — и к кандидату тоже. Лучше честные 5 минут чем полтора часа ложных надежд.
У меня есть полный чеклист по всем ролям и грейдам. Если нужен — пишите в личку, поделюсь. 🙌
Звучит жёстко. Но когда проект нужен вчера, тратить 1,5 часа команды на человека который не подходит — непозволительная роскошь.
Схема простая: самопрезентация + один вопрос. Если человек не отвечает — пишу в командный чат, сворачиваемся.
Вопрос должен быть не про опыт и не про резюме — про hard skills. Тот минимум который кандидат не имеет права не знать на своём грейде.
Вот мои вопросы для кросс-функциональной команды веб-разработки:
Аналитик (мидл): Спроектируй базу — авторы, книги, магазины, продажи. 5 таблиц. Сразу видно — человек думает системно или рисует таблицы наугад.
Тестировщик (джун): Как определяешь — баг на фронте или на бэке? Простой вопрос, но сразу понятно есть ли понимание архитектуры.
Frontend (джун): Что такое OPTIONS-запрос и почему браузер его отправляет? Если не знает CORS — первый совместный дебаг с бэком превратится в часовой квест.
Backend (синьор): Что такое идемпотентность и почему это важно в API? Один вопрос который делит кандидатов на тех кто проектирует системы и тех кто просто пишет эндпоинты.
Дизайнер (джун): Бизнес просит аккордеон. Твои действия? Правильный ответ начинается не с Figma — а с вопроса “зачем”.
И универсальный для любой роли в 2026 году:
Ты используешь AI в работе. Как проверяешь что результат правильный? Ищу не инструмент — ищу того кто думает, а не доверяет слепо.
Это не про жёсткость. Это про уважение к времени — и к кандидату тоже. Лучше честные 5 минут чем полтора часа ложных надежд.
У меня есть полный чеклист по всем ролям и грейдам. Если нужен — пишите в личку, поделюсь. 🙌
Этот вопрос мне задали на собеседовании. Я задумалась — и поняла, что у меня есть чёткий ответ.
Многие идут к тимлиду. Или к самому опытному разработчику. Я всегда иду к… расскажу в конце поста 😉
Однажды меня пригласили на проект с интересной задачей — разобраться в процессах и найти узкие места. Люди в команде опытные, сервис работает.
Но чего-то не хватало (правильного процесса) — и команда раз за разом чинила баги, которые порождали новые баги. Фичи застревали.
Первую неделю — только наблюдение за внутренней коммуникацией, сначала нужна была общая картина.
И вот первый разговор one-2-one с тестировщиком — и мы идём смотреть систему вместе.
Тестировщик всегда знает про проект то, чего нет ни в одном документе: какая логика живёт только в головах людей, где баг давно маскируется под фичу — и все уже привыкли, а где формально всё работает, но вопросы остаются.
За несколько таких разговоров появилась реальная картина проекта. Не официальная, а живая.
Именно с этого началась настоящая работа.
Один из секретов успеха в таких вызовах - начать общение с того, кто знает, где болит.
P.S. Тот вопрос мне задали на собеседовании. Лишний раз убедилась — на собесы стоит ходить даже когда не ищешь работу. Но это уже отдельная история. 😏
Многие идут к тимлиду. Или к самому опытному разработчику. Я всегда иду к… расскажу в конце поста 😉
Однажды меня пригласили на проект с интересной задачей — разобраться в процессах и найти узкие места. Люди в команде опытные, сервис работает.
Но чего-то не хватало (правильного процесса) — и команда раз за разом чинила баги, которые порождали новые баги. Фичи застревали.
Первую неделю — только наблюдение за внутренней коммуникацией, сначала нужна была общая картина.
И вот первый разговор one-2-one с тестировщиком — и мы идём смотреть систему вместе.
Тестировщик всегда знает про проект то, чего нет ни в одном документе: какая логика живёт только в головах людей, где баг давно маскируется под фичу — и все уже привыкли, а где формально всё работает, но вопросы остаются.
За несколько таких разговоров появилась реальная картина проекта. Не официальная, а живая.
Именно с этого началась настоящая работа.
Один из секретов успеха в таких вызовах - начать общение с того, кто знает, где болит.
P.S. Тот вопрос мне задали на собеседовании. Лишний раз убедилась — на собесы стоит ходить даже когда не ищешь работу. Но это уже отдельная история. 😏
Я не верила в фулстеков.
Когда кандидат писал в резюме “фулстек” — я читала это как “умею всё понемногу, но не умею ничего глубоко”. И очень часто это подтверждалось на интервью.
Фронт и бэк — это два разных мира с разной культурой мышления, разными паттернами и разной болью. Совместить их в одном человеке на высоком уровне казалось честной невозможностью.
Но с приходом 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