«Разработка не деливерит». Что делать?

1. «Разработка не деливерит».
Что делать?
Довбуш Павел

2. Кризисы роста
• “Эволюция разработки” - Алексей Рыбак
Whalerider 2013
• Кризисы роста:
• 10-20 => 20-50 => 50-100+ человек
• Саппорт => Новые роли => Процессы + QA
• Сейчас - 265 инженеров
• Очередной кризис роста и как мы его прошли
2

3. 3

4. “Нужно больше минералов!”
• Растут основные продукты
– Больше пользователей и функционала
– Эксперименты, A/B тесты
• Тестируем новые продукты, больше в параллель
• Процессы построены
4

5. “Нужно больше минералов!”
• Растут основные продукты
– Больше пользователей и функционала
– Эксперименты, A/B тесты
• Тестируем новые продукты, больше в параллель
• Процессы построены
5
Нужно нанимать!

6. Растем
• Фокус внимания ограничен
• С этими работаю, ну а там еще 200 волшебных
гномов строят космический корабль
• Людей добавляем а ощущение скорости не
меняется
6

7. Растем
• Фокус внимания ограничен
• С этими работаю, ну а там еще 200 волшебных
гномов строят космический корабль
• Людей добавляем а ощущение скорости не
меняется
7
“Разработка не деливерит!”

8. Не деливерит?
• Давайте разбираться
• Что нужно бизнесу?
– Больше пользователей и денег
• Стратегия продукта
– нишевые продукты, быстрый тест идей
• Что ожидается от разработки?
8

9. Деливери
9
Идея
Разработка
Результат

10. Деливери
10
Идея
Разработка
Результат
Есть!
Процесс идет!
Прозрачно, прогнозируемо.
По плану.

11. Планирование
• Планы: общие, каждой команды. Много!
• “А чего они?”
• “Нагородили тут планирований!”
• “Тикет им поставь!?”
• “Планы” начинают вызывать раздражение
11

12. Ген. План
• Так может в этом проблема?
• Надо еще лучше планировать и все станет хорошо
• Один инструмент
• … на §00 человек?
12

13. Планирование
• ...планов стало больше
• Что-то не получилось…
– толи не умеем
– толи причина не в этом
13

14. Деливери
14
Идея
Разработка
Результат

15. Разработка
• Люди
• Технологии
• Процессы
– Взаимодействия между командами
– Внутри команд
15

16. Процессы взаимодействия
• Вроде отличные процессы
• Специализация
• Взаимодействие
• АПИ
16

17. Процессы внутри команд
• Все делают дело (заняты, устали)
• “У меня” - хорошо, “а вот они” - мешают
• То задерживают, то раньше отдают, то лезут
помогать когда не просят
• "Мы" и "Они"
17

18. "Мы" и "Они"
18
Спринты (2 недели)
Планинг покер
Стэндапы
Командная ответственность
Релизы 2 раза в день
Планирование тимлидом
Личная ответственность
DUE date готовности
"Типа" скрам "Типа" waterfall

19. 19
Холивар.

20. Методологии разработки
• Разные подходы? Ок.
• Один плохой, другой хороший? Нет.
• Плохо что их два в одном процессе.
Потери на стыке.
20

21. Унифицируем процесс
I. Диктатура
II."Вежливый" менеджмент
III.Договариваемся
21

22. I. Диктатура
- Ты, ты и ты...
- А можно и я?
- Хорошо, и ты. Расстрелять.
Мы вас научим жить правильно!
22

23. II. "Вежливый" менеджмент
• Всё тоже
• Но с "привкусом лесных ягод"
23

24. III. Договариваемся
• Слушать
• Ценности
• Цели
• Общий язык
24

25. Ценности
• На ком ответственность?
– За процесс
– За сроки
– За качество
– За результат на продакшене
25

26. Цели
• Фокус на бизнес
• Быстрый тест идей
• XP, MVP, A/B test
• Гибко
• Прозрачно
• Прогнозируемо
26

27. • Должен быть единый подход и культура
разработки
• Ценности, а не шаги флоу
• + Набор способов решения стандартных ситуаций
27
Договорились!

28. Developer Responsibility Flow
Idea PRD
Developer
Owner
Plan
MAPI
SRV
Design
Kick Off
Tech Plan
DUE
DATE
Development
Visual QA
Auto
Test
Review
Feature
Branch QA
Integration
QA Release
Retrospective
Product
Feedback
by PM
with PM
with PM
with PM
PM can be
invited
by PM
Release
Date

29. Ответственность разработчика
• Подход “старатапа” в большой компании
• Софт скилз
• Сложнее нанимать
• Рост ответственности
• “Прокачка”
29

30. Ответственность за результат
• За результат!
• DUE date
• Планирование
– что?
– зависимости
– как?
– “цена” разработки
30

31. Качество
• Качество — ответственность разработчика
• QA — “страховка”
• Баланс цена/качество
31

32. Ретроспектива
• Основная цель, не “найти виноватого”, а понять
как можно улучшить процесс
• Раз в месяц
• Анализ топ 3 причины не попадания в срок
• Регулярный, циклический тюнинг процесса в
каждой команде
32

33. Результат на продакшене
• Результат нового функционала
• Ошибки
• Техническая статистика
• Продуктовый импакт
• Селф-Мотивация
33

34. Инструмент №1 — Kick-off
• Продажа “идеи” заказчику
• Помогает убедиться что правильно поняли
• Поиск MVP, срезаем углы
• “Цена” разработки
• DUE date
34

35. Инструмент №2 — Visual QA
• Показать результат, рано
• Ответственность за качество
– на разработчике
• Экономим время на дальнейших шагах
35

36. Что получилось
• Делегируем ответственность
• Рассказываем “как” правильно
• Даем инструменты
• Легче масштабировать команды
• Прозрачность
• Прогнозируемость
36

37. Прозрачность
• 3 Колонки
– Бэклог
– В работе
– Готово
• Команды — swimlanes
• Можно видеть “дифф” — изменения WoW, MoM
37

38. “Деливерит!”

39. Спасибо!
Вопросы?