Всем привет!
26-ой обзор полезностей для управления проектами уже ждет!
НА этой неделе нам рассказывали:
- об использовании критического пути в планировании проекта,
- о разнице между проектным и продуктовым подходами,
- о том, как сделать работу ПМа похожей на сказку и что этому мешает,
- о чаптерах как альтернативах обычным командам,
- о важности онбординга и R&D.
Отличная выдалась неделя!
А еще нашему дайджесту стукнуло полгода:
26 выпусков,
~800 публикаций вошло в обзоры,
почти сотня подписчиков
и десятки тысяч просмотров.
Принимаем поздравления 🎉

Давайте не игнорировать роль продюсера проектов
#заметкиНаПолях
Мы привыкли к РП/PM/руководителю проектов, но, как обычно, когда возникает общеупотребительный термин, всегда находятся "еретические движения". И "продюсер проектов" - это ересь, которая мне нравится 😜

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

Но ведь это же работает не только в медиа, правда? Проджект нередко занимается более широкой деятельностью, чем то, чем учат на курсах и пишут в стандартах. Он может не только администрировать проект, который ему дали вести, но и сам его инициировать. Быть одновременно и заказчиком, и администратором проекта и будущего продукта. Особенно если это происходит в небольших компаниях и командах. И этому "продюсированию" тоже нужно учиться.

Я когда-то работал в медиа, и приходилось эпизодически быть "продюсером". Но потом я (снова) оказался в ИТ и понял, что роль у меня примерно та же самая. Я не получаю идею проекта от заказчика. Почти всегда я придумываю идею сам, просчитываю и собираю нужные ресурсы и веду проект к результату.

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

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

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

За что я люблю лекции и вебинары Иннокентия - они всегда полезны и интересны, даже если вы вроде бы хорошо знакомы с темой.
Эту недавнюю трансляцию очень рекомендую всем, кто занимается сбором требований.
https://youtu.be/Y6H6zXP9VHQ

Всем привет!
В новом обзоре публикаций:
- причины, по которым не взлетают Agile, скрам и канбан (три отдельные статьи, но вот так кучно вышли)
- подготовка к P3.Express (ребята из Pmclub молодцы - теперь уже и мне хочется пройти этот курс). От них же прекрасная статья про ошибки ПМа.
- правила успешных тимлидов
- очень много классного опыта:
* странные паттерны автоматизации (у каждого заказчика свои тараканы)
* как выкрутиться из ситуации, когда на проекте нет документации
* вкусные кейсы по разработке продуктов для социальных служб и грантовых конкурсов.
- ОЧЕНЬ много публикаций про переезд с Трелло на...
Спасибо, что читаете! 😊

#книгаНедели
В магазине "Настольная книга project-менеджера" Владимира Завертайлова (а это основатель скрам-студии "Сибирикс") производит внушительное впечатление. Во-первых, 750 страниц - это вам не худосочные скрам-гайды и прочие "Дедлайны". Сразу видно, что управлять проектами - это не проскроллить пару статей на хабре и готово, а все-таки полноценный кусок гранита науки. Во-вторых, на открывшемся случайном развороте было много выстраданных крепких слов. Это давало надежду на искренность, непосредственность, много кейсов и жизненного опыта.
Конечно же, я купил и прочитал.

Главная фишка книги - ее энциклопедичность. Автор пишет эпичное полотно, посвященное управлению диджитал-проектами "от А до Я", в котором нашлось место практически всем темам и проблемам, с которыми можно столкнуться, реализуя проект. Здесь и скрам, и продуктовая разработка, и карта компетенций ПМа, и OKR, и оценка персонала, и работа с интеграциями, и риск-менеджмент, и даже микрокурс по основам технической грамотности. Бери, читай и используй и большие никакие материалы не нужны. Причем написано всё не заумными словами, требующими примечаний или гуглежа, а просто и понятно, как для своих, с приколами и цитатами из фильмов.

Но эта же энциклопедичность, возможно, и главная уязвимость книги. Часть тем описана "галопным" методом. Часть упрощена. Часть вообще внесена в книгу просто потому, что она близка автору и определенной (но не всей) его аудитории - например, большую главу про дизайн веб-сайтов я честно пропустил. Да и в целом, все акценты и примеры в этой тяжеловесная книга касаются сферы заказной разработки. С одной стороны, это классно: автор не занимается теоретизацией, а берет собственный опыт. С другой - универсальность книги все-таки страдает.

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

И наконец, есть простой вопрос, на который я не смог найти однозначного ответа. Кому бы я порекомендовал эту книгу?
Вряд ли начинающим ПМам - у них нет релевантного опыта, чтобы спроецировать примеры автора на свою работу. Да и объем такой, что пока доберешься до конца - забудешь начало. Лучше уж более фастфудные книги, статьи и курсы.
Возможно, что опытным проджектам - из принципиально нового они узнают нюансы веб-разработки (если ей не занимались), ну и, конечно же, кейсы. Но тут может слегка отпугнуть тот самый "голос автора".
Пока главная ЦА книги, кажется, - руководители таких же, как "Сибирикс", веб-студий, которые смогут узнать, как разработка устроена у одного из лидеров рынка. Но это довольно мало...

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

