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

1. 2020
12-14 марта 2020, Минск, Беларусь
UPSTREAM KANBAN
ИЛИ КАК ПОЧИНИТЬ
СКРАМ
Повысьте отдачу команды,
вовлекая ее в процесс
принятия решений

2. def is_valid_walk(walk):
startingpoint = 0
if len(walk) == 10:
for i in walk:
if i == 'n' or i == 'e':
startingpoint += 1
else:
startingpoint -= 1
Agile delivery coordinator в
Godel Technologies Europe
5 Более 5 лет управления проектами
Опыт работы в продуктовых и
сервисных компаниях
Алексей
Богдановский

3. СОДЕРЖАНИЕ
ОТПРАВНАЯ ТОЧКА
ОПРЕДЕЛЕНИЕ ПРОБЛЕМ
ПОИСК РЕШЕНИЯ
ПЕРВЫЕ РЕЗУЛЬТАТЫ
СЛЕДУЮЩИЕ ШАГИ

4. ОТПРАВНАЯ
ТОЧКА

5. Бизнес
Отсутствие прозрачности
давало ложное
ощущение контроля
Сфокусироваться на решении
текущих проблем

6. ПРОЕКТ
• Риск потерять проект
из-за отсутствия
объема работ
• Утилизация
ресурсов

7. КОМАНДА
• Готова к любым
поворотам событий
• Только персональная
ответственность
• Накопленная
усталость
• Нет фокуса на
доставке

8. Я

9. ОПРЕДЕЛЕНИЕ
ПРОБЛЕМ

10. ОТПРАВНАЯ ТОЧКА
Отсутствие долгосрочных планов
Не использование возможностей
команды
Нет понимания добавленной
ценности

11. ПРОБЛЕМЫ КОМАНДЫ
• Технические решения
принимают не
технические
специалисты
• Задача максимально
загрузить команду
• Однотипная работа
• Страх потерять проект
• Команда не доставляет
решение конечному
пользователю

12. ПОИСК
РЕШЕНИЯ

13. Выделенные потери:
• Незавершенное
производство
• Ненужные движения
информации
• Перепроизводство
• Слишком сложные
решения
• Не использование
талантов команды

14. UPSTREAM KANBAN
БЭКЛОГ ИДЕЙ
UPSTREAM
ОТОБРАННЫЕ СИСТЕМНЫЙ
АНАЛИЗ
ТЕХНИЧЕСКИЙ
АНАЛИЗ
СТРАТЕГИЯ
ПРИЕМКИ
ГОТОВО ДЛЯ
РАЗРАБОТКИ

15. UPSTREAM - РЕАКЦИЯ КОМАНДЫ

16. UPSTREAM - РЕАКЦИЯ PO и Бизнеса

17. ПЕРВЫЕ
РЕЗУЛЬТАТЫ

18. ПРОБЛЕМЫ КОМАНДЫ
Выделенные потери:
• Незавершенное
производство
• Ненужные движения
информации
• Перепроизводство
• Слишком сложные
решения
• Не использование
талантов команды

19. Backend
разработчики
начали
осваивать
Frontend

20. Владение
бэклогом
разделилось
между командой
и владельцем
продукта

21. МЕТРИКИ
БЫЛО:
• Стабильная
скорость работы
команды 30-35 story
points
• 40 Человеко-часов в
неделю на встречи
СТАЛО:
• Стабильная
скорость работы
команды 40-45 story
points
• 10 Человеко-часов в
неделю на встречи

22. СЛЕДУЮЩИЕ ШАГИ
1. Внедрение петель обратной связи
1. Использовать метод для улучшения процесса
производства
1. Обучение использованию метода других отделов
компании
1. Уйти от таймбоксов

23. СПАСИБО ЗА
ВНИМАНИЕ
www.linkedin.com/in/asbogdanovskiy/
6705067@gmail.com
+375 29 670-50-67 (Viber, Telegram, WhatsApp)