Менеджмент

Ассоциация “Проектный Альянс” выпустила книгу “Управление проектами для заинтересованных сторон (стейкхолдеров)" (В.Воропаев, Я.Гельруд, О.Клименко), посвященную стейкхолдерам проекта и тому, как собирать управление сложными проектами вокруг интересов всех ключевых игроков, а не только команды PM.

Я прочитал новинку, и вот тезисно про книгу, ее плюсы и особенности.

Плюсы:

• Нацеленность на сложные крупнобюджетные проекты, вне зависимости от сферы (не столько привычные ИТ-проекты, но и “стройки века” и производственно-добывающие проекты). Сейчас комплексных материалов в этой сфере сильно не хватает, имхо, если знаете - напишите в комментах.

• Здоровая хардкорность. Да, тут не заскучаешь над авторскими эмоциями и отступлениями. Книга на 70% состоит из математического аппарата, формул, которых "гуманитариям не понять" (с), но которые прекрасно впишутся в excel и ИСУП и помогут проекту. Авторы именно считают, а не оценивают эффективность проектного управления.

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

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

  

• Из этого складывается основа (скорее ТЗ) для интегрированной информационной системы управления проектами, которая должна собрать вместе всё: архитектуру, логику взаимодействия сторон, планы финансов/поставок/налогов, функции по всем стадиям жизненного цикла.

• Есть практическая оптика для разных ролей: таблицы с ожиданиями, целями, ограничениями и инструментами по каждой стороне призваны помочь быстро собрать «карту интересов» под конкретный портфель/программу. Причем тут без формул...

И есть особенности.

• Монографический стиль. Среди авторов - доктор технических наук, и книга ни разу не лайтовый гайд, к которым многие из нас привыкли, а солидная академическая работа с формальными постановками и алгоритмами. Листается в целом быстро, но ожидает от читателя готовности к моделям и матанализу.

• Математический аппарат - это и достоинство, и порог входа. Но, с другой стороны, есть понятные гуманитариям выводы, и если они ок, то дальше можно погружаться и в расчеты с шарящими коллегами.

• Логика “сверху вниз”, от универсальной модели проектного управления к конкретным календарям, ресурсам и т.д. Если привыкли «от Jira к стратегии», то придётся развернуть взгляд.

Резюме.
Рекомендую книгу, в первую очередь, PMO, руководителям портфелей/программ, менеджерам крупнобюджетных проектов, интеграторам и консультантам, кто “варится” в многосубъектных проектах с конфликтующими интересами.

Пан или MVP пропал! Дебаты на ProductCamp

Уже в эту субботу, 20 сентября, МойОфис организует жаркий баттл продуктологов в формате парламентских дебатов на ProductCamp. Никакой воды и эмоций — только факты и сильные аргументы.

Тема встречи: «Fail Fast наносит больше вреда качеству продукта и духу команды, чем приносит пользы?»

Мы обсудим, может ли быстрая «обкатка» сырой версии подорвать продукт и команду, и бывают ли ситуации, когда Fail Fast действительно оправдан.

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

Дебаты стартуют в субботу, 20 сентября, в 17:00 в большом шатре. Будет жёсткая профессиональная дискуссия без купюр и сантиментов!

Права на код и приложения: как ИТ-компании защитить интеллектуальную собственность и выстроить отношения с разработчиками

В ИТ-бизнесе главный актив - интеллектуальная собственность: код, программы, приложения, интерфейсы, алгоритмы.

Но именно здесь чаще всего возникают конфликты между работодателем и сотрудником-разработчиком: кому принадлежат права на созданный продукт?

Согласно ГК РФ, результаты интеллектуальной деятельности (РИД), созданные работником в рамках трудового договора, признаются служебным произведением. Это означает:

• исключительное право автоматически переходит работодателю;

• авторское право (право называться автором) остается за сотрудником;

• использование произведения работником без согласия работодателя запрещено.

Но важно: если работа выполнена по гражданско-правовому договору (например, подряд или услуги), то правило о служебном произведении не действует. В таком случае исключительное право сохраняется за исполнителем, если иное прямо не оговорено в договоре.

По данным ЭБР и Минцифры, в 2024 году количество судебных дел по авторским и смежным правам выросло на 35 % и составило около 28 800 дел. Общий рост споров по интеллектуальной собственности — около 5 %. При этом 84 % всех споров касались именно исключительных прав.

