Получите все материалы с наших тренингов — бесплатно
Примеры Доски 🙂 Канбан — Примеры Канбан–систем
Примеры Доски 🙂 Канбан — Примеры Канбан–систем
Примеры Доски 🙂 Канбан — Примеры Канбан–систем

Канбан Доска — Пример Канбан–системы в 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, сделавшими его таким популярным. Штатные разработчики лучше знали, как сделать это. Изучение и адаптация к мобильному окружению было лёгкой частью задачи.

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

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

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

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

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

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

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

🦄
LeadStartup
Обучаем IT–предпринимателей и корпоративных инноваторов
Получите доступ к нашему Google-диску
Скачать модель

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🎓
Получите материалы наших тренингов — бесплатно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

📚️
Получите доступ к Google-диску
Скачать модель
Получите таблицу расчета юнит–экономики и долей стартапа, а также базу Excel–таблиц для продактов
Скачать модель

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

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

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

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

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

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

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

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

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

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

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

канбан доска

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

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

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

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

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

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

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

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

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

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

⭐️
Digital Transformation Officer
Обучение управлению цифровизацией бизнес–моделей корпоративных продуктов
Corporate Innovation Pipeline Customer Development Методология «Lean Startup»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

💎
Получите таблицу расчета юнит–экономики стартапа
Excel–таблицы для продактов Шаблоны и чек–листы Руководства по использованию

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

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

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

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

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

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

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

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

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

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

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

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

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

🎓
Получите материалы наших тренингов — бесплатно

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

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

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

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

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

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

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

Программы обучения всех тренингов LeadStartup, упакованные в единый цифровой курс. Доступно на ПК, в App Store и Google Play.
  • Это не обычный курс с теорией, а симулятор решения реальных управленческих задач в крупных компаниях и стартапах.
  • Обучаем с нуля до позиции Chief Product Owner — вы станете тем, кто отвечает за прибыльность новых бизнес–направлений.
  • Обучаем с нуля до позиций Scrum Master и Agile Coach — руководителей нового типа, с помощью в получении международного сертификата по окончанию курса.
  • Обучаем компетенциям Chief Executive Officer — вы поймете как вывести на рынок собственный продукт, без бюджета на запуск.
Стоимость 3 000 рублей
Содержание 14 модулей, 172 задачи
Сертификация от LeadStartup и международных организаций Lean Startup Professional, Certified Agile Professional. По желанию — PSM I и Management 3.0
Обучение цифровизации корпоративных бизнес–моделей
  • Внедрение digital-инструментов с фокусом на возврат инвестиций
  • Аналитика экономической эффективности внедренных инструментов
  • Методология внедрения инноваций в компаниях
  • Сокращение производственных и операционных издержек
  • Кейсы успешной реализации DT в IT, банках, E-commerce и производстве
  • Экономика трансформации, модель расчета
  • Пошаговый план внедрения digital-инструмента с фокусом на ROI
  • Бережливая разработка внутренних корпоративных продуктов
  • Big-data и AI
Стоимость 14 700 рублей
Дата проведения 7 сентября
Время проведения с 10 до 18 часов
Свободные места 5 из 5 человек
Формат тренинга Онлайн
🌟 Освоите методологию роста трафика, активаций и конверсий в продажи.
  • Метрики быстрого роста стартапа, roadmap быстрого роста
  • Методологии поиска точек кратного роста
  • Бережливый маркетинг со страховкой от потерь бюджета
  • Чек-лист маркетинговой стратегии вашей компании
  • Фреймворки быстрой проверки гипотез
  • Growth Hacking Product Launch - тестирование до этапа разработки
  • Принцип Fail Fast - как не бояться совершать провалы и извлекать из них пользу
  • Кросс-инструментарий: аналитика, perfomance, digital-трансформация
  • Запуск, коучинг и формирование команды роста внутри комании
