Менеджмент

Привет всем, я – Соня, IT HRD. Посмотрела большое интервью ex-Amazon VP Ethan Evans про корпоративную политику. Решила с вами поделиться.

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

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

Интервью на 3 часа, ссылку дам в комменте, все заметки делались руками.

1/ Headcount самый простой сигнал лидерства 

Impact субъективен, headcount — нет. Impact сложно оценить. Насколько сложный был проект. Или я работаю в инфре, а ты пилишь revenue-фичи. У кого больше impact? А сколько людей у тебя оценить легко. 

Никто не спорит: у тебя 42 человека, у меня 17. Значит, ты более крупный лидер. 

2/ Если есть метрика — люди начнут под нее играть 

Empire building существует, потому что оно вознаграждается.

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

3/ Для директора в Amazon нужно 80–90 человек

Evans говорит, что для директорского уровня в Amazon сейчас нужно примерно 80–90 человек. Раньше было 22. Чем больше компания, тем выше цифра.

В принципах Amazon записано ‘no bonus for headcount’, но это черт подери не так. У тебя есть огромный бонус в виде должности и зарплаты за хедкаунт.

За годы работы в разнообразных командах я много раз видел одну и ту же ситуацию.

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

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

Одна команда знает, почему была изменена логика онбординга. Другая помнит, какие ограничения есть у биллинга. Третья когда-то проводила исследование, из которого следовало, что пользователи вообще не понимают текущую модель прав доступа. Где-то это лежит в презентации. Где-то в Notion. Где-то в Confluence. Где-то в почте. Чаще всего — в голове конкретного человека.

Пока этот человек рядом, система вроде бы работает. Можно написать ему в Slack, позвать на встречу, спросить: «А почему мы тогда сделали именно так?» Он вспомнит, расскажет, иногда даже найдёт старую ссылку. Но стоит человеку уйти, сменить роль или просто перестать быть доступным, как часть продуктовой памяти исчезает вместе с ним.

И это не исключение. Это нормальное состояние большинства организаций.

Однажды в большой корпорации у нас сменился Product Owner. На первой встрече с новым PO я спросил, что ему передал предыдущий. Ответ был примерно такой: «Мы встретились, он рассказал мне, что к чему».

В IT разработке результат дает не один человек, а команда. А в любой команде (даже если она работает на полной удаленке) будут отношения. А где есть отношения, там есть манипуляшки.

Мир неидеален, на солнце есть пятна, не все проекты делаются в срок, начальники орут, исполнители молча соглашаются с невыполнимым и доблестно выгорают - короче, все неидеально.

Но если все так, то как сохранить себя в этом бардаке, как работать максимально эффективно с совершенно разными людьми?

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

Эта статья написана по мотивам публикаций в моем ТГ канале «Морковка спереди, морковка сзади», который полностью посвящен управлению в IT, а особенно той его части, которой толком никто не учит: софтскиллам. Если вам это интересно, заходите, читайте и подписывайтесь. Ну и читайте другие мои статьи тут, на Хабре.

Итак, поехали!

До 1 сентября всем владельцам доменов в зонах ru, рф, su необходимо пройти идентификацию на Госуслугах. Если этого не сделать, не получится продлить регистрацию домена, сменить администратора или зарегистрировать новый домен. 

Норма введена 569-ФЗ от 29.12.2025 г. и теперь звучит так: регистрация доменных имен осуществляется в соответствии с правилами регистрации доменных имен только после прохождения лицом, на которое регистрируется доменное имя, идентификации с использованием единой системы идентификации и аутентификации.

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

Этот текст о применении ИИ-агентов для задач управления проектами.

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

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

Всем привет! Меня зовут Никита Гусев, я руковожу направлением EPM в компании «Инфосистемы Джет».

