Например, у нас есть команда из 7 человек (не включая Владельца продукта), которая будет работать 2-недельными спринтами, отпусков и отгулов в первом спринте не планируется. Получаем 7 х 8 = 56. Если кто-то из членов команды совмещает свою роль с ролью Scrum-Mastera, можно еще немного уменьшить общую производительность.
Таким образом получаем предполагаемую производительность команды на первый спринт. Для начала этого достаточно, а дальше команда начнет накапливать собственную статистику.
Таким образом получаем предполагаемую производительность команды на первый спринт. Для начала этого достаточно, а дальше команда начнет накапливать собственную статистику.
А отслеживать статистику команды помогает Burndown Chart. На первых этапах он очень полезен для прогресса команды, но и развитым командам рекомендуем не забывать про него и отслеживать динамику своих показателей;)
Друзья, привет! Внезапно освободилось 1 место на завтрашнем тренинге Agile Project Management.
Отличный шанс детально разобраться в особенностях управления проектами в Agile и гибридной среде и получить сертификацию ICAgile. По этому случаю сделаем приятную скидку;)
Тренинг будет проходить 22-24 сентября, с 9.00 до 13.00 (мск). Чтобы забронировать место, напишите на почту olga@onagile.ru
Отличный шанс детально разобраться в особенностях управления проектами в Agile и гибридной среде и получить сертификацию ICAgile. По этому случаю сделаем приятную скидку;)
Тренинг будет проходить 22-24 сентября, с 9.00 до 13.00 (мск). Чтобы забронировать место, напишите на почту olga@onagile.ru
Как учитывать User Story, которую не успели доделать за спринт?
Стоит ли изменить ее оценку перед возвращением в бэклог, ведь часть работы мы уже сделали?
Не нужно: оценка остается такой же. В текущем спринте будет падение Velocity (потому что, если задача не сделана до конца и не соответствует Критериям готовности, мы не можем засчитать ее сторипойнты). Но в следующем спринте мы снова возьмем в работу эту задачу, доделаем, и в итоге к спринту добавятся все те сторипойнты, которые были заложены в задаче.
На показатели производительности команды это не повлияет, потому что для их оценки используется среднее значение по спринтам, которое нивелирует эти скачки.
Стоит ли изменить ее оценку перед возвращением в бэклог, ведь часть работы мы уже сделали?
Не нужно: оценка остается такой же. В текущем спринте будет падение Velocity (потому что, если задача не сделана до конца и не соответствует Критериям готовности, мы не можем засчитать ее сторипойнты). Но в следующем спринте мы снова возьмем в работу эту задачу, доделаем, и в итоге к спринту добавятся все те сторипойнты, которые были заложены в задаче.
На показатели производительности команды это не повлияет, потому что для их оценки используется среднее значение по спринтам, которое нивелирует эти скачки.
Когда стоит выполнить переоценку User Story?
В прошлый раз мы обсуждали сценарий, когда команда не успевает завершить за спринт историю и не засчитывает в свою velocity баллы за выполненную ее часть. Обычно мы рекомендуем использовать именно этот подход, но есть исключения. О ситуациях, когда переоценка полезна, отлично пишет Майк Кон в книге «Agile: Оценка и планирование проектов».
Бывает, что команда не может завершить незаконченную часть User Story в следующем спринте. В этом случае лучше позволить команде получить баллы за завершенную часть истории: на основе новых знаний об объеме и сложности истории мы оцениваем, сколько баллов назначить за завершенную часть, и учитываем эти данные в velocity спринта.
Оставшуюся часть истории мы:
1. Переформулируем с учетом реализованного функционала.
2. Оцениваем на основе полученных в этом спринте знаний.
Суммарная оценка завершенной части истории и оставшейся не обязательно должна быть равна первоначальной оценке, ведь теперь мы знаем об истории больше и можем оценить точнее.
В прошлый раз мы обсуждали сценарий, когда команда не успевает завершить за спринт историю и не засчитывает в свою velocity баллы за выполненную ее часть. Обычно мы рекомендуем использовать именно этот подход, но есть исключения. О ситуациях, когда переоценка полезна, отлично пишет Майк Кон в книге «Agile: Оценка и планирование проектов».
Бывает, что команда не может завершить незаконченную часть User Story в следующем спринте. В этом случае лучше позволить команде получить баллы за завершенную часть истории: на основе новых знаний об объеме и сложности истории мы оцениваем, сколько баллов назначить за завершенную часть, и учитываем эти данные в velocity спринта.
Оставшуюся часть истории мы:
1. Переформулируем с учетом реализованного функционала.
2. Оцениваем на основе полученных в этом спринте знаний.
Суммарная оценка завершенной части истории и оставшейся не обязательно должна быть равна первоначальной оценке, ведь теперь мы знаем об истории больше и можем оценить точнее.
2 хороших способа приоритизации элементов бэклога
Обсуждали с клиентом PI-планирование и зашла речь о способах приоритизации элементов бэклога. Есть два метода, которые мы часто рекомендуем — они хорошо работают даже у команд, у которых пока мало опыта в приоритизации.
Первый вы наверняка знаете, но все же напомним;) Это приоритизация по трем категориям, или MoSCoW.
Акроним MoSCoW включает в себя следующую классификацию элементов бэклога:
- Must Have — эпики/ истории/ фичи, которые обязательно должны быть поставлены. Обычно они касаются решения существующщих проблем бизнеса или требований внешних регуляторов.
Например, мы делаем финасовый продукт, и чтобы не получить штраф, должны к 1 декабря поставить протокол безопасности.
Элементы, отнесенные к Must, составляют минимум того, что мы должны поставить в ближайшие итерации.
- Should Have — эпики/ истории/ фичи, имеющие решающее значение для успеха релиза.
Такие элементы бэклога не менее важны, чем элементы категории Must, но могут быть несрочными.
- Could Have — «желательные» эпики/ истории/ фичи: они представляют собой значительную ценность для релиза или продукта в целом, но не являются критичными, как Must и Should.
- Дополнительная категория — Won't Have: эти элементы бэклога хорошо бы реализовать, если останется время, но, скорее всего, часть из них или даже все не войдут в ближайший релиз.
Метод приоритизации MoSCoW не слишком точный, но достаточно интуитивный и подойдет даже начинающим командам.
Более точный, но и сложный метод — Weighted Shortest Job First, основанный на соотношении ценности элемента бэклога для бизнеса к «размеру» работы, которую нужно совершить для поставки этого элемента.
Подробно об этом методе читайте в блоге.
А какими методами приоритизации чаще пользуетесь вы?
Делитесь опытом в комментариях — соберем все методы в отдельный пост: будет полезно для новичков и не только;)
Обсуждали с клиентом PI-планирование и зашла речь о способах приоритизации элементов бэклога. Есть два метода, которые мы часто рекомендуем — они хорошо работают даже у команд, у которых пока мало опыта в приоритизации.
Первый вы наверняка знаете, но все же напомним;) Это приоритизация по трем категориям, или MoSCoW.
Акроним MoSCoW включает в себя следующую классификацию элементов бэклога:
- Must Have — эпики/ истории/ фичи, которые обязательно должны быть поставлены. Обычно они касаются решения существующщих проблем бизнеса или требований внешних регуляторов.
Например, мы делаем финасовый продукт, и чтобы не получить штраф, должны к 1 декабря поставить протокол безопасности.
Элементы, отнесенные к Must, составляют минимум того, что мы должны поставить в ближайшие итерации.
- Should Have — эпики/ истории/ фичи, имеющие решающее значение для успеха релиза.
Такие элементы бэклога не менее важны, чем элементы категории Must, но могут быть несрочными.
- Could Have — «желательные» эпики/ истории/ фичи: они представляют собой значительную ценность для релиза или продукта в целом, но не являются критичными, как Must и Should.
- Дополнительная категория — Won't Have: эти элементы бэклога хорошо бы реализовать, если останется время, но, скорее всего, часть из них или даже все не войдут в ближайший релиз.
Метод приоритизации MoSCoW не слишком точный, но достаточно интуитивный и подойдет даже начинающим командам.
Более точный, но и сложный метод — Weighted Shortest Job First, основанный на соотношении ценности элемента бэклога для бизнеса к «размеру» работы, которую нужно совершить для поставки этого элемента.
Подробно об этом методе читайте в блоге.
А какими методами приоритизации чаще пользуетесь вы?
Делитесь опытом в комментариях — соберем все методы в отдельный пост: будет полезно для новичков и не только;)
Нужен ли вам аудит команд и чем его заменить
В последнее время нам приходит много запросов на аудит команд и процессов. Поскольку к концу года вопрос особенно актуальный, давайте разбираться, как получить максимум пользы и сэкономить драгоценное время и деньги.
Первое, на что стоит ориентироваться — как устроена работа в вашей компании сейчас.
1. У вас есть команды, которые уже работают по Scrum. Задача: найти дисфункции и потенциальные риски, выявить точки роста и составить план по развитию команды.
С этим отлично справляется аудит. Причем, если у нас есть 10 команд, нет необходимости оценивать их все — достаточно оценить 1-2 команды, в остальных будет плюс-минус такая же ситуация. А деньги, которые вы не потратите на избыточный аудит, целесообразнее направить на улучшение работы команд.
2. У вас пока нет команд, которые используют agile. В этом случае аудит как отдельная активность по сути не требуется, поскольку планируется значительное изменение всех процессов. Нам предстоит постоить работу над проектом или продуктом заново, и эффективнее сосредоточиться именно на этом: на подготовке и обучении людей, на формировании договоренностей с бизнесом.
Слабые места в работе команд обнаружатся в процессе подготовки к внедрению изменений, и мы сможем их пофиксить во время обучения и отладки процессов.
Если у вас много команд, рекомендуем выбрать в качестве пилота 1-2 и запустить сначала их, а через 2-3 месяца масштабировать опыт на остальные команды.
Масштабная трансформация всей компании сразу — по-своему хороший вариант, но требует гораздо больших ресурсов и более тщательной и долгой подготовки, что не всегда целесообразно в условиях, когда изменения уже назрели и нужны бизнесу здесь и сейчас.
—
Если вам нужна консультация по Agile, обучение, помощь с запуском команд или поддержка Agile-трансформации компании, напишите или позвоните нам, будем рады поделиться опытом и помочь.
info@onagile.ru, +7 495 221 87 39
В последнее время нам приходит много запросов на аудит команд и процессов. Поскольку к концу года вопрос особенно актуальный, давайте разбираться, как получить максимум пользы и сэкономить драгоценное время и деньги.
Первое, на что стоит ориентироваться — как устроена работа в вашей компании сейчас.
1. У вас есть команды, которые уже работают по Scrum. Задача: найти дисфункции и потенциальные риски, выявить точки роста и составить план по развитию команды.
С этим отлично справляется аудит. Причем, если у нас есть 10 команд, нет необходимости оценивать их все — достаточно оценить 1-2 команды, в остальных будет плюс-минус такая же ситуация. А деньги, которые вы не потратите на избыточный аудит, целесообразнее направить на улучшение работы команд.
2. У вас пока нет команд, которые используют agile. В этом случае аудит как отдельная активность по сути не требуется, поскольку планируется значительное изменение всех процессов. Нам предстоит постоить работу над проектом или продуктом заново, и эффективнее сосредоточиться именно на этом: на подготовке и обучении людей, на формировании договоренностей с бизнесом.
Слабые места в работе команд обнаружатся в процессе подготовки к внедрению изменений, и мы сможем их пофиксить во время обучения и отладки процессов.
Если у вас много команд, рекомендуем выбрать в качестве пилота 1-2 и запустить сначала их, а через 2-3 месяца масштабировать опыт на остальные команды.
Масштабная трансформация всей компании сразу — по-своему хороший вариант, но требует гораздо больших ресурсов и более тщательной и долгой подготовки, что не всегда целесообразно в условиях, когда изменения уже назрели и нужны бизнесу здесь и сейчас.
—
Если вам нужна консультация по Agile, обучение, помощь с запуском команд или поддержка Agile-трансформации компании, напишите или позвоните нам, будем рады поделиться опытом и помочь.
info@onagile.ru, +7 495 221 87 39
Итак, подарки открыты, все новогодние фильмы посмотрены, а впереди еще несколько дней каникул.
Предлагаем начать использовать их так, чтобы заложить фундамент продуктивного года, при этом не слишком отвлекаясь от отдыха.
Команда OnAgile подготовила для вас небольшой адвент🎁 с рекомендациями, которые помогут подготовиться к первому рабочему дню и начать 2022-й максимально продуктивно.
Каждый день мы будем публиковать по одной карточке с небольшим заданием на 3-5 минут. Не забывайте пересылать друзьям и коллегам.
Начинаем!
Предлагаем начать использовать их так, чтобы заложить фундамент продуктивного года, при этом не слишком отвлекаясь от отдыха.
Команда OnAgile подготовила для вас небольшой адвент🎁 с рекомендациями, которые помогут подготовиться к первому рабочему дню и начать 2022-й максимально продуктивно.
Каждый день мы будем публиковать по одной карточке с небольшим заданием на 3-5 минут. Не забывайте пересылать друзьям и коллегам.
Начинаем!
Мысленная ретроспектива 2021 года
Отвлеченный от рабочих будней контекст долгого праздника — самое время ненадолго вернуться в 2021 год и спросить себя:
🔹 Чем из того, что я (или моя команда) сделали в ушедшем году, мы действительно можем гордиться?
🔹 Какие из проблем, с которыми мы столкнулись, можно было решить гораздо проще и быстрее?
🔹 Что из сделанного оказалось не очень полезным и можно было не тратить свои силы и время на это?
Для того чтобы ответить на эти вопросы, вам не нужно собирать команду — просто подумайте об этом в свободное время и новые идеи не заставят себя ждать.
Отвлеченный от рабочих будней контекст долгого праздника — самое время ненадолго вернуться в 2021 год и спросить себя:
🔹 Чем из того, что я (или моя команда) сделали в ушедшем году, мы действительно можем гордиться?
🔹 Какие из проблем, с которыми мы столкнулись, можно было решить гораздо проще и быстрее?
🔹 Что из сделанного оказалось не очень полезным и можно было не тратить свои силы и время на это?
Для того чтобы ответить на эти вопросы, вам не нужно собирать команду — просто подумайте об этом в свободное время и новые идеи не заставят себя ждать.
Новые идеи по продукту
🔹 Попробуйте посмотреть на продукт, которым занимается ваша команда, свежим взглядом: что может дать значимый толчок в его развитии и что для этого следует сделать сразу после праздников?
Например, можно протестировать несколько интересных на ваш взгляд гипотез, которые могут дать ценные данные и подтолкнуть к новым идеям.
🔹 Также рекомендуем лишний раз посмотреть продукты/сайты конкурентов: на что они делают упор, что появилось интересного в этих продуктах за последнее время, что конкуренты говорят клиентам о себе и о своем сервисе?
Для того чтобы сделать вышеперечисленное, не обязательно быть менеджером продукта. Вне зависимости от вашей роли в команде, это небольшое упражнение поможет увидеть интересные идеи, которые можно будет взять в работу после праздников.
🔹 Попробуйте посмотреть на продукт, которым занимается ваша команда, свежим взглядом: что может дать значимый толчок в его развитии и что для этого следует сделать сразу после праздников?
Например, можно протестировать несколько интересных на ваш взгляд гипотез, которые могут дать ценные данные и подтолкнуть к новым идеям.
🔹 Также рекомендуем лишний раз посмотреть продукты/сайты конкурентов: на что они делают упор, что появилось интересного в этих продуктах за последнее время, что конкуренты говорят клиентам о себе и о своем сервисе?
Для того чтобы сделать вышеперечисленное, не обязательно быть менеджером продукта. Вне зависимости от вашей роли в команде, это небольшое упражнение поможет увидеть интересные идеи, которые можно будет взять в работу после праздников.
Клиенты и конверсия
В продолжение темы развития продукта полезно также запустить мыслительный процесс в сторону клиентов, их потребностей и того, как они взаимодействуют с нашим продуктом/сервисом/компанией.
Например:
🔹 Кого из конкретных клиентов (или представителей определённого сегмента) можно было бы кратко проинтервьюировать в первые рабочие дни, чтобы лучше понять, что им сейчас нужно, как они взаимодействуют с нашим продуктом, что у них не совсем получается?
🔹 Как выглядит конверсия на разных этапах пути клиента: какой процент людей возвращается, какой процент делает полезное действие, на каком этапе уходит больше всего клиентов и с чем это может быть связано?
🔹 Какой ещё сегмент клиентов мы могли бы привлечь, чтобы протестировать их интерес к нашему продукту? И как это обернуть в высококонверсионное ценностное предложение?
Безусловно, для всего этого есть стандартные отчеты, каникулы же дают возможность попробовать посмотреть отвлечённым от рабочей рутины взглядом и увидеть что-то новое.
В продолжение темы развития продукта полезно также запустить мыслительный процесс в сторону клиентов, их потребностей и того, как они взаимодействуют с нашим продуктом/сервисом/компанией.
Например:
🔹 Кого из конкретных клиентов (или представителей определённого сегмента) можно было бы кратко проинтервьюировать в первые рабочие дни, чтобы лучше понять, что им сейчас нужно, как они взаимодействуют с нашим продуктом, что у них не совсем получается?
🔹 Как выглядит конверсия на разных этапах пути клиента: какой процент людей возвращается, какой процент делает полезное действие, на каком этапе уходит больше всего клиентов и с чем это может быть связано?
🔹 Какой ещё сегмент клиентов мы могли бы привлечь, чтобы протестировать их интерес к нашему продукту? И как это обернуть в высококонверсионное ценностное предложение?
Безусловно, для всего этого есть стандартные отчеты, каникулы же дают возможность попробовать посмотреть отвлечённым от рабочей рутины взглядом и увидеть что-то новое.
Встреча с командой по ближайшим целям
Первые рабочие дни — идеальное время, чтобы поговорить с командой о ближайших целях и обсудить формат совместной работы.
🔹 Что нам предстоит сделать в ближайшие 2-3 месяца? На чем нам следует сфокусироваться? Как мы сможем измерить результат?
🔹 Еще один важный вопрос — что можно улучшить в процессах работы команды. Что мы можем сделать по-другому по сравнению с тем, как работали в прошлом году? Вспомните, как проходили стендапы, планирование и другие командные встречи: были ли они достаточно эффективными? Как можно их улучшить?
Запланируйте встречу на первый или второй рабочий день, пока у всех еще свободны календари. Такая встреча будет полезна и с точки зрения укрепления внутрикомандных связей и поможет быстро настроиться на рабочий ритм.
Первые рабочие дни — идеальное время, чтобы поговорить с командой о ближайших целях и обсудить формат совместной работы.
🔹 Что нам предстоит сделать в ближайшие 2-3 месяца? На чем нам следует сфокусироваться? Как мы сможем измерить результат?
🔹 Еще один важный вопрос — что можно улучшить в процессах работы команды. Что мы можем сделать по-другому по сравнению с тем, как работали в прошлом году? Вспомните, как проходили стендапы, планирование и другие командные встречи: были ли они достаточно эффективными? Как можно их улучшить?
Запланируйте встречу на первый или второй рабочий день, пока у всех еще свободны календари. Такая встреча будет полезна и с точки зрения укрепления внутрикомандных связей и поможет быстро настроиться на рабочий ритм.
Друзья, на этом наш адвент подошёл к концу. Напишите в комментариях, понравились ли вам вопросы, возникали ли у вас новые идеи, пока вы читали посты и помогло ли это подготовиться к рабочей неделе.
Желаем вам чудесного, интересного и продуктивного года!
Команда OnAgile
Желаем вам чудесного, интересного и продуктивного года!
Команда OnAgile
Стартовал новый тренинговый сезон🚀 Так что если вы планируете развить компетенции в сфере Agile, выбирайте программу, которая отвечает вашим интересам, а мы позаботимся о том, чтобы трехдневный интенсив принес вам максимум практических знаний
Ближайшие тренинги
1. Фундаментальный курс по всему, что есть в Agile: Scrum, Kanban, SAFe, LeSS
Cамый широкий по охвату тем тренинг, основной курс по гибким подходам, включающий Scrum, Kanban и обзор фреймворков масштабирования. Идеальная программа для тех, кто присоединился к scrum-команде или планирует перестроить работу своей команды.
Ближайшая группа на следующей неделе, 26 – 28 января. Забронировать участие.
Следующие группы 01-03 марта, 20-22 апреля, 18-20 мая, 20-24 июня
2. Продвинутый курс для Владельцев Продуктов
Углубленный курс по созданию, выводу на рынок и развитию продуктов в быстроменяющейся среде. Включая управление ожиданиями заказчиков, работу в agile-команде, проектирование и развитие продукта на основе глубокого понимания потребностей клиентов.
Ближайшие группы 09 – 11 февраля, 25-27 мая, забронировать участие.
3. Продвинутый курс для Скрам-мастеров
Лучший тренинг по отзывам 2021 года — продвинутый курс для Скрам-мастеров и всех, кому важны развитие команды, эффективное проведение командных встреч, командный коучинг и фасилитация.
Ближайшие группы 23-25 февраля, 27-29 апреля, забронировать участие.
4. Курс по управлению проектами в Agile
Менеджеры проектов выбирают тренинг Agile Project Management, в программе которого мы разбираем все аспекты современного подхода к управлению проектами в гибкой и гибридной среде, от дизайна проекта и оценки рисков до взаимодействия с подрядчиками.
Ближайшие группы 29 – 31 марта, 28-30 июня забронировать участие.
5. Курс по Agile для сотрудников HR
Специальный курс для HR-специалистов и руководителей HR департаментов — Agile в HR. Ранее доступный только для корпоративных клиентов тренинг теперь проходит в открытом формате. Разберем развитие HR-сервисов, мотивационной стратегии и организационной структуры компании на основе agile-практик, процесс найма и онбординга сотрудников.
Ближайшая группа 06 - 08 июня, забронировать участие.
1. Фундаментальный курс по всему, что есть в Agile: Scrum, Kanban, SAFe, LeSS
Cамый широкий по охвату тем тренинг, основной курс по гибким подходам, включающий Scrum, Kanban и обзор фреймворков масштабирования. Идеальная программа для тех, кто присоединился к scrum-команде или планирует перестроить работу своей команды.
Ближайшая группа на следующей неделе, 26 – 28 января. Забронировать участие.
Следующие группы 01-03 марта, 20-22 апреля, 18-20 мая, 20-24 июня
2. Продвинутый курс для Владельцев Продуктов
Углубленный курс по созданию, выводу на рынок и развитию продуктов в быстроменяющейся среде. Включая управление ожиданиями заказчиков, работу в agile-команде, проектирование и развитие продукта на основе глубокого понимания потребностей клиентов.
Ближайшие группы 09 – 11 февраля, 25-27 мая, забронировать участие.
3. Продвинутый курс для Скрам-мастеров
Лучший тренинг по отзывам 2021 года — продвинутый курс для Скрам-мастеров и всех, кому важны развитие команды, эффективное проведение командных встреч, командный коучинг и фасилитация.
Ближайшие группы 23-25 февраля, 27-29 апреля, забронировать участие.
4. Курс по управлению проектами в Agile
Менеджеры проектов выбирают тренинг Agile Project Management, в программе которого мы разбираем все аспекты современного подхода к управлению проектами в гибкой и гибридной среде, от дизайна проекта и оценки рисков до взаимодействия с подрядчиками.
Ближайшие группы 29 – 31 марта, 28-30 июня забронировать участие.
5. Курс по Agile для сотрудников HR
Специальный курс для HR-специалистов и руководителей HR департаментов — Agile в HR. Ранее доступный только для корпоративных клиентов тренинг теперь проходит в открытом формате. Разберем развитие HR-сервисов, мотивационной стратегии и организационной структуры компании на основе agile-практик, процесс найма и онбординга сотрудников.
Ближайшая группа 06 - 08 июня, забронировать участие.
Как расширить команду и не провалиться в организационный хаос?
В один прекрасный момент развития продукта или компании в целом команда перестает справляться с объемом задач, и тогда компания принимает решение масштабироваться.
Часто численность в течение года увеличивается вдвое, но некоторые наши клиенты вырастали даже в пять раз🚀 Впрочем, стрессом для компании становится и куда менее драматичный рост. И главный вопрос — как организовать все процессы так, чтобы получить желаемый результат и поскорее пройти этап "шторма".
В ближайших постах мы подробно поговорим о фреймворках масштабирования SAFe, LeSS и Nexus, о модели Spotify и других гибридных решениях.
Первая часть — ошибки, с которыми сталкиваются СЕО и СТО на старте увеличения численности — уже доступна в блоге: https://onagile.ru/trends/business-agility/scaling-the-company-part-1-growth-mistakes
С какими сложностями сталкивалась ваша команда при увеличении штата?
В один прекрасный момент развития продукта или компании в целом команда перестает справляться с объемом задач, и тогда компания принимает решение масштабироваться.
Часто численность в течение года увеличивается вдвое, но некоторые наши клиенты вырастали даже в пять раз🚀 Впрочем, стрессом для компании становится и куда менее драматичный рост. И главный вопрос — как организовать все процессы так, чтобы получить желаемый результат и поскорее пройти этап "шторма".
В ближайших постах мы подробно поговорим о фреймворках масштабирования SAFe, LeSS и Nexus, о модели Spotify и других гибридных решениях.
Первая часть — ошибки, с которыми сталкиваются СЕО и СТО на старте увеличения численности — уже доступна в блоге: https://onagile.ru/trends/business-agility/scaling-the-company-part-1-growth-mistakes
С какими сложностями сталкивалась ваша команда при увеличении штата?
На пути к «компании будущего»
Рост численности сотрудников и команд вынуждает компанию пересмотреть свою структуру.
SAFe — один из самых популярных фреймворков масштабирования — предлагает рассматривать организацию, как взаимодействие трех уровней:
1. Уровень портфеля
2. Уровень координации (или программы)
3. Уровень команды
Подробнее о структуре, ролях, которые появляются в SAFe, и их особенностях читайте в нашем блоге
Рост численности сотрудников и команд вынуждает компанию пересмотреть свою структуру.
SAFe — один из самых популярных фреймворков масштабирования — предлагает рассматривать организацию, как взаимодействие трех уровней:
1. Уровень портфеля
2. Уровень координации (или программы)
3. Уровень команды
Подробнее о структуре, ролях, которые появляются в SAFe, и их особенностях читайте в нашем блоге
OnAgile Consulting
Один из самых популярных фреймворков масштабирования организации — SAFe, или Scaled Agile Framework. Разбираемся, на чем он основан…
Как обеспечить развитие организации. Часть 2: Роли в SAFe 💎 — OnAgile Consulting
Друзья! Ищем себе в команду двух (пока двух) мобильных разработчиков, iOS и Android, уровня senior.
Мы (OnAgile и компания наш клиент) работаем над развитием европейского финтех продукта, сейчас масштабируемся по географии и объёмам клиентов/транзакций.
И нам очень нужно крутое мобильное приложение, которое будет радовать клиентов.
100% agile разработка (это не шутка). Недельные спринты, движение через гипотезы и их валидацию, максимально частые релизы и сбор обратной связи от клиентов.
Официальное оформление, соцпакет, работа онлайн (или офис, если вы в Москве и хотите выбраться из дома и поработать в тишине) и прочие прелести финтеха.
Если интересно, присылайте резюме и небольшой сопроводительный текст о себе вот сюда: dmitry@onagile.ru
Мы (OnAgile и компания наш клиент) работаем над развитием европейского финтех продукта, сейчас масштабируемся по географии и объёмам клиентов/транзакций.
И нам очень нужно крутое мобильное приложение, которое будет радовать клиентов.
100% agile разработка (это не шутка). Недельные спринты, движение через гипотезы и их валидацию, максимально частые релизы и сбор обратной связи от клиентов.
Официальное оформление, соцпакет, работа онлайн (или офис, если вы в Москве и хотите выбраться из дома и поработать в тишине) и прочие прелести финтеха.
Если интересно, присылайте резюме и небольшой сопроводительный текст о себе вот сюда: dmitry@onagile.ru
Разработка, основанная на данных
Известный факт, что лучшие решения принимаются на основе данных.
Так, например, разработка новых фичей продукта просто потому что попросил бизнес, даст качественно отличный результат от разработки, основанной на анализе ключевых метрик продукта.
Хочу порекомендовать отличный бесплатный инструмент, который мы последние полгода используем почти в каждом новом проекте - metabase.com
Ставится локально, умеет подключаться ко всем базам данных, к гугл аналитике и позволяет буквально парой кликов строить достаточно продвинутые отчеты. Для особо сложных случаев есть sql.
Например, что обычно смотрим мы:
- Данные по регистрациям новых клиентов, включая источники
- Основные показатели активности за день/месяц
- Возврат клиентов (retention) по когортам
- Эффективность рекламных каналов
- Отработка бэкофисных процессов (верификация, aml, anti-fraud)
В целом могу сказать, что на позиции Владельца продукта или любого человека кто отвечает за развитие бизнеса, работа с аналитикой в metabase - это около часа в день. На первых порах становления продукта - все три.
Зато в команду приносятся не фичи, а основанные на данных гипотезы. И если кто-то из стейкхолдеров говорит «точно нужно сделать вот это», утверждение можно легко проверить на валидность по имеющимся данным и не тратить на его реализацию время и силы.
Известный факт, что лучшие решения принимаются на основе данных.
Так, например, разработка новых фичей продукта просто потому что попросил бизнес, даст качественно отличный результат от разработки, основанной на анализе ключевых метрик продукта.
Хочу порекомендовать отличный бесплатный инструмент, который мы последние полгода используем почти в каждом новом проекте - metabase.com
Ставится локально, умеет подключаться ко всем базам данных, к гугл аналитике и позволяет буквально парой кликов строить достаточно продвинутые отчеты. Для особо сложных случаев есть sql.
Например, что обычно смотрим мы:
- Данные по регистрациям новых клиентов, включая источники
- Основные показатели активности за день/месяц
- Возврат клиентов (retention) по когортам
- Эффективность рекламных каналов
- Отработка бэкофисных процессов (верификация, aml, anti-fraud)
В целом могу сказать, что на позиции Владельца продукта или любого человека кто отвечает за развитие бизнеса, работа с аналитикой в metabase - это около часа в день. На первых порах становления продукта - все три.
Зато в команду приносятся не фичи, а основанные на данных гипотезы. И если кто-то из стейкхолдеров говорит «точно нужно сделать вот это», утверждение можно легко проверить на валидность по имеющимся данным и не тратить на его реализацию время и силы.