Собрал материалы за неделю.
Отдельно отмечу вышедшие на неделе публикации про
- определение стоимости проекта/продукта
- диаграмму Гантта
- организацию дискавери-стадии
- проблемы коммуникации в команде
- культуру работы с ошибками
- переход с Trello на отечественные решения и свободное ПО.

Прочитал книгу "Шум. Несовершенство человеческих суждений" Канемана, Сибони, Санстейна (вроде спин-оффа к "Думай медленно, решай быстро"), посвященную теме нежелательной вариативности экспертных суждений.

Местами книга требует вникать в мат. статистику и немного экзотические предметные области, но in nuce она довольно простая: есть феномен "шума", когда по одному вопросу разные эксперты (или даже один и тот же) высказывают разные суждения, дают сильно дифференцирующие прогнозы.

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

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

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

Книга совсем не про управление проектами, но авторы регулярно проецируют свою теорию на работу аналитиков, предпроектные исследования и прогнозы трудозатрат проектов.

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

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

А еще я сейчас с интересом читаю небольшие монографии Юрия Дубровского про аналитику, аналитиков, бизнес-требования и пресейлы. Если интересен мой подробный обзор, - ставьте лайки, так у меня точно будет дополнительный стимул 😇
https://vc.ru/books/809592-mnogo-chek-listov-stressovye-relizy-i-kak-byt-kogda-tebe-figovo-proektnyy-daydzhest-29

#книгаНедели
Почти случайно набрел на новинку - книгу Татьяны Тиминой "Секреты аналитики, или Аналитика без секретов".
Как говорится, прочитал ее, чтобы вам не пришлось. Книга не столько про аналитику и требования, сколько про основы построения интерпретационных моделей и data-driven подход в управлении и маркетинге.

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

Плюсы:
- Хорошо и доступно изложены концепции аналитической модели, KPI, ABC, gap- и root-cause-анализа и т.д.
- Много практических и загружаемых примеров анализа и представления информации в excel (других средств автор избегает)
- Много примеров из фармы (родная сфера для автора)
Минусы:
- Не совсем про аналитику и не для аналитиков ;-)
- Хотя книга рассчитана на новичков в анализе данных, часть понятий (например, регрессионный анализ) изложены недостаточно понятно и доступно.
- Книга издана самим автором (self-publishing) со всеми вытекающими опечатками (это терпимо) и не отфильтрованными лирическими отступлениями (что нередко мешает читать и воспринимается скорее как неизбежная дань).

Рекомендовать не буду - разве что если вы случайно оказались в роли биздева с кучей отчетов на столе и совсем не знаете, с какого бока к ним подступиться.
https://www.litres.ru/book/tatyana-timina/sekrety-analitiki-ili-analitika-bez-sekretov-69510253/

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

⭐️ Коллеги из Systems Education собрали гигантскую базу инфо по базам данных - Каталог ссылок на тему баз данных и анализа данных для аналитиков и проектировщиков.
В составе:
Основы использования реляционных баз данных
Структура языка SQL
Получение данных. Основы SQL (DQL: Data Query Language)
Базовые операторы SQL
Использование соединений
Агрегатные и аналитические функции
Генерация SQL-запросов
Основы оптимизации запросов
Разработка реляционных баз данных
Производительность и оптимизация SQL
Индексы в таблицах
Планы запроса
Денормализация
Теорема CAP
Транзакции в БД, OLTP, ACID, TCL
Команды администрирования баз данных в SQL
Ограничение видимости данных с помощью представлений
Обновление схем БД, Миграция данных
Администрирование реляционных баз данных
Команды администрирования баз данных в SQL
Ограничение видимости данных с помощью представлений
Обновление схем БД
Миграция данных
Документарные БД
Базы «ключ-значение»
Документарные БД
Колоночные БД
Основы анализа данных
Основы статистики
Основы анализа данных в Excel
Анализ данных с помощью SQL

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

Очередная подборка полезных материалов по управлению проектами.
В этот раз особо отмечу:
🔥 Безусловно, большую базу знаний по IT Project management, Авторы собрали в общую базу огромное количество материалов и тем практически по всем аспектам работы ПМа и управления проектами. Часть писали сами, часть компилировали из источников. Труд, достойный уважения! Читайте и ставьте в закладки!
🟢 Саммари-перевод руководства по написанию требований INCOSE (к стыду, я впервые про него узнал)
🟢 Материалы по сертификации P3.Express и PMP Exam
🟢 Лайфхаки по уходу в отпуск во время проекта, онбордингу, решению конфликтов в команде
🟢 Много кейсов и инструментов - в фокусе снова переход с Трелло и Jira.