Это значит: ключевая проблема в ИТ-компаниях — отсутствие должного оформления прав на код, программы и приложения.

Если компания не закрепит права документально, то:

• разработчик вправе требовать компенсацию за нарушение его исключительных прав (ст. 1301 ГК РФ);

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

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

Практики защиты интеллектуальной собственности в ИТ-компаниях

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

Должностная инструкция
Включать обязанности по созданию РИД, а также условия соблюдения режима коммерческой тайны.

Служебные задания и фиксация результатов
Формализовать приказами каждое задание работнику по разработке РИД и фиксировать факт передачи готового результата (например, через акт приема-передачи).

Отдельное вознаграждение за РИД
Выплачивать авторское вознаграждение отдельно от зарплаты. Регулярность таких выплат — доказательство факта создания служебного произведения.

Ведение внутреннего реестра разработок
Каталог проектов и модулей с информацией об авторах, дате создания, исходных материалах. Это облегчает защиту прав.

Использование систем контроля версий.
История изменений может служить доказательством в случае спора.

Локальные нормативные акты
В компании должны действовать положение о порядке создания и передачи РИД, регламент вознаграждений авторам, правила документооборота.

Режим коммерческой тайны
В отличие от соглашений о конфиденциальности, режим коммерческой тайны действует и после увольнения сотрудника. Он фиксируется внутренними актами, приказами, перечнями сведений.

Технические меры защиты
Лицензионные ключи, шифрование, контроль доступа к репозиториям, аудит использования библиотек (особенно open source).

Своевременная регистрация РИД в Роспатенте на работодателя с указанием авторов.

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

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

Больше интересного на моем канале.

ТОП-5 КНИГ, которые изменили мое видение управления

Всем привет! Меня часто спрашивают, что почитать для развития CEO-мышления. Делись своей подборкой книг, которые дали мне больше всего инсайтов.

1. «The Hard Thing About Hard Things» Бена Горовица
   Самая честная книга о кризисах, принятии сложных решений и выживании бизнеса. Никакой теории — только личный опыт вывода компаний из пропасти.
   Ключевой инсайт: «Иногда нет правильных решений. Есть только твое решение и готовность его реализовать».

2. «Good Strategy / Bad Strategy» Ричарда Румельта
   Лучший антидот от пустых словосочетаний вроде «стать лучшим на рынке». Учит отличать реальную стратегию от ее имитации.
   Ключевой инсайт: «Сердце хорошей стратегии — диагностика главного вызова и концентрация ресурсов на его решении».

3. «High Output Management» Энди Гроува
   Библей операционного управления от легендарного CEO Intel. Как создавать системы, которые работают без твоего постоянного вмешательства.
   Ключевой инсайт: «Выход менеджера = выход его команды × его влияние на смежные команды».

4. «The Innovator’s Dilemma» Клейтона Кристенсена
   Почему стоит читать: Объясняет, почему успешные компании умирают, игнорируя «подрывные» инновации. Must-read для тех, кто думает о долгосрочном росте.
   Ключевой инсайт: «Рынки меняются быстрее, чем любые компании. Выживают те, кто учится меняться вместе с ними».

5. «The First 90 Days» Майкла Уоткинса
   Лучшее руководство для мягкого входа в новую роль CEO. Десятки практических фреймворков для диагностики и планирования.
   Ключевой инсайт: «Ваша цель — не доказать свою правоту, а понять реальное положение дел и адаптироваться к нему».

Бонус для своих:
Также рекомендую обратить внимание на:

«Thinking, Fast and Slow» Канемана (принятие решений)
«Measure What Matters» Доерра (про OKR)
«Leaders Eat Last» Сина (лидерство)

Что из этого читали? Какие книги добавите в список? Жду ваши рекомендации в комментариях! 📚

Почему агентский бизнес без табличек — это рулетка

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

Именно поэтому я с первого дня решил, что нужно вести учёт финансов. Мы настроили отчёт о движении денежных средств (ДДС), потом добавили платёжный календарь и P&L. Выглядит это в виде красивых дашбордов.

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

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

🔥 Конференция BOOST 2025 уже совсем скоро

23–24 сентября в Кампусе Школы управления «Сколково» пройдёт BOOST 2025 — крупнейшая конференция для руководителей агентств, студий и продакшенов. Более тысячи участников, мастермайнды, воркшопы, вечерние активности и, конечно, доклады от практиков бизнеса.