Стоимость 13 650 рублей
Дата проведения 9 сентября
Время проведения с 10 до 18 часов
Свободные места 5 из 5 человек
Формат тренинга Онлайн
💎 Подготовите бизнес–модель, экономику и презентацию идеи нового бизнес–направления.
  • Создание прототипа продукта (Lean Canvas, модель Остервальдера) с нуля
  • Расчет юнит-экономики будущего продукта - разбор бизнес-модели через цифры?
  • Принятие решений на основе данных - что делать дальше и почему?
  • Тестирование продуктового спроса через "Get Out of the Building"
  • Customer Development - практика клиентских интервью онлайн
  • Продуктовые гипотезы и Impact Mapping
  • ADCDX-сегментация клиентов - принцип поведенческого разделения клиентов
  • Когортный анализ - аналитическая с данных о пользователях и клиентах
  • PIVOT - быстрая смена бизнес модели, примеры кейсов
Стоимость 13 650 рублей
Дата проведения 11 сентября
Время проведения с 10 до 18 часов
Свободные места 5 из 5 человек
Формат тренинга Онлайн
🏄‍♂️ Научитесь проводить внедрение, а также получите международный сертификат PSM.
  • История появления Agile майндсета / Agile-манифест
  • Scrum как самая наглядная модель работы Agile команды
  • Ритуалы в Scrum, правила проведения, сложности соблюдения и удержания
  • Сокращение сроков поставки продуктов и его инкрементов на рынок (Time-to-Market)
  • Увеличение ценности разработки для клиентов
  • Кроссфункциональность команды, правила подбора участников
  • Фасилитация мероприятий, инструменты и методологии фасилитатора
  • Мотивация команд, отстройка от привязки к финансовым ценностям
  • Игры и практики, способы развития и коучинга команд
Стоимость 13 650 рублей
Дата проведения 14 сентября
Время проведения с 10 до 18 часов
Свободные места 5 из 5 человек
Формат тренинга Онлайн
💳 Сделаете первые продажи у вашего стартапа, используя бесплатные онлайн–каналы. С нуля.
  • Вы будете учиться создавать продукты, которые покупают
  • Вы получите собственные кейсы по бережливому запуску новых продуктов
  • CEO–Level мышление — прибыль, последствия, возврат инвестиций
  • Качество обучения — как для крупных компаний
  • Сертификация навыков — Lean Startup Professional
  • Тренера — управляющие партнеры LeadStartup
Стоимость 13 650 рублей
Дата проведения 16 сентября
Время проведения с 10 до 18 часов
Свободные места 5 из 5 человек
Формат тренинга Онлайн
Научитесь подбирать наилучший Agile-фреймворк для работы вашей команды и быстро запускать его в работу
  • Agile Manifesto - основа майндсета: зачем и как он появился
  • Фреймворки Agile (Scrum, Kanban, XP, Lean Startup, OKR), основы и различия
  • Business Agility: критерии гибкости продуктовой команды
  • Agile-планирование в условиях крайней неопределенности
  • Ключевые ритуалы каждого фреймворка / Scrum как MVP Agile
  • Трансформация корпоративной культуры посредством гибкости мышления
  • Базовые навыки проведения ретроспектив для улучшения процесса
  • Построение карьеры в Agile команде: какую роль выбрать, как расти
  • Планирование, оценка, критерии готовности, User Story, Story Points
Стоимость 13 650 рублей
Дата проведения 18 сентября
Время проведения с 10 до 18 часов
Свободные места 5 из 5 человек
Формат тренинга Онлайн
Корпоративный абонемент
📑 На протяжении года вы сможете посещать любые тренинги LeadStartup, в любое время.
Приобрести абонемент
Стоимость 59 600 рублей
Максимум тренингов 7
Форматы тренингов Любые
Доступ к приложению Да
Возможность замены участника Да
Бесплатные места на тренингах
Даем возможность участвовать бесплатно, при наличии невыкупленных мест на тренингах.
Возможность доступна при соблюдении хотя бы одного из следующих условий:
1. Вы участвовали в любом тренинге LeadStartup или приобрели доступ к нашему приложению
2. Опубликовали авторскую статью в базу знаний
3. Участвовали в наших корпоративных тренингах, или являетесь нашим клиентом
4. Вы с нами запартнерились в любом виде :)