#книгаНедели
Открыл для себя книги Юрия Дубровского - про бизнес-анализ и работу аналитика. Всего пока нашел 4 книги, все прочитал и, если вы не против, немного порассказываю.

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

Книга "Живые требования" - посвящена "созреванию" требований. Автор берет метафорический образ фрукта. Изменчивость требований часто недооценивается, а иногда и вовсе отвергается: собрали на старте - несём в неизменном виде до завершения проекта. Это "простая модель требований" - экономная и дает твердую почву под ногами. Но чем сложнее проект и будущая система - тем большими связями обрастает требование и тем меньше неизменны эти связи. Не говоря уже о том, что они могут измениться "просто так", вне связей.

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

Решение - итерационные модели и учёт "растительного жизненного цикла" требований.
Начинается всё с посева/зарождения: у кого-то в голове появляется идея "а неплохо бы, чтобы...". Затем идет самый трудоемкий процесс - выращивание: идея обрастает "мясом", уточнениями, ограничениями, примерами и т.д. и т.п.

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

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

Зачем же учитывать этот "жизненный цикл"? В первую очередь, чтобы выставлять приоритеты. Реализация более зрелых требований, постановка на паузу реализации "молодняка" и отказ от реализации увядающих и мертвых - путь к сокращению потерей. И чем масштабнее проект, тем больше экономия.

Еще нужно учитывать влияние требования на проект, - увядание "широко влияющего" требования (например, зависимость от библиотеки) приведет к росту затрат на перестройку. Здесь важно балансировать: нельзя изолировать требование, поэтому нужно балансировать и еще на старте ввода требования убеждаться, что риск преждевременной смерти ключевого требования низкий.

От меня: конечно, как и любая метафора, тема "созревания" требований и вообще аналогий с живой природой может показаться "weird". Тем не менее, вместе с минусами (неточность и неформальность) метафоры имеют и плюсы - они стимулируют "правополушарное" мышление и поиск нестандартных, спорных мест в теории. И след. раз, когда я буду переписывать требование или закрывать его за ненадобностью, я точно вспомню про эти "фрукты"))
https://www.litres.ru/author/uriy-dubrovskiy/

#книгаНедели
Еще одна книга (скорее мега-лонгрид) Дубровского "Идеальный ИТ-аналитик (Как нанять лучшего аналитика в команду)" - о процессе найма. Причем это взгляд с обеих сторон, интересный как РП / тимлиду / архитектору / HR, так и самому аналитику. Автор обстоятельно рассказывает о собеседовании (и подготовке к нему), о развитии нужных качеств, о месте аналитика в команде проекта и компании.
Лично я сам в последнее время наймом почти не занимаюсь, но пройтись по виртуальному собеседованию было интересно, даже с учетом того, что книга 2019 года.
Условно она делится на две части. Первая - это процесса поиска аналитика. Глава для нанимающей стороны. Автор использует модель "метапрограмм" - установок, по степени выраженности которых можно определить, соответствует ли кандидат нашим требованиям (стремление, внутренняя референция, процесс, процедуры, содержание). Далее - про техническое интервью: определение, сможем ли мы собрать с этим кандидатом нужный нам пазл. В структуре интервью - определение "правил игры", проверка знаний базовых понятий, умение решать технические задачи, владение технологиями бизнес-анализа, доменами, технологиями системного анализа, понимание рисков и умение выходить из проблемных ситуаций.
Вторая часть - это сборник конкретных вопросов и задач для интервью аналитиков, все с примерами, по каждому из представленных выше направлений: общие, вопросы по требованиям, по документированию, по архитектуре (от микросервисов до REST и SOA), по бизнес-процессам, интеграциям. Отдельные главы - по решению задач и владению технологиями и инструментами: сформулируйте ФТ к такому-то предмету, программе, определите требования по работе с исключительными ситуациями, определите минимальный перечень этапов и документов для ЖЦ разработки из взятого примера. Вопросов и примеров реально много.

В общем, не могу не рекомендовать, - книга уникальна и максимально ориентирована на практику.