В программе:

— управление бизнесом;
— продажи и развитие;
— управление проектами;
— маркетинг и PR;
— управление разработкой;
— дизайн и креатив;
— digital-маркетинг.

📌 А 24 сентября в 11:00 на сцене выступит Асатур Хачатрян, соучредитель ITFB Group, с докладом:
«Диверсификация против Фокуса: как двигаться в эпоху турбулентности».

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

📍 Место: Кампус Школы управления «Сколково»
🗓 Даты: 23–24 сентября
🔗 Регистрация

Новые правила передачи данных банками и операторами связи в 2025–2026 годах: что изменилось в законах

В 2025 году утверждены два постановления Правительства, которые вводят новые правила взаимодействия банков и операторов связи с государственными органами через систему межведомственного электронного взаимодействия (СМЭВ). Оба документа направлены на обеспечение доступа к сведениям, которые могут понадобиться для оперативно-розыскной деятельности и обеспечения безопасности РФ.

Новые постановления напрямую связаны с изменениями в законодательстве, вступившими в силу весной 2025 года.

• Статья 9 Федерального закона о банках и банковской деятельности с апреля 2025 года обязывает кредитные организации предоставлять сведения уполномоченным органам через МЭВ в сроки и формате, которые устанавливаются Правительством РФ совместно с Банком России.

• Статья 46 Федерального закона «О связи» закрепила аналогичную обязанность для операторов связи.

 До этих изменений порядок был иным:

• правоохранительные органы направляли запросы в банки и операторам связи в бумажном или электронном виде напрямую;

• не существовало единого формата и технического канала передачи данных.

Для банков (ПП РФ от 30.08.2025 № 1344).

Правила вступят в силу с 1 марта 2026 года

Подключиться к системе банкам нужно до 31 августа 2026 года. Минцифры обещает техническую поддержку и предоставление адаптера СМЭВ бесплатно.

В соответствии с правилами Банки будут обязаны по запросам органов передавать через систему межведомственного электронного взаимодействия (далее – СМЭВ) широкий перечень данных о клиентах.

Передаваться будут:

• сведения о счетах и вкладах, движении средств по ним;

• место и время выдачи наличных;

• телефонные номера, связь по которым оплачивается картой или иным средством платежа клиента;

• участие клиента в брокерской деятельности;

• данные о сейфовых ячейках.

Если у банка нет запрашиваемой информации - он обязан сообщить об этом.

При нарушении формы запроса (например, отсутствует номер, дата, ссылка на правовое основание) банк возвращает его без рассмотрения и объясняет причину.

Сроки в правилах указано, что в соответствии со ст. 26 ЗаконА о банках, но четкого срока установить не удалось.

Для операторов связи (ПП РФ от 29.08.2025 № 1316)

Правила вступили в силу уже с 1 сентября 2025 года, а к СМЭВ операторы должны подключиться до 28 февраля 2026 года.

 Сроки передачи данных гораздо жестче, чем для банков:

• в течение 24 часов с момента получения запроса нужно передать основные сведения;

• на дополнительные данные (например, историю использования номера за три года) дается 72 часа.

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

 Передаваться будут:

• Ф.И.О. абонента, дата рождения, адрес;

• паспортные данные;

• дата заключения договора об оказании услуг связи;

• дата последнего использования номера.

Есть и технические ограничения: мобильные операторы не могут передавать более 0,05% сведений от всех своих номеров в сутки, для остальных операторов лимит — 0,03%. Это сделано, чтобы избежать перегрузки системы и массовой выгрузки информации.

Как юрист я вижу несколько ключевых моментов:

Баланс между безопасностью и правами клиентов. Наши данные становятся более доступными для правоохранительных органов.

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

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

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

Больше интересного на моем канале.

Продакт, отпусти! Как перестать всё тащить на себе и взрастить сильную команд

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

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

• Почему важно отдавать команде право самим планировать сроки и брать ответственность.

• Как простое делегирование делает метрики прозрачнее, а тимлида — свободнее.

• Про проверенные практики взросления команды.

• Как поддерживать моральный климат и не дать команде выгореть.

Обязательная маркировка звонков для бизнеса с 1 сентября 2025 года: что нужно знать?

Внимание, бизнес: с 1 сентября 2025 года все исходящие звонки с корпоративных номеров на мобильные должны быть маркированы.

