Менеджмент

Как я учу английский каждый день? Или как сделать погружение в английский в течении дня. 

Моя цель - говорить на английском как native. Поэтому ежедневно я максимально стараюсь погрузить себя в язык. 

В мини видео (залила в телеграм) показала 3 вещи, которые я делаю ежедневно для улучшения английского. Но это не все, вот полный список:

1. Начинаю день с практики Speaking - говорю перед камерой на любую интересную мне тему или просто рассказываю, что делала вчера и планы на сегодня. 

Зачем? Учишься говорить быстрее, активирует словарный запас, проходит страх говорить. Отдельный бонус - тренирует работу перед камерой. 

Я разговариваю с людьми на английском в течении дня, но не так много, поэтому добавляю практику Speaking.

Время: 10-20 минут ежедневно. За неделю это 60 минут - 2 полноценных урока с преподавателем (так как на уроке вы обычно говорите и слушаете 50/50). 

2. Пишу на английском - переписка с ChatGPT, планы на день, мысли. Тренирует письменный английский, ну и на речь тоже влияет. 

Время: Практика нативно вшита в день - я просто пишу, когда мне нужно, поэтому отдельного времени или усилий не требуется. 

3. Смотрю и слушаю на английском - TV, Youtube. Тренирует понимание английской речи и разных акцентов на слух. Еще давно пришлось отказаться и заменить блогеров на русском на английский язык. 

Время: Аналогично не требует выделенного времени. Когда ем или в свободное время - смотрю ютьюб или сериал, сейчас The Office, Gossip Girl. 

4. Делаю shadowing практику - пытаюсь повторить акцент за носителем языка. Тренирует произношение, интонацию и восприятие речи на слух. Shadowing начала делать относительно недавно (5 месяцев назад). 

Сначала повторяла за этим блоггером с британским акцентом - Thinking in English, сейчас миксую его и повторение за актерами сериала Gossip Girl (американский акцент). 

Время: 20-30 минут в день. По факту слушаешь интересный подкаст или смотришь сериал и повторяешь - то есть для меня совмещаешь приятное с полезным. 

5. Делаю 3-5 упражнений из Duolingo - хорощо для изучения новых слов и связок и повторения слов, которые редко используешь и они забываются. 

Время: 15 минут в день. 

6. Читаю на английском - в основном это переписка с нейросетью. На выходных читаю книгу.  

Если читать ответы нейросети на английском сложно - можно попросить ее отвечать на вашем уровне английского (более понятно и простыми словами). 

Время: в процессе работы, не требует специально выделенного времени. 

7. Грамматика запоминается хорошо в процессе слушания, чтения и тп. Но делая все вышеперечисленное все равно возникают вопросы - как правильно сказать или построить предложение и почему. С этими вопросами иду к ChatGPT.  

Время: по мере возникновения вопросов. 

Подходит ли это все новичку? Наверное учителя скажут, что не подходит. Но я начала делать большинство из вышеперечисленного в первый же год изучения. Заметила также, что полиглоты (те, кто знают много языков) именно так и учат языки - погружают себя в практику с первых же дней. Вдохновляюшие примеры - Steve Kaufmann и İclal. 

Kлючевое - это слушать, писать, читать, смотреть и т.д. то, что интересно, а не то что кто-то рекомендует, но вам это не нравится. И по большей части нативно встраивать английский язык в каждый день. Именно эти два принципа позволяют не воспринимать практику как упражнения.

Два типа решений которые я принимаю по-разному

Заметил за собой паттерн который долго не мог сформулировать.

Есть решения где нужно больше данных. И есть решения где больше данных не помогают - только откладывают.

Первый тип: технические и операционные решения. Какую платёжку подключить, как организовать онбординг, какой инструмент выбрать для аналитики. Здесь данные реально помогают. Можно посчитать, сравнить, проверить на маленькой выборке.

Второй тип: стратегические и продуктовые решения. Идти в этот сегмент или нет, запускать эту фичу или другую, нанимать этого человека или подождать. Здесь дополнительные данные почти никогда не меняют решение. Они только создают ощущение что ты думаешь а не откладываешь.

Разница которую я для себя нашёл: в первом типе данные снижают неопределённость. Во втором - они её маскируют. Неопределённость никуда не уходит, просто становится менее заметной за таблицами.

Сейчас когда ловлю себя на желании «собрать ещё данных» - спрашиваю: изменит ли следующая порция информации моё решение или я просто ищу повод не решать? Если честный ответ второе - принимаю решение с тем что есть.

Как вы разделяете у себя эти два типа?

От теории к практике: приглашаю на тренинг «Трудные Диалоги»

В статье «От «я знаю» к «я делаю» мы разобрали четыре препятствия, которые мешают нам перейти от знания к действию: иллюзия, что мы всё знаем; сопротивление принятию ответственности и признанию своей неспособности; неспособность сменить парадигму; власть старых привычек.

Особенно остро эти препятствия проявляются, когда речь идёт о навыках, овладение которыми одновременно вызывает сопротивление и дискомфорт, но при этом даёт нам ощутимые преимущества.
Умение вести трудные диалоги — как раз из таких.

Договориться с тем, кто с вами не согласен, когда эмоции зашкаливают, а на кону проект, карьера или отношения... А если другой человек — ваш руководитель, категоричный и властный. В такие моменты думать сложно, не то что действовать. Кажется, что научиться этому невозможно: слишком сильны старые привычки, слишком страшно сделать что-то не так.

