PM Live | проджект и продакт менеджмент — дайджесты в Телеграме
Почитать:
Women’s inventions that changed the world
Знаменитая актриса сильно повлияла на развитие современных технологий. Вместе с композитором Джорджем Антейлом она разработала технологию частотного скачкообразного распространения радиосигналов, которая лежит в основе многих современных технологий беспроводной связи, таких как Wi-Fi и Bluetooth.
В 1941 году Хеди Ламарр и Джордж Антейл создали систему, которая перехватывает радиоуправляемые торпеды. Эта система использовалась в военно-морских силах США. Идея заключалась в том, чтобы радийный сигнал, который управляет торпедой, переключался между множеством частот, что делало его недоступным для радиоразведки противника.
Хотя эта технология не была внедрена в военное время, именно она позже легла в основу беспроводных технологий, которые стали использоваться в развитии Wi-Fi, Bluetooth и мобильных сетей.
Главные герои и место событий
- Вебстер Томпкинс — главный герой. Фамилию получил от другого персонажа: физика Томпкинса из серии научно-популярных книг советского учёного Георгия Гамова. ДеМарко в начале книги честно говорит, что присвоил своему герою эту фамилию, потому что был в восторге от работ Гамова — маленькая приятность русскоязычному читателю.
- В заголовок вынесен дедлайн, потому что роман именно о сроках сдачи проекта — вообще, даже множества проектов. Эти дедлайны определяют всё, что происходит с героями романа — сложности с руководством, наймом и увольнением людей, нервотрёпка, переработки и всё прочее.
- Южная, жаркая, но маленькая и бедная страна Моровия. Выдуманная, конечно же. Судя по описанию природы и расположения, прототипом могли послужить современные Албания или Черногория.
В чём замысел
Мистера Томпкинса похищают: вырубают каким-то димедролом и увозят в Моровию рулить несколькими крупными проектами. Эти проекты, по замыслу коммунистического тирана, должны обогатить страну и вывести её на международный уровень.
Тиран Моровии — Великий вождь народов — оказывается не тираном вовсе, а очень амбициозным айтишником с большим количеством денег. При чтении представляется кто-то вроде Илона Маска, только без насильственных заскоков. Происходящее вокруг вождя вообще мало интересует, он хочет кодить целыми днями и хорошо вложить деньги. В общем-то, Моровию он тоже купил. И ему просто по душе образ тирана — мол, люди так лучше слушаются.
В итоге Томпкинс безапелляционно ставит ему собственные условия — никакой тирании, не будет жёстких сроков сдачи проектов, команды он формирует сам, управлять процессами будет через тимлидов (в книге называются по-другому, но суть такая) и все методы будут его собственные.
Матрицы RACI, DACI, AAI для распределения ответственности в команде
RACI — простой инструмент для распределения ролей и обязанностей. Позволяет избежать дублирования задач и путаницы.
В аббревиатуре RACI зашифрованы четыре ключевых роли:
- R (Responsible) — ответственный за выполнение задачи.
- A (Accountable) — ответственный за результат: делегирует работу и следит за ходом выполнения.
- C (Consulted) — консультирующий: тот, кого привлекают для принятия решений.
- I (Informed) — информируемый: ему сообщают, как идёт работа и к чему привело то или иное решение.
Как управлять загрузкой команды
Когда лодка причаливает к берегу, все прибывают одновременно: и те, сладко спал, и те, кто грёб двумя вёслами. Важно управлять рабочей нагрузкой, чтобы сотрудники не сбегали
Метод PARA эффективного планирования
Метод PARA — это система организации информации, которая помогает структурировать задачи, идеи и ресурсы так, чтобы всегда можно было быстро найти нужное.
Как провести интервью с заказчиком и не упустить ни одной детали
Самый простой способ узнать, что хочет человек — спросить у него. Поэтому интервьюирование стало самым популярным методом выявления требований у заказчика. В теории всё кажется простым: собери список вопросов и докопайся с их помощью до сути проблемы. Но
Как оценить индивидуальный вклад разработчика в проект
Будучи тимлидом, я многократно задавался вопросом объективной оценки эффективности работы сотрудника, основанной на данных, а не только на субъективном мнении руководителя или коллег. До пандемии коронавируса преимущественно во всех IT компаниях сотрудники работали в офисах, и, если человек приходит на работу, значит он скорее всего что-то делает. В 2020 году ситуация усугубилась, все ушли на удаленку, а инструментов оценки эффективности попросту не оказалось. Более того, спустя пару лет крупные компании, включая таких мастодонтов как Google, Apple, Amazon и т.д. вновь начали выводить своих сотрудников в офис, что может служить индикатором того, что инструментов до сих пор так и не появилось.
“если человек приходит на работу, значит он скорее всего что-то делает”
Это утверждение не просто спорное, оно ложное. То что человек приходит на работу значит только то что он сидит на стуле на территории работодателя. Больше ничего.
Вылезти из ловушки микроменеджмента и запустить автопилот
Суровая правда жизни такова, что пока для этого не будут созданы нужные условия, вы, как руководитель организации, будете продолжать все вывозить на себе и делать работу не своего уровня.
5 принципов архитектуры ПО для старта проекта
Для заказчика, незнакомого с разработкой, может казаться, что глубокое продумывание архитектуры на ранних этапах — это не очень важный шаг. Часто можно услышать стартаперское классическое: «Давайте скорее сделаем что-то работающее, а потом уже будем рисовать красивые диаграммы».
Но это очень опасный путь. Без сомнения, разработчики могут придумать что-то и без всех этих «красивых диаграмм и схем». Например, возьмут готовую типовую архитектуру из учебника или ту, с которой у них уже есть опыт работы, а может вообще будут продумывать всё на ходу. И к какому-то моменту у них даже что-то «построится». Но, исходя из нашего опыта, выглядеть это будет скорее всего как-то так:
Системы work management: выбор решения для команды
Материал не претендует на объективность и содержит много впечатлений в стиле нравится/не нравится. Но, как показывает мой более чем 30-летний опыт, то, что не нравится, внедрить гораздо сложнее чем то, что нравится.
ОКR: разбираем основные заблуждения
Про OKR знают уже многие, но воспринимают по-разному.
Как когда-то, лет 15 назад, было со Scrum. За время существования методология OKR обросла собственными мифами, большинство из которых связаны с ошибками внедрения или использования. Но мифы про выполнение на 70% или обязательную амбициозность только набирают популярность.
«Долго объяснять, проще сделать самому»
Пишете инструкции, проводите по 10 созвонов в день, но стоит вам уйти в отпуск — сотрудники звонят, чтобы вы «потушили пожар». Хочется развивать бизнес, а вы все еще помогаете офис-менеджеру заказывать стаканчики для кофе. Это нормально: так ошибался и я, 10 лет строя диджитал-агентство.
Канбан Метод: не магия, а логика
Алексей Пименов — тренер, эксперт и практик по Канбан Методу, Гибкости Бизнеса и Стратегическому Маркетингу. Более 10 лет помогает компаниям разного уровня с построением адаптивных процессов. Организатор, продюсер, постоянный спикер и кейноут крупнейших профессиональных конференций FlowDays, Kanban Eurasia, AgileDays, TeamLead Conf, Merge, IT Nights, SECON, SECR, CodeFest, Стачка и пр. Специально для комьюнити Skillbox Code Experts рассказал про мифы о Канбан Метода. Публикую статью по мотивам этого эфира.
Cистемы управления проектами в 2025 году: выбираю подходящий инструмент
Когда я пришёл в новую команду, сперва просто впал в ступор: задачи разлетались по чатам, созданным непонятно кем, дедлайны плыли, контроль держался исключительно на напоминаниях. А мне в этом всём предстояло наладить выпуск материалов.
Разбирался я поэтапно, но в детали вдаваться не буду — специфические нюансы контент-менеджмента вряд ли пригодятся разработчикам, тестировщикам или дизайнерам. Зато вот этап, который применим в любой команде — выбор системы управления задачами.
Так как я за этим рынком постоянно не слежу, пришлось порядочно походить по сайтам систем и пересмотреть с десяток обзоров. После всего этого понял простую вещь: идеальной системы нет. Все они строятся вокруг одной концепции — канбан-доски.
Скрам — не работает, плак-плак? Нытики не понимают Agile
Скрам не работает. Скрам не бывает в чистом виде. Скрам — это для корпораций. Скрам душит разработку.
Если вы хоть раз видели такие комментарии, то знайте: перед вами либо человек, который не понял Agile, либо тот, кому однажды внедрили скрам через одно место, и теперь гибкого тут только его растяжка.
Как найти управу на технический долг
Не всегда следует любой ценой избегать технического долга, в некоторых случаях его разумное использование становится стратегическим инструментом для достижения целей проекта. Однако для того, чтобы технический долг перестал ощущаться как что‑то пугающее и неконтролируемое, важно научиться осознанно им управлять. Команда должна воспринимать обсуждение долга как часть рабочего процесса, а не как негативный аспект работы. Если долг рассматривается как управляемая часть системы, он становится менее тревожным.
Гайд по менеджменту знаний: 6 решений для разных бизнес-задач
В этой статье я расскажу, как база знаний помогает компаниям перестать терять деньги на бесконечное обучение новичков, путаться в старых инструкциях и срывать сроки проектов.
«Мы просто обновили рабочий таск-трекер, а команда обновила резюме»
В компании решили обновить софт, потому что «так будет лучше», а вместо обучения — документация на 40 страниц. Знакомая ситуация?
Руководство уверено, что «все привыкнут», но на деле половина сотрудников ищет кнопки, другая — способы обойти систему, а третья просто уходит. Новый таск-трекер? Задачи по-прежнему в Google Таблицах. Свежая CRM? Клиенты всё так же в Telegram. В итоге продукт «внедрили», но им никто не пользуется.
Я давно наблюдаю, как ломаются копья в вечных спорах: “Нужно ли оценивать задачи?” и “Нужно ли списывать время?”. Мне кажется, я нашёл тот баланс, который позволяет, с одной стороны, учитывать трудозатраты, а с другой — не превращать процесс в никому не нужную бюрократию.
Примеры неудачной автоматизации и чек-лист перед началом работ
Занимаясь много лет реализацией ИТ-проектов и улучшением бизнес-процессов в крупных финтех-компаниях, я столкнулся с реальными случаями, когда автоматизация вместо положительного эффекта приносила отрицательный, особенно на первом этапе после внедрения.
10 методов принятия решений в команде
Каждый день мы принимаем решения: иногда это простой выбор — что заказать на обед, а иногда сложный, влияющий на будущее команды или бизнеса. В идеальном мире у нас было бы достаточно данных, времени и уверенности, чтобы выбирать оптимальные решения. Но реальность устроена иначе: неопределенность, дефицит информации, давление сроков и страх ошибки делают процесс выбора трудным.
GTD: Как довести дела до завершения
Когда-то в моей голове был настоящий бардак, в котором небрежно валялись интересные идеи, бытовые задачи, страхи, что забыла вовремя внести тот или иной платеж и тревоги за рабочие задачи. В периоды авралов даже тараканы в моей голове уходили нервно покурить в сторонку и не возвращались. Стресс был моим спутником, хотя, конечно, такого спутника себе я явно не хотела. В какой-то момент мне пришлось собрать всех своих тараканов (включая беглецов) на совет мыслей
В лучших традициях Хабра статья начиналась проникновенной историей о продакте, который пришел с картинкой космолета и ожиданием, что космолет будет готов к запуску через неделю. Ну, конечно, это шутка, какая неделя?
Путешествие из проджекта в продакты: какие навыки помогут построить карьеру
В эту ИТ-профессию попал не сразу, ранее строил карьеру в проджект-менеджменте: собирал требования, делал ТЗ и брифы, реализовывал проекты. Но мне стало скучно — слишком много рутины, нет места творчеству и возможности влиять на продукт. Тогда определил, что может принести удовольствие в работе: новые задачи, реализация идей и возможность принимать решения. Продуктовая разработка подошла по всем пунктам. Так началось мое путешествие из проджекта в продакты.
Оценка срока и трудозатрат на реализацию задач с помощью Монте-Карло
Существует много методов оценки задач с точки зрения трудозатрат:
- Scrum Poker
- T-Shirt Sizing
- Метод аналогий
- «Три амиго»
- и т.д.
Сегодня я подробно расскажу, почему в нашей команде ни один из них не используется и как мы пришли к точности планирования сроков и трудозатрат 80-90%.
Геймификация продукта: призы и награды — не главный мотиватор пользователей
Почти все современные акции и промо кампании завязаны на материальную мотивацию – деньги, дорогие призы, айфоны, сертификаты и прочее.
Это сажает маркетинг на “иглу” призов с которой невозможно слезть. Показываю отличный пример, как создается нематериальная мотивация без призов и дорогих наград.
Что такое продуктовая культура
что на самом деле стоит за понятием продуктовой культуры, какие метрики и бенчмарки помогут ее измерить, и как крупные компании (Яндекс, Т-Банк, VK) используют ее
Гайд как делать нормальные, не бесящие кросс-продажи на примере Burger King
«Возьмите картошку и колу», — говорит пользователям баннер перед кнопкой «Оформить заказ». Он мешает и раздражает, хотя должен побуждать купить больше.
Как мы превратили релиз-ноуты в продуктовый блог
В 2ГИС продакт-менеджеры отвечают за полный цикл фичи: важно не просто запустить её, но и рассказать о ней. Подробно, честно, с деталями: как появилась идея, какие были сложности, что в итоге получилось и какие первые результаты. Это не просто «мы добавили кнопку, и теперь всё классно» — это история про поиск решения, процесс, ошибки и инсайты.
Введение в таблицы решений для начинающих
Представьте, что вы отвечаете за организацию сложного ужина и вам нужно выбрать меню, рассадку гостей и даже музыку, основываясь на десятках различных предпочтений и ограничений, при этом сохраняя всё простым для ваших гостей. Поражает, не правда ли? Теперь представьте, как эту сложность можно масштабировать на потребности принятия решений в бизнесе — например, для одобрения кредитов, применения скидок или оценки рисков — и вы получите представление о том, насколько хаотичным может быть управление логикой принятия решений.
Грейды бизнес и системных аналитиков
Скиллы и компетенции аналитиков в данной статье описаны в срезе компании, занимающейся аутсорс‑разработкой. Это накладывает определенные требования к аналитикам, так как им за частую приходится участвовать в проектах с разными стеками технологий и доменами. Что в свою очередь требует широкой эрудиции и умения быстро разбираться в новых предметных областях и технологиях. Ниже приведены требования к каждому грейду для бизнес‑аналитиков (BA) и системных аналитиков (SA), с акцентом на их отличия. Учтены ключевые компетенции (SQL, Python, бизнес и системный анализ, UML, BPMN, интеграции, брокеры сообщений, микросервисная архитектура, базы данных), софт скиллы (усиливаются с ростом грейда), опыт работы (основной фактор грейда) и требования, продиктованные аутсорсинговой спецификой.
Декомпозиция задач разработчика
Ответьте себе на вопрос, бывает ли такое, что в процессе выполнения задачи на разработку вы понимаете, что не укладываетесь в срок, сталкиваетесь с чем-то, что не учли заранее, какие-то доработки занимают больше времени и усилий, чем вы планировали? Из-за нарастающей сложности задач в процессе их выполнения вы заводите дополнительные технические задачи на исправление, оставляете по коду множество TODO и комментариев в надежде позже вернуться к задаче
Конспект по архитектуре ПО и System Design
Несколько лет назад я начал всё больше разбираться в том, как проектируются большие и сложные IT-системы. Ещё и такие, которые выдерживают огромные нагрузки: обрабатывают запросы миллионов пользователей каждый день, гоняют петабайты данных ежемесячно и всё такое. YouTube, TikTok, Google Docs и т.п.
А в последнее время и по работе чаще стало необходимо погружаться в архитектурные обсуждения. Интересно ещё и то, что в крупных IT-компаниях всё чаще наблюдается тренд на проведение так называемых System Design Interview.
Использование Mindmap для написания требований
В этой статье я разберу использование простого, понятного, наглядного инструмента, который интегрируется с подходом Docs as code – Mindmap (Интеллект-карта). Этот метод позволяет организовывать требования в виде древовидной структуры, что делает процесс работы более гибким и наглядным.
BPMN и оркестрация микросервисов. Часть 1: Языки потоков, движки и вневременные паттерны
Мы создаем Zeebe как движок для рабочих процессов нового поколения для таких новых сценариев, как оркестрация микросервисов — сценариев, которые могут требовать от движка обработки сотен тысяч (или миллионов) новых экземпляров рабочих процессов в секунду.
Digital Twin — цифровая копия физической системы
Современный цифровой двойник состоит из множества взаимосвязанных компонентов. Он получает данные с физических объектов через периферийные линии данных и IoT-устройства, а затем анализирует их, используя многодоменные модели и алгоритмы машинного обучения.
Шаблоны проектирования в документации
Напомню, что шаблоны проектирования описывают типичные способы решения часто встречающихся проблем при проектировании программ.
“Бизнес в России — это гомерически смешно”
Когда вы внутри, это, конечно, тяжко, печально и всё такое, но снаружи это всегда смешно.
Архитектура национального видеохостинга RUTUBE
За полгода с июля 2024 года большинство аудиторных и технических показателей RUTUBE выросло в разы: количество ежедневных пользователей выросло почти в 4 раза; количество видео, ежедневно загружаемых на видеохостинг — в 3 раза, с 330 тыс. до 1 млн единиц контента; CDN-трафик — в 4 раза и в пиковые часы превышает 7 Тбит/с. Как архитектура сервиса показала себя в условиях продолжительного «нагрузочного тестирования» и как команда переживала такой рост нагрузки, читайте в этой статье.
Посмотреть:
Data Analytics: from Data to Insights | IIBA Belarus⏱️1 час
Ежедневная рутина аналитика данных — основные задачи
Роадмап развития мышления аналитика | Flow ⏱️1 час
Для качественного профессионального роста (особенно вверх) недостаточно знать больше техник или осваивать больше инструментов и технологий. Переход на следующий шаг — на новый уровень или в другую роль — обязательно сопровождается сменой мышления: от аналитического и алгоритмического к тактическому и стратегическому, к agile-мышлению, к продуктовому или предпринимательскому. По дороге захватываем design thinking, абстрактное, концептуальное и прочие. Типов мышления — десятки! Но все ли они важны нам здесь и сейчас? Можно вообще об этом не думать. Жизнь заставит изменить взгляды и мышление, когда вы в очередной раз упретесь в стеклянный потолок и будете упорно искать новые подходы для решения нерешаемых проблем. Есть риск погрязнуть в этом болоте, копаясь в неработающих уже инструментах и подходах. И есть возможность найти новую точку опоры и придать себе мощного ускорения — если вы вовремя переключитесь на другой концепт понимания ситуации, то есть смените тип мышления.
Use Cases: Как улучшить требования к проекту ⏱️1 час
Вебинар будет полезен
- Аналитикам, разработчикам, менеджерам проектов.
- Всем, кто работает с требованиями и проектной документацией.
Как адаптироваться к роли руководителя? Чек-лист новичка ⏱️25 минут
Вчера ты был исполнителем, а сегодня – руководитель! Что делать, если на тебя свалилось повышение, но ты не знаешь, с чего начать? Как не потерять доверие команды, преодолеть синдром самозванца и научиться делегировать? В этом видео я поделюсь личным опытом, расскажу про главные ошибки новых менеджеров и дам конкретные советы по адаптации в новой роли.
Модель зрелости продуктовых исследований⏱️30 минут
Правильно выстроенный процесс дискавери дает до 40% экономии бюджета на ИТ за счет отказа от разработки ненужных продуктов. Мы не можем позволить себе идеи, которые стоят минус миллион рублей – нам нужно экономить бюджет и избегать ошибок. И благодаря тому, что мы делаем продукты, которые нужны рынку, нам удается заработать новые деньги, и наши метрики с точки зрения бизнеса растут.
Kafka: что нужно знать Системному аналитику⏱️45 минут
Вы узнаете, что важно учитывать при постановке задач разработчикам, познакомитесь с принципами работы распределенной архитектуры и асинхронным взаимодействием сервисов внутри системы на примере подсистемы технической поддержки.
Продуктовые гипотезы: источники и проверка⏱️40 минут
— Зачем нужны гипотезы и где их искать. — Как правильно их формулировать. — Какие методы проверки работают лучше всего.