Рассказываю кратко, что это значит и к чему готовиться.

Согласно Постановлению Правительства РФ от 28.08.2025 № 1300, все юридические лица и индивидуальные предприниматели обязаны обеспечить маркировку исходящих звонков на мобильные номера.

Это значит, что при звонке на экране абонента должно отображаться название компании или ИП, а также категория вызова.

Подчеркну - маркировка звонков обязательна для всего бизнеса.

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

Что будет отображаться:

Наименование юридического лица или Ф.И.О. индивидуального предпринимателя.

Категорию вызова (например, «банк», «доставка», «медицина»).

Коммерческое обозначение (если оно есть).

Текст для отображения ограничен 32 символами, включая буквы кириллицы или латиницы и цифры.

Законодатель говорит о том, что новые правила направлены на:

Борьбу с мошенничеством: граждане смогут отличать легитимные звонки от подозрительных.

Повышение доверия: клиенты чаще будут отвечать на звонки, если увидят название знакомой компании.

Улучшение деловой репутации: бизнес получит дополнительный инструмент для узнаваемости.

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

Маркировка звонков — платная услуга.

Тарифы зависят от оператора связи. Например, некоторые операторы взимают плату за каждый маркированный звонок.

А значит это дополнительных расходы бизнеса.

Отдельная сложность для ИП, которые работают в одиночку, рекламные звонки не осуществляют, но созваниваются с клиентами в рамках имеющегося сотрудничества, им тоже нужно заключать договор?

Ответ - да, и им тоже.

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

То есть,исключений нет, но есть три варианта:

1. Не звоним клиентам сами.

2. Используем мессенджеры.

3. Все-таки узнаем стоимость и заключаем договор, заводим отдельный номер для бизнеса.

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

Также существует риск потери клиентов: абоненты могут проигнорировать звонок без идентификатора.

Но прямых штрафов за отсутствие маркировки пока нет.

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

В договоре должны быть указаны:

Наименование компании или Ф.И.О. предпринимателя.

Коммерческое обозначение (если есть).

Категория вызовов (на основе ОКВЭД).

Текст для отображения (до 32 символов).

Список номеров, с которых осуществляются звонки.

Для подключения также понадобится предоставить оператору документы:

ИНН, данные о виде деятельности, перечень корпоративных номеров, а также настроить отображение через личный кабинет оператора или с помощью технической поддержки.

Правила действуют в течение шести лет.

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

Постановление Правительства РФ от 28.08.2025 № 1300

Планируете подключать маркировку? Сталкивались уже с тарифами операторов? Делитесь в комментариях, обсудим вместе.

Nuclearn — AI для ядерной энергетики

Может заметили как изменились анонсы новых дата-центров: раньше писали про процессоры и хранилища, теперь про доступную энергию в гигаваттах. Этому есть вполне понятное объяснение. Генеративный AI требует всё больше электричества, и ядерная энергетика становится еще более актуальной. На этом фоне в США идут крупные инвестиции в атомную отрасль, упрощаются законы, появляются стартапы. Один из них - Nuclearn, и он работает не над реакторами напрямую, а делает AI-инструменты, которые упрощают работу тем, кто их строит и обслуживает.

Сам по себе атом вызывает тревогу с этим ничего не поделать, но с другой стороны, он стабильно производит энергию без выбросов CO₂, в отличие от угля или газа, да еще и зависимость снижается от других стран. А в случае с новыми АЭС это еще и компактность, масштабируемость и отказоустойчивость. Проблема в другом: отрасль зарегулирована, переполнена ручным трудом и теряет опытных инженеров. Nuclearn решил автоматизировать всё, что можно, не снижая уровень контроля.

Стартап развивает свою собственную языковую модель, натренированную на документах от регулирующих органов, включая NRC. Она помогает в:

• анализе рисков и слабых мест перед лицензированием новых объектов;

• генерации отчётов и документации, включая обновление лицензий;

• проверке безопасности и проектных спецификаций;

• планировании ремонтов и поиске устаревших комплектующих;

• повышении эффективности при дефиците специалистов;

• адаптации решений под специфику ядерной отрасли.

Команда бывшие сотрудники атомной станции Palo Verde. То есть они сначала страдали от бумажной рутины, а потом решили автоматизировать её для всех. И результат: сокращение задач с 400 часов до одного дня впечатляет.