Но это именно тот случай, когда системная методика и тренировка в безопасной среде действительно работают и делают невозможное возможным.
Приглашаю вас на очный тренинг «Трудные Диалоги», где вы сможете в этом убедиться.

Тренинг построен так, чтобы помочь вам пройти через каждое из четырёх препятствий на пути от нового знания к новым действиям.
Вы увидите реальный разрыв между тем, «как вы думаете, что говорите», и тем, «как вас на самом деле слышат».
Вы поймёте, что ваши привычные способы общения в сложных ситуациях не работают так, как вам хотелось бы, и сделаете первый шаг к изменениям.
Вы столкнётесь со своей привычной парадигмой («я прав - ты не прав») и увидите альтернативу — диалог как совместный поиск решения.
Вы многократно потренируете новые модели поведения, чтобы они постепенно начали замещать старые привычки.
На тренинге мы создаём пространство, где можно ошибаться, пробовать, получать обратную связь  - и уйти с готовым планом действий для реальных рабочих и личных ситуаций.

«Трудные Диалоги»/Crucial Conversations – один из самых востребованных soft skills тренингов в крупнейших IT-компаниях. Он входит в программы обучения Google, Facebook, Microsoft и Amazon и является важным компонентом Agile-трансформации.

Компания SmartValues - единственный обладатель лицензии на проведение «Трудных Диалогов» в России. С 2013 года мы с коллегами обучили более 5000 человек. Наблюдая за их результатами и учитывая свой личный опыт, я могу с уверенностью сказать, что «Трудные Диалоги» меняют жизнь к лучшему.

Тренинг состоится 22-23 августа 2026 года в Москве. Подробности и запись здесь.

Задавайте вопросы в комментариях – обязательно отвечу.

Проджект или Продакт?

В очередной раз столкнулся с тем, что человек из нашей айтишной индустрии не понимает разницы между продакт и проджект менеджерами. Типа ПМ и ПМ, не все ли равно. Поскольку приходилось мне бывать и в той и в другой роли, захотелось зафиксировать отличия этих популярных сейчас специальностей. Ну и может пригодится кому-нибудь, при выборе обучения например.

Менеджер проекта - человек, который управляет проектом, то есть чем-то, имеющим конкретные цели, сроки и бюджет. Проектом может быть что угодно, от создания презентации до постройки завода. Главное, что проект конечен и имеет плановую дату окончания, соблюдением которой менеджер вобщем-то и управляет. Поэтому основные компетенции здесь - хорошее умение планировать, способность делить работу на этапы и фиксировать их оценку, следить за качеством на промежуточных точках, организовывать работу команды. Необходимо правильно выяснять требования к проекту во всех подробностях, быть в диалоге с заказчиком и уметь эти требования донести до команды разработки на понятном ей языке (это могут делать аналитики, но на небольших проектах часто приходится менеджеру). Если в команде вдруг не хватает нужного специалиста, менеджер должен уметь его быстро найти. Из-за того, что проекты способны заканчиваться после выполнения, проджект может позаниматься в течение года несколькими совершенно разноплановыми проектами (а бывает, что и несколькими параллельно) и совершенно не заскучать.

Менеджер продукта управляет процессом развития продукта - то есть некоего артефакта, имеющего ценность на рынке. Продукт в этом подходе тоже понимается максимально широко - им может быть как конкретная модель автомобиля КАМАЗ, так и форма поиска на сайте популярного поисковика. Здесь от менеджера требуются другие компетенции, во многом завязанные на маркетинг. Поскольку продукт уже существует, и им пользуются живые люди, нужно уметь проводить исследования, выяснять потребности пользователей, придумывать новые фичи, расширять аудиторию за счет рекламы и других способов привлечения. И главное - добиваться того, чтобы продукт приносил ту пользу, для которой он был создан. То есть в большинстве случаев - чтобы зарабатывал деньги. В процессе этой деятельности менеджер продукта часто становится заказчиком проектного менеджера, поручая ему например разработку новой функциональности своего сервиса. Но если он совсем молодец, то может и самостоятельно поставить задачу команде разработки, а потом ее принять. Впрочем, это уже больше истории про человеков-оркестров )

Помимо описанных различий между двумя профессиями есть еще одно очень важное. Проектный менеджер живет и развивается в рамках своей отрасли - например, разработки мобильных приложений, где он хорошо знает технологии, людей, подходы к работе и т.п. Менеджер продукта должен хорошо знать не только правила развития и продвижения, но и ту отрасль, к которой относится его продукт. То есть если раньше вашим продуктом был информационный сервис для строителей, а потом стал информационный сервис для рестораторов, то вам конечно пригодится опыт постройки сервиса, но придется заново узнавать весь ресторанный рынок, его игроков, правила и истории успеха. А это может быть непросто. Ну и стоит сказать, что работа продакта - это больше про выстраивание процессов. И срок жизни продукта не задается изначально, как срок проекта, а может длиться гораздо дольше - пока продукт востребован рынком.

История о том как я РОМ искал в клининговую компанию очередного HR специалиста для массового подбора персонала, потому что предыдущая не могла закрыть вакансии (куча неразобранных откликов, куча пропущенных и только пустые слова что людей нет на рынке)

В тредс HR пишут о том что нужны сопроводительне письма обязательно и т. д. Куча требований что бы добраться до собеседования, тем временем откликающие HR, резюме как обрубки, ошибки, не доходят до собеседования (пропадают по дороге) просят много денег, а по факту ничего не могут. Я такого насмотрелся в резюме и на собеседованиях (так как я их вел) что у меня к направлению подбора персонала очень много вопросов. Зп HR была от 120 000 руб. на руки +kpi и это был 2023 год.

