Менеджмент

3D-модель — визуальный образ быстро собирает внимание команды и создаёт ощущение движения. Это естественно: форму легко показать, легко сравнить, легко обсуждать.

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

Сегодня Инфостарту — 20 лет. За это время мы прошли путь от первой публикации до одного из крупнейших профессиональных сообществ и экосистемы сервисов для специалистов и бизнеса на 1С. Спасибо всем, кто был с нами — и тем, кто присоединился совсем недавно.

Все началось 16 января 2006 года, когда основатель Инфостарта Доржи Цыденов опубликовал на сайте первую запись — «Добро пожаловать на Инфостарт». Тогда это был небольшой шаг, который стал началом большого проекта: площадки, где люди делятся опытом, инструментами и решениями для 1С...

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

Но почему же тогда так часто это не работает? Почему добавление людей в проект иногда его только тормозит?

«Разные команды работают по-разному»… С вами был Капитан Очевидность. DevOps-инженеры живут в спринтах и ретро-встречах. Маркетологи создают сложные контент-планы, где каждая кампания требует десятков документов, презентаций и аналитики. Менеджеры по продажам и поддержке держат в голове скрипты, FAQ и индивидуальные истории клиентов. HR-специалисты собирают разрозненные инструкции для онбординга, пытаясь из хаоса материалов слепить цельные курсы обучения.

К моменту прихода Ли Якокки (легенда менеджмента производства авто, создатель Форд Мустанг) Крайслер находилась на грани банкротства. Чтобы не потерять бизнес Якока закрывал убыточные заводы, продавал непрофильные активы, изменил отношения с поставщиками, сконцентрировал все усилия на создании новой линейки автомобилей — K‑Car и другие. Принятые меры позволили оживить бренд, погасить долги и начать рост бизнеса. 

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

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

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

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

Всем привет. Я Диана Шигаева, создатель «могучей кучки»😁 международных карьерных консультантов 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 лет. Хватит думать о них как о «тревожных детях», нуждающихся в более умном руководстве. Сегодняшние зумеры — это первое по‑настоящему глобальное и цифровое поколение, которое уже берет на себя лидерство. А завтра им предстоит управлять поколением альфа. Пора менять оптику.

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

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