Сравнивая с другими AI-продуктами, здесь чёткая вертикаль, высокая цена ошибки и узкая экспертиза. То есть это не “просто GPT обертка", а действительно индустриальное решение, рассчитанное на суровую регуляторную среду.

Так что выходит почти замкнутый круг: AI требует энергии → энергия требует атома → атом требует AI, вот и пошла цепная реакция. Недавно стартап привлек $10,5 млн. на развитие продукта и дальнейшее масштабирование. Уже работают на 65 реакторах.

Про другие стартапы пишу тут.

На сайте Сколково вышла история о том, как мы перестраиваем культуру от проектной к продуктовой.
Главный инсайт — технологии сами по себе мало чего стоят. Важно проверять спрос, быстро тестировать идеи и выводить на рынок только то, что реально нужно клиентам.
В итоге мы выстроили систему R&D, научились работать с гипотезами и запустили собственные продукты. Это не только про рост бизнеса, но и про смену культуры внутри команды.

Каждая идея проходит определённые этапы: исследования, прототипирование, планирование продукта и реализация MVP. Идеи "отваливаются" на каждом этапе и это позволяет сделать процесс более дешевым и не "тащить" за собой идеи, которые в последствии не примет рынок.
Таким образом, повышается вероятность продукта на рынке.
На картинке ниже схематично представлена воронка идеи от этапа к этапу. Из 100 идей до вывода на рынок доходят примерно 7, это среднее значение по акселераторам крупных компаний.

Ссылка на публикацию: https://lnkd.in/ez3Qx26y

Провидец поневоле

