Этот дайджест создан совместно с телеграм-каналом PM Live | проджект и продакт менеджмент. Подпишитесь, чтобы получать дайджесты прямо в телеграм!
Почитать:
Мне часто пишут и задают вопросы о моих прошлых статьях по IDEF0, MRP, ERP, BPMN и т.д. И очень часто звучит один и тот же вопрос, «устарел ли» тот самый IDEF0 или другая методология, технология, система. Также часто задают вопрос, а что лучше, например, «BPMN или ERP». В целом, все эти вопросы можно объединить в один – «устарела ли та или иная технология». Потому я решил поговорить о том, как в принципе стоит относиться к технологиям, и можно ли оценивать их с точки зрения времени, прошедшего с их выпуска, т.е. говорить об устаревании.
Метод оценки движения людей в пространстве и оптимизации бизнес-процессов.
Прежде, чем объединяться, нам надо решительно размежеваться (Business continuity management vs Business Process Continuity vs Dependability in technics). Синонимы: Надежность в процессах = надежность процессов = надежность операций = операционная надежность.
Для компании SimpleOne управление спецификациями требований было настоящей головной болью, требующей унификации подходов и учета потребностей разных команд. Мы стояли перед выбором: сделать свое решение для управления требованиями и сбора спецификаций или попробовать уже существующие практики. Концепция DocOps привлекла внимание тем, что помогает стандартизировать инструменты и навести порядок в хранении артефактов… В этой статье мы расскажем, как внедрили подход на основе docs as code, какие преимущества получили и какие трудности преодолели на пути.
Разница в графиках даже на один час может помешать общению, усложнить его.
Если новичок постоянно отвлекает коллег вопросами и не понимает, что ему нужно сделать в первый день работы, с онбордингом в компании что-то не так.
STATIK (от англ. Systems Thinking Approach To Introducing Kanban) расшифровывается как «системный подход для представления Канбана». Он разработан Дэвидом Андерсоном и задумывался как основной подход к внедрению Канбан в компаниях. STATIK показывает, как система ведёт себя в целом, а не через анализ отдельных её частей.
Классический подход в разработке продуктов требует сначала провести исследование, а потом уже создавать продукт. В Passion-Driven Decision Making вы сначала создаете продукт, а потом подбираете инструменты для его продвижения и развития.
Более 90% российских IT-специалистов сталкивались с выгоранием. При этом более 40% доводят себя до поздних стадий, когда эмоциональное истощение уже перерастает в депрессию.
В статье рассказываем, как на этапе Discovery (начальный этап проработки задачи, на котором выявляются основные требования и анализируются поставленные бизнес‑цели) прорабатывать большие инициативы, используя USM.
Фокус делаем на практическом использовании карты и на что обращать внимание при построении USM. Мы собрали возможные сложности, разобрали конкретные кейсы и описали варианты взаимодействия с заинтересованными лицами.
Информация будет вам полезна, если вы провели минимум 20 кастдевов, умеете формулировать гипотезы и знаете, что вопросы должны касаться исключительно прошлого опыта, а не будущих намерений.
В этой статье рассказываю о применении дашборда функциональной составляющей качества продукта, наборе показателей качества, на нём отражаемых, способах их измерения, основанных на рекомендациях стандарта ISO 25023 и показываю положительные изменения в работе продукта.
Среди нас есть люди, которые являются искусными стратегами. Они могут вникнуть в любую область, понять всю её модель, а потом составить стратегию следующего шага развития с чистого листа.
Проблема только в том, что приёмы, с помощью которых эти гении создают стратегии, являются их персональными методами. Они неразрывно связаны с особенностями мышления, культуры, опыта и так далее, присущими конкретному человеку. То есть эти приёмы неотделимы от носителя — без него они не работают.
В этой статье мы хотим поделиться историей, как мы разработали продукт c использованием современных технологий AI, ML, NLP и применили этот продукт для оптимизации собственных процессов. Главная проблема в соблюдении требований: их всегда очень много! Особенно в случае проектирования и эксплуатации сложных агрегированных составных систем, производимых различными субподрядчиками. В процессе работы необходимо учитывать множество как мелких, так и значимых условий требований, каждое из которых может влиять на конечный результат. Поэтому большое значение придается отслеживанию, актуализации и проверки всех требований на каждом этапе проекта. Это особенно важно в проектах, где необходимо точное соответствие результата техническому заданию. Исследовав проблему, мы обнаружили, что задача соблюдения и отслеживания технических требований остро стоит также у технического персонала (проектные офисы, инженеры), юристов, экономистов и руководства компании.
Мне доверили руководство новой командой в проекте, который уже был в стадии разработки. Эта команда работала по процессам, отличающимся от стандартных практик нашей компании. Веря в их экспертность и не желая разрушить устоявшийся рабочий процесс в бегущем проекте, я решила не углубляться особо в их методологию и не проводить дополнительных встреч, чтобы выяснить детали: как они работают, как проект работает и как именно планируется реализовать задуманное решение. Я безоговорочно доверилась их прогнозам по срокам — это то, что впоследствии оказалось моей главной ошибкой.
Что мы поняли, запустив простой конвертер картинок за 1 месяц в США. И как заработали 100 000 рублей за первые 3 месяца, хотя вокруг куча бесплатных аналогов.
В современном мире программирование связано с высокой стрессовой нагрузкой — намного большей, чем на моей памяти было в 90-х и начале 2000-х, когда я только начинал свой путь в этой сфере. В те времена безумие начиналось в преддверии дедлайнов, но в остальное время всё шло более-менее размеренно.
Взаимодействие между коллегами усложнилось, а процессы пошатнулись. Мы поняли, что нам пойдет на пользу время от времени встречаться всей командой, чтобы выслушать друг друга и понять, почему что-то не получается. Так мы пришли к мысли провести ретро.
В последние годы в бизнес-среде России стал популярен такой термин, как «траблшутинг». В России он овеян легендами. Существует мнение, что траблшутер – это человек, работающий за огромные деньги, который находит решения проблем за считаные часы, почти всегда секретно, и посредством этих решений, приносит корпорациям огромные деньги. Своего рода секретный агент на службе бизнеса.
Рассказываю, как разрушить империю продуктовую команду, сломать ее взаимодействие с другими отделами и иллюстрирую текст реальными историями.
Обсудим, почему «сгорают» незавершенные задачи, как визуализировать ограничения, чтобы наладить диалог с бизнесом и повысить предсказуемость процесса и, конечно, как в этом нам помогут Канбан-доска и WIP-лимит.
Посмотреть:
- Тренды рынка труда 2024 ⏱1 час
Стоит ли менять работу и где искать самые интересные вакансии? Работа на результат, урезание костов, переход в регионы и удержание сотрудников — основные тренды 2025 года. Как поменялись основные игроки и что сейчас происходит на рынке труда в ИТ рассказала Ирина Кузьменкова — карьерный консультант и генеральный директор Бюро по талантам UPSTEP, в прошлом HR директор научно-технического центра Газпром нефть.
При составлении дашборда понятно, что нужно сделать: сформулировать задачу, выбрать данные и показать их. Но часто при этом теряется какая-то часть и это обнуляет результат работы.
Как выйти на уровень стратегии с помощью Карты гипотез. Это позволяет решить все вышеперечисленные проблемы и разгоняет внутри компании маховик инноваций.
- Как создать продуктовую стратегию ⏱1 час 40 минут
Разработка продуктовой стратегии часто воспринимается как один из самых сложных и запутанных процессов для руководителей продуктов, CPO и собственников бизнеса. Однако это не «магия», а последовательная работа, основанная на видении, аналитике и исследованиях. Как связать знания о рынке и потребностях пользователей с целями компании? Как превратить гору данных в структурированный план?
Почему так происходит? Почему подстраховка не спасает, а ранний старт приводит к ещё более позднему финишу? Как понять, что мы опаздываем, когда ещё можно что-то сделать, а не когда дедлайн уже завтра? Как распределять ресурсы между проектами, когда всё в огне.
