Менеджмент

ЭТО - НЕ ПРО ОШИБКУ КАДРОВ. Это про систему, где клиническая неспособность становится культом, а профессиональный кретинизм возводится в ранг гениальности. История о том, как в команду внедряют "ментального инвалида" на позицию продакта, и его начальник - сентиментальный идиот наверху - с благоговением принимает этот дефект за "нестандартное мышление".

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

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

В финале - не жалость, а чёткий, безжалостный алгоритм выживания. Ваше профессиональное достоинство не должно сгореть в костре, разожжённом восторженными идиота́ми. Эта статья - инструкция по тушению.

Всем привет. Я Диана Шигаева, создатель «могучей кучки»😁 международных карьерных консультантов LifeCareerBalance. Пишу, опираясь на свой опыт и на кейсы коллег. Поэтому в этой (и в любой другой) статье собраны и инструменты, и психология, и наблюдения, и мотивация, и инсайды и много других интересностей.

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

В этой статье я делюсь этим списком с комментариями - возможно, он окажется полезен тем, кто тоже заходит в новую команду в роли тимлида или хочет навести порядок в своей команде. Здесь нет разбора софт‑скиллов, нет обсуждения, чем тимлид отличается от продакт‑ или проджект‑менеджера, и нет универсальной модели роли. Это набор конкретных действий, которые я для себя определил как важные.

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

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

95% корпоративных пилотов по внедрению LLM проваливаются. При этом фрилансеры и инди-специалисты показывают кратный рост эффективности с теми же инструментами.

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

Почему так и что с этим делать?

Это базовая методичка по канбан. На пальцах объясняю, как устроен метод и даю рабочую схему, как внедрить его в команде.

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

Я сначала не понял, что стало происходить. Было ощущение странного дежавю: читаю change request или баг‑репорт, киваю, вроде всё логично... но что‑то не так, как будто где это уже читал. Слова правильные. Причинно‑следственные связи на месте. Термины употреблены верно. Пытаюсь понять в чём проблема — ноль. Как будто читаешь инструкцию к микроволновке, а не описание реальной проблемы. Пытаюсь прочитать ещё раз и ещё раз — с трудом продираюсь через текст с каким‑то смутным понимаем того, что написано.

И тут до меня доходит - как обухом по голове.
Мои дорогие гении из техподдержки и продакт менеджер нашли «идеальный» способ сэкономить на обсуждении технической стороны проблемы со мной. И действительно, зачем? Клиент что‑то спросил. Они прогнали это через ИИ. И ИИ вник. Глубоко. Старательно. Затем сгенерировал текст, старательно объясняя мне что нужно добавить, починить и даже каким образом это сделать (не имея даже понятия о нашей кодовой базе).

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

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

“Надо увеличить ценность нашего продукта!” - фраза, которую произнес, пожалуй, каждый продакт хотя бы раз за свою карьеру. Эта фраза уже так набила оскомину, что уже потеряла всякий смысл.

А вот такой фразой “это не увеличивает ценность продукта для пользователей” отшиваются многие неугодные инициативы будь-то от команды или от СЕО.

Но что скрывается за этим мифическим термином “ценность для пользователя”?

Давайте разбираться.

Кажется, что цели ставить легко: мы вроде бы чётко понимаем, чего хотим. «Хочу быть богатым». «Хочу начать ходить в зал и быть спортивным» и тд.

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

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

Тем, как правильно это делать, мы сегодня и займёмся.

Если коротко, то, конечно, есть. Но я бы не писала об этом, если бы все было так просто.

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

Сделаем шаг назад и попробуем описать термины «продукт» и проект» и их связь. Вот и все 😊. Собственно, на этом шаге и стала очевидна первопричина всех споров.

В классических стандартах PMBOK, PRINCE2, ISO 21500, ICB «продукт» рассматривается как конечный результат проектной деятельности под запрос. Например, нам заказали строительство дома. Проект – это вся деятельность: планирование, закупка материалов, работа строителей, контроль сроков и бюджетов. Продукт - сам дом, который мы получаем в конце целиком или по частям (кухня, гостиная и т.д.).

В Agile-методологиях Scrum, Kanban, SAFe, Lean «продукт» - это ценность, которая развивается и поддерживается итеративно, понятие «проект» почти исчезает.  Например, продукт – дом пригоден для жизни уже после первых итераций, но со временем только улучшается. Проект – работа с итерациями (Scrum), поток задач (Kanban), оптимизация процесса строительства (Lean). То есть в классических стандартах проект «больше» продукта, в Agile – наоборот. Важно, что здесь мы не говорим об однозначном соответствии классических стандартов со способом реализации, то есть сравнение классические стандарты vs Agile‑методологии это не то же самое, что и Waterfall vs Agile, ведь и в классических стандартах, например, PMBOK, описывается управление проектами через «гибкие» методологии.