А еще они любят говорить о том что на рынке труда нет людей, при этом менеджера обьектов как-то сами закрывают вакансии, просто хотели снять эту нагрузку с менеджеров.

В итоге вакансию закрыл, но не на долго, проработала пол года и снова начали искать, потому что очередные обещания. (Если кто-то скажет что для подбора были низкие зп на обьектах, то я вам скажу что при расчете обьектов зп согласовывалась с ней, а что бы не было того что я такого не говорила, все согласование зп происходило в битрикс crm).

Как получить готовый план по оптимизации лагающего сайта с помощью аудита фронтенда

Привет! Я Рома Игнатович, лид фронтенд-разработки в Далее. Обычно задача «ускорить сайт» без конкретики превращается в перебор гипотез вслепую. PageSpeed тут не спасет, потому что он показывает только симптомы — например, низкую скорость загрузки, нестабильную вёрстку, задержку кликов, — но не причины. За одинаковыми цифрами может стоять что угодно, от тяжёлых картинок до медленного бэкенда. Поэтому вместо точечных проверок я использую аудит фронтенда — он сразу сужает область поиска и помогает быстро составить план по доработкам.

Как проходит аудит

Смотреть можно без доступа к коду, во вкладке Performance в DevTools. Берём ключевой сценарий (например, флоу покупки) и записываем performance trace: скролл, клики, переходы, ввод — ищем долгие таски, блокировки потока, просадки анимаций. Параллельно смотрим Network waterfall (какие запросы блокируют остальные), рантайм и три метрики Web Vitals: LCP, TTFB, CLS. Для мультирегиональных продуктов пригодится WebPageTest — показывает поведение сайта из разных точек и с разным качеством соединения.

Проверять стоит не только на мощной машине: CPU throttling (4–6x) имитирует медленное устройство и вскрывает лаги, а network throttling на 3G/4G показывает, насколько критичны тяжёлые изображения и порядок загрузки. Сценарии прогоняем дважды — в норме и с throttling; если с throttling сайт деградирует критично, это уже не техдолг, а прямые потери конверсии.

После прогона получаем список проблем — и они часто бывают типовыми. Задача не просто найти лаг, а быстро понять, в какой зоне он лежит: в загрузке, в интерфейсе или в логике приложения.

Типичные проблемы и варианты их решений

Загрузка и контент:

• весь код в одном бандле → браузер грузит и парсит всё сразу, плюс изображения по 20–30 МБ. Фикс: разбить на смысловые чанки, грузить по страницам и сценариям;

• устаревшие форматы вместо WebP/AVIF, нет адаптивных размеров (srcset), грузятся элементы за пределами вьюпорта. Фикс: современные форматы + lazy loading;

• высокий TTFB значит, что тормозит бэкенд, высокий LCP может быть где угодно. Фикс: проверяем бэкенд, настраиваем отправку первичного запроса при монтировании страницы.

Интерфейс и рендеринг:

• расчёт анимаций на CPU вместо GPU, свойства вроде width/height/top/left вместо transform — браузер пересчитывает layout. Фикс: transform/opacity, но без перебора с will-change;

• main thread перегружен синхронными операциями и тяжёлыми вычислениями. Фикс: распределять задачи параллельно, выносить тяжёлые операции из основного потока;

• layout shift — не зарезервировано место под контент, не заданы размеры изображений и блоков. Фикс: фиксировать размеры заранее, skeleton-заглушки.

От аудита к бэклогу

Такой аудит даёт гипотезы, которые ещё нужно перевести на язык задач. Формулирую каждую находку как цепочку: проблема → гипотеза → действие. Например:

• интерфейс подвисает при открытии карточки → долгие JS-задачи → разбить выполнение;

• анимация лагает → расчёты идут на CPU → перевести на GPU через transform;

• страница долго грузится → тяжёлые изображения → оптимизировать формат и размер.

У любой оптимизации — измеримая цель: например, LCP < 2.5 с, CLS < 0.1, снижение веса страницы на 30–40% и т. п.

Из действий собираю план: задачи ранжирую по эффекту и затраченным ресурсам — в приоритете то, что влияет на ключевые сценарии, конверсию и быстро чинится.

В итоге получается приоритизированный план с обоснованными гипотезами и задачами на доработку, который потом проверяется повторно — тестированием, бизнес-командой или новым техническим анализом.

Подробнее обо всех этапах пишу в большой статье на Workspace: читать здесь.

Ежедневные заметки

Мой опрос руководителей показал, что один из самых полезных инструментов тимлида — ежедневные заметки. Они позволяют вести список влетающих задач, записывать новую информацию, фиксировать возникающие идеи. Основная цель — выгрузить всё из головы и освободить её для новой информации.

В Obsidian для ведения ежедневных заметок пригодятся следующие плагины:

• Daily notes — позволяет одной кнопкой или сочетанием клавиш создать ежедневную заметку на сегодня.

• Periodic Notes — расширенная версия предыдущего плагина, умеющая помимо ежедневных создавать недельные, месячные, квартальные и годовые заметки.

• Calendar — простой календарик для быстрой навигации по ежедевным заметкам.

Ведёте ли вы ежедневник? Бумажный или электронный? Если второй, в какой программе? Чтоб обычно фиксируете в течение дня?

Как давать и принимать обратную связь


