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

#почитать

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

Стандартный цикл выхода из кризиса:
1. Назначить ответственного
2. Определить цели
3. Сконцентрироваться на проблеме
4. Составить план действий
5. Сохранять единое информационное поле
6. Измерять результаты
7. Рефлексировать

⏱Читать статью

🟡Дайджест полезных материалов по project и product менеджменту за неделю c 27 ноября по 3 декабря

🔖 Почитать:

▪️Если процесс нельзя роботизировать, то он кривой
▪️Идеальное резюме бизнес-аналитика
▪️Управление командой. Weekly-встреча
▪️Как добавить Impact Map, CJM и USM в документ и не пострадать
▪️Правильное проектирование
▪️Почему в Google и Intel любят OKR
▪️Микроменеджмент — зло
▪️Как выиграть дуэль с тимлидом и клиентом
▪️Как российская IT-компания выстраивает корпоративную культуру для удаленных сотрудников, не хуже, чем в Google
▪️Как общаться с коллегами, которые бесят, и не перейти на КАПСЛОК
▪️Как предупредить негативные настроения в команде - они заразные

👀 Посмотреть:

🌐 Рынок ИТ: как изменились зарплаты и вакансии для джунов за 2023 год ⏱1 час 15 минут
🌐 Интервью с автором Learning Domain-Driven Design ⏱1 час 40 минут
🌐 Что такое FIT interview? ⏱2 часа 20 минут
🌐 Интеграции (REST&SOAP) с позиции System Analyst ⏱45 минут

⏱Подробный дайджест с описаниями

Хорошего дня!

LEGO-подход к разработке проектов - идея и логика которых никак не описаны. Product Discovery

#почитать

"Мы сначала подготавливаем нефункциональные требования, формируем пользовательские сценарии (User Stories), документируем их в виде диаграмм с логикой продукта и архитектурой базы данных. После определения сценариев мы создаём вайрфреймы – прототипы интерфейса, которые показывают пользовательские сценарии в картинках. Наш формат максимально похож на Product Discovery — фазу в развитии продукта, когда команда изучает рынок и формирует требования к продукту."

⏱Читать статью

▫️Process Mining – специфический способ анализа процессов

#посмотреть

▫️Данные о событиях должны считаться объектами первого класса
▫️Журналы должны извлекаться в соответствии с предметными вопросами
▫️Необходимость поддержки операторов параллелизма, выбора и других базовых элементов моделей потока управления
▫️События должны соотноситься с элементами модели
▫️Модели следует рассматривать как целенаправленные абстракции реальности
▫️Process Mining должен быть непрерывным

⏱Смотреть видео на YouTube ⏱1 час

Чемпионат продактов. Вместо тошных тестов по компетенциям - соревнование по бизнес-кейсам

#почитать

Профессиональный уровень продакта объективно оценить весьма трудно, потому что:
▫️уровень знаний не говорит об уровне в профессии
▫️ожидания стейкхолдеров не сформулированы явно
▫️сложно добиться объективности

Взяли кейс с реальным контекстом, в котором оказался один из наших продактов. Ответ на тестовое задание невозможно уместить в одно предложение или выбрать правильный вариант из предложенных. Для повышения объективности решили использовать крауд-оценку — анонимное ранжирование решений участниками друг друга.

⏱Читать статью

Наследие прошлых разработчиков. Что делать с легаси-проектом (создать 3 спецкоманды)

#почитать

Типичное:
▫️Документации нет
▫️«Что-то» находится у другого исполнителя
▫️Защищенный периметр, сложно обмениваться кодом
▫️Решение не работает или работает некорректно

Что делать:
Одним из вариантов эффективного управления командой разработки на легаси-проектах могут быть выделенные команды.
▫️1. Support Team. Основная задача: поддержание стабильности проекта и оперативное устранение ошибок.
▫️2. Refactoring Team. Основная задача: оптимизация, реорганизация и модернизация кода.
▫️3. Feature Team. Основная задача: разработка и добавление новых функциональностей, которые будут актуальными для проекта в будущем.

⏱Читать статью

▫️Спорный вопрос: можно ли отказаться от фуллстек-аналитиков. Обсуждение на Analyst Days

#посмотреть

По крайней мере в X5 Tech отказались, и ничего не случилось.

⏱Смотреть видео на YouTube ⏱25 минут

Откажитесь от формата Историй. Они себя изжили. Пользователя привлекает контент, а не "сторис"

#почитать

▫️"Расскажу вам, как мы реализовали проект «Истории»: опишу вдохновение, разочарования, запуск и метрики, и отвечу на вопрос — должны ли истории умереть (да). Эта информация может пригодится тем, кто планирует запускать такой или похожий проект в своём продукте, или думает о том, как решить похожие задачи.