Я не экономист и не связан с менеджментом, тем более никогда не интересовался складской логистикой. У меня свой взгляд человека со стороны, разобравшегося и осмыслившего частную проблему. Хочу описать то понимание, которого мне не хватало изначально, как программисту. Хочу сохранить это понимание и, возможно, донести эти мысли для профессионалов в своей области. Возможно, хочу сохранить свои эмоции.. Без формул и заумных терминов, эта несложная математика уровня средней школы, которая может различаться у разных групп людей. Например, кто‑то подгоняет lcr под 100%, а другие считают обратное значение и добиваются зеленного уровня в 25-35%, и это просто местные привычки, которые погоды не делают. Поэтому в дальнейшем буду оперировать словами «хороший» и «плохой» lcr, потому что каждый менеджер сам знает, какие цифры под этими словами подразумеваются. Другое дело, есть ли вообще понимание, зачем это считать? Оказывается, самое сложное не посчитать, а объяснить, зачем мы это считаем.

Исследовательская компания Gartner представила тренды развития технологий на 2026 год. Обозреваем ключевые любопытные тезисы.

В 2026 году темпы изменений ускоряются, и ИИ больше не является опцией «по желанию». На конференции Gartner IT Symposium/Xpo 2026 вице-президент Garter Джин Альварес и аналитик Тори Полман подчеркнули, что ключевые стратегические технологические тренды этого года — это необходимые инструменты для CIO и ИТ-лидеров, позволяющие создавать устойчивые основы, выстраивать интеллектуальные системы и защищать ценность бизнеса.

Зумерам стукнуло 30 лет. Хватит думать о них как о «тревожных детях», нуждающихся в более умном руководстве. Сегодняшние зумеры — это первое по‑настоящему глобальное и цифровое поколение, которое уже берет на себя лидерство. А завтра им предстоит управлять поколением альфа. Пора менять оптику.

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

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

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

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

Да, я знаю про опыт BigTech компаний. Они экспериментируют, устраивая марафоны из 4–5 секций подряд, пытаясь имитировать «реальный рабочий день». Но давайте будем честны: это имитация, которая не имеет ничего общего с реальностью. И вот почему.

1. Фактор нервозности и искажение реальности Интервью — это не работа, это экзамен под прицелом. У каждого своя степень стрессоустойчивости. Я видел десятки случаев, когда у кандидата буквально отключался мозг от того, что на него смотрят и комментируют каждую строчку кода. В спокойной обстановке этот человек может писать гениальные решения, но в режиме live-coding, когда интервьюер дышит в спину, он забывает синтаксис языка. И наоборот: есть люди с превосходными навыками самопрезентации, которые уверенно пишут плохой код, но делают это с таким видом, что джуниор-интервьюер ставит им «Strong Hire». Мы оцениваем не навык разработки, а навык прохождения интервью.

2. Разрыв между вопросами и реальными задачами Очень часто задания на интервью абсолютно оторваны от того, что человек будет делать на проекте. Классический пример: секция System Design. Это стандарт де-факто в бигтехе и крупных аутсорсерах. Мы просим кандидата спроектировать условный Uber или Instagram, обсуждаем шардирование баз данных и балансировку нагрузки. При этом человека рассматривают на роль Senior-разработчика, который ближайшие два года будет писать бизнес-логику в уже устоявшемся монолите или микросервисах. Ему никто не даст ничего проектировать с нуля. Возникает стойкое ощущение, что отделы найма просто усложняют процесс, чтобы продемонстрировать начальству свою «изобретательность» и важность, создавая искусственные барьеры там, где они не нужны.

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

Эта статья — крик души Кирилла, основателя одной ИТ‑компании и руководителя подразделения в другой (обе специально не называю). Работал 20 лет в ИТ, писал код, управлял проектами, продавал, сделал пару ИТ бизнесов. Далее рассказ от его имени. 

Привет! Меня зовут Виталий.

Уже более 7 лет я помогаю внедрять IT-решения для бизнеса. Довелось пообщаться с разными компаниями, клиентами, пользователями, собрать интересный опыт. В этой статье вы найдете топ-5 low-code платформ для автоматизации бизнеса, а также мои мысли, наблюдения и опыт в части выбора такой платформы.

В рамках управления корпоративной архитектурой необходимо определить, в каком направлении нужно «двигать» организацию для достижения «светлого будущего». Для формализации целевого состояния организации может быть использовано дерево целей. Об этом мы и поговорим в этой статье.