С обратной связью мы сталкиваемся постоянно: на встрече с руководителем, после презентации или просто при обсуждении задачи. Но даже полезный комментарий не всегда приводит к результату. Может не хватать конкретики, стороны могут по‑разному понимать ситуацию, а разговор — закончиться без ясного следующего шага.

Задача обратной связи — не определить, кто прав. Она помогает понять, что уже работает, что стоит изменить и как двигаться дальше.

Собрали несколько принципов для обеих сторон разговора: как принимать обратную связь и как давать ее с пользой.

🔸 Когда обратную связь дают вам

• Сначала уточните, о чем речь

Когда мы слышим замечание о своей работе, первая реакция часто — объяснить, почему получилось именно так. Но если в комментарии не хватает конкретики, можно начать спорить не с самой проблемой, а с тем, как мы ее поняли.

Поэтому сначала уточните, что именно человек заметил, где это проявилось и какого результата он ожидал.

Что именно стоит изменить?
Можешь привести пример?
Какого результата ты ожидал?

Чем конкретнее комментарий, тем проще понять, нужно ли что-то менять и что именно.

• Отделяйте наблюдение от оценки

Не вся обратная связь сформулирована удачно. Иногда вместо конкретной ситуации мы слышим вывод о себе или своих качествах.

«Ты невнимательный» — это оценка. За ней может стоять одна ошибка, несколько пропущенных деталей или совсем другое ожидание от результата. Поэтому полезнее сначала понять, на каком наблюдении она основана.

Можешь подсказать, где именно была ошибка и на что она повлияла?

• Не спешите соглашаться или спорить

Принять обратную связь — не значит автоматически признать любую оценку верной. Если комментарий оказался неожиданным или вызвал эмоции, не обязательно сразу решать, согласны вы с ним или нет. Можно сначала уточнить детали и дать себе время все обдумать.

Спасибо за обратную связь. Я подумаю над этим и вернусь с ответом.

Но если похожий комментарий повторяется от разных коллег или одна и та же ситуация возникает снова, стоит посмотреть на нее внимательнее.

🔸 Когда обратную связь даете вы

Хорошая обратная связь отвечает на три вопроса: что произошло → на что это повлияло → что делать дальше.

• Описывайте действие, а не качества человека

«Ты безответственный», «ты постоянно все затягиваешь» звучат как вывод о человеке. С таким выводом сложно что‑то сделать — остается только соглашаться с ним или защищаться.

Поэтому описывайте то, что можно было увидеть или проверить: конкретное действие и его последствия.

Мы договорились получить материалы во вторник, но они пришли в четверг. Из-за этого макет ушел на согласование на два дня позже.

• Обсуждайте, что именно стоит изменить

Фразы вроде «здесь плохо» или «надо сделать лучше» сообщают, что результат вас не устраивает, но не объясняют, в чем именно разрыв между текущим и ожидаемым результатом.

Здесь не хватает данных, на которых основан вывод. Давай добавим источник или поясним логику.

Если есть единственно верный способ решения, его лучше назвать прямо. Но когда вариантов несколько, сначала полезно услышать человека: возможно, у него есть контекст, которого вы не знаете.

Что можно сделать иначе в следующий раз?

• Говорите не только об ошибках

Положительная обратная связь полезна не только как поддержка. Она помогает человеку понять, какие именно действия дали хороший результат и что стоит повторить в следующий раз.

В презентации ты вынес выводы в начало, поэтому было легко понять главное. Такой формат стоит сохранить.

Считал экономику платного Telegram-канала. Комиссия с оборота или фиксированный тариф - разница оказалась неожиданной

Последний месяц изучаю рынок монетизации Telegram. Не в теории - смотрел реальные проекты, считал цифры, разбирал юридические нюансы.

Поделюсь тем что удивило.

Большинство людей выбирают сервис по стоимости подключения. Это почти всегда ошибка.

Настоящая стоимость - в модели работы сервиса. А моделей сейчас три.

Модель 1 - комиссия с каждой оплаты

Tribute, Paywall и похожие сервисы берут 10-20% с каждой транзакции. Деньги идут через их систему, они выплачивают тебе остаток по расписанию.

Считаем на конкретных числах. При обороте 30 000 рублей в месяц комиссия 10% это 3 000 в месяц и 36 000 в год. При обороте 100 000 - уже 10 000 в месяц и 120 000 в год. При 300 000 - 30 000 в месяц и 360 000 в год только за пользование платформой.

Плюс: не надо думать о платёжках, просто подключился и работаешь.

Минус который мало кто считает заранее: при обороте от 100к в месяц комиссия начинает ощутимо давить. А ещё - Tribute работает через иностранное юрлицо (TRBT Limited). Для самозанятых это дополнительные вопросы по 173-ФЗ о валютном контроле.

Модель 2 - Telegram Stars

Нативная валюта платформы. Пользователь платит не выходя из Telegram, конверсия выше.

Но есть нюансы которые многие узнают постфактум. Если пользователь купил Stars через iOS или Android - Telegram отдаёт разработчику примерно 70%, остальное уходит Apple или Google. Если через десктоп - почти всё твоё. Вывод только через Fragment в TON, для рублёвой отчётности лишний шаг.

Для кого подходит: проекты где аудитория сидит в основном на десктопе, или те кто не против крипто-вывода.

Модель 3 - фиксированный тариф

Деньги идут напрямую на твой счёт в ЮKassa или CloudPayments, сервис берёт фиксированную абонентку.

