🧠Почему «сеньор» — не всегда спасение

Иногда бизнес думает: «наймём сеньора — он всё решит».
Но это ловушка.

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

И тогда звучит:

Ну и что с него толку? Мы платим в 2 раза больше, а результат тот же!

А проблема не в человеке.
Проблема в контексте, в котором он работает.

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

📌 Сеньор не лечит систему.
Он помогает, если системе дают дышать.

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

Подписывайся

🛠 Когда «сделаем универсально» — это худшее решение

В один момент кто-то в команде говорит:

Давайте сразу сделаем гибко, с запасом — пригодится

Звучит как зрелый подход.
Но на деле — часто оборачивается катастрофой.

➖ Делают абстрактную логику «под расширение»
➖ Строят сверхгибкую архитектуру
➖ Добавляют настройки, которых никто не просил

📥 И в итоге тратим недели на подготовку к «будущему», которое может не наступить.

👀 И я так ошибся
В одном проекте решили построить «универсальный модуль отчётов» — под любые данные, фильтры, роли.
Хотя по факту нужен был один простой отчёт — для одной команды.
Ушло, наверное, раза в 3 больше времени, чем могло бы уйти
А потом, систему интегрировали в другой отдел, а там уже был совершенно другой формат…
Пришлось переписывать

📌 Универсальность — это не по умолчанию.
Это инвестиция.
Если у бизнеса нет запроса «масштабировать это решение в 3 направления через 2 месяца», то скорее всего ему нужно просто решение здесь и сейчас.

Сначала — рабочая фича.
Потом — если надо, расширим.

Подписывай

💬 Чат-менеджмент

Всё идёт нормально, пока проект маленький.
5 человек в команде, один чат — и вроде всё под контролем.

Потом начинается:

— Кто делает выгрузку для отчёта?
— Я вроде делал...
— А где ты это писал?
— Ну… я вышел писал об этом.

👀 Добро пожаловать в чат-менеджмент.

Задачи ставятся в Telegram, Slask, Notion комментариях или даже комментарии в ворде(и такое бывает).
Статусы задач? Конечно - "прочитано" или "не прочитано"
Пинг в чате - способ управления и отслеживания.

⚠️ И всё вроде работает… пока не сломается.

Как только людей станет больше 5, задач больше 10 в неделю или кто-то уйдет в отпуск - то все превращается в сущий ад.
Таски теряются, люди отстреливаются фразами "ты мне не писал", а приоритетов вообще нет...

❓ Оно вам надо?

Чат — для обсуждения.
Задачи — в трекере.
Согласования — письменно или в таске.
История — не в голове, а в системе.

И жизнь спокойнее, и процессы прозрачнее

Подписывайся

❌ Когда фидбэк может уничтожить продукт

— Нам написали, что неудобно искать товары, надо переделать поиск!
— Пользователь жалуется, что кнопка не там. Надо срочно перенести!
— Все пишут: сделайте темную тему, это must have!

А теперь включим рациональность.
Сколько таких "все" на самом деле? Трое? Или один активный, но крикливый?

📉 Продукт, который бежит за каждым фидбеком — теряет лицо.

Вы не улучшаете его — вы превращаете его в комок компромиссов.
Есть разница между: "мы услышали пользователей" и "мы сломались под первым комментом"

⚪️ Фидбек нужно фильтровать.

1️⃣ Это разовое мнение или тренд?
2️⃣ Это влияет на метрики?
3️⃣ Это относится к нашей целевой аудитории?
4️⃣ Решает ли это бизнес-задачу?

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

Если у продукта нет своего курса, его уносит течением чужих хотелок — и чаще всего в никуда.

Подписывайся

🎯 Приоритизация — фильтр выживания

Сделаем попроще, а то не успеем.
Добавим ещё вот это, пока есть время.
Эта задача не срочная, но она интересная...

💥 Вот так проект начинает разваливаться не потому, что команда плохая, а потому что нет приоритетов.
Каждый занят делом. Только непонятно, каким именно.