Новый обзор публикаций за неделю - уже на vc.ru.
В этот раз я продублирую список наиболее заметных и полезных публикации здесь. Ставьте реакции, если такой формат удобнее.
Основы и гайды
📌Как выбрать тип контракта для разработки IT-продукта: Fixed Price, Time & Materials или Retainer
📌Монолитная и микросервисная архитектура. Сравнение
📌Шаг за шагом: как мы управляем короткими и средними проектами длительностью до 1 года
Карьера и навыки менеджера проекта
🥇14 российских систем управления проектами: кто съест рынок. Разбираю киллер-фичи
🥇За кулисами Scrum-мастерства: о навыках, заблуждениях и реалиях профессии
🥇Проджект менеджер и аналитик: два сапога — пара?
🥇Модель Такмана в переговорах
🥇Зарплаты и конкуренция на IT-рынке труда в России сегодня
🥇Иллюзия контроля и недооценка случайности
Команда проекта
👨‍👦‍👦Как управлять командой проекта
👨‍👦‍👦Доверяй, но проверяй: как компании контролируют удалёнщиков
👨‍👦‍👦О контроле на удаленке: как совместить спокойствие бизнеса и доверие разработчикам
👨‍👦‍👦Самый плохой программист, которого я знаю
👨‍👦‍👦Задачи руководителя команды аналитиков
👨‍👦‍👦Выгорание у аналитиков: как заметить и предотвратить
👨‍👦‍👦Как грамотный подход аналитиков может сэкономить бюджет компании за счет изменения подхода к реализации проекта
Опыт и советы
🦋Если бы мне в школе рассказали, что такое Кайдзен и Канбан... Подробный разбор принципов планирования с примерами
🦋Нужен ли вам Agile? Новая модель применимости всё объясняет
🦋Гибкий водопад: гибрид Agile и Waterfall в проектном управлении. Часть 2
🦋Нарушая правила: как я выбросил 10-месячный проект после 2 месяцев в должности
🦋Как WhatsApp справлялся с 50 миллиардами сообщений в день, имея всего 32 инженера
🦋«Всё происходит само собой, когда тебе не всё равно»: как из игрока в покер стать руководителем тимлидов
Инструментарий
🛠20 лучших инструментов для таск-менеджмента, планирования и интеллект-карт
🛠Trello ofigello: что делать, если Atlassian выгнал силой
🛠Что не нравится в российских системах управления проектами ИТ-компаниям?
🛠Как компания нашла аналог Trello и что изменилось за год работы
YouTube
🔴 Разборы проектов и кейсов управления проектами от компании Инфостарт
🔴5 Effective Types of Requirements Documentation for Business Analysts
🔴Треки развития аналитиков. Кукбук или "Карьерный гайд"
🔴Бенчмаркинг как инструмент аналитика
🔴Как не просто работу работать, а в удовольствие: 6 практик, которые поднимают настроение команде
🔴OKR как методология личной и профессиональной эффективности: развивайся как Google
🔴Публичное собеседование: вакансия менеджера IT-проектов в компании Andersen.

Новый проектный дайджест уже ждет вас на VC - вместе с моими аннотациями, конечно)
Читайте и отдыхайте!
Итак, лучшее на этой неделе:
Основы и гайды
📌Инструкция для проджект-менеджеров: как выстроить эффективную коммуникацию с заказчиком
📌Приложение от проекта до релиза: этапы реализации
📌Как Kanban позволил повысить гибкость, прозрачность и скорость реализации ключевых проектов в компании
📌Примеры формулировок требований по правилам руководства по написанию требований от INCOSE
📌Управление портфелем проектов по методологии P3.express в Kaiten
📌Как справиться с техническим долгом в Scrum
📌Наводим порядок в бэклоге: как не потеряться среди сотен идей для развития продукта и выбрать лучшие

Карьера и навыки менеджера проекта
🥇ТОП-20 курсов по AGILE и SCRUM методологиям от лучших онлайн-школ
🥇Как в Тинькофф появились деливери-менеджеры и чем они занимаются
🥇Как развиваться Junior Project Manager в digital-агентстве
🥇Тебя уволят именно за это! Одно качество, которое влияет на успех в карьере и в жизни. Разбор на реальном примере
🥇Как найти руководителя международного проекта?

Команда проекта
👨‍👦‍👦Я устал: работа — рутина, и нет ощущения, что создаю что-то ценное. Как быть?
👨‍👦‍👦Как работать в удовольствие: 6 практик, которые поднимают настроение команде
👨‍👦‍👦Офис vs Удаленка. Как и зачем удерживать айтишников в офисе?
👨‍👦‍👦Как мы ведём базу знаний для бизнес-аналитиков: поиск, отбор и создание контента
👨‍👦‍👦Team Topologies: Рациональный Подход к Организации Команд

Опыт и советы
🦋Работа над ошибками: как мы анализируем дефекты
🦋Когда не стоит экономить на аналитике
🦋SAFe и как мы с этим живем
🦋Как писать технические задания для продакшенов, чтобы не получать ХЗ в результате

Инструментарий
🛠Учить, лечить, мочить: три инсайта о внедрении базы знаний от бизнес-консультанта с опытом работы в S7
🛠«Мультиверсионная» документация с GitHub Pages
🛠Это база: 10 сервисов, в которых удобно вести базу знаний
🛠Без стресса и хаоса: как вести аутсорс-проекты и не продать душу дьяволу
🛠Ща покажу: топ онлайн-досок для продуктивных созвонов с командой
🛠Как перевезти в новый таск-менеджер 35 очередей и десятки тысяч задач: история Mediascope

YouTube
🔴 Рациональный подход к декомпозиции систем на модули или микросервисы
🔴DDD в действии
🔴Моделирование бизнес-процессов. Кому от этого польза?
🔴Публичное собеседование: вакансия Account/Project manager

