Инструменты Lean. Черный пояс по Lean Six Sigma

#посмотреть

Содержание:
▫️Что такое Lean в трех-пяти предложениях
▫️Кто такой специалист по Lean
▫️Что он делает в современных российских компаниях
▫️Идут ли сегодня компании на использование Lean-техник
▫️В чем фокус Lean-практик
▫️Есть ли у вас опыт применения Lean для улучшений нематериальной работы
▫️Lean разный. Есть про материальное производство, есть про интеллектуальное. Это разные курсы и пояса
▫️Какая книга введения в Lean самая базовая
▫️Какие сертификации есть у Lean
▫️Различаются ли пояса по Lean и по Lean Six Sigma
▫️Можно быть специалистом по Six Sigma и не специалистом по Lean
▫️Lean базируется на ценностях Agile
▫️Lean — это про Кайдзен или про Кайкаку
▫️Как бы вы объяснили Lean обывателю
▫️Если что-то из 5S не соблюдается, это уже не Lean
▫️Есть ли какая-то самоцель у организаций внедрить все, что есть в Lean и называться Lean-компанией
▫️В каких источниках можно найти кейсы применения Lean
▫️Как ты попала в бережливое производство
▫️Если вернуться назад и построить карьеру заново, ты бы тоже выбрала Lean
▫️Есть ли какие-то различные взгляды и разные школы в бережливом производстве со своими противоречиями
▫️Что на данный момент в Lean является устаревшей практикой

⏱Смотреть на YouTube ⏱40 минут

▫️ BPMN за 9 минут: все квадратики на примерах

#посмотреть

"Все вообще типы квадратиков в BPMN"

⏱Смотреть на YouTube ⏱9 минут

▫️ Импортозамещение BI. Встраивание 1С:Аналитики в аналитический ландшафт компании

#посмотреть

Когда эффективность работы бизнес-аналитика ограничивается скоростью разработки, и добавление одного поля в отчет PowerBI занимает до полутора месяцев, приходится искать альтернативы. Рассказ том, как встраивание 1С:Аналитики в BI-ландшафт компании помогло оперативно импортозаместить Power BI и повысить эффективность бизнес-анализа в компании.

⏱Смотреть на YouTube ⏱30 минут

Техническое задание в картинках. Главное

#почитать

Что важно:

1. Система понятий, терминов, определений, которые используются при описании требований, должна быть единообразной, конкретной, одинаково пониматься и Заказчиком и Исполнителем.

2. Требования должны взаимно увязываться между собой, желательно выявить смысл каждого требования, цель его предъявления, а также влияние требования на оконечный продукт.

3. Выполнение требования должно быть достоверно проверяемо, то есть должна существовать такая процедура проверки, которая будет необходима и достаточна для подтверждения выполнения требования.

4. Способ проверки может быть разным для разных видов требований, выполнение требования может проверяться как аналитически так и фактически - непосредственным наблюдением.

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

Как синхронизировать множество команд между собой

#почитать

Мы делаем интернет-эквайринг для бизнеса, и в разработке продукта участвуют 30 команд. При создании новой фичи какие-то команды могут действовать обособленно, но это редкость. В большинстве случаев командам при разработке нужна помощь друг друга. Расскажу, как у нас получилось сделать так, чтобы не было очередей из команд.

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

▫️ Пятничное. История Канбан в России

#посмотреть

Подробно: c чего все начиналось, и какие дальнейшие планы канбан-комьюнити.

⏱Смотреть на YouTube ⏱30 минут

Контроль продуктивности. Тайм-трекеры

#почитать

Коменты:

Статью стоило назвать - "Как превратить разработчиков в рабов в кандалах тайм трекера", "Практикуем галерный подход к организации работы разработчиков","Как заставить разработчика писать код под бой барабанов менеджера" и т.д.

Просто удивительно, как много этой пакости.

⏱Читать

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

🔖 Почитать:

▪️Управление стрессом в удаленных командах
▪️Хит недели на Хабре: Почему новым сотрудникам платят больше, чем работающим давно
▪️20 тайм-трекеров на любой вкус (антихит недели на Хабре)
▪️Неклассическое чтение для руководителей
▪️Как руководить экологично
▪️Чем отличается 1% лучших менеджеров по продукту от 10% лучших. Иэн Макалистер
▪️Управление проектами в работе и жизни
▪️Айсберг системного мышления
▪️Экс-вице-президент по работе с персоналом Google: «Отделите рабочие цели от зарплаты»
▪️Теория игр за 15 минут
▪️Agile поменял принципы регулярного менеджмента в компаниях
▪️Чтиво: многолетний адский бардак в Boeing
▪️Без ТЗ будет ХЗ. Антикейс

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

