Ответим в течение 30 минут — contact@leadstartup.ru
+7 495 150 42 63 — с 8:00 до 21:00 МСК
Получите все материалы с наших тренингов — бесплатно
Примеры Доски 🙂 Канбан — Примеры Канбан–систем
Примеры Доски 🙂 Канбан — Примеры Канбан–систем
Примеры Доски 🙂 Канбан — Примеры Канбан–систем

Канбан Доска — Пример Канбан–системы в IT Разработке

Из этой статьи вы узнаете больше читать о Канбан-методе на примере компании–разработчика IT–продукта.

Мастер–классы по современному менеджменту и запуску стартапов

Как запустить первую канбан–доску

Хольгер начал работать в берлинской компании mobile.de в 2007 году в качестве фрилансера, затем перешел в штат. Интернет платформа насчитывает миллион предложений на автомобили как частных владельцев, так и дилеров.

Сервис используется преимущественно в Германии, а также во многих других странах Центральной и Восточной Европы. Нагрузка достигает до 2000 запросов в секунду. Сервис основан в 1996 году и куплен eBay.

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

Из–за предстоящего сложного реинжиниринга, немецкая консалтинговая компания IT-Agile посоветовала использовать гибкие подходы, такие как Скрам.

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

В поисках решения этих проблем, в последующие годы в дополнение к Скраму были применены практики из Канбан Метода. С помощью внешних тренеров из IT-Agile были внедрены практики визуализации интеллектуальной работы и запуска эволюционных изменений в процессах, чтобы сделать их плавнее — как на уровне команды, так и на уровне управления портфелем проектов.

канбан доска

К 2010 году Ральф и остальные менеджеры высшего звена, уже переработав web версию, решили расширить свои услуги для сегмента мобильных пользователей. В то время для создания приложения было целесообразнее нанять опытное внешнее агентство, вместо создания команды из собственных разработчиков, так как пришлось бы тратить время на изучение платформы.

В 2010 году iPhone от Apple и их мобильный App Store были самыми продвинутыми на рынке, поэтому выбор iOS как базы для приложения был очевиден.

«При наличии сомнений относительно дизайна и удобства продукта, реализованного агентством, мы все равно решили выложить его в Apple App Store. Хотелось посмотреть, будет ли спрос. Мы не понимали, насколько слабо наше приложение», — вспоминает Ральф.

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

«Семь миллионов человек используют mobile.de. Пришлось столкнуться с тем фактом, что многие из них теперь хотели искать свою следующую машину на мобильных устройствах. Чтобы клиенты продолжали использовать mobile.de, мы должны были создавать беспроблемный опыт использования нашего приложения», — вспоминает Ральф.

Мобильное приложение должно было сохранить дух и философию mobile.de, сделавшими его таким популярным. Штатные разработчики лучше знали, как сделать это. Изучение и адаптация к мобильному окружению было лёгкой частью задачи.

«Мы поняли, что единственный шанс для появления хорошего мобильного приложения — это если команда будет создана и воспитана в внутри, с одним этим приоритетом в головах», — объясняет Ральф.

В то время Хольгер работал программистом в другой команде. На протяжении многих лет он проявлял интерес к Канбан Методу. Работая в Скрам–команде, он замечал другие команды, которые визуализировали работу на досках, называемых Канбан досками.

Эти доски делились на столбцы, представлявшие собой отдельные этапы процесса, через которые проходили рабочие элементы, начиная с очереди и готовности к разработке, до релиза и развертывания.

Рабочие элементы записывали на цветных стикерах и клеили на доске. Хольгер видел, как коллеги из других команд посещали статусные встречи каждое утро. Он слышал, как обсуждали задачи, особенно те, которые двигались с трудностями.

Он заметил интересную вещь: процесс постоянно эволюционировал. Имена столбцов, количество задач на столбец, модераторы и присутствующие на этих ежедневных встречах люди — ничто не было постоянным. Ему была по нраву такая свобода. Коллеги подтвердили, что с каждым изменением процесс становился только лучше. Удивляло, что даже для таких внешних людей, как он, эти изменения были заметны.

