Прочтена книга Steve Tendon, «The Book of TameFlow», 2022. Опубликовано в блоге эссе с мыслями, пришедшими в голову по ходу прочтения книги (без этого эссе книгу нельзя считать прочитанной).
Книга о том, как управлять работами в "нестабильных средах"(PEST). т.е. когда интересантов,кому требуется твои продукты или услуги много, проектов у них много и выполняющих работу команд также несколько и внешние и внутренние условия и параметры изменяются ежедневно(VUCA). К условиям применения рекомендаций книги также следует отнести именно нематериальные/знаниевые работы, т.к. материальное производство прекрасно закрывается методами ТОС с учетом прохода, определением ограничения и оценкой пропускной способности. В знаниевых продуктах ограничение труднее определить, оно более динамично, т.е. при незначительном изменении условий перемещается от команды к команде, не зависимо от корреляции компетенций, не редко и в другое подразделение.
ГДЕ ограничение(методы его определения), один из основных вопросов книги.
Поэтому важно(главный фокус внимания книги) КАК(в каком порядке) построить выполнение работ, выстроить коммуникацию между интересантами, менеджерами проектов/продуктов, командами.
Базируется материал, как на уже знакомых методологиях и законах, теории ограничения систем, учете прохода, законе Литтла, подходах Agile и SCRUM, планировании Буфер-Барабан-Веревка так и на понятиях, которые раньше не встречались, различных комбинаций и связей времени ожидания и времени работы, пропускной способности команд, продуктов/проектов в местах ограничений, рабочего потока и рабочего процесса, единиц выполненной работы/результата(MOVE) и оценки динамики ее изменения.
Книги нет в официальном русском переводе, благо автоматизированные средства перевода выросли достаточно и использовав пару сервисов и имея интерес к теме(или небольшой опыт в деле) почти все мысленные конструкции, ментальные модели и вновь введенные понятия оказались по силам.
Понравилось ступенчатость(последовательность) изложения с постепенным вводом новых концепций, к которым много графиков диаграмм и рисунков, визуализирующих связи, без них было бы тяжело). Заканчивается практическими рекомендациями инструментов(рабочих столов и досок) и индикаторов оперативного управления. Динамика буферов - огонь!
Прочтена книга Donald G Reinertsen «The Principles of Product Development Flow: Second Generation Lean Product Development». Опубликовано в блоге эссе с мыслями, пришедшими в голову по ходу прочтения книги (без этого эссе книгу нельзя считать прочитанной).
В книге собраны принципы успешной совместной деятельности по созданию продукта, объединенные в главы по темам. Похоже на наблюдения из практики, зафиксированные и отсортированные по частоте встречи с провалами/факапами или заметными успешными действиями при создании ПО. Фокусирует внимание на потоке разработки продукта, бьет на методы и призывает количественно оценивать экономическое воздействие, эффективно управлять очередями, принимать изменчивость в качестве инструмента для создания стоимости и использовать преимущества небольших партий, ставить ограничения WIP, планировать ритмы взаимодействия и быстрой обратной связи, децентрализовать управление на локальных участках работ. Читал в машинном переводе, к слову о качестве Яндекс переводчика, вполне хватило узнать 70% принципов, 30 % или недопонимал из-за перевода или не встречал. Часть принципов очевидны и кажутся высосанными из пальца, но большинство полезны, а некоторые как открытие. Наиболее полезным оказалась сама фокусировка и рефлексия на тех, что вроде были знакомы, но были пересмотрены как важные/главные, за счет примеров. Сам материал вроде бы и не сложен .. но тяжело шел сам процесс "пережевывания" принципов, может потому что их аж 175, может потому что они разных масштабов или из-за субъективности восприятия и частоте встреч, не такой как у автора. Кажется менее понятна будет людям только начинающим, не имеющим практики в разработке ПО и более подойдет людям, которые уже знакомы с элементами потока разработки и миксуют высокоуровневые (по главам, разделам) принципы между собой.
В рабочем проекте использована как минимум одна практика операционного менеджмента книги «The Book of TameFlow» и опубликовано эссе с описанием этого эксперимента и его результатов.
Главная мысль, которую я подчеркнул из книги - это то что можно пробовать разными практиками оптимизировать процессы проектирования/разработки/адаптации/поддержки (знаниевую работу) супротив увеличению ресурсов(найму персонала/расширения инфраструктуры). Пробуем менять процессы выполнения работ и взаимодействие с заказчиками, берем в работу(обязательства) только после примерной оценки объема, с учетом свободной емкости, пропускной способности и компетенций, пока на глаз, метрики самые общие (деньги и экспертная оценка) Пробуем смотреть на процесс работы с разных точек и применять разные практики работы различных команд - один из вариантов повышения эффективности и чаще дешевле, чем увеличение ресурсной составляющей. Буфер-Барабан-Веревка - самая распространенная практика, более менее знакомая раньше. Почему то приходит аналогия из ТРИЗ с решением задач либо во времени(за счет буферов), либо в пространстве(за счет переорганизации команд/перераспределению работ).
Опубликовано эссе о том, что наиболее контринтуитивно в принципах, изложенных в книге «The Principles of Product Development Flow».
Контр интуитивные принципы для себя выделил следующие:
-
Полная загрузка мощностей (увеличение работ программистов) отдела не улучшит, а ухудшит общий результат компании.
Работы с высокой вариабельностью периодически требуют буферных мощностей.
Если программисты заняты на 100 % при изменении конъюнктуры проекта велика вероятность “наложать”, если сразу не взяться за решение возникших трудностей по проекту.
Другими словами НЕ обеспечить требуемый клиенту уровень реакции по проекту и риск потерять проект из-за потери актуальности. -
Нелинейный рост очередей при сокращении ресурсов/ рабочей мощности.
-
Вариативность действительно чаще рассматривалась как враг, с которым необходимо бороться.
Исходя из мыслей автора это не всегда плохо, чаще даже хорошо, т.к. это способствует более адекватной оценки продукта рынком, а следовательно и улучшением экономической составляющей создаваемого продукта, как для клиента/заказчика, так и для создателя.
Остальные вроде как все принципы интуитивные, большинство простые, но почему то не все учитывались (удостаивались внимания), не все рассматривались как важные, хотя после ознакомления с аргументами с большинством согласен, они достаточно значимы, чтобы учитывать их в процессе создания продуктов.
Опубликовано эссе с обзором современных практик управления личной эффективностью (включая, но не ограничиваясь практиками из литературы, приведённой в нашем курсе. В эссе включить результаты эксперимента по использованию каких-то из практик управления личной эффективностью, в том числе и личного опыта попыток переноса практик корпоративного операционного менеджмента в адаптированный для себя метод достижения личной продуктивности).
Для качественного обзора понадобиться второй проход методологии и знатная рефлексия по этому поводу. Что в данный момент не приоритетно, есть ряд книг, которые ждут в качестве задач/этапов прохождения данного курса системного менеджмента в его базовом варианте. Практики управления проектами, процессами и потоками в их глобальном представлении и соответствующие им нотации и фрэймворки PMBok, Prince2, Scram, Agile, Kanban, ТОС, TameFlow и другие flow, SAFe и т.п. - это база для выстраивания любой командной деятельности и соответственно тема бесконечная, как и само развитие.
Чего не заметил в материалах ШСМ, но частично использую это методология или framework PARA.
Вроде прост и понятен, подходит для систематизации информации по любой деятельности.
Тут описание:
Тут использование с Obsidian:
Данное верхнеуровневое структурирование можно использовать как в личных, так и в рабочих проектах, Понятия для деления достаточно абстрактны:
Projects (проекты): краткосрочные задачи с конкретными целями и сроками;
Areas (области): задачи без конечных сроков и долгосрочные обязанности,часто должностные инструкции и регламенты;
Resources (ресурсы): полезные материалы и информация для будущего использования, сюда же можно отнести инструменты;
Archive (архив): завершённые проекты и задачи, неактуальное, для истории, рефлексии, шаблонизации и т.п.