Друзья! Ищем себе в команду двух (пока двух) мобильных разработчиков, iOS и Android, уровня senior.

Мы (OnAgile и компания наш клиент) работаем над развитием европейского финтех продукта, сейчас масштабируемся по географии и объёмам клиентов/транзакций.

И нам очень нужно крутое мобильное приложение, которое будет радовать клиентов.

100% agile разработка (это не шутка). Недельные спринты, движение через гипотезы и их валидацию, максимально частые релизы и сбор обратной связи от клиентов.

Официальное оформление, соцпакет, работа онлайн (или офис, если вы в Москве и хотите выбраться из дома и поработать в тишине) и прочие прелести финтеха.

Если интересно, присылайте резюме и небольшой сопроводительный текст о себе вот сюда: dmitry@onagile.ru

Разработка, основанная на данных

Известный факт, что лучшие решения принимаются на основе данных.

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

Хочу порекомендовать отличный бесплатный инструмент, который мы последние полгода используем почти в каждом новом проекте - metabase.com

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

Например, что обычно смотрим мы:
- Данные по регистрациям новых клиентов, включая источники
- Основные показатели активности за день/месяц
- Возврат клиентов (retention) по когортам
- Эффективность рекламных каналов
- Отработка бэкофисных процессов (верификация, aml, anti-fraud)

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

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

Agile-коуч: нанимать или нет?

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

Но это гиганты рынка с их ресурсами. А как поступить компании среднего размера или небольшому стартапу?

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

Друзья!

События в мире не смогли обойти и Agile сообщество. Хотя в это трудно поверить.
Один из сертификационных центров, Scrum.org, приостановил работу с Россией по проведению тренингов и выдаче сертификатов.

На сегодняшний день это не затронуло нашу сертификацию от ICAgile.