Так происходило благодаря присущей Канбану прозрачности, дающей подробное понимание происходящего. Хольгер начал больше читать о Канбан–методе и обратил внимание на еще один аспект: Некоторые эксперты утверждали, что оценка задач может не требоваться.

Выполнение задач в надежном и постоянном потоке казалась гораздо важнее, чем их оценка. Сколько на самом деле времени будет потрачено, зависело от измерений в реальном времени. Он пытался убедить руководство попробовать этот подход на своей команде, но те не соглашались, полагая, что это противоречит принципам Скрама.

🎓
Получите материалы наших тренингов — бесплатно
Получите доступ к нашему Google–диску — бесплатно
Скачать модель

3 важных аспекта формирования системы Канбан

Мобильная команда разработчиков была собрана в 2011 году. Хольгера назначили руководителем. Первоначально было два разработчика, тестировщик и владелец продукта. «У всех нас был опыт в создании сайтов электронной коммерции с высокой нагрузкой. Но мы мало знали о том, как создавать мобильные приложения, и понимали, что в любом случае столкнемся с ловушками и проблемами на пути.

Мы могли бы потратить первые месяцы на обдумывание идей и проработку решений, но такая подготовка выглядела как пустая трата времени», — вспоминает Хольгер Проект имел стратегическое значение не только с экономической точки зрения, но и с точки зрения подтверждения способности mobile.de быть инновационной и быстро развивающейся компанией. Команда должна была стартовать разработку незамедлительно.

 пример канбан доски

Чтобы организовать работу, решили положиться на Канбан Метод. Команда верила, что правильный процесс будет построен благодаря прозрачности — визуализации невидимой работы и процесса. Прозрачность также поможет в выявлении и устранении блокирующих проблем.

«Я верил, что мы способны создавать мобильные приложения без слишком большого количества заранее заготовленных планов и документации. Для меня они выглядели как ограничения и лишняя нагрузка, так что мы убрали на первом этапе», — говорит Хольгер.

Коммуникации, вплетенные в Канбан — ежедневные статусные встречи, сессии планирования и последующие ретроспективы — дадут возможность для быстрого решения проблем, связанных с технологиями или процессами.

«Это был наш шанс поэкспериментировать с Канбаном, и мы им воспользовались», — говорит Хольгер.

Такой подход имел свои риски. Хольгер и команда были готовы взять на себя ответственность за них. Вопрос был в том, согласятся ли вышестоящие менеджеры? Проекты в mobile.de обычно выполнялись с четкими вехами и отчетностью по расходованию ресурсов.

Предыдущие внедрения Канбан–Метода улучшали поставку, но они шли поверх существующих релизных циклов и процессов. Мобильная команда была первой, кто начал с нуля с Канбан. Они настаивали, чтобы не было ни итераций, ни оценок, ни сроков: просто постоянный поток работ, коммуникаций, обучения и поставки.

«Для этого потребовался прыжок веры, что эта команда без нужного опыта, добьется успеха с самого начала, без метрик, чтобы привлечь к ответственности, используя только Канбан–доску», — говорит Ральф.

Команда взяла на себя обязательство экспериментировать с разными решениями каждой из проблем проектирования и архитектуры, с которыми сталкивались, пока не найдут наилучшее решение.

Для непрерывности и устойчивости потока, задачи дробились так, чтобы с одной̆ стороны их разработки занимала до двух дней на реализацию, с другой стороны чтобы их можно было включать в релиз для пользователей. На доске команды было всего два столбца: Запланировано и В работе.

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

В первый год сфокусированная команда решила много проблем например, какой бэкэнд–движок будет управлять будущими мобильными приложениями и использовать ли существующие API. Еще сохранялось горькое послевкусие низких рейтингов первой̆ версии приложения на iOS, теперь все технические решения должны быть безупречными.