Пару дней назад писал (https://habr.com/ru/articles/944756/) про supply chain-атаки и то, что зависимостям доверять на 100% — плохая идея.

И вот — крупнейшая атака в истории npm.

8 сентября хакеры через фишинговое письмо угнали аккаунт известного разработчика. Скомпрометировали даже 2FA.

В npm вылетели вредоносные версии debug, chalk и ещё около 16 пакетов. Общий охват — 2.6 миллиарда загрузок в неделю.

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

Внимание! Ущерб!
Он оказался смехотворным, украли они… около $500.
По одной версии — даже меньше $50. Весь этот хай-тек-рэкет ради пары мем-коинов.

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

Дейлики: благо или зло?

В новом выпуске подкаста «Свободный слот» Саша Прокшина и Паша Федотов разбирают принципы грамотного планирования. Обсуждаем:

• какими должны быть идеальные итоги встречи?

• как выглядят секреты эффективной фасилитации и perfect follow-up?

• и конечно, как выстроить день так, чтобы успеть всё?

А в финальной рубрике «Встреча — или текстом» попробуем найти ответ на вечный вопрос: сколько людей нужно, чтобы согласовать цвет кнопки, утвердить формат даты и решить другие, не менее судьбоносные задачи?

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Как машинки помогли выявить лучших продавцов

Когда я работал исполнительным директором в Smartykids, в нашем отделе продаж было 12 менеджеров. Мы пытались по-разному мотивировать продавцов и фокусировать их на результате.

У нас в офисе был установлен колокол. Когда приходила оплата, ответственный за оплату менеджер шёл и бил в колокол.

Также мы купили магнитную доску и расположили на ней 12 машинок. У каждого менеджера был месячный план в 1 млн рублей. Каждый день на планёрке менеджеры двигали эти машинки. Так все видели, кто сколько продал в этом месяце.

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

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

«О чем на самом деле думает проджект-менеджер во время митинга: перевод с корпоративного на русский»

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

Про оценку сроков

Каждому проджекту знакомо. Митинг с заказчиком и командой, вдруг, не согласовав оценку с менеджером, разработчик говорит: «Ну, это задача дня на четыре... Если ничего не помешает».
Тут же слышится от заказчика: «Фиксируем, через 4 рабочих дня будет готово».
Вспышка, шторм, помешательство. У проджекта в голове: «Ага, “Если ничего не помешает”, так вам ничего и не помешает, конечно. Сейчас начнется: мало ресурсов на сервере, срочный баг от другого клиента, а тестирование? В этой оценке указана только время разработки! Минимум неделя нужна. А обещать буду за 7 рабочих дней».
Проджект тут же говорит вслух на корпоративном: «Предлагаю заложить на задачу 7 рабочих дней с учетом возможных рисков и интеграции в основной процесс. Нужно обстоятельно убедиться, что функционал готов к релизу».
Заказчик недоверчиво фиксирует 7 рабочих дней на задачу — фух, пронесло 😓

Про «немного поменять ТЗ»

Это из фонда золотых цитат заказчиков: «Мы тут подумали и хотим немного улучшить концепцию. Фактически, всё остается по-старому, просто логика немного меняется».
С этого начинается внутренний диалог проджекта: «„Улучшить концепцию“... Это значит пришить к штанам капюшон и выкинуть 3 недели работы. „Логика немного меняется“ — это сделаем из грузовика экскаватор, новый движок, новая база данных и отказ от всего, что уже сделано».
Проджект говорит вслух: «Понимаю ваше стремление к улучшению! Давайте проведем отдельную встречу вместе с аналитиком, где вы подробно расскажете о новой концепции. Мы проведем анализ, посчитаем новые сроки и бюджет и обсудим решение».
(редко кто меняет изначальную логику, увидев новые сроки и бюджет 😉)

Работа PM — это искусство баланса между желаемым, возможным и реализуемым. Главное — сохранять спокойствие и дальновидность.

Подписывайтесь здесь или в тг: @projectmindset_pm

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

Логично предположить, что HR не ожидают увидеть там репозитории рабочих коммерческих проектов, а всего лишь хотят посмотреть на pet-проекты или вклад в open source.

Но на месте работодателя стоит задаться вопросом: «Когда разработчик этим занимался?»

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

А если кандидат занимался pet-проектами после основной работы, то у меня для вас плохие новости.

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

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

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

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

Есть несколько советов о том, как не зацикливаться на работе.

Во-первых, необходимо делать небольшие перерывы в течение рабочего дня.

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

Во-вторых, в офисе очень важны социальные контакты и поддержка.

Найдите на работе приятеля, с которым у вас совпадают хобби, или вовлекитесь в общую активность, принятую в вашей компании.

Это поможет вам не только переключиться, но и избавиться от чувства социальной исключённости.

В-третьих, планируйте работу на следующий день с вечера.

Чёткий план действий позволит не распыляться и закончить начатые задачи.

Иначе незакрытые гештальты будут преследовать вас вне офиса.

В-четвёртых, простройте чёткие границы между работой и домом.

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

Источники

• A Meta-Analysis on Antecedents and Outcomes of Detachment from Work

• Facilitating Detachment from Work: A Systematic Review, Evidence-Based Recommendations, and Guide for Future Research

• Detach to Thrive: Psychological Detachment from Work and Employee Well‑Being

Кого нанимать в стартап?

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

На что обращать внимание:

Высокая адаптивность и умение работать на скорости.   Для стартапа важно не получать сразу идеальный результат, а быстро внедрять новые фичи, делать одну итерацию за другой. Гораздо правильнее сделать 3 попытки внедрения новой функции за неделю, чем “выдать” идеальную за месяц.
Умение адаптироваться к меняющимся условиям позволит сотрудникам легче относиться к переменам и меньше выгорать.

Кросс-функциональность. Да, сотрудник стартапа - “многорукий многоног”, иначе не назовешь! Ваши сотрудники должны уметь закрывать множество компетенций, но самое главное - им должно это нравиться. Сотрудники, которые не любят (не могут) делать сверхзадачи или живут по принципу “это не мои обязанности” в стартапах не приживаются. Есть прекрасное сравнение: в зрелом устойчивом бизнесе сотрудники напоминают гирлянду - цепь из одинаковых лампочек, каждую из которых можно легко заменить. А вот в стартапе каждый - это яркая звезда, которую очень болезненно потерять.

Высокая мотивация. Сотрудник стартапа в идеале должен сам “гореть” идеей проекта. Это будет существенно влиять на результативность труда и атмосферу в команде.

Задавайте “правильные” вопросы на собеседовании и ориентируйтесь больше на soft-skills: в стартапе это самое ценное! 

Что будет с человеком, если его перегрузить задачами до предела? Ну конечно - он выгорит.

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

1. Падение продуктивности. Он не хочет делать лучше и быстрей, только допустимый минимум. К тому же выгоревшие люди ищут причины, чтобы избежать работы и чаще берут больничные.

2. Падение качества. Это влияет на количество инцидентов и тогда риски возрастают кратно. Восстановление, репутация, штрафы. Например, утечка персональных данных будет стоить до 15 млн только штрафа. А ошибки в мед- или авиаоборудовании могут стоить кому-то жизни.

3. Текучка. Если сотрудник выгорел, то время до его заявления на вашем столе уже пошло. И его не отговорить, он уже нашел интересную замену. А найм и адаптация нового сотрудника дорого. И есть угроза цепной реакции в коллективе.

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

На ИТ-рынке, в целом, заметен тренд на заботу о состоянии сотрудников. Хотя чаще он довольно поверхностный. Стандартный набор — ДМС, оплата спорта, тим-билдинг, корпоратив, индивидуальная работа с сотрудниками, материальная мотивация. Является ли это достаточным? На мой взгляд — мало, но допустимо. Например, психологов я в малом и среднем бизнесе не встречал, только изредка в корпоративном слое. Работу над положительной нематериальной мотивацией встречал где-то в 20-30% организаций.

Нулевого выгорания не достигли нигде (это невозможно из-за особенностей человеческой природы), но значительно снизить удавалось. Помню случай с ТехноНиколь времен пандемии — им за счет работы с выгоранием сотрудников удалось повысить производительность на 50%! По их оценкам они при этом снизили уровень выгорания с 80% до 20%.

Со стороны сотрудника:

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

Со стороны бизнеса:

Работа с выгоранием — это похоже на регулярную страховку: объем бюджета, который менеджмент готов потратить на проблему, и уровень риска, на который согласен. Где брать на это деньги? В фонде оплаты труда. Если выгорание присутствует — потери производительности — 5-50%. Это размер ФОТ, который потрачен впустую. Можно взять из будущего ФОТ 5% и получить прирост производительности в 10%. А это уже рост EBITDA и чистой прибыли.

Берегите себя, и своих сотрудников, коллеги!

И расскажите как у вас с этим?

Delivery Manager: где его место среди Project, Product и Program Manager?

Недавно я публиковал статью о различиях Project Manager, Product Manager и Program Manager. В комментариях закономерно возник вопрос: "А где же Delivery Manager?"

Давайте разберёмся!

В базовой статье я сознательно ограничился тремя ролями - PM, PdM, PgM.
Это клубок который действительно может ввести в ступор даже бывалых, который часто встречается в IT и лучше всего показывает разницу между управлением проектами, продуктами и программами.

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

Чем отличается: Delivery Manager = фокус на выполнении обязательств команды и стабильности поставки.

• Project Manager отвечает за проект: сроки, бюджет, риски.

• Product Manager отвечает за ценность и развитие продукта.

• Program Manager отвечает за синхронизацию множества проектов и продуктов.

• Delivery Manager отвечает за то, чтобы команда реально и предсказуемо доставляла результат, а процессы разработки и поставки не ломались.

Задачи Delivery Manager-а

• Следить за здоровьем процессов в команде (Agile церемонии, velocity, SLA).

• Снимать операционные блокеры, чтобы команда могла работать.

• Координировать взаимодействие с другими командами (DevOps, QA, Support).

• Мониторить метрики поставки.

Когда Product Manager уходит в стратегию и общение с рынком, а Project Manager в бюджет и отчётность, команде часто нужен человек, который держит фокус на ежедневной предсказуемости поставки. В крупных организациях Delivery Manager становится опорой для нескольких команд разработки, снимая с PdM и PM часть операционных забот.

Метрики эффективности Delivery Manager:

• Velocity & Throughput - стабильность скорости команды.

• Lead Time & Cycle Time - скорость прохождения задач.

• Defect Rate - качество поставки.

• Team Satisfaction - насколько комфортно команде работать в текущем процессе.

Delivery Manager - это не конкурент Project/Product/Program Manager, а их дополнение.

• PM, PdM и PgM отвечают за "что и зачем" (стратегия, ценность, цели).

• Delivery Manager отвечает за "как именно" на уровне повседневной работы команды.

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

А у вас в компаниях, есть ли отдельные Delivery Manager-ы или их функции выполняют PM/PdM?

Безработица в российской ИТ отрасли продолжает расти

Индекс hh.ru достиг максимального значения за всю историю. Сейчас он равен 13,7. Это значит что количество открытых вакансий по отношению к размещенным резюме стало меньше чем когда-либо.

Сравнивая с показателями индекса в 2019 году, когда он равнялся 2,7 - можно сделать выводы что ИТ специалисты становятся менее востребованы.

https://habr.com/ru/articles/855608/ анализ индекса 2019-2024