Релиз вроде бы близко, но всё время что-то мешает.
И в какой-то момент вы ловите себя на мысли:
все работают, а вперёд — не двигаемся.

🔍 Почему приоритизация — не банальность, а необходимость:

Фокус на важном.
Команда перестаёт хвататься за всё подряд и делает то, что реально двигает продукт.

Прозрачность.
Можно сказать “нет” не потому что “не хотим”, а потому что есть чёткий план. И все его видят.

Безопасность.
Отсекаются фичи, которые потенциально могут всё сломать прямо перед релизом.

💡 Приоритизация — это не табличка в Notion.
Это инструмент, который экономит нервы, время и деньги.
Он не для менеджера. Он для всей команды.

Без приоритетов: задачи множатся, продукт буксует, а команда слепа
А релиз?
Он просто не наступает.

Подписывайся

🏃 Синдром бессмысленного спринта

Когда задачи есть, а работы — нет

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

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

Обычно это сопровождается размытыми приоритетами, отсутствием ясного Definition of Done и желанием сделать всё, что успеем.
В результате — перегруз, выгорание и ощущение, что труд напрасен.

Необходимо каждый раз задаваться вопросом: "то, что мы делаем - приближает нас к релизу?"

🔵 Жёсткая приоритизация — не про то, чтобы вычёркивать, а про осознанный выбор: что действительно нужно сейчас.

🔵 Общая цель — не для красивых презентаций, а для синхронизации команды

🔵 Внятный результат — это не про закрытую задачу, а про изменение, которое мы хотим видеть в продукте.

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

Подписывайся

👨‍💻 — Слушай, я посмотрел у Тинькоффа — у них такие крутые анимации. Давайте и нам такие сделаем!

👨‍💻 — Ну, у нас не финтех, мобильного приложения нет, и вообще — у нас CRM для логистов…

👨‍💻 — Ну и что? Люди любят, когда красиво! Сделаем плавные графики, чтобы всё оживало. UX, UI, ты же понимаешь!

👨‍💻 — У нас при этом не работают фильтры, отчёты формируются вручную, и у клиента падает система при импорте Excel. Может, сначала это починим?

👨‍💻 — Ладно… Только кнопки тогда сделай с закруглениями, как в Тинькоффе. Хоть что-то красивое будет.

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

💡 Вдохновение — не преступление.
Но копирование без понимания контекста — худший выбор.
У Тинькоффа и команда дизайнеров, и исследования юзабилити, и огромный бюджет, и полгода на rollout.

Сначала надо решить боль клиента, а не украсить страдание.
Сделай стабильный функционал, и только потом — красивый.
Иначе копирование по цене тех долга выйдет.

Подписывайся

😱 Команда боится принимать решения

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

– с нас за это потом спросят
– менеджер всё равно всё переиграет
– легче согласовать, чем спорить
– если сломается — крайний я

👀 И вот ты видишь:

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

Это не культура безопасности. Это культура страха.
И в такой среде не бывает прогресса — потому что любое движение воспринимается как риск.
Проще отсидеться молча (Моя хата с краю)

❤️ Как лечится?

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

И вот тогда будет прогресс

Подписывайся

🔥 Потушили — и молодцы

Или же почему проект вечно на соплях

🧯 Пожары вместо разработки

Команда чинит баги по тревоге, на коленке. Все радуются — решили!
Но баги возвращаются. Причины те же. Ошибки — те же.
Почему? Потому что никто не останавливается, чтобы решить причину

🧠 Лечим симптомы, а не причины

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

💣 Хрупкая система и страх менять

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

😏 Закрываем заслонку

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

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

Подписывайся

🎭 Иллюзия контроля

— У нас же всё нормально.
— Все задачи в трекере.
— Команда на созвоне.
— Вижу, что код пушится.

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