В такой маленькой команде было легко держать фокус, обсуждать и принимать решения.

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

В течение нескольких месяцев был разработан слой бизнес логики.

Как бы ни пыталась команда c помощью разработчиков из IT-Agile спасти iOS приложение, стало понятно, что его нужно переписывать с нуля, чтобы сделать удобным, стабильным и обслуживаемым в долгосрочной перспективе.

Часть команды взялась за переписывание iOS приложения, и спустя немногим более года после старта, у многих владельцев айфонов в Германии появился удобный способ найти себе следующий автомобиль. Но усилия были далеко не окончены: были и другие ОС для мобильных устройств.

📚️
Получите доступ к нашему Google-диску — бесплатно
Скачать модель
Получите таблицу расчета Юнит–Экономики
Скачать модель

Как использовать визуализацию задач на доске

«Вы действительно думаете, что этой функциональности достаточно, чтобы выпустить Android приложение?»

Унизительный вопрос представителей бизнеса застал Хольгера врасплох. К 2012 году ОС Android уже набрала внушительную динамику на рынке. Все больше производителей смартфонов использовали ее, база пользователей была значительной.

Разрабатывать на Android был логичный шаг, поэтому в команду было добавлено больше разработчиков. Им дали время изучать среду разработки Android, пока формулировали и добавляли на доску пользовательские истории.

 пример канбан системы

Итак, когда команда показали бизнес заказчиком то, что считали законченной первой версией Android приложения, они были ошеломлены отрицательной обратной связью.

«Но вы все время могли наблюдать за тем, что мы разрабатывали, и не говорили, что этого недостаточно, — возмущался Хольгер.

С самого начала команда старалась избегать ярлыка «проект». Проект подразумевал планы, документы и фиксированные ожидания. Все это было ненужной тратой в системе, главной целью которой, в конце концов, было создание работающего мобильного приложения.

В команде полагали, что пользовательская история в тикете с полями «кто», «что» и «почему» описывает требования в простой и сжатой̆ форме, что это должно быть понятно всем. Не было необходимости в дополнительном слое управления.

Теперь они впервые начали сомневаться в своих установках. Команда столкнулась с блокером в процессе, и это был не простой розовый стикер вроде отсутствующих требований.

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

После нескольких обсуждений, кристаллизовалось новое определение первой версии Android приложения. Недостающие функции, как обычно, записали в форме пользовательских историй на стикерах.

Но все хотели убедиться, что такие недоразумения в будущем не возникнут. Увеличение количества встреч и детальных планов, конечно, не подходили в отрасли непрерывно меняющихся технологий.

В поисках ответа Хольгер отправился на Канбан доску. Он смотрел на столбцы, на массу цветных стикеров в них, и размышляя о решении. Вспомнил, как с любопытством изучал Канбан–доски других команд.

И тогда его озарило. Все, над чем работала команда, было на доске; ничего не было спрятано. Но постороннему человеку эта информация непонятна. Пользовательские истории сами по себе были достаточно маленького размера, чтобы создать устойчивый поток, которого хотелось.

Но не достаточно большими, чтобы человек извне мог понять, над чем работала команда. В стремлении к созданию потока работ и устойчивого процесса Хольгер пожертвовал контекстом. У команды не было шанса получать своевременную обратную связь о ключевых функциях Android–приложения или о чем–либо еще, потому что представители бизнеса не понимали, что происходит.

Вскоре было введено понятие «Эпик», и для него было обозначено место на доске (рис. 1). Эпик представлял собой набор функций, связанных одной идеей, и назывался таким образом, чтобы каждый понимал, что это такое. При формулировании эпиков команда старалась сделать так, чтобы разработка занимала не более двух–трех недель.

Пользовательские истории в нем по–прежнему были написаны на языке разработчиков, например «Поле ввода для первой даты регистрации», но Эпик будет называться, например, «Создать форму для вставки автомобиля частными клиентами» — это язык, который понятен каждому в компании.