Та же математика. При обороте 30 000 в месяц платишь фикс около 2 000 - экономия против 10% всего 1 000, разница несущественная. При 100 000 в месяц фикс те же 2 000, экономия уже 8 000. При 300 000 - фикс 2 000, экономия 28 000 в месяц. За год это больше 300 000 рублей которые остаются у тебя а не у платформы.

Из российских сервисов с такой моделью смотрел Nemiling - там фиксированный тариф от 1 790 ₽ в месяц без ограничений по количеству проектов, деньги приходят напрямую на счёт, бесплатно до 5 000 ₽ оборота.

Что ещё важно при выборе - и про что почти не пишут.

Автоматическое удаление при отмене подписки. Кажется очевидным, но не все сервисы делают это надёжно. Если бот не удалил пользователя который не продлил - он продолжает получать закрытый контент бесплатно. На маленькой аудитории не критично, на большой - реальные потери.

Платные группы а не только каналы. Большинство сервисов умеют закрытые каналы. Но платная группа где участники общаются между собой - это другой технический сценарий. Не все его поддерживают.

Платные консультации с таймером. Если продаёшь не подписку а доступ к себе - нужен другой механизм. Пользователь платит за определённое время общения, после которого доступ закрывается автоматически.

Налоговый статус. Самозанятый или ИП - это влияет на выбор сервиса. Деньги которые приходят от иностранного юрлица могут создавать вопросы которые лучше закрыть заранее, а не когда уже пришло требование от банка.

Правильный вопрос при выборе сервиса не «сколько стоит подключение», а «какова полная стоимость при моём планируемом обороте через год» плюс «какие юридические риски я принимаю».

При обороте до 20-25 тысяч в месяц разница между моделями почти незаметна - можно брать что удобнее. При росте выше - фиксированный тариф начинает выигрывать математически.

А вы как выбирали инструмент для монетизации Telegram-проекта - считали экономику заранее или уже потом пересчитывали?

Варианты старта: тимлид в новой или существующей команде

Продолжаем серию постов о переходе из роли старшего инженера в трек начинающего технического менеджера — тимлида.

Как это случается

Переход из инженера в тимлида почти никогда не происходит мгновенно. Сначала будущий руководитель набирает управленческий опыт: берёт на себя делегированные активности, работает с чужими целями и учится смотреть на команду шире технических задач.

Освоение роли опирается на три составляющие: теорию, практические кейсы и работу с делегированными активностями. Теории в сети предостаточно, а практических кейсов меньше: их разбирают на абстрактных примерах или внутренних тренингах, да и симуляторы построены на типовых ситуациях. Рост через делегирование возможен только в повседневной работе, с последствиями принятых решений, — поэтому он самый ценный и самый сложный.

Тимлиды вырастают из инженеров разных функций — например, из бэкенда, фронтенда, мобильной разработки или QA. Но старт определяет не столько специализация, сколько то, как человек входит в роль и с какой командой ему предстоит работать.

Стартовые позиции

Нередко новоиспеченный тимлид — это инженер, который давно исполняет обязанности руководителя: формально остаётся инженером, но фактически ведёт команду, распределяет задачи, планирует. Такой плавный переход смягчает шок, но это не единственный сценарий.

Если смотреть шире, есть две принципиально разные стартовые позиции: тимлид в новой команде и в уже существующей. Логика у них общая, но различия существенные, а значит, различается и набор нужных знаний и опыта.

Тимлид в новой команде

Новая команда начинается с чистого листа. Её предстоит собрать, поэтому на первый план выходит быстрый, но точный найм: ошибка на старте дорого обходится. Параллельно — выстраивание отношений, запуск процессов с нуля и культура работы с метриками, которой пока нет. Всё это — в сжатые сроки и при большом объёме контекста.

Команда здесь по определению незрелая, поэтому задача руководителя двойная: выстроить выверенный найм и сформировать среднесрочную стратегию, задающую направление на ближайшие месяцы.

Тимлид в существующей команде

Второй сценарий — приход на замену прежнему руководителю (например, после его повышения или ухода). Чистого листа здесь нет: новому тимлиду достаются незакрытые «хвосты», настрой команды, уровень развития людей, процессы и метрики. Всё это нужно быстро оценить.

Ключевой показатель — зрелость команды или Team Maturity Model (TMM): развитая, базового уровня или незрелая. С развитой можно работать на длинную дистанцию, с незрелой — сначала закрывать базовые пробелы.

Акцент смещается на быстрые победы, укрепляющие доверие, и «north stars» для долгосрочного развития.

Сложности вступления в роль

Состояние команды удобно оценивать через три призмы: метрики, процессы и людей. По каждой из них нужно честно ответить на вопрос: ситуация критичная или некритичная? Такая диагностика быстро показывает, где горит.

Дальше всё упирается в планирование. Правильно разложенные по горизонтам быстрые победы, среднесрочные планы и долгосрочная стратегия — ключ к эффективности на старте. Ошибка в приоритетах может стоить дороже ошибки в конкретном техническом решении.

Онбординг тимлида длится около полугода. За это время необходимо: 

• показать профессиональный авторитет; 

• сделать прозрачными границы роли; 

• быстро погрузиться в боли команды и продукта; 

• обеспечить быстрые победы и план работы со сложными проблемами; 

• системно развивать все три направления: метрики, процессы и людей.

Выводы

Оба сценария имеют свои особенности, но логика старта одна: быстро погрузиться в информационное поле команды, понять её проблематику и в первые одну-две недели выработать краткосрочный план, а ко второму месяцу — долгосрочное видение, ту самую «полярную звезду» развития команды.

