Менеджмент

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

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

Всем доброго полудня, меня зовут Лара и я работаю менеджером проектов в вебе больше 5 лет.

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

Сходив к специалисту я радостно узнала, что владею таким чудесным расстройством как «тревожное расстройство» и потихоньку начала разбираться в каких сферах я это я, а где эта обезьяна, которая постоянно орет «БЕЙ ИЛИ БЕГИ».

Я пришла не ныть, а разобрать как это работает в профессиональной сфере (и не только у меня).

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

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

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

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

Как добавить возможность расчета номеров задач в менеджере задач и проектов?

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

При этом, зачастую требуется расчет последовательно для нескольких служб: Например, для двух служб: Служба 1 -> Служба 2 -> Возврат номера службы 2 службе 1. Обычно же служб участвующих в цепочке - 7-8. Выполнение таких действий вручную очень трудозатратно.

В данной статье приведен анализ способ реализации такой задачи настройкой интеграций средствами Yandex Cloud

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

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

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

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

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

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

Преамбула.

Если вас позвали работать в компанию, то почти всегда это означает одно: там есть работа, и что-то уже идёт не так.

Введение. Почему цепочки поставок ломаются

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

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

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

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

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

Всем привет! Сегодня поделюсь своими наблюдениями и наблюдениями соискателей, с которыми я работаю.

Сразу сделаю отсылку на выборку, т.к. я не ВЦИОМ, моя насмотренность рынка труда ограничена определенными параметрами. Но общие тенденции будут полезны и для не моей ЦА.

Последние полгода каждый месяц общаюсь с 50+ соискателями, активно работаю с +/- 15 (зависит от месяца), +/- 10 на моём сопровождении с глубоким погружением в их ситуацию.

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

География: в основном Москва, работаю со всеми регионами.

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

Основные проблемы рынка и найма, которые начались еще в 2025 году и усугубятся в 2026.

1. Качество рекрутинга

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

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

Что делать? Готовиться к собеседованиям, адаптировать и переводить самопрезентацию со сложного языка на простой (это не я придумала, это бизнес экономит на рекрутерах).

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

Мы же посмотрим на тимлида как на лидера, ментора и стратега в одном лице.

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

Когда мы начинали делать модуль «Единый сток» внутри нашей WMS МПФИТ, задача звучала почти детски: есть поставщик, есть магазин, давайте синхронизируем остатки.

Первые внедрения быстро отрезвили. «Единый сток» у селлера редко про один магазин. Обычно это 2–3 витрины на маркетплейсах, плюс FBS, плюс сезонные всплески, плюс ассортимент в 500–3000 SKU, где часть товаров в вариантах (размер, цвет), а часть продается наборами.

И вот тут простая синхронизация перестает быть решением. Она становится источником сюрпризов.

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

Операционный директор CleverPumpkin вместе с продуктовыми командами Dodo Pizza, Lamoda Tech и «Лемана Тех» выделили шесть направлений, которые определят стратегию развития цифровых продуктов в 2026 году.

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

Тимлид — не повышение. Это смена профессии.

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

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

Если за неделю команда не начала нормально работать в новом софте — вы выбрали не инструмент, а проблему. Такую систему либо бросят, либо будут использовать для галочки.

Рассказываем, как мы делаем систему, которая не требует «внедрения».

В 2021 году выход работы Даниэля Канемана, Оливье Сибони и Касса Санстейна «Шум» закрепил в научном и управленческом сообществе представление о вариативности суждений как о критическом изъяне человеческого интеллекта.

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

Стейкхолдеры — это те самые люди, которые приходят с задачей «Надо ещё вчера», а формулируют её на уровне «Копаем от забора до заката!» и при этом вполне способны одним решением заморозить проект. В итоге команда либо бросается делать «как поняла» и приплывает не туда, либо зависает в ожидании мифического ТЗ, либо выгорает в героическом овертайме, а результат всё равно остаётся под вопросом. Знакомо?

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

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