Новый выпуск дайджеста уже ждет вас на VC!
Самое заметное и интересное на этой неделе:
Основы и гайды
📌Создание карты зависимостей: как увидеть системный уровень в процессах
📌Говорить по делу и не переходить на личности: как правильно давать обратную связь
📌10 признаков недопонятого Agile, или почему ваш Agile не работает
📌Agile для всех или привычка натягивать сову на глобус
📌Естественный отбор в разработке: как вендоры и заказчики ПО выбирают между no-, low- и high-code
📌Как убедиться, что продукт соответствует ожиданиям заказчика?
📌Создание прототипа: как сэкономить нервы, время и деньги
📌Полный релиз бесплатного интерактивного 700-страничного учебника по тестированию

Карьера и навыки менеджера проекта
🥇Как вести за собой команду, ставить личные цели и помогать в этом сотрудникам
🥇Босс-идеалист: как с этим жить и не свихнуться
🥇Лидерство руководителя: как привести коллектив к работе не за страх, а за совесть
🥇Тестовые задания в IT: давать или не давать, вот в чем вопрос
🥇Больше, чем развлечение: какие фильмы пригодятся в работе проджектам и продактам

Команда проекта
👨‍👦‍👦Собрать dream-team или как выстроить процесс найма аналитиков в компании без большого опыта в этом непростом деле
👨‍👦‍👦Наставничество в компании: как к нему подступиться и почему это вам нужно
👨‍👦‍👦Как синхронизировать множество команд между собой
👨‍👦‍👦«В ближайшие 6 лет требования к системным аналитикам вряд ли сильно изменятся»
👨‍👦‍👦Кто такое Senior, Middle и Junior? И на кой ляд нужны грейды?
👨‍👦‍👦Кто такой архитектор ПО и как им стать

Опыт и советы
🦋5 последствий, которые ждут бизнес, если в разработке не будет участвовать ЛПР
🦋Меряем баги весами и рулеткой
🦋Продуктовый подход к инхаус-разработке: отвечаем бизнесу, когда наконец-то будет готово через метрики и 85й перцентиль
🦋"Здравствуйте, я - IT Project Manager" как каминг-аут
🦋Зачем Agile сотруднику, а не компании?

Инструментарий
🛠6 шаблонов досок в Miro для объединения кросс-функциональной команды
🛠Альтернативы Microsoft Exchange в облаке в России
🛠Топ популярных плагинов Confluence и их замена
🛠Обзор Zetep — эффективной системы ведения задач
🛠Вместо Trello: 5 сервисов c аналогичным функционалом
🛠Не Trello единым: чем заменить сервисы Atlassian в 2023 году
🛠7 инструментов управления проектами, которые должен знать каждый фрилансер

YouTube
🔴Event Storming: методика ускорения аналитических работ в ИТ-проекте • Денис Бесков
🔴Проблемы HR с Agile. Использование Agile в управлении персоналом
🔴Обзор методов сбора требований к ПО
🔴Матрица компетенций в развитии отдела тестирования
🔴What Are Sprints For?
🔴Модели корпоративной архитектуры. TOGAF 10 и Archimate 3.2 - обзор курса

Новый выпуск дайджеста - обзор за неделю!
И, видимо, скоро начнём публиковать на канале более частые сводки.
Итак, самое заметное и интересное на этой неделе:

Основы и гайды
📌Как ставят цели Google, Intel и Amazon? Разбираемся в методе OKR
📌Зачем нужна оценка зрелости бизнес-процессов при разработке системы
📌Погружаемся в базы данных и SQL: полезные материалы и инструменты от сотрудников Selectel
📌В толковый словарь Business Process Management: Бизнес-функция vs Бизнес-процесс
📌Простыми словами о Kubernetes и не только — материалы для менеджеров и парочка примечательных инструментов по теме

Проект-менеджер и команда проекта
🥇«Будем знакомы»: грантовый проект-менеджер, он же грантрайтер
🥇Собеседование руководителя проектов: как подготовиться и какие вопросы задать кандидату
🥇Почему компании не нужен архитектор
🥇Почему я сначала не хотел в тимлиды, а когда занял такую должность в ЮMoney, то понял, что это мой путь
🥇Метрики Эффективности Команд. Data driven подход к улучшению эффективности команд и бизнес результатов
🥇10 небанальных ресурсов для системного аналитика
🥇Полезное для начинающего Системного аналитика
🥇Компании плакали, кололись, но продолжали искать системных аналитиков
🥇Как устроен онбординг в больших компаниях: личный опыт
🥇«Миссия выполнима!» или как заставить работать подчиненных
🥇Smart-аналитик: ищем общий язык с заказчиком и руководителем проекта