Что дальше?

В следующей статье поговорим о целеполагании и планировании: как планировать, когда всё горит и ничего не понятно.

Почему люди не покупают подписку даже если им нравится контент

Сперва слышал об этой проблеме от других, думал что у меня то будет иначе - но...

Канал реально живой. Контент, обратная связь - всё как положено. Люди читают, реагируют, пишут приятные слова. И вроде тестовых заходов в платный канал много. Но вот в постоянку остаются единицы. Начинаешь думать что контент недостаточно хороший. Но дело было не в этом.

Три реальные причины почему платники не остаются надолго.

Не понимают что получают дополнительно. Если платный контент не отличается явно от бесплатного в голове читателя - зачем платить снова. Разница должна быть ощутимой и конкретной. Не «закрытые материалы», а что именно и почему это ценно прямо сейчас.

Нет момента для продления. Люди редко сами идут платить повторно. Первый раз сработало любопытство или импульс. Второй раз нужен триггер - пост который попал точно в боль, напоминание в нужный момент, ощущение что что-то потеряешь если не продлишь. Без этого даже довольный подписчик просто не доходит до кнопки.

Не успели привязаться. За месяц человек может не успеть почувствовать что канал стал частью его жизни. Особенно если контент выходит редко или онбординг слабый. Уходят не потому что плохо - просто не успело стать привычкой.

Всё это лечится, но не контентом. Контент это необходимое условие, а не достаточное.

Сталкивались с таким? Как решали проблему удержания?

Как Kubernetes, Jira и Keycloak не помогли выпустить продукт

Небольшой повод похвастаться: меня начали звать на технические аудиты не только по работе, но и просто как специалиста.

Первый кейс сразу интересный. Есть команда из трёх разработчиков, больше 30 репозиториев, Kubernetes, Helm, Argo CD, Keycloak, Jira и куча другой инфраструктуры. Нет только новой версии приложения, которую заказчик может нормально открыть в браузере.

У заказчика уже есть работающий продукт примерно на 3000 активных пользователей в месяц. Пользователи покупают подписку и получают доступ к текстам, фотографиям и видео.

Заказчик решил обновить приложение и нанял отдельную команду. Прошло довольно много времени, но внятного результата он так и не увидел.

Разработчики говорят, что проблема в непонятном ТЗ. Заказчик говорит, что команда не отвечает на вопросы, не доводит решения до конца, а то, что показывает, регулярно не работает.

Меня позвали разобраться.

Первым делом я попросил доступ к коду. Код лежит в собственном GitLab. Правда, сам GitLab периодически тоже лежит, поэтому попасть туда получилось не сразу.

Когда доступ появился, меня встретила авторизация через Keycloak.

Напомню: разработчиков трое.

Спрашиваю, как деплоят. Kubernetes, Helm, Argo CD. Открываю список репозиториев, а их больше 30. Часть занята общими библиотеками и Docker images, но большая часть приходится на отдельные сервисы.

Потом выяснилось, что у команды есть собственные registry, Jira, Grafana, VictoriaMetrics и ещё пачка инфраструктурных компонентов.

Всё это работает на мощностях заказчика. Точнее, периодически работает. То GitLab недоступен, то проблемы с кластером, то ломается ещё что-нибудь. А отдельных людей, которые могли бы постоянно следить за этим зоопарком, нет.

Старая версия приложения продолжает обслуживать пользователей. У новой тоже есть production-контур, но он сильно отстаёт от dev и пока не соответствует требованиям.

Frontend вроде бы существует. Но вживую я его до сих пор не видел, только на скриншоте.

Сколько функций действительно готово, тоже непонятно. Приёмочные испытания ещё не начались, потому что критерии приёмки всё ещё согласовывают.

Получается странная картина. Инфраструктура уже сложная. Репозиториев много. Инструментов ещё больше. А общего понимания, что считается готовым продуктом, до сих пор нет.

Дело не в том, что Kubernetes, Jira или Keycloak плохие. Вопрос в том, зачем всё это понадобилось именно сейчас и кто должен это обслуживать.

Если команда из трёх человек построила инфраструктуру, за которой не успевает следить, значит, сложность уже стала проблемой. Особенно когда она не помогает быстрее выпускать продукт.

Поэтому моя первая рекомендация заказчику простая: упростить инфраструктуру до уровня, который команда реально может поддерживать. Уменьшить количество движущихся частей и сначала научиться стабильно доставлять продукт пользователям.

Забавно, что это полная противоположность истории с The Signal.

Там ребята быстро выкатились на Vercel, но забыли настроить RLS в Supabase. А когда я поднял логи и метрики, мне сказали, что это уже какой-то очень серьёзный подход.

Тут всё наоборот. Логи есть. Метрики есть. Kubernetes есть. Даже Argo CD есть. А работающий frontend пока существует для меня только на скриншоте.

Обе крайности плохие. Можно месяцами строить идеальную инфраструктуру и не выпустить продукт. А можно выкатиться за вечер, забыв про безопасность, логи и бэкапы.

Нормальный вариант где-то между ними: работающий пользовательский сценарий, понятные критерии готовности, минимальная безопасность, логи, метрики и повторяемый деплой.

А вы в какой крайности?

Вообще, по официальным данным из Единого реестра ФНС на 10 июля 2026 года числится 6,61 млн субъектов малого и среднего бизнеса.