▫️Первое, с чего мы начали — пошли советоваться с теми, у кого в продуктах уже работают истории для бизнеса. И сразу напоролись на мнение о том, что истории себя изжили, это прошлый век, нужно придумывать что-то новое. Мне понравилась эта мысль, но я думал (ошибался), что время историй ещё не прошло.

▫️Это подтвердил релиз Telegram спустя пару месяцев, все мы были не рады видеть истории наших бывших, крепко забытых людей из прошлого, и вообще странных личностей."

▫️Коменты на Хабре традиционно ещё ярче чем статья: "Как же бесит этот тренд на истории. Большинство использует истории для одного - разложить усталый мозг за просмотром незатейливых тупых историй. Всё. Кто, скажите мне, кто придумал позиционировать истории как полезный инструмент? Тот же, кто начал лепить везде в таблицах админкок бесконечный скролл вместо паджинации?"

⏱Читать статью

🟡Дайджест полезных материалов по project и product менеджменту за неделю c 4 по 10 декабря

🔖 Почитать:

▪️Важное на старте нового проекта
▪️История методологий. Что дальше? LLM-модели и безработица
▪️Уточнение требований. Вопросы закрытые и открытые
▪️Карта пути клиента на примере покупки Tesla
▪️Выполнение задач можно прогнозировать с вероятностью 80-90%
▪️Когда проект растет — надо менять подходы
▪️Есть такой стиль лидерства — служение
▪️Дневник эмоций и эмоциональная безопасность
▪️Полное руководство по фидбеку
▪️Нетворкинг и личный бренд реально влияют на ЗП. Просто у этих вещей есть плохие названия
▪️Я добился успеха как ПМ вообще без негатива
▪️Тирания маргинального юзера. Почему всё вокруг становится примитивнее (крайне субъективная точка зрения, тем не менее заслуживающая обсуждения)

👀 Посмотреть:

🌐 Счастливый заказчик и счастливая команда ⏱30 минут
🌐 Продуктовая революция ⏱30 минут
🌐 Как работают со стейкхолдерами в Спортмастере ⏱45 минут
🌐 Лекция про исследование клиентского и пользовательского опыта ⏱50 минут

⏱Подробный дайджест с описаниями

Хорошего дня!

Эффективная командная работа: рецепты Яндекса для командиров проектов

#почитать

▫️Определитесь с целью
▫️Выберите неформального лидера
▫️Договоритесь о базовых принципах взаимодействия
▫️Обсудите и добавьте ритуалы
▫️Говорите и слушайте — это помогает!

В конце немного расскажу о том, что делать, если застрял с задачей.

⏱Читать статью

Деды были правы: делай что-то одно и делай это хорошо

#почитать

▫️40 лет назад два идеолога, две легенды computer science Брайан Керниган и Роб Пайк опубликовали радикальный манифест… ну, или что-то вроде того. Сформулировали в книге Program Design in the UNIX Environment паттерн архитектуры ПО, за сохранение которого оба боролись долгие годы. Как и следовало ожидать от манифеста, в нём два этих канадских инженера максимально решительны.

▫️Самый резкий тейк в статье — это запомнившаяся многим строчка из аннотации: Старые программы покрываются коркой сомнительных фич.

▫️Суть статьи часто сводят к аббревиатуре DOTADIW, или «Do One Thing And Do It Well» («Делай что-то одно и делай это хорошо»).

▫️К сожалению, как и в случае с большинством манифестов, этот идеал не выдержал столкновения с реальностью. Прекрасная идея Кернигана и Пайка так никогда и не дала плодов.

▫️Керниган и Пайк были правы хотя бы в одном: что раздувание ПО является проблемой. Огромные приложения сложно изучать, трудно использовать и в них куча багов. Это и есть гниение платформ. Крупных платформ - монолитных платформ.

▫️Попыткой частичного решения DOTADIW стали микросервисы. Микросервисы должны «делать что-то одно и делать это хорошо».

▫️При разбиении сервисов на мелкие части мы получаем микросервисы, а при разбиении фронтендов — очевидно, микрофронтенды. Но на самом деле микрофронтенды являются ребрендингом старой идеи: апплетов.

▫️Простых ответов не существует, но повсюду можно найти подсказки. Чтобы подобрать идеальную структуру для сложного ПО, обратите внимание на структуры, пережившие миллиарды лет жесточайшей эволюции: атомы и молекулы, солнечные системы и галактики, наши собственные внутренние органы. Тракторы и камеры. Obsidian и VS Code. Все они созданы из маленьких однофункциональных блоков, как и задумывалось Керниганом и Пайком.

⏱Читать статью