Рекомендации по снижению риска издержек в ходе цифровой трансформации компаний МСБ

#почитать

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

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

Переход на эфемерную среду тестирования. К чему подготовиться проектному менеджеру

#почитать

Для тех, кто пока не сталкивался с Эфемерными средами: такая среда создается на короткий период и удаляется после тестирования. Эта среда более чистая (в ней код от develop и ветка задачи на проверку, больше ничего).

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

"Я по факту выполнял невидимую функцию продакта: просчитывал юнит-экономику, строил CJM, формулировал SMART-гипотезы"

#почитать

До обучения в Geekbrains 4 года работал в Сбере. Прошёл путь от выездного специалиста по прямым продажам, втюхивал кредиты рАботягам и офисному планктону по телефону. Да-да, был именно тем «человеком», который звонит вам в 8 вечера или в 9 утра и предлагает кредитную карточку (и поверьте, в этот момент он максимально несчастлив). А потом в дождь, град и в -30 в туфельках, брюках и рубашечке с отмороженными конечностями (ведь ты доблестный представитель Банка и должен выглядеть солидно, а не практично) спешит к Вам на работу или домой, чтобы Вы стали счастливыми обладателями ипотеки от Сбера;)
Пройдя этот ад, стал менеджером по продажам в управлении «Безналичные решения». Продавал такие продукты, как Сбер спасибо, QR код, интернет/торговый эквайринг, кредитование на терминалах, Сбер Pay и тд. А закончил уже КАМом в корпоративном блоке — реализуя в принципе всю линейку продуктов Сбера (Основной упор кредитование бизнеса), включая Saas‑решения.
И вот на 4 год своей трудокарьеры в Сбере, с ежедневными переработками в 1,5 часа и скотским отношением руководства, я окончательно выгорел."

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

▪️"Пестование системной сложности по Щедровицкому". Большой текст об управлении знаниями

#почитать

Принципы систематизации знаний при проектировании цифровых продуктов.

"Прежде важно договориться о понятии системы. Мы воспользуемся для этого категорийным понятием системно‑структурного подхода [Щедровицкий, 1995]. Согласно ему, ... "

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

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

🔖 Почитать:

▪️Triforce-встречи, или встречи трех амигос, как они помогают согласовать критерии приемки
▪️Спектральный анализ должен снизить стресс в команде
▪️Дауншифтинг из ПМа в разрабы. Причем в джуны. В EPAM
▪️Продакт — это не директор
▪️Идеальные отношения со стейкхолдерами
▪️Как проджекту найти нормальный проект на удаленке
▪️Бывший разработчик не станет успешным предпринимателем, пока не научится управлять командой
▪️Не бойтесь брать джунов — просто смотрите на них по другому
▪️Команда, разбросанная по всему миру — может быть эффективной
▪️Плохой девелопмент и ChatGPT
▪️Сколько стоит «минимальный набор» для IT-бизнеса

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

🌐Самоуправление в косметической компании ⏱25 минут
🌐 How to Be a High-Performing Business Analyst 🇻🇬⏱1 час 15 минут
🌐 Человечность позволяет добиваться выдающихся результатов ⏱40 минут

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

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

Список необходимой информации для составления ТЗ - от бизнес-идеи до готового документа

#почитать

Кому будет полезно:
▫️Тем, кто начинает свой путь в IT-предпринимательстве, но не знаком с технической стороной вопроса.
▫️Начинающим менеджерам IT-проектов, которые пока не имеют опыта в постановке задач подрядчикам.
▫️Владельцам уже существующих проектов, которые нуждаются в дополнениях/доработках.

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

Краткое изложение последней версии свода знаний Project Management Body of Knowledge (PMBoK)

#почитать

Первый комментарий: "Мастрид для всех руководителей проекта. Но читать лучше спустя полгода-год практики, чтобы понимать о чем речь"

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

▫️ BPMN-нотация кажется простой и понятной. Кажется.

#почитать #посмотреть

Ошибки в BPMN бывают трех видов:

▫️Ошибки формальные — когда диаграмма не соответствует BPMN.
▫️Ошибки стиля — когда схема формально правильная, но читать или модифицировать её неудобно.
▫️Ошибки логики — это когда схема правильная, стиль соблюден, но есть проблемы в сути того, что нарисовано.

⏱Почитать достаточно полный разбор ошибок
или
▫️ Посмотреть на YouTube ⏱20 минут

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

#почитать

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

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

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

#почитать

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

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

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

▫️Постепенная рационализация процессов - Process Decision Record

#посмотреть

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

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

Анализ сотен миллионов строк кода - о фреймворке для удаления мёртвого, с точки зрения бизнеса, кода

#почитать

В фреймворке Systematic Code and Asset Removal Framework (SCARF) компании Meta* есть подсистема выявления и удаления мёртвого кода. SCARF использует статический и динамический анализ программ для выявления кода, мёртвого с точки зрения как бизнеса, так и языков программирования. Этот фреймворк автоматически создаёт запросы изменений, удаляющие мёртвый код, выявленный при помощи анализа программ, таким образом, минимизируя трудозатраты разработчиков.

Их подходы:
▫️Анализ кода
▫️Сборка мусора
▫️Тонкая настройка графа зависимостей
▫️Автоматизация изменений в коде
▫️Крупномасштабное и точечное удаление
▫️Достаточно ли просто удаления

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

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

🔖 Почитать:

▪️Непрерывный рефакторинг: семь принципов
▪️Рынок заставил сделать аналог Jira
▪️Сложности планирования
▪️Метод «помидора» повышения эффективности продуктовых команд
▪️Распространённые проблемы разработки, связанные с людьми
▪️Плоская модель управления организацией
▪️Как проводить диагностику команды при помощи ролевых игр
▪️Опыт Kaiten, как избавиться от стресса и лишних созвонов
▪️Токсичность в российском ИТ безусловно присутствует
▪️Что такое HADI-циклы
▪️Покер-планирование спринтов

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

🌐 Новый метод мозгового штурма — «Холивар» ⏱10 минут
🌐 Опыт OKR в Тинькофф ⏱30 минут
🌐 Как измерить скрам-мастера ⏱45 минут

🟢Полная версия дайджеста на сайте

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

Уточнение таймлайна проекта: почему ошибаемся в оценке времени и что можно исправить

#почитать

В реальной жизни мало кто может позволить себе подход Джона Кармака, который, разрабатывая Doom 3, заявил: «Будет сделано, когда будет сделано». Но вообще оценка таймлайна проектов — это скилл, его можно прокачать.

▫️поймите, для чего нужна оценка
▫️возьмите время «на подумать»
▫️задавайте правильный вопрос
▫️соберите команду оценки
▫️сделайте блиц-оценку
▫️документируйте предположения
▫️разбейте проект на понятные части
▫️используйте диапазон для оценки
▫️исследуйте сложные части до оценки
▫️сравните свои оценки с историческими данными
▫️используйте удобные единицы времени
▫️анализируйте, что получилось в итоге

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

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

#почитать

Как правильно выстроить общение в команде и почему это важно. В статье сформулировал принципы общения с коллегами, в котором есть место вопросам, доверию и делегированию.

Как я это сделал:
▫️Корректно и подробно ставил задачи
▫️Ставил дедлайны с большим запасом
▫️Не боялся делегировать
▫️Но плотно контролировал результаты
▫️Мотивировал премиями, благодарственными письмами и подсказками
▫️Поощрял дружеское общение внутри команды

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