В новом выпуске подкаста «Свободный слот»Саша Прокшина и Паша Федотов разбирают принципы грамотного планирования. Обсуждаем:
какими должны быть идеальные итоги встречи?
как выглядят секреты эффективной фасилитации и perfect follow-up?
и конечно, как выстроить день так, чтобы успеть всё?
А в финальной рубрике «Встреча — или текстом» попробуем найти ответ на вечный вопрос: сколько людей нужно, чтобы согласовать цвет кнопки, утвердить формат даты и решить другие, не менее судьбоносные задачи?
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Привет, я Юра, Project-менеджер с 10-летним стажем. Рассказываю о личном опыте в IT. тг: @projectmindset_pm
«О чем на самом деле думает проджект-менеджер во время митинга: перевод с корпоративного на русский»
На рабочих митингах мы все разговариваем на корпоративном языке, так уж заведено. Разработчики, которые умеют не только писать код, но и разговаривать на корпоративном языке, со временем становятся тимлидами и техническими директорами. Но что такое этот корпоративный язык? Покажу вам глазами проджект-менеджера.
Про оценку сроков
Каждому проджекту знакомо. Митинг с заказчиком и командой, вдруг, не согласовав оценку с менеджером, разработчик говорит: «Ну, это задача дня на четыре... Если ничего не помешает». Тут же слышится от заказчика: «Фиксируем, через 4 рабочих дня будет готово». Вспышка, шторм, помешательство. У проджекта в голове: «Ага, “Если ничего не помешает”, так вам ничего и не помешает, конечно. Сейчас начнется: мало ресурсов на сервере, срочный баг от другого клиента, а тестирование? В этой оценке указана только время разработки! Минимум неделя нужна. А обещать буду за 7 рабочих дней». Проджект тут же говорит вслух на корпоративном: «Предлагаю заложить на задачу 7 рабочих дней с учетом возможных рисков и интеграции в основной процесс. Нужно обстоятельно убедиться, что функционал готов к релизу». Заказчик недоверчиво фиксирует 7 рабочих дней на задачу — фух, пронесло 😓
Про «немного поменять ТЗ»
Это из фонда золотых цитат заказчиков: «Мы тут подумали и хотим немного улучшить концепцию. Фактически, всё остается по-старому, просто логика немного меняется». С этого начинается внутренний диалог проджекта: «„Улучшить концепцию“... Это значит пришить к штанам капюшон и выкинуть 3 недели работы. „Логика немного меняется“ — это сделаем из грузовика экскаватор, новый движок, новая база данных и отказ от всего, что уже сделано». Проджект говорит вслух: «Понимаю ваше стремление к улучшению! Давайте проведем отдельную встречу вместе с аналитиком, где вы подробно расскажете о новой концепции. Мы проведем анализ, посчитаем новые сроки и бюджет и обсудим решение». (редко кто меняет изначальную логику, увидев новые сроки и бюджет 😉)
Работа PM — это искусство баланса между желаемым, возможным и реализуемым. Главное — сохранять спокойствие и дальновидность.
Что будет с человеком, если его перегрузить задачами до предела? Ну конечно - он выгорит.
Выгоревший сотрудник это реальная проблема, а не «загрустил, пройдет». Она имеет такие вполне конкретные последствия:
Падение продуктивности. Он не хочет делать лучше и быстрей, только допустимый минимум. К тому же выгоревшие люди ищут причины, чтобы избежать работы и чаще берут больничные.
Падение качества. Это влияет на количество инцидентов и тогда риски возрастают кратно. Восстановление, репутация, штрафы. Например, утечка персональных данных будет стоить до 15 млн только штрафа. А ошибки в мед- или авиаоборудовании могут стоить кому-то жизни.
Текучка. Если сотрудник выгорел, то время до его заявления на вашем столе уже пошло. И его не отговорить, он уже нашел интересную замену. А найм и адаптация нового сотрудника дорого. И есть угроза цепной реакции в коллективе.
Потеря экспертизы. Каждый сотрудник уже встроен в систему, знает все процессы, технологии, несет какие-то уникальные знания о своих задачах. Нельзя выдернуть одного и вставить другого как деталь. Свой опыт ушедший заберет с собой. Иногда такие потери могут быть весьма значимыми.
На ИТ-рынке, в целом, заметен тренд на заботу о состоянии сотрудников. Хотя чаще он довольно поверхностный. Стандартный набор — ДМС, оплата спорта, тим-билдинг, корпоратив, индивидуальная работа с сотрудниками, материальная мотивация. Является ли это достаточным? На мой взгляд — мало, но допустимо. Например, психологов я в малом и среднем бизнесе не встречал, только изредка в корпоративном слое. Работу над положительной нематериальной мотивацией встречал где-то в 20-30% организаций.
Нулевого выгорания не достигли нигде (это невозможно из-за особенностей человеческой природы), но значительно снизить удавалось. Помню случай с ТехноНиколь времен пандемии — им за счет работы с выгоранием сотрудников удалось повысить производительность на 50%! По их оценкам они при этом снизили уровень выгорания с 80% до 20%.
Со стороны сотрудника:
Следите за графиком и эмоциональным состоянием: тайм-менеджмент и дофаминовые мелочи - обязательная программа. На короткой дистанции переработка не критична, но на постоянке доведет до дауншифтинга в деревню. Просите фидбек от руководства - часто в депрессию загоняет комплекс самозванца, и не по делу. Вовремя давайте фидбек обратно - наверняка руководитель не захочет потерять сотрудника, и найдет способ изменить ситуацию.
Со стороны бизнеса:
Работа с выгоранием — это похоже на регулярную страховку: объем бюджета, который менеджмент готов потратить на проблему, и уровень риска, на который согласен. Где брать на это деньги? В фонде оплаты труда. Если выгорание присутствует — потери производительности — 5-50%. Это размер ФОТ, который потрачен впустую. Можно взять из будущего ФОТ 5% и получить прирост производительности в 10%. А это уже рост EBITDA и чистой прибыли.
«СберТех», Cloud.ru и Хабр заколлабились и запустили грантовую программу «Код без границ». Это отличная мотивация для разработчиков и ресурсы для проектов. Можно доработать свой проект с поддержкой сообщества, найти единомышленников и показать свои возможности.
Участвовать просто:
разместить свой проект на GitVerse (СберТех) или импортировать его с другой площадки.
делится кодом и вдохновляться чужими разработками.
Номинации следующие: ИИ‑инновации, «Наука и образование», «Проекты для всех», «Разработка для разработчиков».
Заявки на грантовую программу «Код без границ» принимаются с 3 сентября по 31 октября. Отбор проведут в ноябре, а результаты огласят в декабре.
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?
Ну что вы скажете? С 12 минут до 3 секунд(!) сократил время поиска инструкций полнотекстовый поиск в KMS Gran.
Один из наших клиентов - IT-компания - хранила документацию в Google Docs и Telegram, что вызывало путаницу. В 2024 году внедрили базу знаний KMS Gran, создав разделы "Проекты", "API-документация" и "Ошибки и уроки".
Результат спустя год:
время поиска инструкций сократилось до 3 секунд
скрипты автоматизировали уведомления о новых версиях API, уменьшив время согласования релизов на 30%.
за 6 месяцев количество багов в коде снизилось на 25%, так как разработчики быстро находили решения по прошлым ошибкам.
Статистика показала, что раздел "Ошибки и уроки" просматривали 80% команды, что привело к добавлению видео-разборов типичных ошибок.
А какие процессы хотелось бы улучшить в вашей команде?
Компания PVS-Studio и платформа Securitm заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.
Облачный сервис и программное обеспечение SGRC Securitm позволяют построить управление информационной безопасностью на базе риск-ориентированного подхода и единой информационной модели компании.
Отчёт анализатора PVS-Studio стало возможным загрузить в Securitm для дальнейшего использования с помощью пользовательского интерфейса системы.
Подробнее о том, как загрузить отчёт анализатора PVS-Studio в систему Securitm можно прочитать в посвящённом этому разделе нашей документации.
Также мы с коллегами из Securitm провели совместный вебинар, на котором обсудили, как обеспечить соблюдение требований ГОСТ в области РБПО, а также показали реальные примеры использования PVS-Studio и Securitm.
Почему ваша архитектура ломается? Спросите у того, кто чинил десятки таких систем!
04.09.2025 в 15:00 (Мск) приглашаемна первую открытую AMA-сессию «Спроси меня о чем угодно» с Дмитрием Овчаренко — техническим директоромдепартамента«Разработка для финансового сектора» IBS и экспертом Учебного центра IBS по архитектуре ПО.
Что вас ждёт (и почему это не обычный вебинар):
✔️ Без воды — только честные ответы на ваши вопросы (даже на те, о которых стыдно спросить).
✔️ Разбор реальных косяков — как ломались системы и что с этим делали.
✔️ Карьерный лифт — что нужно, чтобы перейти из разработчика в архитекторы?
А еще конкурс:
Пришлите самый нестандартный, забавный или абсурдный вопрос в комментариях к этому посту. Автор лучшего получит приз!
Кому полезно?
➕ Разработчикам, которые хотят расти до архитекторов.
➕ Аналитикам, уставшим от абстрактных советов.
➕ Всем, кому интересно, как устроена «кухня» fintech.
Компания PVS-Studio и Inseq заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.
Программное обеспечение Inseq RBPO предназначено для создания и управления конфигурациями, необходимыми для автоматического развёртывания и настройки компонентов инфраструктуры безопасной разработки ПО — систем контроля версий, анализаторов кода, инструментов автоматизации сборки, тестирования и развёртывания. Управление конфигурациями и политиками безопасности осуществляется централизованно.
"ИНСЕК.РБПО" представляет собой клиент-серверную систему, работающую на локальном оборудовании. Она включает серверную часть, генерирующую конфигурационные файлы, и веб-приложение с графическим интерфейсом для взаимодействия с пользователями.
Внутри этой платформы стало возможным использовать статический анализатор PVS-Studio для поиска критических ошибок в исходном коде.
Также мы провели вебинар с коллегами из Inseq, в котором поговорили о необходимости регулярного статического анализа, а также в целом об автоматизации в РБПО.
Красные флаги в код-ревью: перегибы, которых лучше избегать
Фокус на мелочах. Если уделять много внимания опечаткам и код-стайлу, то времени уйдет много, а реальных результатов будет мало. Главное — это всё-таки архитектура, алгоритмы и производительность, а косметика только на втором плане. Зачем портить настроение себе и команде, если можно ничего никому не портить?
Поверхностный анализ. Забивать на проверку кода — тоже плохая идея. И дело даже не в багах, их отловит тестировщик. Дело в безопасности всей системы. Если какой-нибудь хакер найдет уязвимость, которую QA не нашел, — жди беды. Ну и техдолг никто не отменял: если не делать сразу хорошо, однажды придется переделывать.
Токсичность. Во время код-ревью лучше всё-таки искать потенциальные проблемы с кодом, а не учить коллег работать. То есть фокус внимания — не на поиске недостатков в чужой работе, а на самом коде. А личные предпочтения и вкусы относительно кода лучше обсуждать отдельно.
Обратную связь стоит давать вдумчиво — подбирать слова и контролировать интонацию. Фидбек должен быть таким, чтобы у разработчика не возникало ощущения, будто он ни на что не годится.
А каким должен быть хорошее код-ревью — в нашем блоге.
Эффект «стены Дурова», который я открыл за 10 лет до самого Дурова
По студенчеству я, как и любой джун, совершал ошибки. Одна из них — классический пример истины «работает — не трожь».
2004 год. Я на 3-м курсе факультета прикладной математики и информатики АГУ (г. Майкоп), параллельно работаю программистом в математической школе при университете. Моя вотчина — программа для подсчёта рейтингов учеников, набор текстов для методичек и небольшой сайт с гостевой книгой.
Кто не застал — гостевая книга тогда была чем-то вроде бесконечного чата без регистрации. У детей мат. школы в ней кипела жизнь: по 100–200 сообщений в день (иногда даже больше), свои шутки, обсуждения задачек, разговоры «за жизнь». Формат был простой и лёгкий — написал ник, сообщение, и готово.
А я молодой, амбициозный и несу людям счастье)))
Я тогда подумал. Почему они мучаются с этим бесконечным тредом сообщений? Это же жутко неудобно! А что если я уберу эту гостевую книгу и заменю ее на удобный форум для своих? Хорошая же идея? Ну, если судить логически, то да. Свой форум, регистрация, понятно, кто пишет, можно делать свои темы и не тонуть в бесконечной беседе. На тот момент мне казалось, что это отличная идея сделать жизнь определенного круга людей лучше.
Нашел на просторах хороший движок и в один прекрасный день заменил гостевую книгу на этот форум. Создал темы и стал ждать, как мне люди скажут спасибо.
Догадываетесь, что было дальше? )))
Правильно. Провал… Ученики не стали использовать новый форум!
Была попытка одного человека что-то написать, но когда никто не ответил, то и он перестал что-то писать + пара регистраций пользователей. Моя попытка это исправить ни к чему не привела. Я даже старые сообщения пользователей из гостевой книги загрузил в новый форум. Все бестолку. Сайт, у которого был отличный трафик, буквально за неделю перестали посещать.
Для меня это было потрясение. Как так вообще? Я же хотел сделать как лучше для пользователей! Почему они не стали использовать новый форум?
Рефлексия и мои мысли на эту тему прилагаются:
Новый форум не взлетел, т. к. старый был ламповый, легкий. Можно добавить одну запись под ником «Препод такой-то», а следующую «Иванов Иван». Было интересно переписываться в таком легком формате. Был вайб от использования такого формата. Может, помните в VK знаменитое: «Дуров, верни стену!»? Этот косяк Павла из той же оперы.
Если какой-то сервис работает хорошо, но, на твой взгляд, там все организовано очень нелогично, не надо это исправлять сию минуту! Надо сделать опрос, проверить гипотезы, попробовать узнать мнение пользователей. Бывает, конечно, и такое, что пользователи не могут тебе сказать, что нужно добавить, и при добавлении этого «чего-то» оно действительно взлетает, но делать это нужно аккуратно, просчитывая варианты.
Этот студенческий урок 20-летней давности я вспоминаю до сих пор каждый раз, когда моя команда предлагает «быстро улучшить» какой-нибудь работающий модуль. Часто при взгляде на проблему задаю себе вопрос: «Какую настоящую работу выполняет для пользователя этот старый, неудобный, но привычный функционал? И не убьем ли мы ту самую "ламповость", просто заменив ее на "правильное" решение?»
Вот такая история.
P. S. Если кто-то читает мой пост из тех, кто тогда сидел в этой гостевой книге, прошу у вас прощения. Я не хотел, чтобы так все вышло.
---
Понравилась эта история? Это пример того, как я анализирую ошибки и извлекаю из них практические уроки. В моем ТГ канале Код ИТ-директора я гораздо чаще делюсь подобными мыслями, короткими кейсами и полезными инструментами, которые не всегда доходят до формата большой статьи.
Приглашаем вас на регулярную встречу фронтенд-сообщества в неформальной обстановке 28 августа. В этот раз — MoscowJS в гостях у Альфа-Банка.
В программе:
От JavaScript к DeFi: как инженеры могут изменить мир финансов. Спикер: Даниил Швецов, Full Stack Engineer. Доклад познакомит JavaScript-инженеров с основами DeFi: ключевыми концепциями, математическими моделями и работой с JS SDK.
Архитектура микрофронтендов: от А до Single Spa. Спикер: Павел Шлыков, Team Lead Frontend. Поговорим о микрофронтендах с нуля: от принципов и базовой реализации до инструментов вроде Module Federation и single-spa. Разберёмся, как всё устроено, и рассмотрим нестандартные подходы.
Под капотом платформы. Спикер: Антон Марченко, Ведущий разработчик. Доклад об опыте сборки платформы из готовых решений и объединения приложений через iframe, Module Federation и webview. Узнаете про выбор подходов и работу с командами.
Гильдия: место, где разработчик перестаёт быть одиноким кузнецом. Спикер: Владислав Сазонов, Head of Frontend. Чувствуете себя одиноким фронтендером? Есть решение — гильдия. В докладе — о том, как этот формат помогает расти, делиться опытом и не выгорать, а также краткий исторический экскурс.
Присоединяйтесь онлайн и офлайн — зарегистрироваться можно по ссылке.
Где: г. Москва, Андропова пр-т., 18, к. 3 (офис Альфа-Банка)
OpenAI выпустила GPT-5. Разница между GPT-4 и GPT-5 примерно как между студентом и доктором наук, заявлил Сэм Альтман.
GPT-5 является самой мощной существующей моделью для кодинга. Она может выстраивать более сложные цепочки действий и писать более сложный код в одном стиле. Простым промптом можно создать функционирующее веб-приложение — на презентации сгенерировали Duolingo платформу для изучения французского языка с полноценными дизайном, анимациями, озвучками и игрой. Новая модель значительно меньше склонна к галлюцинациям — она будет меньше врать и притворяться. Также она стала гораздо менее «подхалимской». Тексты, генерируемые GPT-5, стали более естественными и человечными. Вместе с этим модель лучше понимает и исправляет свои ошибки. ChatGPT интегрируют в Gmail и Google Календарь на следующей неделе. Можно будет управлять как электронной почтой, так и своим расписанием прямо в чате. GPT-5 сама определяет, как лучше ответить — быстро или «подумав».
GPT-5 умеет не только вести разговор, но и выполнять реальные задачи: создавать приложения, планировать календарь, проводить исследования. Она сама определяет, как лучше ответить — быстро или «подумав». Модель справляется с генерацией кода, выдаёт меньше галлюцинаций, и даже даёт более точные ответы на медицинские вопросы.
По тестам GPT-5:
Обходит Claude Opus 4.1 и Gemini 2.5 Pro в программировании
Слегка уступает Grok 4 Heavy в тесте «Humanity’s Last Exam»
Отвечает на медицинские вопросы с ошибками всего в 1.6% случаев (у GPT-4o — 12.9%)
Ведёт себя безопаснее: меньше обманывает, точнее различает вредные и безопасные запросы.
Платные подписчики Plus и Pro получили доступ к более мощной версии GPT-5 Pro. В API теперь доступны три размера: gpt-5, mini и nano.
GPT-5 можно попробовать в Cursor — тут, и в Copilot — тут.
Компания PVS-Studio и платформа Hexway заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.
Hexway VamPy — это решение, агрегирующее данные о безопасности из разных источников для работы с уязвимостями.
В Hexway стало возможным загрузить результаты анализа PVS-Studio в виде отчёта и работать с конкретными ошибками так же, как это позволяют другие инструменты. Загрузка возможна двумя способами: через пользовательский интерфейс или командную строку с использованием CLI-инструментов.
Подробнее о том, как загрузить результаты анализа PVS-Studio в Hexway VamPy можно прочитать в соответствующем разделе нашей документации.
Говорим на языке событий: что даёт ивент-шторминг и как его правильно провести
Привет! Я Иван Чернов, системный архитектор, в этом посте расскажу про ивент-шторминг.
В Островке есть набор сервисов, который разбит на логические блоки так, чтобы в рамках блока можно было итерировать: Островок, Островок B2B и Островок Командировки. При этом запускать новые фичи, которые будут сквозь эти слои прорезаться.
Мы растём по количеству и продуктов, и людей, нанятых для их разработки. Недавно начали толкаться локтями: не понимали, как качественно контрибьютить в большие кодовые базы, как они должны эволюционировать. Поэтому пришли к ивент-штормингу.
Что это за практика? На встрече с одной стороны сажаем бизнес, с другой — разработку. Просим бизнес рассказать, что и как он делает в работе с клиентом.
Ивент-шторминг проводится с фокусом на цикличную реактивность: происходит событие, которое визуально меняет что-то для пользователя, тот принимает решение и отдаёт команду, команда приводит к новому событию.
На этих циклах фокусируемся на доске в Miro во время встречи.
В ивент-шторминге 3 этапа:
1. Сейлзы выстраивают по циклам цепочку событий: от «клиента у нас ещё нет» до «клиент нас окончательно покинул». Даже в простых цепочках 20–30 действий. В готовом таймлайне есть happy pass: клиент успешно прошёл весь путь. И альтернативные пути: что-то пошло не так.
2. Проходим по таймлайну с конца, ищем ошибки. Выделяем ключевые события, которые нельзя откатить: клиент зарегистрировался, совершил бронирование, провёл оплату. Здесь происходит стык сервисов. На стыках обогащаем цепочку. Пишем, кто и что делает: актор-клиент зарегистрировался, подключился сервис юзер-менеджмента.
3. Выявляем, какие агрегаты работают с событием. Мапим команды: клиент регистрируется, в работе участвует команда регистрации.
Цепочка готова, мы получили полезный контекст, все одинаково понимают процессы и видят, что нужно делать, чтобы их улучшить.
Во время встречи составляем словарик. Если сейлз говорит непонятное разработчикам слово — мы его добавляем в словарь, и оно просасывается в наш интерфейс и кодовую базу. Всё это учит разработчиков понимать, на какие рычажки они влияют своим кодом.
Поделюсь советами, как круто провести ивент-шторминг.
Онлайн-формат
● Для проведения онлайн достаточно доски в Miro.
● Разбивайте встречу на три части, каждая встреча — один этап.
● На последней встрече отпустите бизнес, выявите агрегаты и сервисы, задействованные в таймлайне с разработкой.
● Максимум людей для успешной фасилитации онлайн — 8–10 человек.
● Ищите представителей бизнеса в оргчате выбранного домена: спрашивайте у руководства, «кто тут самый инициативный».
● Вам нужны работники «с полей», которые лучше всего шарят в процессах, и тимлиды первого уровня.
● Берите людей из разных направлений домена.
● Бизнес-участники должны понимать: ивент-шторминг — процесс обучения, они эксперты, а разработка — ученики. Им нужно говорить на своём языке, а не подстраиваться под разработку.
● Дайте участникам базовый словарь. Четыре самых важных слова: актор, команда, событие, термин.
● Важны вводные по времени и цели: на сессию уйдёт суммарно 6–8 часов, она даст единое понимание процессов.
Фасилитация
● На старте не бойтесь повторить все вводные.
● Дайте сейлзсам 10 минут на то, чтобы каждый выстроил индивидуальный таймлайн, дальше начинайте мёржить таймлайны с общим обсуждением.
● Событие — факт в прошедшем времени, его не отмотать. Следите, чтобы так и записывали.
● Первым делом простройте happy pass, иначе у вас не выстроится цельное видение процесса. Альтернативные ветки обозначьте на первом этапе, а достраивайте на втором, проверяя таймлайн с конца.
● Если бизнес утверждает, что два события происходят одновременно, это важная точка обсуждения.
● Организуйте пост-процессинг: важно передать разработке результаты, объяснить, какие процессы у нас уже верно реализованы, а где нужно обновление и дополнительное внедрение.
Почему ваш новый «гениальный» флоу вызывает тревогу в команде? Всё о психологии сопротивления изменениям — в одной статье!
Представьте ситуацию: вы, как продакт, несколько недель потратили на исследования, кастдевы, прототипирование и дизайн. Вы выносили идею, защитили её перед стейкхолдерами и теперь, сияя от предвкушения, приносите команде разработки новый, идеально продуманный флоу. А в ответ — тишина. Или, что хуже, шквал вопросов в стиле «а зачем?», «у нас и так всё работает» и «это всё сломает».
Знакомо? Прежде чем записывать команду в ретрограды и саботажники, давайте разберёмся. То, с чем вы столкнулись — не вредность, а фундаментальный баг (или фича?) человеческой психики. Имя ему — сопротивление изменениям.
В статье «Почему ваш новый «гениальный» флоу вызывает у команды панику? Разбираем психологию сопротивления изменениям» мы копнём в нейробиологию и психологию, чтобы понять, почему наш мозг так ненавидит всё новое, и что с этим делать продакту, тимлиду или любому другому менеджеру. Узнаем почему понятный костыль всегда приятнее неизвестного счастья, что на самом деле пугает разработчиков и тимлидов, когда вы внедряете инновации, как обойти страхи, не потерять доверие и не получить force push в master обратно и какие психологические лайфхаки реально работают в жизни, а не в учебниках. Автор разбирает реальные кейсы, шутит, находит баги в «операционке» команды и даёт понятные инструкции, как внедрять любые изменения.
Представлен обучающий курс по Python под названием Advanced Python Mastery от Дэвида Бизли, автора нескольких книг-бестселлеров по этому языку программирования и одного из главных знатоков Python. В базе курса представлены данные по работе на уровне процессора и компилятора до продвинутых концепций программирования на Python и самых актуальных фреймворков, а также десятки материалов с PyCon.
Для ЛЛ: перечислены способы мотивации сотрудников, которые вам могут показаться банальными
Недавно на работе разгорелся жаркий спор. Двое наших разработчиков сцепились из-за выбора библиотеки для работы с датами в монорепе на js. Один был фанатом Luxon, утверждая, что она идеально подходит для сложных задач с датами и временем. Второй клялся, что Date-fns – в это лучший выбор, потому что она лёгкая, быстрая и позволяет использовать только нужные функции, не раздувая проект.
Ну не суть. Я сидел рядом и наблюдал за этим словесным баттлом. Проект уже грозил загнуться, не начавшись.
Понимая, что бесконечные дебаты ни к чему не приведут, я решил вмешаться. Первое, что необходимо сделать в таких ситуациях – выслушать всех причастных. Я дал каждому возможность высказаться, кивая и делая вид, что записываю их аргументы в блокнот. В голове я уже прикидывал, как не дать спору остановить работу.
Разрешение конфликта
Чтобы выйти из тупика, я предложил компромисс: «Ребята, давайте так. Каждый из вас реализует свою часть проекта с использованием своей библиотеки. На проверку идей у вас 2 дня, потом сравним, что получилось». Они согласились, и весь накал спора тут же утих – оба погрузились в работу, стремясь доказать, что их выбор лучший.
В итоге мы остановились на одной из либ, но не это важно. Главное, что разрешился конфликт между двумя сотрудниками на почве выбора технологий. А часто бывает и по-другому, что никто не хочет уступать и каждый топит за свой алгоритм/либу в проекте.
В таких случаях я обычно:
Развожу спорщиков по разным проектам
Или принимаю сам решение какую технологию использовать далее
В обоих случаях после конфликта может упасть мотивация, могут затаиться обиды и т.д.
Мотивация-шмотивация
Несмотря на подзаголовок, я приведу реально применённые способы поднятия мотивации разработчиков:
Деньги-деньги, решают многое. Сюда же незапланированные премии.
Повышение должности сотрудника (иногда даже без повышения зарплаты, не везде корректно настроены грейды). Был «разработчик», стал «Ведущий разработчик», потом «Старший разработчик» и т.д.
Обновляешь ноутбук работнику. Иногда для сотрудника это долгожданное обновление, и это очень повышает его мотивацию и лояльность к компании (ну или к тому, кто её выбил).
Про лишние дни отдыха тоже понятно.
Оплата билетов на конференции по IT-тематике (а они не всем по карману сейчас), покупка лицензий на удобный софт.
Признание заслуг в разработке проекта перед вышестоящим начальством и текущей командой. Хотя это должно быть по умолчанию в команде.
Этих пунктов может быть ещё очень много, везде индивидуально.
Конфликты между коллегами в команде – это не трагедия, а возможность для экспериментов и роста. Выслушать каждого, дать шанс доказать свою точку зрения на практике и подкрепить это мотивацией – именно так конфликт становится точкой роста.
Если есть чем поделиться, как вас мотивировали - прошу в комментарии.
Краткий (и не краткий) экскурс в ГОСТ Р 56939-2024 – РБПО
Недавно мои коллеги обработали и опубликовал пятую — финальную — часть моего рассказа про ГОСТ Р 56939-2024 – Разработка безопасного программного обеспечения. Поскольку все части записывались сразу, к моменту выхода этого заключительного видео я понимаю, что сейчас бы немного иначе его сделал. Видение меняется, появляется новая информация. Например, завершился этап домашнего задания испытаний анализаторов кода, и про это стоило бы упомянуть. Или, например, появилась эта методическая рекомендация, про которую стоило бы рассказать.
Но не страшно, про новое расскажем в рамках других митапов и вебинаров. А пока, вот все части общего обзора:
Но на этом история не закончилась. Сейчас вместе с УЦ "МАСКОМ" и приглашёнными гостями-экспертами мы записываем подробный цикл вебинаров про каждый из 25 процессов, описанных в стандарте.
чем отличаются SLI, SLO и SLA и как их правильно применять?
когда компании осознают необходимость этих метрик и как их встраивать в процессы?
как оценить критичность сервисов и доказать бизнесу ценность SLO/SLA?
В теме помогут разобраться Паша Лакосников, руководитель юнита ArchGovernance в Авито, Дима Синявский, SRE-инженер в Ви.Tech, и Кирилл Юрков, Observability and Reliability Engineering Manager в ecom.tech.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
