Forwarded from Номикс - всё о XR | AI | Digital Twins
This media is not supported in your browser
VIEW IN TELEGRAM
✔️Инженеры разбирались в нюансах Scrum, дедукции, индукции, модели Cynefin, модели применимости Agile-практик по типу продукта, а также адаптации и инновации Agile в инженерной среде и многом другом.
🗯️Важная мысль лекции: «Жизнь - это борьба с неопределенностью». И, исходя из того, каков процент этой неопределенности, нужно выбирать наиболее эффективные стратегии действия.
Please open Telegram to view this post
VIEW IN TELEGRAM
С чего начался Scrum?
Многие считают, что Scrum был создан Джеффом Сазерлендом и Кеном Швабером, но на самом деле их заслуга заключается в разработке фреймворка Scrum, который мы знаем и используем сегодня. Они систематизировали и популяризировали этот подход, сделав его одним из самых востребованных в мире.
Однако корни Scrum уходят глубже — в Японию. Идеи, лежащие в основе современного фреймворка, были впервые описаны в статье, опубликованной в 1986 году Хиротака Такеучи и Икуджиро Нонакой. В своей статье, размещённой в Harvard Business Review под названием "The New New Product Development Game", они привели в пример команд, работающих как единое целое, подобно "регби", где каждый игрок взаимодействует и координирует свои действия с другими.
Такеучи и Нонака предложили холистический подход к разработке продуктов.
Такой подход включает шесть ключевых характеристик:
1. Встроенная нестабильность: Руководство ставит перед командой амбициозные цели, но не дает четкого плана действий, создавая таким образом условия для инноваций.
2. Самоорганизующиеся команды: Команды получают автономию и возможность разрабатывать собственные решения и концепции.
3. Перекрывающиеся фазы разработки: Фазы разработки не следуют строго друг за другом, а накладываются, что позволяет ускорить процесс и повысить его гибкость.
4. Многоуровневое обучение: Участники команды обучаются на всех уровнях (индивидуальном, групповом, корпоративном) и в различных функциональных областях.
5. Тонкий контроль: Команды остаются автономными, но при этом управление осуществляется через мягкие формы контроля, такие как самоконтроль и контроль через взаимодействие с коллегами.
6. Передача знаний: Полученные знания и опыт передаются другим командам и используются в последующих проектах.
Эти идеи позже были взяты на вооружение Сазерлендом и Швабером при создании фреймворка Scrum.
Читайте вольный перевод статьи
https://teletype.in/@incrementum/thenewnewproductdevelopmentgame
или ищите оригинал у Harvard Business Review, чтобы прикоснуться к истокам 😊
Многие считают, что Scrum был создан Джеффом Сазерлендом и Кеном Швабером, но на самом деле их заслуга заключается в разработке фреймворка Scrum, который мы знаем и используем сегодня. Они систематизировали и популяризировали этот подход, сделав его одним из самых востребованных в мире.
Однако корни Scrum уходят глубже — в Японию. Идеи, лежащие в основе современного фреймворка, были впервые описаны в статье, опубликованной в 1986 году Хиротака Такеучи и Икуджиро Нонакой. В своей статье, размещённой в Harvard Business Review под названием "The New New Product Development Game", они привели в пример команд, работающих как единое целое, подобно "регби", где каждый игрок взаимодействует и координирует свои действия с другими.
Такеучи и Нонака предложили холистический подход к разработке продуктов.
Такой подход включает шесть ключевых характеристик:
1. Встроенная нестабильность: Руководство ставит перед командой амбициозные цели, но не дает четкого плана действий, создавая таким образом условия для инноваций.
2. Самоорганизующиеся команды: Команды получают автономию и возможность разрабатывать собственные решения и концепции.
3. Перекрывающиеся фазы разработки: Фазы разработки не следуют строго друг за другом, а накладываются, что позволяет ускорить процесс и повысить его гибкость.
4. Многоуровневое обучение: Участники команды обучаются на всех уровнях (индивидуальном, групповом, корпоративном) и в различных функциональных областях.
5. Тонкий контроль: Команды остаются автономными, но при этом управление осуществляется через мягкие формы контроля, такие как самоконтроль и контроль через взаимодействие с коллегами.
6. Передача знаний: Полученные знания и опыт передаются другим командам и используются в последующих проектах.
Эти идеи позже были взяты на вооружение Сазерлендом и Швабером при создании фреймворка Scrum.
Читайте вольный перевод статьи
https://teletype.in/@incrementum/thenewnewproductdevelopmentgame
или ищите оригинал у Harvard Business Review, чтобы прикоснуться к истокам 😊
Оптимизация стандартного сервисного конвейера - реальность или иллюзия?
Когда речь идет о массовом производстве автомобилей, конвейерная сборка уже давно стала стандартом в автомобильной индустрии. Каждый этап производства авто тщательно регламентирован и отлажен: от сборки кузова до установки двигателя и финальной проверки качества. Этот процесс нацелен на производство стандартизированных моделей автомобилей с минимальными затратами времени и ресурсов, что позволяет компаниям выпускать продукцию в больших объемах.
Однако создание новой модели автомобиля – это совершенно другая история. Здесь процесс начинается с разработки прототипа, который в дальнейшем должен пройти множество тестов и доработок. Но на этом трудности не заканчиваются. Сам прототип – это лишь вершина айсберга, представляющая идею того, каким будет новый автомобиль. Настоящая сложность заключается в создании нового производственного конвейера, который будет адаптирован под эту новую модель. И здесь проявляется диалектика: чтобы создать что-то новое, нужно не просто модифицировать старое, а часто полностью перестраивать всю систему производства. В зависимости от сложности проекта, затраты на R&D могут составлять от $1 до $3 миллиардов. Затраты на модернизацию производственных мощностей могут варьироваться от $500 миллионов до $1,5 миллиардов. Затраты на маркетинг могут составлять от $100 миллионов до $500 миллионов.
Диалектика этого процесса заключается в постоянной борьбе и единстве противоположностей. На одном конце у нас – стандартный конвейер, отлаженный и готовый к выпуску миллионов одинаковых машин. На другом – необходимость внедрения изменений для запуска новых уникальных продуктов, которая требует создания новой производственной линии, способной воплотить новую модель с ее уникальными особенностями и характеристиками.
Этот процесс не просто сложный, он требует экспериментов и постоянного поиска новых решений.
Сложность – не в самой машине, а в производственной системе. Как яблоки не отделимы от яблонь, продукт не отделим от этой системы.
Иначе можно сказать, что сложность заключается не столько в создании самого автомобиля, сколько в организации всей системы производства вокруг него. Когда разрабатывается новая модель, необходимо предусмотреть не только ее технические характеристики, но и то, как она будет производиться в условиях массового производства. Все усилия команды разработки направлены не на создание экземпляра нового продукта, а на изменение всех процессов.
Главный вызов, с которым сталкиваются продуктовые компании, занимающиеся разработкой программного обеспечения, заключается в том, что они постоянно создают новые продукты, каждый раз перестраивая весь производственный процесс. Однако менеджеры часто стремятся увидеть в этом процессе нечто более стабильное и предсказуемое, мечтая о создании "стандартного сервисного конвейера" для новых нестандартных продуктов. Такой конвейер можно было бы просто оптимизировать небольшими усилиями и сохранить статус "кво".
Эта иллюзия стабильности и стандартности препятствует осознанию диалектики, присущей процессу разработки новых продуктов.
Когда речь идет о массовом производстве автомобилей, конвейерная сборка уже давно стала стандартом в автомобильной индустрии. Каждый этап производства авто тщательно регламентирован и отлажен: от сборки кузова до установки двигателя и финальной проверки качества. Этот процесс нацелен на производство стандартизированных моделей автомобилей с минимальными затратами времени и ресурсов, что позволяет компаниям выпускать продукцию в больших объемах.
Однако создание новой модели автомобиля – это совершенно другая история. Здесь процесс начинается с разработки прототипа, который в дальнейшем должен пройти множество тестов и доработок. Но на этом трудности не заканчиваются. Сам прототип – это лишь вершина айсберга, представляющая идею того, каким будет новый автомобиль. Настоящая сложность заключается в создании нового производственного конвейера, который будет адаптирован под эту новую модель. И здесь проявляется диалектика: чтобы создать что-то новое, нужно не просто модифицировать старое, а часто полностью перестраивать всю систему производства. В зависимости от сложности проекта, затраты на R&D могут составлять от $1 до $3 миллиардов. Затраты на модернизацию производственных мощностей могут варьироваться от $500 миллионов до $1,5 миллиардов. Затраты на маркетинг могут составлять от $100 миллионов до $500 миллионов.
Диалектика этого процесса заключается в постоянной борьбе и единстве противоположностей. На одном конце у нас – стандартный конвейер, отлаженный и готовый к выпуску миллионов одинаковых машин. На другом – необходимость внедрения изменений для запуска новых уникальных продуктов, которая требует создания новой производственной линии, способной воплотить новую модель с ее уникальными особенностями и характеристиками.
Этот процесс не просто сложный, он требует экспериментов и постоянного поиска новых решений.
Сложность – не в самой машине, а в производственной системе. Как яблоки не отделимы от яблонь, продукт не отделим от этой системы.
Иначе можно сказать, что сложность заключается не столько в создании самого автомобиля, сколько в организации всей системы производства вокруг него. Когда разрабатывается новая модель, необходимо предусмотреть не только ее технические характеристики, но и то, как она будет производиться в условиях массового производства. Все усилия команды разработки направлены не на создание экземпляра нового продукта, а на изменение всех процессов.
Главный вызов, с которым сталкиваются продуктовые компании, занимающиеся разработкой программного обеспечения, заключается в том, что они постоянно создают новые продукты, каждый раз перестраивая весь производственный процесс. Однако менеджеры часто стремятся увидеть в этом процессе нечто более стабильное и предсказуемое, мечтая о создании "стандартного сервисного конвейера" для новых нестандартных продуктов. Такой конвейер можно было бы просто оптимизировать небольшими усилиями и сохранить статус "кво".
Эта иллюзия стабильности и стандартности препятствует осознанию диалектики, присущей процессу разработки новых продуктов.
Прозрачность в Scrum: Почему артефакты, а не люди, являются объектом прозрачности
Прозрачность — один из ключевых принципов эмпиризма Scrum, но часто он понимается неправильно. Существует распространённое заблуждение, что прозрачность направлена на команду, словно команда должна быть "без одежды" перед всеми, то есть подвергаться постоянному контролю и критике. В действительности же, объектом прозрачности в Scrum являются артефакты, а не люди. Прозрачность достигается через видимость и доступность артефактов, таких как Product Backlog, Sprint Backlog и Increment. Эти артефакты предоставляют всю необходимую информацию о прогрессе, обеспечивая прозрачность процесса, а не команды.
Артефакты — ключ к прозрачности
Прозрачность в Scrum создаётся через артефакты, которые формируют основу для всех решений и позволяют участникам процесса видеть состояние работы. Например, без прозрачного бэклога продукта команда не сможет эффективно планировать свои спринты, а без спринт бэклога дейли превратятся в отчётную встречу вместо инспекции движения к цели спринта.
Прозрачность артефактов позволяет всем участникам иметь одинаковое понимание текущего состояния работы, а также возможных рисков. Решения, основанные на непрозрачных или неверных артефактах, могут привести к снижению ценности продукта и повышению уровня неопределённости. Как только артефакты становятся доступными и понятными для всех, они начинают выполнять свою основную функцию — предоставлять объективную картину текущего положения дел.
Прозрачность — это не контроль
Важно понимать, что прозрачность не подразумевает полного контроля за действиями команды. Некоторые могут ошибочно полагать, что прозрачность в Scrum означает полную видимость всех шагов команды, подобно наблюдению через стеклянные стены. Однако это не так. Прозрачность в Scrum направлена на результат работы команды, а не на индивидуальные действия участников. Такой подход защищает команду от чрезмерного давления, создаёт среду, способствующую развитию, и без страха перед ошибками.
Аналогия с музыкой: процесс и артефакт
Для более глубокого понимания прозрачности через артефакты можно представить такую аналогию: вы и ваши друзья слушаете радио, но как можно понять, что вы слушали одну и ту же песню? Ведь музыка — это поток, процесс, который трудно зафиксировать. Чтобы точно определить, можно записать ноты этой песни и сравнить их. В этом случае ноты представляют собой артефакт, который обеспечивает прозрачность того, что происходило в процессе воспроизведения музыки.
Также и в Scrum: процесс работы команды похож на непрерывный поток. Артефакты скрам превращают этот поток в нечто измеримое и понятное, создавая основу для прозрачности и дальнейшего принятия решений.
Заключение
Прозрачность в Scrum не о контроле над каждым шагом команды, а о создании условий, при которых ключевая информация, зафиксированная в артефактах, доступна и понятна всем участникам процесса. Спринт бэклог корректируется каждый день командой разработки. Такие артефакты как инкремент и бэклог продукта играют решающую роль, предоставляя команде и всем заинтересованным сторонам возможность видеть и понимать прогресс работы. Прозрачность артефактов помогает преодолеть неопределённость и контролировать риски.
Прозрачность — один из ключевых принципов эмпиризма Scrum, но часто он понимается неправильно. Существует распространённое заблуждение, что прозрачность направлена на команду, словно команда должна быть "без одежды" перед всеми, то есть подвергаться постоянному контролю и критике. В действительности же, объектом прозрачности в Scrum являются артефакты, а не люди. Прозрачность достигается через видимость и доступность артефактов, таких как Product Backlog, Sprint Backlog и Increment. Эти артефакты предоставляют всю необходимую информацию о прогрессе, обеспечивая прозрачность процесса, а не команды.
Артефакты — ключ к прозрачности
Прозрачность в Scrum создаётся через артефакты, которые формируют основу для всех решений и позволяют участникам процесса видеть состояние работы. Например, без прозрачного бэклога продукта команда не сможет эффективно планировать свои спринты, а без спринт бэклога дейли превратятся в отчётную встречу вместо инспекции движения к цели спринта.
Прозрачность артефактов позволяет всем участникам иметь одинаковое понимание текущего состояния работы, а также возможных рисков. Решения, основанные на непрозрачных или неверных артефактах, могут привести к снижению ценности продукта и повышению уровня неопределённости. Как только артефакты становятся доступными и понятными для всех, они начинают выполнять свою основную функцию — предоставлять объективную картину текущего положения дел.
Прозрачность — это не контроль
Важно понимать, что прозрачность не подразумевает полного контроля за действиями команды. Некоторые могут ошибочно полагать, что прозрачность в Scrum означает полную видимость всех шагов команды, подобно наблюдению через стеклянные стены. Однако это не так. Прозрачность в Scrum направлена на результат работы команды, а не на индивидуальные действия участников. Такой подход защищает команду от чрезмерного давления, создаёт среду, способствующую развитию, и без страха перед ошибками.
Аналогия с музыкой: процесс и артефакт
Для более глубокого понимания прозрачности через артефакты можно представить такую аналогию: вы и ваши друзья слушаете радио, но как можно понять, что вы слушали одну и ту же песню? Ведь музыка — это поток, процесс, который трудно зафиксировать. Чтобы точно определить, можно записать ноты этой песни и сравнить их. В этом случае ноты представляют собой артефакт, который обеспечивает прозрачность того, что происходило в процессе воспроизведения музыки.
Также и в Scrum: процесс работы команды похож на непрерывный поток. Артефакты скрам превращают этот поток в нечто измеримое и понятное, создавая основу для прозрачности и дальнейшего принятия решений.
Заключение
Прозрачность в Scrum не о контроле над каждым шагом команды, а о создании условий, при которых ключевая информация, зафиксированная в артефактах, доступна и понятна всем участникам процесса. Спринт бэклог корректируется каждый день командой разработки. Такие артефакты как инкремент и бэклог продукта играют решающую роль, предоставляя команде и всем заинтересованным сторонам возможность видеть и понимать прогресс работы. Прозрачность артефактов помогает преодолеть неопределённость и контролировать риски.
Менеджмент с использованием гибких практик: где скрыта настоящая ценность
Когда менеджеры организации и лиды разработки наблюдают за работой команд, они часто ожидают от агентов изменений активного участия в планировании, визуализации процессов и перемещении задач в Jira. Но в чём истинная ценность агента изменений? Я думаю, что в первую очередь в умелом внедрении практик "второго поколения". Рассмотрим на примере использования и понимания метода Канбан.
Видимое и скрытое в гибких практиках
При упоминании Канбана многие сразу думают о визуализации работы, ограничении незавершённых задач (WIP) и управлении потоком. Эти практики важны и помогают командам эффективно выполнять работу от начала до конца.
Однако, если сосредоточиться только на этих видимых аспектах, можно упустить более глубокую и значимую часть Канбана — управленческие практики.
Первое поколение гибкости
Операционные практики обеспечивают то, что мы называем гибкостью первого поколения. Этот тип гибкости позволяет организациям быстро реагировать на новые запросы и эффективно выполнять работу. Хотя это представляет значительное улучшение для многих, это лишь поверхностное использование возможностей Канбан метода.
Второе поколение гибкости
Канбан обеспечивает организационную гибкость, а не только гибкость проекта или продукта.
Канбан был разработан, чтобы обеспечить гибкость второго поколения — более глубокую способность адаптироваться к меняющимся рыночным условиям, потребностям клиентов и экономическим изменениям. В отличие от гибкости первого поколения, которая фокусируется на адаптации отдельных проектов, вех или задач, гибкость второго поколения подразумевает эволюцию всей системы предоставления услуг.
В своей мини-книге 2009 года «Scrum and Kanban: Making the Most of Both» Хенрик Книберг и Матиас Скарин определили Канбан через три видимые практики: визуализация, ограничение WIP и управление потоком. Они сравнивали Kanban со Scrum, акцентируя внимание на его способности адаптироваться к меняющимся требованиям. Однако такой узкий взгляд упустил полный потенциал Канбана, как подхода к гибкости второго поколения.
Ключевые управленческие практики Канбана
Управленческие практики дают необходимые инструменты:
1. Сделать политики явными: Четко определить правила и руководства системы, чтобы обеспечить прозрачность и последовательность.
2. Внедрить циклы обратной связи: Создать системы, которые учатся и адаптируются благодаря регулярной обратной связи.
3. Улучшать совместно, экспериментировать: Поощрять общую ответственность за улучшения и использовать данные для принятия решений.
Важность улучшения управления
Барри Боэм в своей книге "Software Engineering Economics" (1981) отметил, что плохое управление может увеличить затраты на разработку программ быстрее, чем любой другой фактор. Это актуально и сегодня.
Чтобы улучшить технологии и инновации, нужно совершенствовать управленческие навыки. Менеджеры должны мыслить системно и создавать среду, которая поддерживает эффективные решения и успешные результаты.
Раскрытие истинной ценности Канбана
Хотя операционные практики Канбана широко доступны и их относительно легко освоить, настоящая ценность в том, чтобы понять управленческие практики, а не только операционные. Вы можете научиться визуализировать рабочие процессы и ограничивать WIP через разные источники. Но истинная сила Канбана приходит с пониманием того, как управлять системой в целом.
Заключение
Чтобы полностью раскрыть потенциал Канбана, нужно выйти за пределы видимых аспектов и погрузиться в управленческие практики. Именно они являются ключом к организационной гибкости и постоянному совершенствованию.
Помните, настоящая ценность гибких практик заключается не в досках и стикерах, а в глубоком понимании системного подхода к управлению.
Когда менеджеры организации и лиды разработки наблюдают за работой команд, они часто ожидают от агентов изменений активного участия в планировании, визуализации процессов и перемещении задач в Jira. Но в чём истинная ценность агента изменений? Я думаю, что в первую очередь в умелом внедрении практик "второго поколения". Рассмотрим на примере использования и понимания метода Канбан.
Видимое и скрытое в гибких практиках
При упоминании Канбана многие сразу думают о визуализации работы, ограничении незавершённых задач (WIP) и управлении потоком. Эти практики важны и помогают командам эффективно выполнять работу от начала до конца.
Однако, если сосредоточиться только на этих видимых аспектах, можно упустить более глубокую и значимую часть Канбана — управленческие практики.
Первое поколение гибкости
Операционные практики обеспечивают то, что мы называем гибкостью первого поколения. Этот тип гибкости позволяет организациям быстро реагировать на новые запросы и эффективно выполнять работу. Хотя это представляет значительное улучшение для многих, это лишь поверхностное использование возможностей Канбан метода.
Второе поколение гибкости
Канбан обеспечивает организационную гибкость, а не только гибкость проекта или продукта.
Канбан был разработан, чтобы обеспечить гибкость второго поколения — более глубокую способность адаптироваться к меняющимся рыночным условиям, потребностям клиентов и экономическим изменениям. В отличие от гибкости первого поколения, которая фокусируется на адаптации отдельных проектов, вех или задач, гибкость второго поколения подразумевает эволюцию всей системы предоставления услуг.
В своей мини-книге 2009 года «Scrum and Kanban: Making the Most of Both» Хенрик Книберг и Матиас Скарин определили Канбан через три видимые практики: визуализация, ограничение WIP и управление потоком. Они сравнивали Kanban со Scrum, акцентируя внимание на его способности адаптироваться к меняющимся требованиям. Однако такой узкий взгляд упустил полный потенциал Канбана, как подхода к гибкости второго поколения.
Ключевые управленческие практики Канбана
Управленческие практики дают необходимые инструменты:
1. Сделать политики явными: Четко определить правила и руководства системы, чтобы обеспечить прозрачность и последовательность.
2. Внедрить циклы обратной связи: Создать системы, которые учатся и адаптируются благодаря регулярной обратной связи.
3. Улучшать совместно, экспериментировать: Поощрять общую ответственность за улучшения и использовать данные для принятия решений.
Важность улучшения управления
Барри Боэм в своей книге "Software Engineering Economics" (1981) отметил, что плохое управление может увеличить затраты на разработку программ быстрее, чем любой другой фактор. Это актуально и сегодня.
Чтобы улучшить технологии и инновации, нужно совершенствовать управленческие навыки. Менеджеры должны мыслить системно и создавать среду, которая поддерживает эффективные решения и успешные результаты.
Раскрытие истинной ценности Канбана
Хотя операционные практики Канбана широко доступны и их относительно легко освоить, настоящая ценность в том, чтобы понять управленческие практики, а не только операционные. Вы можете научиться визуализировать рабочие процессы и ограничивать WIP через разные источники. Но истинная сила Канбана приходит с пониманием того, как управлять системой в целом.
Заключение
Чтобы полностью раскрыть потенциал Канбана, нужно выйти за пределы видимых аспектов и погрузиться в управленческие практики. Именно они являются ключом к организационной гибкости и постоянному совершенствованию.
Помните, настоящая ценность гибких практик заключается не в досках и стикерах, а в глубоком понимании системного подхода к управлению.
Знания и умения
Понимание принципиального различия между явным знанием и способностью (и умением) помогает всем лучше понять, зачем нужны гибкие практики в организации. И даже найти ответ как достигнуть целей в срок, когда неопределённость зашкаливает.
1. Способ приобретения и передачи:
- Знание: Может быть приобретено мгновенно и передано напрямую без потерь. Пример — запоминание номера телефона или изучение формулы.
- Способность (умение): Требует личного опыта и длительной практики. Невозможно передать способность напрямую через коммуникацию.
2. Выразимость в тексте или артефакте:
- Знание: Однозначно выражается в тексте и может быть свободно передано другому человеку.
- Способность: Не полностью выразима в тексте, особенно если основана на неявной памяти человека. Можно описать действия, но не передать сам опыт выполнения.
3. Взаимосвязь и независимость:
- Хотя обучение навыкам может сопровождаться приобретением знаний, они остаются различными. Обладать теоретическими знаниями не означает иметь практические способности и умения, и наоборот.
Связь с Agile-командами и моделью СЭКИ:
В контексте Agile-команд это различие между знанием и способностью имеет прямое отношение к тому, как команды обучаются и развиваются.
- Социализация: Команда обменивается неявными знаниями и опытом через совместную работу, что способствует развитию способностей и умений.
- Экстернализация: Знания оформляются в виде документов и планов, что облегчает их передачу, но для развития способностей требуется практика.
- Комбинация: Объединение знаний может привести к новым идеям, но для их реализации нужны развитые способности.
- Интернализация: Применение знаний на практике превращает их в способности через личный опыт и обучение.
Важно для организации:
- Прозрачность артефактов: Обеспечение прозрачности артефактов разработки, таких как документация, код, планы и дашборды, важно для эффективного сотрудничества и принятия решений. Прозрачность позволяет всем участникам иметь доступ к актуальной информации, что способствует лучшему пониманию процессов и ускоряет выявление и решение проблем.
- Развитие умений через эмпирическую работу: Организациям важно создавать условия, где команды могут применять новые знания на практике в реальных проектах. В Agile-подходе это достигается через выполнение спринтов и получение инкрементов продукта. Такой эмпирический подход позволяет командам не только приобретать новые знания, но и превращать их в практические умения, улучшая продукт на основе реального опыта.
- Поощрение экспериментирования: Предоставление возможностей для экспериментов и практического применения знаний ускоряет процесс развития способностей в команде. Это помогает адаптироваться к неопределённости и быстро реагировать на изменения возможностей внешней среды.
- Интеграция обучения в рабочий процесс: Объединение процессов обучения и работы над продуктами позволяет сотрудникам постоянно совершенствовать свои навыки, делая обучение и совершенствование навыков непрерывной частью рабочего процесса.
- Учет различий при планировании развития: Программы развития персонала должны учитывать различия между знанием и способностями, предлагая не столько теоретическое обучение, сколько получение новых навыков в практике. Это обеспечивает полноценное развитие компетенций сотрудников и способностей команды.
Заключение:
Обеспечение прозрачности артефактов улучшает коммуникацию и понимание внутри команды. Через эмпирическую работу и получение инкрементов команды не только приобретают новые знания, но и превращают их в практические способности (умения). После достижения прозрачности обязательно обеспечьте эмпиризм. Такое понимание менеджментом необходимости развития способностей как актива организации открывает окно возможностей к созданию уникальных продуктов в условиях неопределённости точно в срок.
Понимание принципиального различия между явным знанием и способностью (и умением) помогает всем лучше понять, зачем нужны гибкие практики в организации. И даже найти ответ как достигнуть целей в срок, когда неопределённость зашкаливает.
1. Способ приобретения и передачи:
- Знание: Может быть приобретено мгновенно и передано напрямую без потерь. Пример — запоминание номера телефона или изучение формулы.
- Способность (умение): Требует личного опыта и длительной практики. Невозможно передать способность напрямую через коммуникацию.
2. Выразимость в тексте или артефакте:
- Знание: Однозначно выражается в тексте и может быть свободно передано другому человеку.
- Способность: Не полностью выразима в тексте, особенно если основана на неявной памяти человека. Можно описать действия, но не передать сам опыт выполнения.
3. Взаимосвязь и независимость:
- Хотя обучение навыкам может сопровождаться приобретением знаний, они остаются различными. Обладать теоретическими знаниями не означает иметь практические способности и умения, и наоборот.
Связь с Agile-командами и моделью СЭКИ:
В контексте Agile-команд это различие между знанием и способностью имеет прямое отношение к тому, как команды обучаются и развиваются.
- Социализация: Команда обменивается неявными знаниями и опытом через совместную работу, что способствует развитию способностей и умений.
- Экстернализация: Знания оформляются в виде документов и планов, что облегчает их передачу, но для развития способностей требуется практика.
- Комбинация: Объединение знаний может привести к новым идеям, но для их реализации нужны развитые способности.
- Интернализация: Применение знаний на практике превращает их в способности через личный опыт и обучение.
Важно для организации:
- Прозрачность артефактов: Обеспечение прозрачности артефактов разработки, таких как документация, код, планы и дашборды, важно для эффективного сотрудничества и принятия решений. Прозрачность позволяет всем участникам иметь доступ к актуальной информации, что способствует лучшему пониманию процессов и ускоряет выявление и решение проблем.
- Развитие умений через эмпирическую работу: Организациям важно создавать условия, где команды могут применять новые знания на практике в реальных проектах. В Agile-подходе это достигается через выполнение спринтов и получение инкрементов продукта. Такой эмпирический подход позволяет командам не только приобретать новые знания, но и превращать их в практические умения, улучшая продукт на основе реального опыта.
- Поощрение экспериментирования: Предоставление возможностей для экспериментов и практического применения знаний ускоряет процесс развития способностей в команде. Это помогает адаптироваться к неопределённости и быстро реагировать на изменения возможностей внешней среды.
- Интеграция обучения в рабочий процесс: Объединение процессов обучения и работы над продуктами позволяет сотрудникам постоянно совершенствовать свои навыки, делая обучение и совершенствование навыков непрерывной частью рабочего процесса.
- Учет различий при планировании развития: Программы развития персонала должны учитывать различия между знанием и способностями, предлагая не столько теоретическое обучение, сколько получение новых навыков в практике. Это обеспечивает полноценное развитие компетенций сотрудников и способностей команды.
Заключение:
Обеспечение прозрачности артефактов улучшает коммуникацию и понимание внутри команды. Через эмпирическую работу и получение инкрементов команды не только приобретают новые знания, но и превращают их в практические способности (умения). После достижения прозрачности обязательно обеспечьте эмпиризм. Такое понимание менеджментом необходимости развития способностей как актива организации открывает окно возможностей к созданию уникальных продуктов в условиях неопределённости точно в срок.
Please open Telegram to view this post
VIEW IN TELEGRAM
Игры будущего: когда развлечение и польза идут рука об руку
С развитием искусственного интеллекта у нас станет больше свободного времени. Думаю, что мы будем проводить его не только за просмотром шоу или спортивных матчей, но и всё больше играть в компьютерные игры. Эту идею подсмотрел у известного философа Александра Болдачева.
Представьте игры, которые ИИ создаёт не только для нашего развлечения, но и для решения своих задач — исследований, расчётов, моделирования сложных систем. Мы можем думать, что просто гоняемся за кем-то в виртуальном мире, а на самом деле наши действия помогают оптимизировать маршруты или решать сложные задачи.
Каждое наше решение в игре, вместе с решениями тысяч других игроков, может стать частью большого эксперимента по изучению социальных взаимодействий или экономики. Возможно, ИИ будет создавать целые виртуальные миры, где наши действия помогают разрабатывать новые технологии или тестировать идеи об устройстве общества. Например, строя космический корабль в игре, мы реально помогаем проектировать будущие космические аппараты.
Такие игры могут стать новой формой сотрудничества между людьми и ИИ. Мы будем наслаждаться игрой, даже не подозревая, что участвуем в чём-то более значимом.
Конечно, возникают вопросы об этичности такого подхода. Но, возможно, в будущем это станет нормой — вносить свой вклад в развитие общества через увлекательные игры, созданные ИИ. Кто знает, может быть, именно так совместная работа людей и машин приведёт к большим прорывам в науке и технологиях. Ставьте лайк, если такое будущее нравится.🔮
С развитием искусственного интеллекта у нас станет больше свободного времени. Думаю, что мы будем проводить его не только за просмотром шоу или спортивных матчей, но и всё больше играть в компьютерные игры. Эту идею подсмотрел у известного философа Александра Болдачева.
Представьте игры, которые ИИ создаёт не только для нашего развлечения, но и для решения своих задач — исследований, расчётов, моделирования сложных систем. Мы можем думать, что просто гоняемся за кем-то в виртуальном мире, а на самом деле наши действия помогают оптимизировать маршруты или решать сложные задачи.
Каждое наше решение в игре, вместе с решениями тысяч других игроков, может стать частью большого эксперимента по изучению социальных взаимодействий или экономики. Возможно, ИИ будет создавать целые виртуальные миры, где наши действия помогают разрабатывать новые технологии или тестировать идеи об устройстве общества. Например, строя космический корабль в игре, мы реально помогаем проектировать будущие космические аппараты.
Такие игры могут стать новой формой сотрудничества между людьми и ИИ. Мы будем наслаждаться игрой, даже не подозревая, что участвуем в чём-то более значимом.
Конечно, возникают вопросы об этичности такого подхода. Но, возможно, в будущем это станет нормой — вносить свой вклад в развитие общества через увлекательные игры, созданные ИИ. Кто знает, может быть, именно так совместная работа людей и машин приведёт к большим прорывам в науке и технологиях. Ставьте лайк, если такое будущее нравится.🔮
Please open Telegram to view this post
VIEW IN TELEGRAM
К чему стремиться Владельцу продукта?
Начнём с типовых ролевых антипаттернов продакта:
1. "Неспокойный контролёр"
Постоянно вмешивается в работу команды, задавая множество уточняющих вопросов. Он словно тень, следящая за каждым движением. Вначале это приводит команду в состояние напряжения. Однако затем разработчики начинают сознательно избегать самостоятельно что-то решать. Проще избежать риска принятия решений и последствий ошибок, перекладывая ответственность на того одного, кто взял на себя эту функцию. Такой стиль управления приводит к снижению инициативы, и команда привыкает полагаться на указания сверху.
Этот феномен часто упоминается в контексте концепций "выученной беспомощности" и "морального риска". Первое - это психологическое состояние, при котором человек убеждён в своей неспособности изменить ситуацию, даже если на самом деле он мог бы принять решение и что-то сделать. Применительно к рабочим и организационным контекстам, может проявляться, когда сотрудники сталкиваются с постоянным контролем и давящей обратной связью.
Моральный риск возникает, когда люди меняют своё поведение, зная, что все потери будут покрыты кем-то другим. Например, если разработчики знают, что их работа будет тщательно проверена и исправлена одним контролирующим, они будут меньше уделять внимания качеству своей работы, ожидая, что контролёр устранит ошибки. Таким образом, передача ответственности от каждого к одному контролёру ведёт к снижению мотивации и ослаблению личных усилий в достижение конечного результата.
2. "Тимлид в душе"
Он начинает управлять техническими аспектами работы, распределять задачи внутри команды и контролировать написание каждой функции. В результате возникают конфликты ролей, а команда обращается по любым и техническим, и продуктовым, и организационным вопросам к владельцу продукта как всезнающему тимлиду.
3. "Привратник"
Такой продакт выступает единственным посредником между стейкхолдерами и командой разработки, препятствуя их прямому общению. Он фильтрует обратную связь, добавляя свои интерпретации, что приводит к искажению информации и недопониманию.
4. "Мастер многозадачности"
Каждый день приносит новые идеи от стейкхолдеров, нет направления развития продукта, а есть только путь. И даже не один путь, а множество путей. Команда делает всё и сразу, ведь надо успеть всё.
Хорошо, а как должно быть, спросите вы?
Владелец продукта, согласно "Scrum Guide" Джеффа Сазерленда и Кена Швабера, отвечает за максимизацию ценности продукта и управление бэклогом продукта. Он фокусируется на понимании потребностей рынка и стейкхолдеров, формулирует видение продукта и устанавливает порядок элементов. Для этого ему делегированы полномочии всеми стейкхолдерами.
Рекомендации для Владельца продукта
1. Управление бэклогом
- Упорядочивайте элементы бэклога, чтобы команда фокусировалась на наиболее ценных функциях.
- Обеспечьте доступность и понятность бэклога для всех.
2. Максимизация ценности
- Проводите анализ рынка и пользователей, собирайте обратную связь.
- Поддерживайте ясное стратегическое видение продукта.
3. Работа со стейкхолдерами
- Поощряйте прямую коммуникацию стейкхолдеров с командой.
- Регулярно информируйте всех о прогрессе и изменениях, не ждите для этого обзора.
4. Четкое видение и цели
- Делитесь стратегическими целями и видением с командой.
- Включайте предложения команды в развитие продукта.
5. Принципы Scrum
- Соблюдайте роли и ответственность в Scrum.
- Используйте масштабирование при работе с большими командами. Один бэклог - один владелец.
6. Сотрудничество с командой
- Доверьте команде принятие технических решений, не тоните в деталях сами.
- На планирование определите цель, но задачи пусть берёт команда сама с бэклога; на дейли приходите как наблюдатель, но не участник; приглашайте стейкхолдеров на обзор и не забивайте на ретроспективу.
7. Фокус на ценности
- Избегайте микроконтроля, ориентируйтесь на результаты.
- Определяйте критерии успеха и давайте команде свободу выбора.
Главное создавать максимально ценный продукт - помните!🌶️
Начнём с типовых ролевых антипаттернов продакта:
1. "Неспокойный контролёр"
Постоянно вмешивается в работу команды, задавая множество уточняющих вопросов. Он словно тень, следящая за каждым движением. Вначале это приводит команду в состояние напряжения. Однако затем разработчики начинают сознательно избегать самостоятельно что-то решать. Проще избежать риска принятия решений и последствий ошибок, перекладывая ответственность на того одного, кто взял на себя эту функцию. Такой стиль управления приводит к снижению инициативы, и команда привыкает полагаться на указания сверху.
Этот феномен часто упоминается в контексте концепций "выученной беспомощности" и "морального риска". Первое - это психологическое состояние, при котором человек убеждён в своей неспособности изменить ситуацию, даже если на самом деле он мог бы принять решение и что-то сделать. Применительно к рабочим и организационным контекстам, может проявляться, когда сотрудники сталкиваются с постоянным контролем и давящей обратной связью.
Моральный риск возникает, когда люди меняют своё поведение, зная, что все потери будут покрыты кем-то другим. Например, если разработчики знают, что их работа будет тщательно проверена и исправлена одним контролирующим, они будут меньше уделять внимания качеству своей работы, ожидая, что контролёр устранит ошибки. Таким образом, передача ответственности от каждого к одному контролёру ведёт к снижению мотивации и ослаблению личных усилий в достижение конечного результата.
2. "Тимлид в душе"
Он начинает управлять техническими аспектами работы, распределять задачи внутри команды и контролировать написание каждой функции. В результате возникают конфликты ролей, а команда обращается по любым и техническим, и продуктовым, и организационным вопросам к владельцу продукта как всезнающему тимлиду.
3. "Привратник"
Такой продакт выступает единственным посредником между стейкхолдерами и командой разработки, препятствуя их прямому общению. Он фильтрует обратную связь, добавляя свои интерпретации, что приводит к искажению информации и недопониманию.
4. "Мастер многозадачности"
Каждый день приносит новые идеи от стейкхолдеров, нет направления развития продукта, а есть только путь. И даже не один путь, а множество путей. Команда делает всё и сразу, ведь надо успеть всё.
Хорошо, а как должно быть, спросите вы?
Владелец продукта, согласно "Scrum Guide" Джеффа Сазерленда и Кена Швабера, отвечает за максимизацию ценности продукта и управление бэклогом продукта. Он фокусируется на понимании потребностей рынка и стейкхолдеров, формулирует видение продукта и устанавливает порядок элементов. Для этого ему делегированы полномочии всеми стейкхолдерами.
Рекомендации для Владельца продукта
1. Управление бэклогом
- Упорядочивайте элементы бэклога, чтобы команда фокусировалась на наиболее ценных функциях.
- Обеспечьте доступность и понятность бэклога для всех.
2. Максимизация ценности
- Проводите анализ рынка и пользователей, собирайте обратную связь.
- Поддерживайте ясное стратегическое видение продукта.
3. Работа со стейкхолдерами
- Поощряйте прямую коммуникацию стейкхолдеров с командой.
- Регулярно информируйте всех о прогрессе и изменениях, не ждите для этого обзора.
4. Четкое видение и цели
- Делитесь стратегическими целями и видением с командой.
- Включайте предложения команды в развитие продукта.
5. Принципы Scrum
- Соблюдайте роли и ответственность в Scrum.
- Используйте масштабирование при работе с большими командами. Один бэклог - один владелец.
6. Сотрудничество с командой
- Доверьте команде принятие технических решений, не тоните в деталях сами.
- На планирование определите цель, но задачи пусть берёт команда сама с бэклога; на дейли приходите как наблюдатель, но не участник; приглашайте стейкхолдеров на обзор и не забивайте на ретроспективу.
7. Фокус на ценности
- Избегайте микроконтроля, ориентируйтесь на результаты.
- Определяйте критерии успеха и давайте команде свободу выбора.
Главное создавать максимально ценный продукт - помните!🌶️
Большое спасибо Алексею Пикулеву за сегодняшнее выступление на очном митапе. Он раскрыл тему токсичности в команде и обусловленности такого поведения факторами системы. Я опишу своими словами как я понял тему, но возможно это будет только как я увидел :) Мой инсайт - это фазы распространения такого поведения.
Алексей сделал свой доклад, вдохновлённый книгой Элизабет Холлоуэй «Токсичное рабочее пространство». Негативное поведение распространяется внутри команды, подобно вирусу, проходя несколько фаз. Разберёмся вместе!
Фазы распространения токсичности:
1. Зарождение токсичности
Всё начинается с поведения продакта, лида или влиятельного члена команды. Негатив, микроменеджмент или отсутствие поддержки создают основу для токсичной среды. Можно наблюдать повышенную критику, отсутствие доверия, пассивно-агрессивное поведение.
2. Распространение как инфекция
Сотрудники начинают копировать токсичные модели поведения, считая их нормой для выживания или продвижения.
В условиях стресса и высокой конкуренции токсичность усиливается, сотрудники могут становиться агрессивнее или всё больше закрываются.
3. Нормализация токсичной культуры
Токсичное поведение становится частью корпоративной культуры, воспринимаясь как необходимое для достижения целей.
Сотрудники перестают замечать или сознательно игнорируют негативную атмосферу.
Последствия для команды и организации
- Падение морального духа: Удовлетворенность работой снижается, увеличивается уровень стресса и выгорания.
- Снижение продуктивности: Коммуникация ухудшается, сотрудничество страдает, инновации замедляются.
- Высокая текучесть кадров: Сотрудники начинают уходить, что приводит к потере профессионалов и знаний.
Чтобы предотвратить развитие токсичности можно использовать следующие практики
1. Позитивное лидерство
- Лидеры должны демонстрировать позитивное поведение и быть примером для всей команды.
- Поддержка и признание достижений.
2. Открытая и честная коммуникация
- Поощрение конструктивного обмена мнениями и обратной связи.
- Создание безопасного пространства для выражения мыслей и чувств.
3. Формирование здоровой корпоративной культуры
- Внедрение ценностей, противодействующих токсичности, таких как уважение, доверие и сотрудничество.
- Регулярные тренинги по эмоциональному интеллекту и разрешению конфликтов.
4. Мониторинг и своевременное вмешательство
- Активное выявление токсичных практик и оперативное реагирование на них.
- Использование опросов и анонимных каналов для получения обратной связи от сотрудников.
В Agile каждая команда — это живой организм, который может поразить свой вирус. Понимание фаз распространения токсичности поможет своевременно вмешаться и сохранить здоровье команды.
Алексей сделал свой доклад, вдохновлённый книгой Элизабет Холлоуэй «Токсичное рабочее пространство». Негативное поведение распространяется внутри команды, подобно вирусу, проходя несколько фаз. Разберёмся вместе!
Фазы распространения токсичности:
1. Зарождение токсичности
Всё начинается с поведения продакта, лида или влиятельного члена команды. Негатив, микроменеджмент или отсутствие поддержки создают основу для токсичной среды. Можно наблюдать повышенную критику, отсутствие доверия, пассивно-агрессивное поведение.
2. Распространение как инфекция
Сотрудники начинают копировать токсичные модели поведения, считая их нормой для выживания или продвижения.
В условиях стресса и высокой конкуренции токсичность усиливается, сотрудники могут становиться агрессивнее или всё больше закрываются.
3. Нормализация токсичной культуры
Токсичное поведение становится частью корпоративной культуры, воспринимаясь как необходимое для достижения целей.
Сотрудники перестают замечать или сознательно игнорируют негативную атмосферу.
Последствия для команды и организации
- Падение морального духа: Удовлетворенность работой снижается, увеличивается уровень стресса и выгорания.
- Снижение продуктивности: Коммуникация ухудшается, сотрудничество страдает, инновации замедляются.
- Высокая текучесть кадров: Сотрудники начинают уходить, что приводит к потере профессионалов и знаний.
Чтобы предотвратить развитие токсичности можно использовать следующие практики
1. Позитивное лидерство
- Лидеры должны демонстрировать позитивное поведение и быть примером для всей команды.
- Поддержка и признание достижений.
2. Открытая и честная коммуникация
- Поощрение конструктивного обмена мнениями и обратной связи.
- Создание безопасного пространства для выражения мыслей и чувств.
3. Формирование здоровой корпоративной культуры
- Внедрение ценностей, противодействующих токсичности, таких как уважение, доверие и сотрудничество.
- Регулярные тренинги по эмоциональному интеллекту и разрешению конфликтов.
4. Мониторинг и своевременное вмешательство
- Активное выявление токсичных практик и оперативное реагирование на них.
- Использование опросов и анонимных каналов для получения обратной связи от сотрудников.
В Agile каждая команда — это живой организм, который может поразить свой вирус. Понимание фаз распространения токсичности поможет своевременно вмешаться и сохранить здоровье команды.
💡 Что такое спайки в Agile?
В Agile-командах есть не только задачи по разработке, но и задачи по изучению чего-то не понятного. Бывает так, что как не подходи к вопросу декомпозиции, то всё равно ничего не ясно. Для поиска решения существуют спайки — небольшие исследовательские задачи, которые помогают команде лучше понять, как сделать фичу продукта.
📌 Как работает спайк?
Представьте, что команда не знает, какой дизайн лучше выбрать для новой функции. Не ясно как будет проходить пользовательский путь. В этом случае можно выделить несколько часов или даже дней на изучение вариантов — это и будет спайк. Его решение поможет команде получить больше информации, чтобы потом двигаться дальше в процессе декомпозиции.
⏰ Когда использовать спайки?
Спайки нужны, когда возникает слишком много вопросов и неопределённости. Но важно не использовать их слишком часто, чтобы это не было оправданием для отложенной работы.
⚙️ Спайки и бэклог:
Спайки могут быть добавлены в бэклог спринта как отдельные задачи. Ведь они помогают команде быть готовыми к быстрому решению комплексных проблем.
Главное — использовать такой инструмент в нужный момент и только там, где это действительно необходимо!
В Agile-командах есть не только задачи по разработке, но и задачи по изучению чего-то не понятного. Бывает так, что как не подходи к вопросу декомпозиции, то всё равно ничего не ясно. Для поиска решения существуют спайки — небольшие исследовательские задачи, которые помогают команде лучше понять, как сделать фичу продукта.
📌 Как работает спайк?
Представьте, что команда не знает, какой дизайн лучше выбрать для новой функции. Не ясно как будет проходить пользовательский путь. В этом случае можно выделить несколько часов или даже дней на изучение вариантов — это и будет спайк. Его решение поможет команде получить больше информации, чтобы потом двигаться дальше в процессе декомпозиции.
⏰ Когда использовать спайки?
Спайки нужны, когда возникает слишком много вопросов и неопределённости. Но важно не использовать их слишком часто, чтобы это не было оправданием для отложенной работы.
⚙️ Спайки и бэклог:
Спайки могут быть добавлены в бэклог спринта как отдельные задачи. Ведь они помогают команде быть готовыми к быстрому решению комплексных проблем.
Главное — использовать такой инструмент в нужный момент и только там, где это действительно необходимо!
📉 Проблемы измерений в Agile-команде
Измерения — важный инструмент для управления и улучшения процессов в Agile-команде, но есть ряд проблем, которые могут мешать их эффективному использованию:
1. Одержимость измерениями: когда команда сосредоточена на достижении показателей, а не на реальной ценности для бизнеса и клиентов.
2. Низкое качество систем измерения и оценки: системы могут быть недостаточно точными или сложными, что вызывает больше вопросов, чем ответов.
3. Отсутствие единой системы, "лоскутная" оценка: фрагментарный подход к измерениям не позволяет получить целостную картину работы и "здоровья" команд.
Почему же измерения важны? 📊
Правильные измерения помогают снизить неопределенность и принимать более обоснованные управленческие решения. Как же их настроить грамотно? 👇
📊 Четыре домена измерений для Agile-команды
Чтобы эффективно управлять и улучшать работу Agile-команды, нужно учитывать четыре ключевых вектора измерений. Они помогают команде лучше понимать свою производительность и влияние на бизнес:
1. Ценность
Ориентирована на владельцев продукта и стейкхолдеров, связана с результатами работы (что?).
Примеры метрик:
- Удовлетворенность клиентов
- Net Promoter Score (NPS)
- Возврат на инвестиции
- Индекс использования функций
2. Продуктивность
Показывает, насколько команда продуктивна за период. Это связано с организацией деятельности (как?).
Примеры метрик:
- Скорость
- Пропускная способность
- Цикл выполнения задачи
- Количество задач за спринт
3. Прогнозируемость
Помогает оценить, насколько точно команда выполняет планы и обязательства (что?).
Примеры метрик:
- Соотношение запланированного и выполненного (Planned-to-Done Ratio)
- Диаграмма сгорания спринта
- Диаграмма накопления релиза
4. Бережливость
Ориентирована на минимизацию потерь и рациональное использование ресурсов (как?).
Примеры метрик:
- Процент незавершенной работы
- Время ожидания задач
- Среднее время поставки
- Количество незавершенных задач
Любой команде важно уменьшить неопределенность в принятии решений и достигать лучших результатов. Измерения становятся не целью, а инструментом для адаптации, роста и повышения эффективности работы Agile-команд. 💪
Измерения — важный инструмент для управления и улучшения процессов в Agile-команде, но есть ряд проблем, которые могут мешать их эффективному использованию:
1. Одержимость измерениями: когда команда сосредоточена на достижении показателей, а не на реальной ценности для бизнеса и клиентов.
2. Низкое качество систем измерения и оценки: системы могут быть недостаточно точными или сложными, что вызывает больше вопросов, чем ответов.
3. Отсутствие единой системы, "лоскутная" оценка: фрагментарный подход к измерениям не позволяет получить целостную картину работы и "здоровья" команд.
Почему же измерения важны? 📊
Правильные измерения помогают снизить неопределенность и принимать более обоснованные управленческие решения. Как же их настроить грамотно? 👇
📊 Четыре домена измерений для Agile-команды
Чтобы эффективно управлять и улучшать работу Agile-команды, нужно учитывать четыре ключевых вектора измерений. Они помогают команде лучше понимать свою производительность и влияние на бизнес:
1. Ценность
Ориентирована на владельцев продукта и стейкхолдеров, связана с результатами работы (что?).
Примеры метрик:
- Удовлетворенность клиентов
- Net Promoter Score (NPS)
- Возврат на инвестиции
- Индекс использования функций
2. Продуктивность
Показывает, насколько команда продуктивна за период. Это связано с организацией деятельности (как?).
Примеры метрик:
- Скорость
- Пропускная способность
- Цикл выполнения задачи
- Количество задач за спринт
3. Прогнозируемость
Помогает оценить, насколько точно команда выполняет планы и обязательства (что?).
Примеры метрик:
- Соотношение запланированного и выполненного (Planned-to-Done Ratio)
- Диаграмма сгорания спринта
- Диаграмма накопления релиза
4. Бережливость
Ориентирована на минимизацию потерь и рациональное использование ресурсов (как?).
Примеры метрик:
- Процент незавершенной работы
- Время ожидания задач
- Среднее время поставки
- Количество незавершенных задач
Любой команде важно уменьшить неопределенность в принятии решений и достигать лучших результатов. Измерения становятся не целью, а инструментом для адаптации, роста и повышения эффективности работы Agile-команд. 💪
26 октября я выступил на лучшей конференции этого года "ПСБ Agile Среда" с докладом "Фенита ля история, прощай Scrum, а что дальше?"
Сегодня мы находимся на 5 уровне парадигмы технологического развития, что говорит об экспотенциальном росте во всех сферах экономической жизни. Такой рост заканчивается сингулярностью. Само понятие сингулярности упрощенно понимается как точка смены прежних закономерностей и трендов. Прогноз за этот горизонт событий обычно считается невозможным. Однако я постарался заглянуть за точку технологической и экономической сингулярности, используя учение о Тектологии Александра Богданова и теорию новаций Александра Болдачёва. В докладе я рассказал о том, что нас может ждать в развитии экосистем адаптивных организаций следующие 20 лет и как менеджменту принять решение о выборе уровня адаптивности.
Фокус на стратегической фазовой адаптивности
В современных условиях фокус смещается с адаптации на уровне команд (таких как Scrum) к адаптации на уровне стратегий. Плавная эволюция - это миф. Вся эволюция происходит через резкие структурные фазовые переходы.
Хотя Scrum и другие Agile-фреймворки остаются важными инструментами для командного уровня, но они не являются главными драйверами изменений на стратегическом уровне.
Важнее понимать и развивать фундаментальные способности организации, чем следовать конкретным фреймворках.
Сто лет назад электрификация была масштабным и новаторским процессом, и должность "директор по электрификации" была критически важна для обеспечения стабильного перехода на новые источники энергии. Например, в начале 20 века внедрение электричества изменило заводы, городскую инфраструктуру и быт, и компании активно привлекали руководителей, чтобы управлять этим новым, сложным процессом. Со временем, однако, электрификация стала рутиной, не требующей специального руководства на стратегическом уровне, и её поддержка интегрировалась в общие системы эксплуатации и обслуживания.
Сегодняшняя ситуация с Agile-фреймворками и фреймворками вроде Scrum, LESS, SAFE чем-то похожа. Гибкие практики, изначально предложенные для разработки ПО, стали важными инструментами для командной адаптивности. Однако, когда организации растут и нуждаются в стратегической гибкости на уровне всей компании, акцент начинает смещаться от отдельных фреймворков (например, Scrum) к стратегическим, более целостным и системным изменениям. Например, сегодня всё чаще начинают подниматься вопросы про изменения организационного дизайна.
В будущем, подобно электрификации, Agile станет традиционной частью работы команд, где его фреймворки и подходы будут рутинной практикой. Стратегическая же гибкость потребует более целостных и комплексных изменений, включающих адаптивные бизнес-модели и принятие структурных решений на уровне всей организации.
В эпоху приближающейся технологической сингулярности модель управления знаниями становятся главным оружием в борьбе с растущей неопределённостью.
Организации новаторы и визионеры займут доминирующее положение на рынке. Компаниям будущего необходимо:
- быть чувствительными к новым возможностям,
- быстро развивать новые способности под возможности,
- корректно выстроить позиционирование,
- определиться с уровнем стратегии адаптации,
- выбирать эффективные методы накопления знаний, чтобы развивать необходимые умения и навыки в командах.
Организации, которые будут искать и находить свой эмпирический фреймворк для адаптации своих стратегий смогут успешно лидировать в условиях радикальных изменений будущего. Возможно фреймворки подобные Scrum станут традиционной практикой организации производственных процессов, принятой по умолчанию на уровне команд. О Scrum будут всё меньше говорить, всё больше докладов мы увидим про подходы к адаптивности на уровне инновационных стратегий.
Сегодня мы находимся на 5 уровне парадигмы технологического развития, что говорит об экспотенциальном росте во всех сферах экономической жизни. Такой рост заканчивается сингулярностью. Само понятие сингулярности упрощенно понимается как точка смены прежних закономерностей и трендов. Прогноз за этот горизонт событий обычно считается невозможным. Однако я постарался заглянуть за точку технологической и экономической сингулярности, используя учение о Тектологии Александра Богданова и теорию новаций Александра Болдачёва. В докладе я рассказал о том, что нас может ждать в развитии экосистем адаптивных организаций следующие 20 лет и как менеджменту принять решение о выборе уровня адаптивности.
Фокус на стратегической фазовой адаптивности
В современных условиях фокус смещается с адаптации на уровне команд (таких как Scrum) к адаптации на уровне стратегий. Плавная эволюция - это миф. Вся эволюция происходит через резкие структурные фазовые переходы.
Хотя Scrum и другие Agile-фреймворки остаются важными инструментами для командного уровня, но они не являются главными драйверами изменений на стратегическом уровне.
Важнее понимать и развивать фундаментальные способности организации, чем следовать конкретным фреймворках.
Сто лет назад электрификация была масштабным и новаторским процессом, и должность "директор по электрификации" была критически важна для обеспечения стабильного перехода на новые источники энергии. Например, в начале 20 века внедрение электричества изменило заводы, городскую инфраструктуру и быт, и компании активно привлекали руководителей, чтобы управлять этим новым, сложным процессом. Со временем, однако, электрификация стала рутиной, не требующей специального руководства на стратегическом уровне, и её поддержка интегрировалась в общие системы эксплуатации и обслуживания.
Сегодняшняя ситуация с Agile-фреймворками и фреймворками вроде Scrum, LESS, SAFE чем-то похожа. Гибкие практики, изначально предложенные для разработки ПО, стали важными инструментами для командной адаптивности. Однако, когда организации растут и нуждаются в стратегической гибкости на уровне всей компании, акцент начинает смещаться от отдельных фреймворков (например, Scrum) к стратегическим, более целостным и системным изменениям. Например, сегодня всё чаще начинают подниматься вопросы про изменения организационного дизайна.
В будущем, подобно электрификации, Agile станет традиционной частью работы команд, где его фреймворки и подходы будут рутинной практикой. Стратегическая же гибкость потребует более целостных и комплексных изменений, включающих адаптивные бизнес-модели и принятие структурных решений на уровне всей организации.
В эпоху приближающейся технологической сингулярности модель управления знаниями становятся главным оружием в борьбе с растущей неопределённостью.
Организации новаторы и визионеры займут доминирующее положение на рынке. Компаниям будущего необходимо:
- быть чувствительными к новым возможностям,
- быстро развивать новые способности под возможности,
- корректно выстроить позиционирование,
- определиться с уровнем стратегии адаптации,
- выбирать эффективные методы накопления знаний, чтобы развивать необходимые умения и навыки в командах.
Организации, которые будут искать и находить свой эмпирический фреймворк для адаптации своих стратегий смогут успешно лидировать в условиях радикальных изменений будущего. Возможно фреймворки подобные Scrum станут традиционной практикой организации производственных процессов, принятой по умолчанию на уровне команд. О Scrum будут всё меньше говорить, всё больше докладов мы увидим про подходы к адаптивности на уровне инновационных стратегий.
🎯 10 рекомендаций: как создавать то, что действительно важно
95% того, что мы делаем, со временем теряет значение. Я придумал 10 руководящих принципов, которые помогают не потерять сути: 🌟
1️⃣ Фокус на ценности, не на отдельных действиях или функциях
• Создавайте то, что ценно для пользователей
• Всегда спрашивайте: "Какую проблему мы решаем и почему это важно?"
2️⃣ Найдите свою "полярную звезду"
• Определите долгосрочное видение
• Задумайтесь: что останется от ваших продуктов через 5 или даже 50 лет? Насколько важно то, что вы создаёте в перспективе?
3️⃣ Учитесь фильтровать информационный шум
• В потоке постоянных изменений важно уметь выделять главное
• Развивайте навык отсечения лишнего
4️⃣ Примите встроенную нестабильность
• Неопределенность и изменения – это норма, а не исключение
• Учитесь использовать турбулентность как источник возможностей
5️⃣ Следуйте философии минимализма
• Избегайте излишеств в работе
• Задавайте вопрос: "Что можно убрать, сохранив тот же результат?"
6️⃣ Стройте крепкие отношения
• Продукт – не единственный результат работы команды
• Создавайте среду для открытого обмена опытом и поддержки
7️⃣ Будьте гибкими
• Примите перемены как часть жизни
• Периодически спрашивайте: "Сделали бы мы то же самое, начиная сегодня?"
8️⃣ Развивайте осознанность
• Ставьте под сомнение рабочие автоматизмы
• Регулярно задавайте себе вопрос "Почему я это делаю?"
9️⃣ Создавайте наследие
• Помните: ваша работа – часть большего
• Думайте о том, какой след оставите в истории компании и жизни пользователей
🔟 Принимайте временность успеха
• Проекты закрываются, продукты устаревают – это нормально
• Цените не только результат, но и путь: рост, опыт, командную работу, – все накопленные знания
💫 Помните: истинная ценность – в тех 5% активностей, которые приносят долгосрочный смысл в работу сегодня и в жизнь целом
95% того, что мы делаем, со временем теряет значение. Я придумал 10 руководящих принципов, которые помогают не потерять сути: 🌟
1️⃣ Фокус на ценности, не на отдельных действиях или функциях
• Создавайте то, что ценно для пользователей
• Всегда спрашивайте: "Какую проблему мы решаем и почему это важно?"
2️⃣ Найдите свою "полярную звезду"
• Определите долгосрочное видение
• Задумайтесь: что останется от ваших продуктов через 5 или даже 50 лет? Насколько важно то, что вы создаёте в перспективе?
3️⃣ Учитесь фильтровать информационный шум
• В потоке постоянных изменений важно уметь выделять главное
• Развивайте навык отсечения лишнего
4️⃣ Примите встроенную нестабильность
• Неопределенность и изменения – это норма, а не исключение
• Учитесь использовать турбулентность как источник возможностей
5️⃣ Следуйте философии минимализма
• Избегайте излишеств в работе
• Задавайте вопрос: "Что можно убрать, сохранив тот же результат?"
6️⃣ Стройте крепкие отношения
• Продукт – не единственный результат работы команды
• Создавайте среду для открытого обмена опытом и поддержки
7️⃣ Будьте гибкими
• Примите перемены как часть жизни
• Периодически спрашивайте: "Сделали бы мы то же самое, начиная сегодня?"
8️⃣ Развивайте осознанность
• Ставьте под сомнение рабочие автоматизмы
• Регулярно задавайте себе вопрос "Почему я это делаю?"
9️⃣ Создавайте наследие
• Помните: ваша работа – часть большего
• Думайте о том, какой след оставите в истории компании и жизни пользователей
🔟 Принимайте временность успеха
• Проекты закрываются, продукты устаревают – это нормально
• Цените не только результат, но и путь: рост, опыт, командную работу, – все накопленные знания
💫 Помните: истинная ценность – в тех 5% активностей, которые приносят долгосрочный смысл в работу сегодня и в жизнь целом
Вы когда-нибудь слышали про птицу додо? Это такая нелетающая птица, которая когда-то обитала на острове Маврикий. У неё не было естественных врагов и конкурентов, еды было в изобилии, жизнь казалась идеальной. Додо так привыкли к комфортной стабильности, что потеряли способность адаптироваться. В 16 веке на Маврикий прибыли европейские моряки — сначала португальцы, затем голландцы. С ними на остров пришли новые животные: крысы, свиньи, коты и собаки. Эти животные начали охотиться на додо и разорять их гнёзда. Додо вымерли достаточно быстро и исчезли бесследно.
Почему я вспомнил про додо? Потому что это отличный пример того, как отсутствие адаптивности в комфортных условиях может привести к печальным последствиям. И это касается не только животных, но и нас с вами — команд и бизнеса в современном мире.
Когда всё слишком хорошо
Представьте команду, которая стабильно показывает отличные результаты. Их хвалят, они получают награды, всё идёт по плану. Казалось бы, именно так и должно быть. Но есть опасность: в такой ситуации легко попасть в ловушку самодовольства. Команда может перестать искать новые решения, учиться и адаптироваться к изменениям. В такой команде полностью довольны своим процессом и ретроспективы воспринимают как ритуал и потерю времени. Они становятся похожи на тех самых додо — успешных в неподвижности, но уязвимых к переменам.
Внешний мир не стоит на месте. Появляются новые технологии, меняются рынки, клиентские потребности эволюционируют. Команда, которая почивает на лаврах, рискует не заметить, как мир ушёл вперёд, и остаться позади.
Адаптивность — ключ к выживанию и успеху
Адаптивность — это не просто способность реагировать на кризисы. Это постоянный процесс обучения, развития и готовности принять новое особенно когда всё вроде как по плану. Какие шаги помогут нам поддерживать и развивать эту способность?
- За пределами зоны комфорта: Поощряйте команду брать на себя новые задачи, выходить за рамки привычного. Это стимулирует рост и развитие.
- Культура обучения: Создайте среду, где обучение и прямой обмен знаниями являются нормой.
- Открытость к новому: Будьте готовы внедрять новые технологии и практики в производственный процесс, даже если сейчас всё кажется стабильным. Быть готовым к переменам, когда айсберг таит легко, но быть готовым к эксперименту, когда всё вроде хорошо, — это путь визионеров.
Генеративный искусственный интеллект — наш новый союзник
Одной из самых захватывающих технологий нашего времени является генеративный искусственный интеллект (ГИИ). Он открывает невероятные возможности для повышения производительности труда в команде.
- Ускорение разработки: С помощью ГИИ можно многократно увеличить скорость написания кода.
- Оптимизация процессов: ГИИ помогает анализировать большие объёмы данных и находить узкие места в операционной деятельности.
- Новые горизонты обучения: ГИИ может стать инструментом для персонализированного обучения сотрудников.
Не быть додо в мире бизнеса
В современном мире, где изменения происходят непрерывно, стабильность может быть обманчивой.
Давайте не будем повторять ошибок додо. Вместо этого будем стремиться к постоянному развитию, использовать передовые технологии и поддерживать культуру адаптивности в наших командах. Так мы сможем не только выжить, но и добиться успеха в долгосрочной перспективе.
🎯 Главный инсайт
Успех может быть опаснее неудачи. Почему? Потому что он усыпляет бдительность! Создаёт иллюзию, что всё хорошо будет всегда.
Но помните: сегодняшний успех — это результат вчерашних действий. А что будет завтра, зависит от того, что вы делаете сегодня.
💪 План действий на завтра
1. Посмотрите на свою команду свежим взглядом, спросите себя насколько скучны ваши ретро встречи и обзоры?
2. Найдите области, где вы "застоялись"
3. Выберите одну новую технологию и практику для изучения
4. Запланируйте эксперимент в практиках работы и в создаваемом продукте
5. Начните действовать!
❓ Вопрос к вам
Как вы создаёте "нестабильность" в успешной команде? Что помогает не расслабляться, когда всё идёт хорошо?
Делитесь в комментариях! 👇
Почему я вспомнил про додо? Потому что это отличный пример того, как отсутствие адаптивности в комфортных условиях может привести к печальным последствиям. И это касается не только животных, но и нас с вами — команд и бизнеса в современном мире.
Когда всё слишком хорошо
Представьте команду, которая стабильно показывает отличные результаты. Их хвалят, они получают награды, всё идёт по плану. Казалось бы, именно так и должно быть. Но есть опасность: в такой ситуации легко попасть в ловушку самодовольства. Команда может перестать искать новые решения, учиться и адаптироваться к изменениям. В такой команде полностью довольны своим процессом и ретроспективы воспринимают как ритуал и потерю времени. Они становятся похожи на тех самых додо — успешных в неподвижности, но уязвимых к переменам.
Внешний мир не стоит на месте. Появляются новые технологии, меняются рынки, клиентские потребности эволюционируют. Команда, которая почивает на лаврах, рискует не заметить, как мир ушёл вперёд, и остаться позади.
Адаптивность — ключ к выживанию и успеху
Адаптивность — это не просто способность реагировать на кризисы. Это постоянный процесс обучения, развития и готовности принять новое особенно когда всё вроде как по плану. Какие шаги помогут нам поддерживать и развивать эту способность?
- За пределами зоны комфорта: Поощряйте команду брать на себя новые задачи, выходить за рамки привычного. Это стимулирует рост и развитие.
- Культура обучения: Создайте среду, где обучение и прямой обмен знаниями являются нормой.
- Открытость к новому: Будьте готовы внедрять новые технологии и практики в производственный процесс, даже если сейчас всё кажется стабильным. Быть готовым к переменам, когда айсберг таит легко, но быть готовым к эксперименту, когда всё вроде хорошо, — это путь визионеров.
Генеративный искусственный интеллект — наш новый союзник
Одной из самых захватывающих технологий нашего времени является генеративный искусственный интеллект (ГИИ). Он открывает невероятные возможности для повышения производительности труда в команде.
- Ускорение разработки: С помощью ГИИ можно многократно увеличить скорость написания кода.
- Оптимизация процессов: ГИИ помогает анализировать большие объёмы данных и находить узкие места в операционной деятельности.
- Новые горизонты обучения: ГИИ может стать инструментом для персонализированного обучения сотрудников.
Не быть додо в мире бизнеса
В современном мире, где изменения происходят непрерывно, стабильность может быть обманчивой.
Давайте не будем повторять ошибок додо. Вместо этого будем стремиться к постоянному развитию, использовать передовые технологии и поддерживать культуру адаптивности в наших командах. Так мы сможем не только выжить, но и добиться успеха в долгосрочной перспективе.
🎯 Главный инсайт
Успех может быть опаснее неудачи. Почему? Потому что он усыпляет бдительность! Создаёт иллюзию, что всё хорошо будет всегда.
Но помните: сегодняшний успех — это результат вчерашних действий. А что будет завтра, зависит от того, что вы делаете сегодня.
💪 План действий на завтра
1. Посмотрите на свою команду свежим взглядом, спросите себя насколько скучны ваши ретро встречи и обзоры?
2. Найдите области, где вы "застоялись"
3. Выберите одну новую технологию и практику для изучения
4. Запланируйте эксперимент в практиках работы и в создаваемом продукте
5. Начните действовать!
❓ Вопрос к вам
Как вы создаёте "нестабильность" в успешной команде? Что помогает не расслабляться, когда всё идёт хорошо?
Делитесь в комментариях! 👇
https://habr.com/ru/articles/892518/ - написал небольшую статью про будущее команд разработки и Agile. Короче так, если вы в ИТ и переживаете за своё будущее, у меня есть мысли. 😎
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Куда катится разработка с ИИ
🔮 Мои мысли на ближайшие 5 лет Привет всем! Я работаю Agile-коучем, но смотрю за миром вокруг и вижу что ГИИ (генеративный искусственный интеллект) поменяет работу команд разработки. Меня впечатляет...
🎯 AgileDays25: День второй
Привет, друзья! Накидаю вам горяченького с AgileDays25 🔥
Сегодня в Hyatt Regency зажигают по полной. Залы забиты, народ активно нетворкится и делится опытом.
Главные темы дня:
- Agile без хайпа: реальные кейсы
- AI в управлении: куда бежать и что внедрять
- Продуктовый подход
и другое
🚂 Отдельное спасибо за дискуссию с Алексею Ионову про разноскоростные SAFe-поезда. Наконец-то кто-то объяснил, почему с этим не только можно, но и нужно жить! Словил инсайт.
🎤 Особо отмечу доклад Ильи Павличенко (ScrumRu) про проектирование Agile-организаций. Бесконечная харизма Ильи дала заряд позитива.
Что ещё крутого:
- Беседы со спикерами
- Квизы с призами
- Традиционная виски-пати
- Эко-мерч из баннеров (довольно оригинально!) 😊
Привет, друзья! Накидаю вам горяченького с AgileDays25 🔥
Сегодня в Hyatt Regency зажигают по полной. Залы забиты, народ активно нетворкится и делится опытом.
Главные темы дня:
- Agile без хайпа: реальные кейсы
- AI в управлении: куда бежать и что внедрять
- Продуктовый подход
и другое
🚂 Отдельное спасибо за дискуссию с Алексею Ионову про разноскоростные SAFe-поезда. Наконец-то кто-то объяснил, почему с этим не только можно, но и нужно жить! Словил инсайт.
🎤 Особо отмечу доклад Ильи Павличенко (ScrumRu) про проектирование Agile-организаций. Бесконечная харизма Ильи дала заряд позитива.
Что ещё крутого:
- Беседы со спикерами
- Квизы с призами
- Традиционная виски-пати
- Эко-мерч из баннеров (довольно оригинально!) 😊