«Изначально придумали это, чтобы помочь руководству понять, что делаем, но со временем эпики помогли придумать, как управлять и ожиданиями», — говорит Хольгер.

В конце концов, эпики доказали возможность команды контролировать объем незавершённой работы и многозадачность — правило состояло в том, что разработчик Работает над пользовательскими историями только в контексте одного эпика. Кроме того, эпик стал метрикой успеха и способом оценки возврата инвестиций, поскольку представлял собой осязаемое улучшение продукта

Обучение цифровизации корпоративных бизнес–моделей
  • Это не обычный курс с теорией, а симулятор решения реальных управленческих задач в крупных компаниях и стартапах.
  • Обучаем с нуля до позиции Chief Product Owner — вы станете тем, кто отвечает за прибыльность новых бизнес–направлений.
  • Обучаем с нуля до позиций Scrum Master и Agile Coach — руководителей нового типа, с помощью в получении международного сертификата по окончанию курса.
  • Обучаем компетенциям Chief Executive Officer — вы поймете как вывести на рынок собственный продукт, без бюджета на запуск.
Стоимость 2 999 рублей
Содержание 14 модулей, 172 задачи
Сертификация от LeadStartup и международных организаций Lean Startup Professional, Certified Agile Professional. По желанию — PSM I и Management 3.0

Как использовать канбан–доску для непрерывных улучшений

«Вы должны чувствовать боль от проблемы и работать над ее решением».

Это направление ознаменовало первые месяцы пребывания Торстена на mobile.de. Будучи Фронтенд разработчиком, он был первым специалистом в разработке для мобильных устройств, начавшим работать в команде.

«Я пришел из рекламных агентств и стартапов, и привык к идее продуктивности. Если что–то блокировало мою текущую задачу, я откладывал ее и переходил к следующей в списке», — говорит Торстен.

Естественно, это привело к привычке работать над несколькими задачами одновременно, некоторые из которых забывались в суете бурной деятельности.

«В первые месяцы мне было очень сложно сосредоточиться только на одной пользовательской истории, особенно, когда она заблокирована. Трудно было побороть желание нарушить это правило», — говорит Торстен.

Предыдущий опыт Торстена мешал на пути адаптации к принципу не оставлять позади незавершенных задач. Будучи из мира, в котором использовалась традиционная модель разработки программного обеспечения (SDLC), он привык к поэтапному проходу через этапы жизненного цикла продукта: сначала будет закончен фреймворк, затем пользовательский интерфейс; после этого будут добавлены функциональные возможности, и, в конце концов, все это будет интегрировано с серверной частью.

«В mobile.de мы с товарищами по команде работали над одной функциональностью, добиваясь, чтобы она работала, прежде чем перейти к следующей», — вспоминает Торстен.

По мере расширения мобильной команды, отслеживать фичи и приложения в разработке становилось сложнее чем в начале.

Без общей картины работать с блокерами высокого приоритета становилось труднее. Как бы хорошо ни звучала разработка в потоке, эпик за эпиком, людям для мотивации важно было чувство направленности и понимания, чего ожидать в будущем.

Хольгер снова пошел за ответами к Канбан доске. Проблему решили во время встречи команды.

канбан доска

«Что нам нужно сделать, чтобы стать лучше?» — спросил он. «Было бы полезно видеть, куда мы идем, на уровне с эпиками и пользовательскими историями», — таков был ответ.

Вскоре после этого появилось "Видение" — колонка концептуальной фазы более высокого уровня. К тому времени у команды уже был третий пул задач, на котором она фокусировала внимание: мобильный веб–браузер.

У каждого из этих доменов было свое видение, потому что он находился на разной стадии разработки. Стало очевидно, что общую доску нужно было разделить на три отдельные Канбан доски.

На досках была колонка Vision Ongoing, которая отображала фазу предварительного планирования. К тому времени у команды уже появился первый владелец продукта, определивший создание видения как свою зону ответственности.