Всего у них работает 15,09 млн наёмных сотрудников — в среднем 2,28 работника на один субъект МСП.

По стране, как вы можете догадаться, разница довольно большая.

И скорее всего, это не обязательно означает, что малый бизнес в этих регионах менее развит. Я бы связывал это, помимо прочего, с тем, что достаточно много доли индивидуальных предпринимателей и небольших компаний, работающих без штата.

Причём самого ИП без наёмных сотрудников ФНС работником не считает, и поэтому здесь показаны именно наёмные рабочие места, а не все люди, занятые в малом бизнесе.

Что делать, если ваш руководитель — чайка?
«Он появляется внезапно, громко говорит, даёт указания и исчезает. А через неделю возвращается и удивляется, почему ничего не сделано».

Супер‑стиль, особенно ощущения от общения, не правда ли?

Чайка‑менеджментом называют стиль управления, которое олды миллениалы зовут ИБД.

Для самого менеджера это энергонезатратно (включаться в процесс не нужно) + заметно для руководства повыше. Для чайки вообще удобно — выплеснул...эмоции, дал «решение» и улетел.

Для команды — хаос: планы ломаются, приоритеты скачут. Ну и последствия разгребают конечно те, кто остался.

Вы не можете быстро переделать руководителя. Но можете лечь в направлении снижения хаоса вокруг себя.

1) Готовьте факты. Перед встречей соберите короткую сводку: что происходит, какие риски, что вы предлагаете. Это не отчёт, а способ не дать эмоциям заменить разговор по делу.

2) Переводите эмоции в вопросы. У себя, и — что сложнее — у начальствующего. Не «так опять всё сломается», а «как мы поймём, что этот подход работает?» или «что будет признаком, что его стоит остановить?». Возвращаем фокус на результат.

3) Фиксируйте решения. Если на встрече что‑то решили — запишите и отправьте краткое резюме. Сохраняем контекст, в том числе для того чтобы «поймать на слове» (да, токсичненько, но иногда — помогает).

4) Предлагайте пилоты. Вместо «ок, давайте пробовать» — «давайте проверим это на одном проекте». Остаемся в безопасной зоне, используем реальные данные.

Кстати, если вы сами иногда оказываетесь в роли «чайки» — я вас не осуждаю (см. выше — это тоже способ продвижения). Но пожалуйста задумайтесь — регулярные короткие встречи, данные вместо эмоций и сопровождение вместо указов работают лучше, чем шумные появления раз в месяц.

А у вас был такой руководитель? Что помогало — или что точно НЕ помогало?

Западные ИИ-модели закрываются для РФ. Что это значит для продуктов

В июне 2026 года Минторг США закрыл доступ к моделям Anthropic для неграждан США. OpenAI согласовывает клиентов новых моделей с правительством. Это не слухи - это уже работающая реальность.

Для большинства российских пользователей это пока незаметно: ChatGPT в браузере доступен, Claude тоже. Но для бизнеса который строит продукты на API - история другая.

Что это значит на практике.

Если ваш продукт завязан на OpenAI или Anthropic API - у вас есть риск который нужно оценить. Не паниковать, но понимать.

Альтернативы есть и они нормальные. GigaChat вырос за последний год. YandexGPT тоже. DeepSeek доступен через API. Для большинства продуктовых задач этого достаточно. Не для всех, но для большинства.

Главный вопрос не «какая модель лучше» а «какая модель точно будет доступна через год». Для российского бизнеса с российскими пользователями это сейчас важнее качества на бенчмарках.

Кто уже перешёл на отечественные модели в продакшене - как ощущения?

«Это разовая ситуация» - самая дорогая фраза в процессах

Видел сегодня статью про стоимость ручных исключений. Там формула и таблица. Хорошо написано, но я хочу добавить кое-что от себя.

В каждой команде с которой я работал была своя версия этой фразы. «Это нетипичный случай». «Сделаем руками, один раз». «Для этого клиента отдельный порядок».

Через год выясняется что таких «разовых» ситуаций накопилось сорок штук. Каждая требует чьего-то времени. Никто не помнит почему именно так. Новый человек в команде не знает что делать и спрашивает того кто знает. Тот кто знает тратит время на объяснение вместо работы.

Ручное исключение это не проблема само по себе. Проблема когда оно становится невидимым. Когда его не фиксируют, не считают и не решают является ли оно симптомом чего-то в процессе.

Простое правило которое помогает: если одно и то же исключение случилось три раза - это уже не исключение. Это дыра в процессе которую надо закрыть.

Как вы отслеживаете ручные исключения в своих процессах и правилах?

Три шляпы Билли Миллигана

Есть три шляпы, которые я попеременно надеваю в течение дня:

1. Секретарша. Она следит за всеми входящими. Читает письма, просматривает чаты, записывает идеи, разбирает голосовые. Все заметки педантично складывает в ежедневник, не особо вникая.

2. Начальник. Вдумчиво разбирает записи секретарши. Простые дела оформляет в виде задач, сложные — в виде проектов. Затем проходится по списку проектов и для каждого актуализирует список следующих шагов. Начальник много думает и быстро устаёт.

3. Работник. Открывает список задач от начальника и выполняет одну за другой. Работник немного туповат. Если какая-то задача ему непонятна, он её откладывает и возвращает на разбор начальнику.

Главный секрет, позволяющий сохранить ясность ума: в один момент времени на голове должны быть только одна шляпа. В идеале — чередовать их не чаще, чем раз в полчаса.