🌐 Как научиться писать документацию и какой она должна быть ⏱30 минут
🌐 Agile-интервизия ⏱50 минут
🌐 Диагностика команды в преддверии больших изменений ⏱30 минут
🌐 Постпроектное сопровождение ⏱1 час
🌐 Как руководителю вовлекать и управлять через истории ⏱1 час

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

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

В команде говорят, что их лид некомпетентен. Как действовать

#почитать

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

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

Гроув. "Высокоэффективный менеджмент". Конспект на 3 странички

#почитать

Что должен делать эффективный руководитель:

- Добавлять стоимость, а не просто передавать информацию
- Быть вовлечённым во всё
- Пробовать, а не ждать
- Решать проблемы на наиболее низкой ступени прибавления стоимости

На каждого сотрудника нужно вести «дежурное» досье, в котором вы будете накапливать важные, но не требующие немедленного решения вопросы для обсуждения на следующей встрече.

⏱Читать конспект

Адаптивные команды

#почитать

Топологии команд были описаны Мэтью Скелтоном и Мэтью Элиасом в виде фреймворка. Основной принцип Team Topologies заключается в создании более адаптивных и гибких команд, что способствует более быстрому достижению поставленных целей.

Team Topologies вводит несколько ключевых видов команд, которые могут быть использованы в структуре организации:

Потоковые Команды (Stream-Aligned Teams). Эти группы специализируются в определенных потоках работы, таких как разработка новых функциональных возможностей продукта или обеспечение его непрерывной поставки. Они ориентированы на оперативное выполнение задач в своих областях, что улучшает скорость и предсказуемость разработки.

Команды Сложных Подсистем (Complicated-Subsystem Teams). Эти группы занимаются созданием и поддержкой сложных компонентов или подсистем в продукте или системе. Обладая экспертизой в конкретных областях, они специализируются на технически сложных аспектах продукта, обеспечивая его надежность и эффективность.

Платформенные Команды (Platform Teams). Ответственные за разработку и поддержание общей платформы, используемой другими группами в организации. Эти команды создают инфраструктуру, инструменты и сервисы, упрощающие и ускоряющие процессы разработки для всех остальных команд, способствуя тем самым повышению продуктивности и гибкости всей организации.

Команды Поддержки (Enabling Teams). Они играют важную роль в обеспечении эффективности работы других групп. Предоставляя инструменты, обучение, консультации и другие ресурсы, необходимые для успеха остальных команд, эти группы поддерживают и стимулируют инновации, обеспечивая необходимые знания и ресурсы для других групп в организации.

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

Пятничное. Взлёт и падение Ай Би Эм

#почитать

Одна из старейших технологических компаний в мире, на счету которой мейнфреймы, некоторые языки программирования и инструменты на основе искусственного интеллекта. Но, - спросите обычного человека в возрасте до 40 лет, - чем именно занимается (или занималась?) Ай-Би-Эм, и ответы будут в лучшем случае расплывчатыми. «Что-то связанное с компьютерами?» — это лучшее, что смогли придумать представители поколения Z, которых я опрашивал.

В летописи гаражного предпринимательства IBM занимает одно из легендарных мест в качестве не очень страшного монстра. В 1980 году, уязвлённые 13-летними антимонопольными разбирательствами, её руководители совершили колоссальную ошибку, разрешив 25-летнему Биллу Гейтсу, соучредителю компании с несколькими десятками сотрудников, оставить за собой права на операционную систему, которую IBM по субподряду разрабатывала для своего тогда ещё секретного проекта персональных компьютеров. Эта ошибка стала причиной создания Microsoft.

Поражали анахронизмы в компании. Спустя десятилетия после того, как большинство крупных американских компаний перешли к управлению с помощью профессиональных менеджеров, IBM оставалась семейной компанией, которая проповедовала преданность превыше всего, не решая при этом внутренних проблем. (А в какой семье не так?) Её боссы враждовали между собой. При этом компания фанатично обслуживала своих клиентов и, начиная с эпохи депрессии, гарантировала своим работникам пожизненное трудоустройство. Как в Японии. Кредо IBM — «Уважать личность». И что из этого получилось?

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