Если вы когда-нибудь видели, как финансист или аналитик ставит себе ТРЕТИЙ монитор, чтобы формулы помещались на экране, то сложности работы Excel в крупных компаниях примерно представляете. В статье расскажу, почему еще планирование в табличках — это больно, и по какому пути идут наши заказчики.

Как связаны ИТ и строительство? Очень тесно — через методологию управления.

Несколько лет назад я впервые столкнулся с методологией Scrum. Тогда она произвела на меня колоссальное впечатление. Позже, конечно, я нашёл и негативные стороны этого подхода, и понял, что в разных проектах лучше использовать разные подходы. Благо, что их придумано множество!

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

Порой он тесно связан с чувством вины — «а хорошая ли я мама?». Вина, конечно, не приговор, а важный сигнал, что нужно что‑то менять, на что‑то обратить внимание и взять фокус.

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

И эту статью мы написали совместно с Еленой Забалуевой. Она многодетная мама (трое детей: 10, 6 и 2 года) и техлид в крупной ИТ‑компании. Ее история — живое доказательство, что совмещать можно, если перестать требовать от себя невозможного и начать выстраивать свою, удобную именно вам систему.

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

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

$180 на Cursor за три дня. Три монитора. Пакет орешков. Ноль тестов. Бизнес в восторге. Команда в ужасе. Угадайте, кто победил.

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

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

Мнение. Предложение к обсуждению, а не новая догма.

Story points долго были удобным способом оценивать сложность задач в разработке. Но в 2026 году всё больше работы делается не только инженером, но и в связке с LLM: генерация кода, тестов, документации, рефакторинг, разбор ошибок. Возникает вопрос: может ли рядом со story points появиться новая метрика — neuro points, отражающая AI-итеративность решения задачи? В статье предлагаю этот подход как гипотезу для обсуждения и разбираю, зачем он вообще может понадобиться командам, которые уже активно используют нейросети в рабочих процессах.

Каждый раз, когда какой‑то продакт с гордостью говорит: «Я сам собрал прототип за вечер на AI/no‑code», я не вижу в этом геройства. Я вижу главу продукта, который превратился в ещё одну пару рук для дешёвого билдинга. Вижу человека, который перестал быть «мозгами продукта» и стал универсальным солдатом, которого удобно использовать, но невозможно уважать как продуктового специалиста.

Данные перенесены, workflow настроен, всех обучили. А через неделю — саботаж, снова задачи в Excel и бунтующий разработчик, у которого «вообще-то в Jira все нормально было»

Цифровые продукты не развиваются в отрыве от среды. И пока проект находится в разработке, меняются приоритеты бизнеса, ситуация на рынке, а исполнитель продолжает работать по уже устаревшему ТЗ. В итоге проект сдан в срок, но результат не решает актуальные задачи бизнеса.

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

В статье операционный директор CleverPumpkin Владислава Ларкина рассказывает, как компания выстраивает отношения со своими клиентами, чтобы знакомство переросло в долгосрочное партнёрство. И какие процессы помогают команде брать на себя больше ответственности, а бизнесу получать предсказуемый результат.

Привет! Меня зовут Света и я — project manager. Или, по мнению разработчиков, человек, который превращает «надо подумать» в «обещали к пятнице».

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

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

То есть уже понятно, что:

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

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

Привет, Хабр!

Я Ирина, в Блоке ИТ-развития инвестиционного бизнеса РСХБ.Цифра помогаю ИТ-командам доставлять ценность бизнесу, содействую оптимизации процессов, повышению эффективности и сплоченности команд, продвигаю Agile-практики.

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

Управлять тимлидами — это не раздавать задачи и проверять сроки. Это выстраивать среду, где сильные технические лидеры могут проявить себя без микроменеджмента. В статье разберем какие ошибки совершают 90% руководителей, почему контроль убивает инициативу, и как перейти к системному лидерству с помощью OKR, DORA-метрик и роли Delivery Manager. Без воды, с конкретными кейсами и схемами!

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