• Если секретарша начнёт разбирать каждое входящее дело, то рискует закопаться и не добраться до важного срочного сообщения.

• Если начальник будет отвлекаться на каждое входящее, то не сможет сконцентрироваться на проработке проектов.

• Если работник начнёт думать о проекте, то может испугаться и не сделать следующий шаг. Не поверите, сколько проектов, поначалу казавшихся неподъёмными и непонятными, удалось довести до конца благодаря работнику, который просто делал очередной маленький шаг к цели.

Секретарша педантичная, начальник вдумчивый, работник туповатый. Люблю их.

Три метрики которые я перестал считать

Работаю с продуктами давно. За это время накопил список метрик которые выглядят полезными но на практике не помогают принимать решения. Вот три из них.

DAU и MAU в отрыве от контекста. Цифра растёт - хорошо. Падает - плохо. Но сама по себе она ничего не говорит о том почему. Видел продукты с растущим DAU и ухудшающейся юнит-экономикой одновременно. Рост привлечения маскировал проблему с удержанием.

NPS. Красивая цифра для отчётов. Но детракторы часто просто уходят молча не заполняя опрос. Промоутеры заполняют охотно. В итоге метрика смещённая. Видел продукты с высоким NPS и растущим churn одновременно.

Completion rate онбординга. Люди проходят кликая далее не читая. Метрика зелёная, понимания продукта нет. Об этом уже писал, но продолжаю видеть это в проектах снова и снова.

Общая проблема у всех трёх: показывают что происходит, но не объясняют почему. А решения нужно принимать именно на основе почему.

Сейчас больше времени трачу на качественные данные: разговоры с пользователями, сессионные записи, открытые вопросы в опросах. Медленнее и субъективнее. Но решения на их основе чаще оказываются правильными.

Какие метрики вы перестали считать или считаете что переоцениваете?

Подборка книг по эффективной работе в команде

Эффективная работа в команде строится на «трех китах»: доверии, четких целях и умении конструктивно общаться. Именно продуктивное взаимодействие с коллегами позволяет быстрее и качественнее достигать общих результатов.

Собрали подборку книг, которые помогут отработать эти навыки на практике.

• «Наука общения», Ванесса Ван Эдвардс

Практическое руководство о том, как начинать разговор, производить первое впечатление, считывать эмоции и невербальные сигналы, поддерживать интерес собеседника и увереннее чувствовать себя на встречах, переговорах и мероприятиях.

• «Пять пороков команды», Патрик Ленсиони

Бизнес-роман о руководителе, которая помогает конфликтующей команде вернуть эффективность. На примере этой истории автор разбирает пять ключевых проблем. Вторая часть книги помогает диагностировать эти проблемы и работать с ними.

• «Идеальный командный игрок», Патрик Ленсиони

Книга о трех качествах, которые помогают эффективно работать с другими. Автор объясняет, как оценить собственные сильные стороны, понять, какие качества стоит развивать, и выстраивать взаимодействие внутри команды.

• «Правила команды. Искусство думать вместе», Максим Поташев, Павел Ершов

Авторы рассказывают о жизненном цикле команды, распределении ролей, разных стилях мышления, лидерстве и коллективном решении сложных задач. В книге есть тесты для определения своей роли и зон развития.

• «Как создать настоящую команду», Дэвид Шервин, Мэри Шервин

Сборник практических алгоритмов и рабочих ритуалов, которые помогают команде договариваться об общих правилах и ценностях, принимать решения, давать обратную связь и справляться с конфликтами.

T-shaped снова в моде?

Подняли тут вопрос, о том что мы снова движемся от специализации в T-shaped специалистов. Компании планируют сокращать персонал и одновременно с тем надеятся на усиление текущих специалистов за счет ИИ. В некоторых случаях это потребует замены текущих команд или как минимум отдельных людей, на агентно-ориентированных.

В обиход входит слово tiny teams. По представлениям сбера (это их инициатива), это компактные команды в несколько человек с большой степенью автономности находящиеся внутри ai sdlc, где все процессы изменены, где все знания доступны агентам и так далее. В общем ai native организации, вместо (зачеркни ненужное) бирюзовых, agile и других слов.

Пару мыслей про это от меня и других ребят, с которыми мы кулуарно общались. Во-первых сама тенденция возврата к фулстек режиму, во многом определяется не тем что у нас появился ИИ, а тем что идет общий экономический спад и компании сжимаются. А в таких случаях обязанности перераспределяются среди оставшихся. И наоборот, когда все активно развивается, происходит дробление обязанностей так как людей становится все больше и процессы становятся все сложнее.

Сейчас же ИИ действительно позволяет увеличить производительность, что само по себе приводит к укрупнению зон ответственности, но это явление временное. Когда агенты станут такой же обыденностью как персональные компьютеры (представьте разницу между теми у кого они были и у кого их не было в 80 годы), то для увеличения производительности труда снова придется дробить ответственности и брать больше людей.

Во-вторых, есть серьезные опасения, что сильных спецов в принципе всегда было мало, а тут мы как будто бы хотим лучших их лучших. Откуда их брать? И насколько людей действительно хватит? Мы не можем бесконечно масштабироваться, ИИ очень быстро уперся в ограничения кожанных. А комфотная работа для многих превратилась в изматывающий марафон на скорости стометровки.

Через 5 лет мы будем оглядываться назад и говорить о том, как все было очевидно, вот это работает, а вот это бы не заработало никогда. Как говорится, знал бы прикуп жил бы в Омске