Все тренинги из нашего расписания актуальны (https://onagile.ru/trainings) и будут проведены в указанные даты.

Даже если временно ограничат выдачу сертификатов, мы заранее оповестим всех участников и найдём решение.
Ведь главное - это знания, которые помогут вам в карьерном росте и повышении дохода.

Так же, мы по-прежнему проводим обучение в корпоративном формате, без изменений.

Ждём вас на ближайших тренингах!

Команда OnAgile

Кто еще нужен в SAFe?

Продолжаем серию постов о расширении компании с помощью фрейворка SAFe.

Для организации слаженной работы нескольких команд в SAFe есть специальные люди: Release Train Engineer ("Машинист"), Архитектор решения и Системный архитектор.

Узнать подробнее об этих ролях

Как стать Скрам мастером в 2022 году

Получаем много вопросов о том, как сейчас найти первую работу в роли Скрам мастера: чему учиться? пригодится ли предыдущий опыт? как пройти собеседование?

Собрали ответы на основные вопросы в пост: опытные Scrum-мастера это знают, а новичкам будет полезно.

Чек-лист запуска продукта

Поиск новых сервисов и ИТ-инфраструктуры взамен временно недоступных показал, что у многих продуктов аналогов нет или они серьезно не дотягивают до лидеров рынка. И пока пользователи адаптируются к новым условиям, разработчики и предприниматели готовятся заполнить опустевшие ниши.

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

✅ Формирование гипотез. Какими бы логичными ни были наши представления о новом продукте/фиче, они должны быть подкреплены реальными данными: исследованиями по схеме “боль — решения”, результатами проблемного интервью, фреймворком Jobs to be done.

✅ Валидация гипотез. До начала работы над продуктом каждая гипотеза должны быть провалидирована. Важно научиться тестировать гипотезы быстро и дешево, чтобы не застревать на этом этапе и сэкономить ресурсы.
Например, можно тестировать гипотезы с помощью Riskiest Assumption Test. Хорошее описание метода есть у Андрея Торбичева, партнера венчурного фонда «Месторождение» и автора канала «Индекс дятла»: ребята валидируют предположение за 1 неделю, и в рамках спринта успевают проверить 5 гипотез.

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

✅ Ориентируемя на быстрый выпуск MVP (Minimal Viable Product, минимально жизнеспособный продукт), который позволит получить обратную связь от пользователей.

✅ Настраиваем циклы обратной связи: отзывы A/B тестирования, отзывы пользователей MVP, регулярный анализ полученной обратной связи и внесение изменений в продукт на ее основе помогут вовремя сориентироваться, если потребности или поведение пользователей изменится.

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

Как проводить PI планирование

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

Собрали для вас ключевые аспекты, которые помогут провести PI планирование.

А для тех, кто уже знаком с теорией, в конце поста разбираем два кейса из нашей практики.

⚡️"Оценка зрелости Agile-команд" бесплатный вебинар 30 мая

Что дает оценка agile-зрелости? В первую очередь, это простой и эффективный инструмент, который позволяет увидеть слабые места, потенциальные риски и наметить точки роста команды.

▪️На вебинаре мы рассмотрим сразу 3 уровня оценки:

- Team Agility: оценка конкретной Scrum-команды
- Уровень портфеля или стрима создания ценности
- Уровень организации в целом

▪️ Разберем оценку реальных agile-команд на примере нескольких кейсов из нашей практики

▪️Вы научитесь применять матрицу для оценки своих команд и получите необходимые материалы

Ссылка на регистрацию. Участие в вебинаре бесплатное.
30 мая в 19.00 (мск). Длительность около 1 часа.

До встречи на вебинаре!

Как найти точки роста вашей Agile-команды

Сегодня в 19.00 по московскому времени проведем вебинар, посвященный развитию Agile-команды.

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

Чтобы присоединиться к трансляции, переходите по ссылке

Начало: 19.00 (UTC+3 MSK)
Продолжительность: 1-1,5 часа.
Спикер: Артём Гринякин — старший agile-консультант OnAgile Consulting

До встречи онлайн!

Ближайшие тренинги

Друзья, мы продолжаем делиться проверенными на практике инструментами управления проектами, продуктами и командой.

Каждая программа — это три дня глубокого погружения в Agile под руководством экспертов-практиков. С получением международной сертификации.

1. Фундаментальный курс по Agile и Scrum

Самый широкий по охвату тем тренинг, основной курс по гибким подходам, включающий Scrum и Kanban. Идеальная программа для тех, кто присоединился к scrum-команде или планирует перестроить работу своей команды.

Забронировать участие

Ближайшие группы
21 – 23 сентября
16 – 18 ноября

2. Курс по управлению проектами в Agile

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

Ближайшие группы
19 – 21 октября
14 – 16 декабря
Забронировать участие

3. Продвинутый курс для Скрам-мастеров и руководителей

Более чем на 60% состоящий из практики продвинутый курс для Скрам-мастеров и всех, кому важны развитие команды, эффективное проведение командных встреч, командный коучинг и фасилитация.

Ближайшие группы
28 – 30 сентября
23 – 25 ноября
Забронировать участие

4. Продвинутый курс для Владельцев Продуктов

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

Ближайшая группа
05 – 07 октября
07 – 09 декабря
Забронировать участие

5. Нужен тренинг для группы коллег?

Адаптируем программу специально для вашей команды и проведем онлайн или очно в Мск/Спб.

Для консультации свяжитесь с нами по тел. +7 495 221 87 39 или на info@onagile.ru

Бывают отзывы, которыми просто невозможно не поделиться:)
Спасибо, Елена, у вас отличная команда, с которой очень приятно работать!

«Мы занимаемся научным консалтингом и недавно решили разрабатывать ПО, что подтолкнуло нас организовать тренинг по управлению проектами с использованием Agile-подходов. 

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

Дмитрий отличный тренер, и практик метода, а учиться у практика - особая привилегия. 

Главный результат тренинга - что уже на следующей неделе после тренинга мы создали рабочую группу и работа по новым правилам началась!»

На выходных ребята опубликовали русский перевод эпичного кейса из заказной разработки ПО, когда Hertz заказал у Accenture новый сайт-приложение и в итоге обе большие и известные компании этот проект не осилили, дело закончилось судом.

Рекомендую почитать как тем, кто разрабатывает софт, так и тем, кто его заказывает - я думаю каждый сможет провести много параллелей со своим опытом. Дело было в 2017-19 годах, но сути это не меняет 🙂

https://vc.ru/dev/468325-keys-kak-kompaniya-hertz-zaplatila-agentstvu-accenture-32-milliona-dollarov-za-veb-sayt-kotoryy-tak-i-ne-zapustilsya

Оригинал на английском здесь: https://www.henricodolfing.com/2019/10/case-study-hertz-accenture-website.html

Что интересно, такой сценарий просто невозможен в agile подходе, потому что:

• Весь большой продукт обязательно делится на небольшие, логически разделенные части. Поэтому не нужно ждать конца проекта, чтобы выпустить продукт на первых клиентов, это можно было сделать в случае с hertz уже через месяц-два.
• Вся разработка делится на недельные итерации. Поэтому в конце каждой недели можно увидеть небольшой, но реальный прогресс. Например, на тестовом стенде. Таким образом, мгновенно не заметить отсутствие той же адаптивной верстки, как в кейсе Accenture- Hertz, просто невозможно.
• Задачи ставятся и тз пишется не все и сразу, а «в моменте», непосредственно перед началом разработки. Поэтому любые важные изменения требований от заказчика всегда будут учтены.
• И последнее. Никогда, никогда и ещё раз никогда нельзя использовать fixed price модель разработки.

Приведу пример из собственного опыта - меня пригласили в крупный и известный банк, который на тот момент уже 2.5 года, в сотрудничестве с не менее крупной и известной компанией-аутсорсером, разрабатывал новый продукт для юрлиц. И за 2.5 года не было не только работающей версии у клиентов, но и тестовых версий с хотя бы одним работающим сквозным сценарием. Напоминает кейс Accenture-Hertz, верно?

Только в данном случае вовремя осознали, что нужно срочно менять подход к ведению проекта, перешли на Agile и все стало хорошо (но, конечно, не сразу).

А первое, что я сделал в этом проекте в качестве консультанта - перевёл взаимодействие банка, который уже был готов подавать судебный иск, и подрядчика на T&M контракт.

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

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

В этом году на тренингах снова часто спрашивают, в чем основное отличие Agile от Lean.

Я обычно объясняю это так.

Другими словами, задача Lean - оптимизировать операционные процессы, задача Agile - оптимизировать разработку новых нетиповых решений за счет коротких циклов проверки гипотез.

Добавите что-нибудь?

Сила продуктовых команд

Одна из самых сильных сторон Agile подхода заключается в вовлечении каждого участника команды в создание конечного продукта.

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

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

Сила продуктовой команды в крутости обсуждаемых гипотез и скорости их проверки.

И чем больше вовлеченных людей будут драйвить этот процесс, тем лучше будут результаты.

Приведу пример вопросов из реальной команды недавно запущенного продукта, которые мы обсуждаем все вместе:

1. Почему у нас только X% клиентов начинают регистрацию?
2. Почему у нас только X1% завершают регистрацию?
3. Почему только Y% зарегистрированных людей делает целевое действие, а Y1% уходит и не возвращается?
4. Почему так мало (до K%) клиентов возвращаются и повторно делают целевое действие?
5. Что не так с СегментомХ клиентов, живущих в СтранеY?

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

Самое частое возражение - «у нас ведь есть продакт и аналитик, это же их работа».

Тем не менее, через несколько недель команду уже, как правило, не узнать.

А у вас был опыт переключения коллег в продуктовое мышление? Как работали с возражениями?

Друзья, привет, обычно мы так не делаем, но 🙂

У вас есть уникальная возможность посетить последний в этом году тренинг "Управление проектами в Agile" с огромной 25% скидкой!

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

13-15 декабря 2022, онлайн

Всего 5 мест с такой скидкой, запишитесь прямо сейчас: https://icagile.ru/agile-project-management.

P.S. Места со скидкой закончились :)

#agile #управлениепроектами #скидка #профессиональноеразвитие

Друзья, привет! Мы решили немного обновить название и концепцию канала в новом году.

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

Итак, встречайте - OnAgile Learning Hub.

Кстати, первый пост у нас вышел почти 5 лет назад, 10 мая 2018 года. Если кто-то из наших дорогих подписчиков помнит то время, напишите в комментариях или поставьте сердечко 🙂

Хочу поделиться очень понятной вводной статьей про работу с графиком распределения Leadtime, надеюсь, вам будет интересно прочитать: https://mauvisoft.com/2020/10/08/how-to-read-lead-time-distribution/

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

Самое удобно в этой диаграмме то, что она может работать с любым процессом, будь то Scrum, Kanban-метод или любой другой существующий в компании процесс разработки и поставки.

Достаточно просто выбрать сущность, время работы над которой хотим измерять (например, Эпик или Инициатива), определить первое состояние жизненного цикла, откуда начнем считать время (например, переход в Анализ) и финальное состояние (обычно это переход в Готово).

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