Только тикеты размера эпиков помещались в столбец Vision Ongoing, и после тщательной оценки владельцем продукта перемещались в колонку Vision Done. Оттуда они будут перемещены в колонку Epic, когда откроется слот.

Колонка Vision помогла Торстену придерживаться пользовательских историй, но также и постоянно коммуницировать.

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

Медленно меняя привычки, он увидел плоды своей работы с Канбан системой – он мог получить то, что нужно гораздо раньше. Ему не нужно было ждать шесть месяцев, чтобы продукт был полностью реализован и выпущен. Создание продукта таким бережливым способом, фича за фичей, сделало приложения более стабильными в долгосрочной перспективе.

Из–за хрупкой природы мобильных приложений и вебсайтов Торстен часто расстраивался из–за сбоев в продуктах после изменений или рефакторинга кода.

«Понимая, что могу добавить функцию без шансов сломать продукт, я чувствовал больше стимула довести задачу до конца, даже если меня блокировали».

Как ретроспективы помогают улучшать Канбан–систему

«У нас всегда была проблема — разработчиков больше, чем специалистов по тестированию. Когда соотношение достигло двенадцати к одному, у нас начались проблемы» — вспоминает Хольгер.

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

Разработчики привыкли передавать свои пользовательские истории в QA для тестирования, но вскоре поток был прерван, и команда больше не добивалась желаемого непрерывного развертывания. Вопрос был поставлен так: нужно ли стремиться к большему количеству инженеров по тестированию, чтобы команда могла продолжать работать как раньше, или к каким–то другим изменениям?

«На ретроспективе мы поговорили о нашем понимании роли QA», — говорит Хольгер.

Ретроспективы доказали, что являются ценным источником для решения проблем, мешающих команде. На них людям приходится думать о трудностях и принимать решения. Во время последующих ретроспектив, команда начала переосмысливать набрасывание работы на одного QA парня.

Насколько это было оправдано? Разработчики были авторами кода, как они могли помочь устранить это узкое горлышко? Когда команда размышляла над этими вопросами, согласились, что нужны радикальные изменения.

И это произошло — понемногу Харальд, тестировщик, начал Рассказывать команде о том, как они сами могли бы больше тестировать и, следовательно, нуждаться в меньшей проверке качества.

Он поделился с командой практиками для самостоятельного тестирования собственной работы.

«Тест–кейсы — это не то, что я мог бы написать как фронтенд разработчик. Не знаю соответствующего языка программирования. Но наш QA создал фреймворки, которые сильно упростили написание тестов. Используя их, я сразу понимаю, хорошо ли реализовал свою фичу», — заметил Торстен.

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

Со временем развилось чувство ответственности разработчиками за качество своего кода. Всякий раз, когда разработчики не могли выполнить тест, они активно сотрудничали с тестировщиками из других команд.

Это эволюционное изменение роли QA помогло вернуть поток в прежнее состояние. Оглядываясь назад, ретроспективы позволили решить многие проблемы, с которыми сталкивались мобильные команды.

Качество ежедневных статусных встреч ухудшилось после увеличения размера команды. Без правил эти встречи зачастую были хаотичны и расфокусированы, иногда уходя в отдаленные от разработки темы.

После того, как проблема с неэффективными ежедневными встречами поднималась в течение нескольких ретроспектив, были введены новые правила. Единственные люди, которым было разрешено говорить во время дейли — разработчики.

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

Как соотносится Канбан и бережливый стартап

«Следующим проектом должно стать iOS приложение mobile.de для автодилеров», — сказали однажды представители бизнеса.

Это был февраль 2013 года. Команда скептически отнеслась к тому, что такая потребность существует. В то время у команды мобильной разработки уже были приложения для iOS, iPhone и iPad, а также приложения для Android на немецком и английском языках.

«Мы уверены, что дилерам нужен серис для отслеживания товарных запасов», — продолжали напирать руководители.

К тому времени две трети автодилеров в Германии пользовались mobile.de. Процесс разработки в мобильной команде стабилизировался, и у Хольгера стало больше времени, чтобы сосредоточиться на других вопросах.