Кейсы, опыт, советы, мнения
🦋Самая сложная часть создания программного обеспечения — это не написание кода, а сбор требований
🦋Минимум менеджеров, максимум инженеров: как Threads* удалось выпустить за пять месяцев
🦋Почему мои клиенты не спрашивают, как дела по проекту, пока я над ним работаю
🦋Без ТЗ результат ХЗ? Не думаю
🦋Как мы придумали LEGO-подход к разработке и успешно внедряем его
🦋Как мы построили свой лунапарк (с блекджеком, разумеется) или опыт внедрения системы управления ИТ-проектами
🦋Спринт, от которого конч*т заказчик - вывели свою формулу
🦋Как мы полностью перешли на Time&Material
🦋Канбан Метод в конструкторском бюро довел половину коллектива до истерики. Почему?
🦋Как довести разработчиков до слез, а менеджеров до отчаяния: практические советы

Инструментарий
🛠Джира для джунов, или как планировать и “не сгореть”
🛠Оптимизация работы с Camunda на основе External task
🛠Удаленная работа и IT: Как обеспечить эффективное взаимодействие команды из любой точки мира
🛠У Webinar Group появились собственные онлайн-доски
🛠Где работать с командой: подборка российских корпоративных мессенджеров в 2023 году
🛠«На сколько баллов ты сдал понимание этого регламента?»: как вдохновить сотрудников на чтение документов

