Менеджмент

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

Сейчас я создаю сообщество «ЛУЧШЕ» — это клуб осознанного досуга для людей 30+. Мы проводим классные мероприятия, где можно найти единомышленников. По сути, решаем проблему того самого «одиночества в большом городе» для взрослых, интересных людей.

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

Поэтому, когда разговор заходит о человеческих отношениях, я — в первых рядах.

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

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

Считается, что физически мы растем до 20-25 лет. А вот психологически, ментально, эмоционально – всю жизнь. С годами мы отрываемся от прежних связей, «вырастаем» из прежнего круга общения. И хотим окружить себя новыми интересными людьми. И тогда встает вопрос, а где искать тот самый новый круг общения? Идеально – в комьюнити, участники которого близки нам по духу и жизненным ценностям.

Борьба с однообразием, эффект Хоторна, альтернативы Ганту, гемба-менеджмент и инцидент-менеджмент, зоны ответственности тимлида и всё интересное, что писали за последние 3 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

В Японии порядка 140 предприятий, которым более 500 лет. Они пережили десятки войн, императоров, катастрофические землетрясения, цунами, депрессии, и так далее.

Эти сверхпрочные старинные предприятия называются «shinise». Исследования показывают, они, как правило, имеют одну общую характеристику: у них много наличных денег и почти нет долгов. Так они выдерживают столетия постоянных бедствий и черных лебедей.

На рубеже 1910-х годов инженер Генри Лоуренс Гант придумал и начал использовать диаграмму Ганта как способ управления проектами. Основная идея заключается в том, что задачи декомпозированы, имеют начало и конец, и показывают последовательность выполняемых работ. Если вы сталкивались с проектным управлением, то знаете, что это очень полезный инструмент.

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

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

Вдохновлено Михаилом Ивановым, коллегой и товарищем, который напомнил про "Мир искусства"

Вы точно хотите это читать? Это длинная и местами сложная статья. Здесь философы XVII-XX веков, проблема индукции и ни одного туториала. Если всё же решитесь - читайте частями и старайтесь осмыслить. Не говорите, что вас не предупреждали.

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

Прямое. Но не потому, что я умею "понимать людей" или "находить подход к разработчикам". Дело в другом предмете из учебного плана.

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

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

В развитие дискуссии (см. здесь и здесь) о разности понимания процессного подхода к управлению организацией by BPM CBOK (в представлении IT мира) и ISO серии 9000 (в представлении Прикладного мира), меня попросили опубликовать методологию построения процессного управления в организациях в соответствии с требованиями стандарта ISO 9001. Т.к. стандартизированной/единой такой методологии нет, то поделюсь своими наработками. Ниже приведу слайды на интересующую тему своего доклада 2003 года на 15ой конференции Центра «Приоритет» посвященной стандартам ISO серии 9000, из которых, я надеюсь, обсуждаемая разница в понимании и подходе будет продемонстрирована.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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