Например, почитать книгу Lean Startup, которую он и его коллеги получили от mobile.de. Он впечатлился идеей для ранней проверки гипотез о потребностях клиентов. Сделать это было просто — создать минимально возможное решение, способное функционировать как жизнеспособный продукт: минимальный жизнеспособный продукт (MVP).

Этот MVP должен быть выведен в поля для тестирования с представителями целевой аудитории, даже если версия приложения для iOS 7 уже на доске команды iOS, даже если много дефектов. Смысл теста в том, чтобы узнать, насколько приложение ценно и интересно целевым пользователям.

Вместо того чтобы спорить с коллегами из бизнеса, отдел разработки продукта выделил бюджет и время на поездку во Франкфурт, для проверки предложенного нового приложения и жизнеспособности бизнес–модели.

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

Они знали, что этого временного отрезка будет достаточно для необходимых итераций, чтобы создать MVP на месте. Они разделили каждый день на четыре итерации и каждый раз представляли улучшенную версию, основываясь на отзывах, которые получали от предыдущей итерации.

Через два дня была создана кликабельная пустышка. После еще нескольких итераций и поворотных моментов стало ясно, что они нашли ценные функции, но, скорее всего, бизнес–модель не будет работать.

За эти четыре дня участники получили так много ценных отзывов о существующем приложении, что вернулись в Берлин с «полным багажником» пользовательских историй. Вдохновленные этим опытом, члены команды Ларс и Макс (владелец продукта и архитектор взаимодействия, соответственно) начали проводить регулярные эксперименты по валидации. Например, раз в неделю Макс берет свой ноутбук и работает в разных кафе Берлина. Там он разговаривает с незнакомцами и просит их поиграть с прототипом.

Быстрая обратная связь с пользователем, правильные метрики и проверка функций в корне изменили способ, которым команда разрабатывает продукты.

Финальный результат использования Канбан–доски

в 2013 году, через три года после создания первого мобильного приложения, разработчики изучили не только мобильную технологию, но и смогли сосредоточиться на экспериментах со своими идеями и наблюдением за реакциями пользователей.

 пример канбан доски

Исследование того, чего хотят люди, стало движущей силой на этапе генераций идей в процессе. Плоский дизайн iOS 7 — один из следующих вызовов.

«Мы хотим выяснить, можем ли разрабатывать новый, плоский вид нашего приложения итеративно, не дожидаясь взрыва от полного редизайна. Это создаст отсутствие визуальной консистентности, к которому пользователи могут быть не толерантны некоторое время, но это даст представление о том, что пользователи хотят видеть и использовать. Риски того стоят», — говорит Ральф.

Он усвоил урок, полученный три года назад, и хочет убедиться в том, что новое приложение — прекрасный актер на мобильной сцене, где в настоящее время миллион других приложений ищут время и внимание со стороны мобильных пользователей.

Он чувствует себя в безопасности, потому что теперь знает, чего ожидать от команды. С принципами и практиками Канбан Метода, применяемыми мобильной командой, следующая крутая фича — вопрос лишь пары экспериментов.