YouTube
🔴 Владимир Маслов — System Design. Как построить распределенную систему и пройти собеседование
🔴 Управление командами в FMCG или как не стать Mudac`ом
🔴 Архитектурная модель Ф. Крачтена (4+1) как фактор управления требованиями и управления изменениями
🔴 7 Expert Business Analysis Tips & Secrets
🔴 Почему мы отказались от фуллстек аналитиков и как работает ролевая модель в энтерпрайзе
🔴 Общение с заинтересованными сторонами: Что нужно знать аналитику?
🔴 Эффективное обучение сотрудников: кого обучать, как часто и за чей счет
🔴 Как быстро изучить новую предметную область и провести предпроектное обследование
🔴 Модели soft skills для тимлида
🔴 Мой опыт: от системного аналитика до архитектора решений за 3 года
🔴 Обзор методов сбора требований к ПО

Ура, суббота! Новый выпуск дайджеста уже ждет вас на VC!
Самое заметное и интересное на неделе:

Основы и гайды
📌Как подружить бизнес и процессы
📌Управление рисками на анимационных проектах
📌Проектная команда: роли и функции
📌Роли и как они объединяются для развития продукта
📌Какие методы управления проектами наиболее эффективны?
📌10 лет Docker: от революционной идеи до современной практики

Карьера и навыки менеджера проекта
🥇К 2030 году мировой экономике потребуется 25 млн новых менеджеров проектов — и другие исследования
🥇Границы проекта в условиях «the roof is on fire»
🥇Рекомендации книг от СЕО M.Tech
🥇Книги по управлению проектами
🥇Руководство для менеджера проекта по освоению Agile методологии
🥇Точно в яблочко или как запускать проекты
🥇Почему каждый должен уметь строить диаграмму Ганта? Разбираемся на жизненных примерах

Команда проекта
👨‍👦‍👦7 золотых правил наставника в IT. Или первый раз в новый класс
👨‍👦‍👦Тестовое задание при приеме на работу: делать или нет? Что говорят эксперты и статистика
👨‍👦‍👦Человек не за бортом: зачем новеньким онбординг и как его проводить, чтобы первый день не стал последним + чек-лист
👨‍👦‍👦Адаптация, а не онбординг: что мы делаем, чтобы наши сотрудники влились в компанию?
👨‍👦‍👦От «эффективного менеджмента персонала» к бережливому управлению людьми. Часть 2: заряжаем батарейки сотрудников
👨‍👦‍👦Как отслеживать здоровье команды и не допускать выгорания
👨‍👦‍👦Слово о команде разработки. Часть 2: Место команды в матричной структуре компании
👨‍👦‍👦Что понимают технологические компании и чего не понимают традиционные компании о разработчиках ПО
👨‍👦‍👦Как растить сотрудника внутри компании: опыт руководителя UX/UI команды
👨‍👦‍👦PI Planing или Как синхронизировать работу в коллективе более 100 человек. Опыт проведения PI планирования
👨‍👦‍👦Как увеличение команды влияет на её продуктивность, или почему 9 женщин не смогут родить ребенка за 1 месяц
👨‍👦‍👦Как устроиться аналитиком в «Авито»

Опыт и советы
🦋Колодец с неприоритетными багами. Как мы закрыли 50 задач за две недели и научились не копить их
🦋Стиль Водолея: как внедрять инструменты менеджмента знаний, чтобы все остались довольны
🦋Исповедь о продуктовых провалах. 6 проектов, которые не стоило запускать, но мы все равно попробовали
🦋Интеграция — быть или не быть? 7 вопросов самому себе
🦋Как гибкая архитектура стала новой стратегией «Леруа Мерлен», а её айтишники получили свободу действий
🦋Как 30 секунд опроса помогают нам контролировать самые сложные IT-проекты

Инструментарий
🛠Альтернативы Trello, JIRA, Slack в России
🛠Asana добавляет функции искусственного интеллекта в свою платформу управления корпоративной работой
🛠Карманная академия: как прокачать обучение в компании с помощью корпоративного мессенджера
🛠Как маркетологу навести порядок в рабочих процессах, когда хаос и ты — одно целое
🛠Обзор на GB CRM — интеллектуальное решение для эффективного управления проектами
🛠Как PM-ы в своей работе могут использовать AI?

YouTube
🔴 Специфика крупных внедрений и как в них выжить специалисту 1С
🔴 Проблемы начинающего руководителя. Рабочие советы и кейсы из практики
🔴 Лучшие процессы в BPMN: работы учеников с курса 0704
🔴 Владимир Маслов — System Design. Как построить распределенную систему и пройти собеседование
🔴 OKR-мастер. Секреты внедрения OKR. Предобучение
🔴 Диаграмма последовательности - сильный инструмент в руках умелого аналитика
🔴 Вопросы и ответы про процессы. Vol.2

Новый выпуск дайджеста уже на VC!
Самое заметное и интересное на неделе:

Основы и гайды
📌 Управление закупками проекта
📌Как построить диаграмму Исикавы: пример и подборка сервисов с шаблонами
📌REST API vs GraphQL: в чём между ними разница
📌Как ответить на вопрос «Когда будет готово?» на основе статистики
📌Внедрить новый управленческий подход и не разрушить команду: эволюция vs революция и причем тут канбан
📌Событийное моделирование традиционных систем

Карьера и навыки менеджера проекта
🥇Как я учился не перебивать собеседников
🥇Почему с моим менеджером так тяжело работать или проблемы в общении с бывшими гуманитариями в IT
🥇20 признаков, что вам повезло с руководителем
🥇Конспект книги "Никаких правил" про корпкультуру Netflix + мой 15-летний опыт в менеджменте
🥇Как сделать конфликт полезным?
🥇Какие скиллы необходимы проектному менеджеру?

Команда проекта
👨‍👦‍👦Чем на самом деле занимается Chief Technical Officer?
👨‍👦‍👦Хэй, джун: как начинающему разработчику преуспеть в первые недели работы
👨‍👦‍👦За пределами KPI: 5 ключевых показателей климата в команде, которые нельзя игнорировать
👨‍👦‍👦Есть ли жизнь после трехчасового созвона?
👨‍👦‍👦Как поощрять лидерские качества в команде на всех уровнях, чтобы бизнес взлетел
👨‍👦‍👦Как построить систему наставничества в IT-компании с нуля
👨‍👦‍👦Кроссдоменная координация. Как двигать огромные IT-проекты в огромной компании
👨‍👦‍👦Работа без созвонов: как компании полностью отказались от совещаний и встреч

Опыт и советы
🦋Как подготовиться к собеседованию: несколько советов, чтобы повысить ваши шансы на трудоустройство
🦋Как внедрить гайд по стилю кода в проект
🦋Записки технического руководителя проектов
🦋Успешный программный продукт без ТЗ: как сэкономить на разработке технического задания и получить 100% результат
🦋Заказал Boeing, а получил кукурузник: почему так случается и при разработке приложения

Инструментарий
🛠Diplodoc — открытый набор инструментов для создания документации
🛠Расследование: Импортозамещение ПО – могут ли наши повторить?
🛠Diátaxis: структура технической документации
🛠Сервисы для планирования MVP: несколько наблюдений после использования
🛠Сотрудники не хотят использовать таск-менеджер. Разбираемся, как их переубедить
🛠Обзор возможностей российской системы проектного управления
🛠Гибкая и жесткая инициация проектов: какую выбрать

YouTube
🔴 Что такое управление проектами? Кому и зачем нужен таск-менеджер?
🔴Эффектное и эффективное техническое задание для собеседований
🔴Как выжить аналитику в атмосфере вечной неопределённости
🔴Пользовательские сценарии — типичные ошибки и пути их решения
🔴BPMN за 9 минут: все квадратики на примерах
🔴Проектная кухня «Софты vs харды. Их можно развить или это врожденные качества?»
🔴Test-Driven Development (TDD) and Agility
🔴Скрытая работа аналитика по проектированию систем
🔴Тестировщик ПО. Есть ли будущее у профессии, заменит ли тестирование ИИ?
🔴Event Sourcing. Плюсы, минусы и подводные камни

Новый выпуск дайджеста уже на VC!
Самое заметное и интересное на неделе:

Основы и гайды
📌 PMBoK — управление проектами с умом
📌Управление знаниями в продукте
📌Поиск лучшего метода оценки времени выполнения задач: кейс команды Kaiten
📌Как написать понятные требования к ПО
📌Как эффективно добавлять документацию при разработке продукта?
📌Теория ограничений, здравый смысл и себестоимость
📌Гибридная система управления менеджмента
📌«Конкурентные преимущества»: полезные материалы для разностороннего проектирования тех.продуктов
📌Как приоритизировать фичи с помощью Unit-экономики?
📌API от А до Я (теория и практика)
📌15 ресурсов по Git. Что почитать/посмотреть?

Карьера и навыки менеджера проекта
🥇Системное представление управления проектами
🥇Почему айтишники часто не справляются с ролью скрам-мастера? И как ментор может с этим помочь?
🥇Как я стал руководителем проекта в IT в 2023 году после обучения
🥇Жить — не тушить: антикризисный режим в управлении проектами
🥇Как найти руководителя международного проекта?
🥇Почему на проекте все идет не по плану
🥇Руководить, когда не готов к этому: путь от «чайка-менеджера» до «servant leader»
🥇Сложные клиенты в ИТ: через тернии к профиту
🥇Анализ «Пяти неправд»


Команда проекта
👨‍👦‍👦Пустите разработчика в продукт
👨‍👦‍👦«Пятидневка в офисе мертва»: компании негодуют из-за удаленной работы
👨‍👦‍👦Что бывает, когда в настольный футбол играют разработчики: проапгрейдили не только игру, но и корпоративную культуру
👨‍👦‍👦Как сформировать проектную команду для цифровизации бизнеса
👨‍👦‍👦Роль и трансформация профессии бизнес-аналитика
👨‍👦‍👦Как системному аналитику найти работу

Кейсы, опыт, советы, мнения
🦋Эволюция фичи за три года: кейс рассылки спецпредложений Авито
🦋Как вести несколько проектов и не сойти с ума. Очередная статья про тайм-менеджмент
🦋Три ошибки, приводящие к бесконечной разработке проекта
🦋Кейс СУШИШОП: непростая разработка мобильного приложения для сетевой компании
🦋Внедрение pet-проекта в реальный бизнес или как в одиночку написать ERP-систему для общепита
🦋Как мы все занялись стратегией: внедрение OKR
🦋Почему модель «MVP + развитие» лучше, чем классическая водопадная

Инструментарий
🛠Создание системы документирования, или как в Cloud.ru от «ворда» к docs as code за месяц переходили
🛠Разработчик сервисов для видеозвонков Webinar сменил название на «МТС Линк»
🛠Эксперимент: отдельный мессенджер под новый проект. Немного про Compass
🛠Инструмент, который легко преобразует видео с YouTube в презентации
YouTube
🔴 Бизнес-архитектура и ее место в компании
🔴 Как избежать фатальных ошибок при разработке IT продукта
🔴 Секреты успешного управления продуктами
🔴 Use Case или как аналитику быть полезным тестировщику
🔴 Onboarding: правила, ошибки, лайфхаки
🔴 AAC - Agile Analysis Certification
Как разобраться в предметной области: инструкция по применению
🔴 Готовь сани летом.. или почему тимлиду нужно начинать готовить команду к своему отпуску еще с осени
🔴 Is Velocity an Effective Tool For Planning?

Всем привет) Обычно мало пишу "отсебятины": сказано и так много, а сделано существенно меньше. Но тут интересная тема из разряда "не могу молчать".

Один известный автор (про проекты) опубликовал кейс про мудака. Вкратце: жила-была проектная команда, которая наняла к себе в аналитики сотрудника, да не простого, а очень прошаренного в предметной области. Но раньше в качестве аналитика не работавшего. И отправила его к заказчику на сбор требований. А он возьми да и начни заявлять заказчику, что тот работает не по фэншую и что нужно не требования собирать, а сам процесс перестраивать. Заказчик в шоке (не для этого затевали проект), команда в шоке (требований нет, контракт под угрозой), "аналитик", видимо, тоже.

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

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

С другой стороны, в разборе кейса не было ни одного вывода в отношении самой команды, ПМа и процессов. А ведь именно они, во-первых, позволили появиться в проекте "мудаку" и создали условия для появления конфликта с заказчиком. Кто-то его принимал на работу, кто-то проверял его навыки как аналитика, - а учитывая, что опыта не было (и об этом знали), кто-то еще и вводил в обязанности, онбордил и т.д. И, получается, либо процесс найма-онбординга в команде проблемный, либо его вообще не было.
Во-вторых, "черно-белое" мышление. На каждом углу говорят про "биасы" и шум в принятии решений, про ошибки интуиции, про "пять почему", про ошибки предвзятости. Тем не менее, расстроило то, с какой радостью менеджерам хочется прикрепить к не вписавшемуся в команду сотруднику ярлык "мудака" и прикрыться от реальности совершенно бессмысленной, но наркотической фразой "не работайте с мудаками", - вместо того, чтобы сделать работу над (своими) ошибками, перестроить процессы так, чтобы такие люди либо не попадали в команду, либо прошли обучение, либо работали как "предметники" без общения с заказчиком. Так и проект был бы более успешным, без лишнего превозмогания, и токсичности было бы меньше в команде. Да и эксперта не потеряли бы, возможно.

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

В общем, разные ситуации бывают. В любом случае, не спешите "не работать с мудаками"))