Недавно меня позвали посмотреть проект, который вот-вот должен был выйти.
Все были уверены — "у нас осталось чуть-чуть".
Но при первом разборе выяснилось:
➖никто не знает, какая именно версия будет релизиться;
➖нет точного Definition of Done;
➖баги ловятся на демо, потому что никто не знает, что именно надо тестировать;
➖команда работает, но все по-своему понимают цель.

Итог?
Идеальный процесс на поверхности.
И абсолютный туман в содержании.

Что с этим делать?
Иногда надо остановиться и задать простой вопрос:
"А что мы хотим получить к дате Х?"

Не список задач, не ощущение движения — а конкретный результат.
Потому что настоящий контроль — это не отчётность. Это осознанный курс.
И способность в любой момент сказать: мы делаем именно это, потому что это важно.

Подписывайся

🔥 Немного из практики

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

Проект с потенциалом, идея хорошая. Но — как часто бывает — техническая база слабая. Экономия на старте, быстрый MVP, вот это всё.

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

Мы наметили план, как закрыть эти риски. Всё ок.

А вот дальше — интереснее.
На созвонах я постоянно слышал:

А давайте сделаем, как у конкурента…

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

❌ Лоскутное одеяло:
– немного своего
– куча чужого
– плюс хотелки пользователей

Так рождается Франкенштейн-продукт. Без лица, без уникальности. На фоне конкурентов он не выделяется — и умирает в тишине(разумеется, бывают и исключения).

Технический долг — это не только про код. Это про стратегию.
Когда вы теряете фокус и лепите как у всех, вы закапываете продукт.

Подписывайся

🚥 Подстраховка как ручник

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

Но продукт стоял на месте!?
Неделя за неделей — ни релиза, ни ощутимого движения.

❓ Почему?
Команда ехала с затянутым ручником.

Каждое решение требовало совещания.
Любая инициатива проверялась с трёх сторон.
Задачи усложнялись, потому что "а вдруг" и "на всякий случай".

Подстраховка превратилась в тормоз.

Вместо уверенности — постоянная тревожность.
Вместо свободы действий — бюрократия.
Вместо темпа — стагнация.

Команда не ошибалась.
Но и не продвигалась.

Зрелость - это больше про управление рисками, чем смелость перед ними.
Иногда стоит опустить ручник и добавить газу.
Если всё проверено десять раз — не значит, что будет безопасно.
Иногда единственная защита проекта — это движение.

Подписывайся

🔧 Разработчик — лицо компании

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

👮‍♂️ А теперь представим последствия.

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

Проект запускается. И вроде нужное - но не то, что нужно.

А вы вроде бы всё сделали. Даже с общением всё было хорошо.
Но результат — посредственный. Без конфликта, но и без ценности.
И заказчик больше не вернётся. Он просто не придёт снова. Потому что получил не решение, а реализацию

🤐 Так и растворяется репутация.

Без шума. Без скандала. Просто вы сделали ещё один "нормальный" проект.
Их на рынке тысячи. И о них никто не вспоминает.

Подписывайся

👋 Привет, друзья!

Хочу поделиться с вами новостью — Паша добавил классную фичу в Telegram: теперь можно писать мне напрямую через канал, без всяких «Контактов в bio» и лишних кликов.

Так что не стесняйтесь — пишите свои предложения, истории и любые пожелания.
Всегда рад обратной связи! 😉

🎭 Фальшивый прогресс

Спринт закрыт, velocity растёт, burn down — как по учебнику.
На стендапе все бодры: задачи движутся, работа кипит, отчёты — загляденье.

А потом смотришь на продукт… и ничего не происходит.
Новых пользователей нет. Старая боль — на месте. Приложением неудобно пользоваться, но у команды — KPI в порядке.

❔ В чём подвох?

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

Когда работа на ублажение графиков — теряется смысл.
Можно бесконечно радоваться графикам, пока продукт не останется без пользователей.
Настоящий прогресс — это не всегда про рост метрик.
Это когда кто-то за пределами команды говорит:

Заметил, что стало удобнее

Подписывайся

👨‍💻 Что лучше: брать мидла или растить джуна?

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

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

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

На старте джун почти всегда в минус.
Но со временем он становится частью команды, а не просто ресурсом.
Знает контекст, понимает архитектуру, адаптирован под реальные задачи. А главное — лоялен.

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

Подписывайся

🔄 Тимлид занят — команда тормозит

Бэклог есть, стендапы идут, задачи в трекере, вроде все ок.
Но стоит тимлиду уйти на приёмку или в отпуск — и команда замирает.

💯Тимлид как точка ясности

Он не просто раздаёт задачи, он снимает туман, берёт на себя "давайте подумаем", решает, когда страшно.
Когда его нет — даже простые штуки становятся "не совсем понятными".
И их никто не трогает.

👤 "Подождём, когда Петя вернётся"

Так выглядит архитектура зависимости.
Один человек — главный по техдолгу, ревью, менторству, мотивации. Ушёл — и всем нечем дышать.

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

Тимлид — не единственный взрослый в комнате.
Если он уехал — а всё встало, значит, не команду строили, а систему зависимостей.

Подписывайся

🤐 Молчит на созвоне — но всё делает

Есть такие: тихий, аккуратный, всё в срок.
На митингах — ни слова. В чате — по делу.
Казалось бы, мечта. А на деле — побочный эффект.

🧠 Молчун — не всегда про интроверта

Часто — про ощущение, что «моё мнение тут не важно».
Или хуже: «не хочу лезть, всё равно решат без меня».

И вот у вас в команде — ручной раннер, не участник.
Не спорит, не предлагает, не кидает идеи.
А потом ты удивляешься, почему никто не сказал, что фича едет в кювет.

❓ Что с этим делать?

Не вытаскивать силой. А создавать среду, где безопасно лезть со своими 5 копейками.
Где вопрос «а что ты думаешь?» — не формальность, а интерес.
Где не перебивают, где ошибки не превращают в стыд.

Тихие часто видят больше всех.
Если они молчат — возможно, проблема не в них.

Есть и другая сторона медали: даешь всем высказываться -> разводите демагогию -> теряете время. Поэтому главное не перестараться со «свободой слова»

Подписывайся

🤖 LLM для устройства на работу

Пошёл тренд: в некоторых бигтехах кандидату дают сложную алгоритмическую задачу и разрешают пользоваться ChatGPT.
Типа:

Ну мы же всё равно с ИИ работаем, давайте проверим, как он с ним ладит.

Звучит модно, а выглядит странновато.

💡 В чём плюс

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

Для бизнеса первый — вопрос скорости, второй — вопрос вменяемости.

⚠️ В чём минус

Если кандидат пройдёт собес, где всё за него написал ChatGPT, есть риск нанять «вайб-кодера» — того, кто не думает, а просто копирует.
Вы сами задаёте тон: «Мы пишем с ИИ».
А потом удивляетесь, что код никто не проверяет, баги размножаются, а техдолг пухнет.

📌 Проблема не в LLM

Вопрос не «может ли он писать с ИИ», а «умеет ли он думать, когда пишет с ИИ».
ИИ — это калькулятор. Он не понимает, что считает.
И если человек тоже не понимает, то у вас теперь два калькулятора и ни одного инженера.

Лично я против такого подхода к найму, а вы?

Подписывайся

🔥 Срочнее срочного

Стартапам или командам с неопытным управленцем присуща проблема, когда все подряд становится срочным
Утро начинается с «бросаем все! срочно делаем вот это!».
И день проходит в тушении нового пожара, а вчерашние «срочно» уже затухли в бэклоге

🪤 Проблема не в том, что есть срочное.

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

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

📌 Всегда надо:

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

Если всё срочно — значит, ничто не срочно и без приоритетов.
Без приоритетов нет управление, это просто попытка потушить лес.

Подписывайся