Количество отзывов (рецензий) 7
Средний рейтинг рецензии 4
Вы научитесь управлять запуском цифровых инноваций и выступать в роли бизнес–трекера для внутренних стартапов.
27 октября
19 530 рублей Скидка -7%
30 ноября
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы научитесь проводить глубинные интервью для поиска сильнейших инсайтов по развитию вашего продукта.
28 октября
19 530 рублей Скидка -7%
4 декабря
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы научитесь визуализировать клиентский опыт взаимодействия с компанией, учитывая мысли, цели и задачи клиента через CJM.
29 октября
19 530 рублей Скидка -7%
7 декабря
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы освоите методологию дизайн–мышления и научитесь использовать дизайн-мышление для поиска прорывных идей.
30 октября
19 530 рублей Скидка -7%
8 декабря
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы освоите методологию развития аналитической культуры в корпорациях для достижения целей цифровой трансформации.
2 ноября
18 900 рублей Скидка -10%
9 декабря
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Обучение эмоциональному интеллекту — способ обновить и оживить корпоративную культуру компании.
3 ноября
18 900 рублей Скидка -10%
10 декабря
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы освоите методологию Growth Hacking — быстрого тестирования гипотез для кратного роста по прибыли.
6 ноября
18 900 рублей Скидка -10%
11 декабря
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Обучитесь Agile-инструментам влияния на выживаемость бизнеса в условиях крайней неопределенности.
6 ноября
18 900 рублей Скидка -10%
25 января
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы научитесь проводить интервью и исследования по методологии Jobs To Be Done для валидации идей роста.
9 ноября
16 800 рублей Скидка -20%
14 декабря
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы научитесь применять навыки Ситуационного Лидерства для развития самоорганизации на уровнях команд и организаций.
10 ноября
16 800 рублей Скидка -20%
15 декабря
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы научитесь проектировать Канбан–системы и работать с Канбан–доской в рамках продуктовой и проектной работы.
11 ноября
16 800 рублей Скидка -20%
16 декабря
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы научитесь управлять продуктовой стратегией и совместно со стейкходерами формировать дорожную карту развития продукта.
12 ноября
16 800 рублей Скидка -20%
17 декабря
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы научитесь радикально повышать вероятность выхода на положительную рентабельность новых бизнес–направлений.
13 ноября
16 800 рублей Скидка -20%
18 декабря
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы научитесь проводить оценку целесообразности запуска нового цифрового продукта или бизнес–направления.
16 ноября
15 960 рублей Скидка -24%
22 декабря
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы научитесь формировать амбициозные, значимые для бизнеса OKR–цели и совместно с сотрудниками достигать их.
17 ноября
15 960 рублей Скидка -24%
24 декабря
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы научитесь использовать сервис продуктовой аналитики Amplitude для нахождения точек роста прибыли продукта.
18 ноября
15 960 рублей Скидка -24%
23 декабря
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы освоите роль Владельца Продукта в Scrum, научитесь приоритизировать задачи и максимизировать бизнес–ценность.
19 ноября
15 960 рублей Скидка -24%
25 декабря
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы освоите все мероприятия, роли и артефакты фреймворка Scrum, и сможете применить Scrum на практике в своем отделе.
20 ноября
15 960 рублей Скидка -24%
21 декабря
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы научитесь вести Scrum–команды к самоорганизации и высокой продуктивности, с получением сертификации PSM I.
23 ноября
14 910 рублей Скидка -29%
20 января
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы научитесь использовать безбюджетный маркетинг и сделаете первые продажи вашего продукта или идеи прямо на тренинге.
24 ноября
14 910 рублей Скидка -29%
21 января
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы научитесь определять точки кратного роста прибыли и обоснованно принимать решение где сфокусировать усилия.
25 ноября
14 910 рублей Скидка -29%
15 января
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы научитесь применять фреймворк LeSS для объединения нескольких Agile–команд при работе над продуктом.
26 ноября
14 910 рублей Скидка -29%
19 января
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы научитесь применять фреймворк SAFe для объединения нескольких Agile–команд при работе над продуктом.
27 ноября
14 910 рублей Скидка -29%
18 января
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы научитесь масштабировать Agile–мышление на уровень всей корпорации и взаимодействовать с ТОП–менеджментом.
1 декабря
14 910 рублей Скидка -29%
22 января
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы научитесь управлять Scrum–командами, создавать Kanban–системы и руководить внедрением Agile фреймворков.
2 декабря
14 910 рублей Скидка -29%
26 января
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%
Вы научитесь создавать бизнес–модели цифровых продуктов и защищать их на презентации перед ТОП–менеджментом.
3 декабря
14 910 рублей Скидка -29%
27 января
14 490 рублей Скидка -31%
Онлайн–курс Digital–курс
2 999 рублей Скидка -80%