Медиатех

1. Решения и проблемы
SCRUM на практике

2. Юрий Соболев (CTO + PO)
10 лет занимаюсь управлением техотдела

3. Юрий Соболев (CTO + PO)
Менеджмент? Не, не знаю

4. Сергей Царев (DCTO + PO)
Челмедведосвин,
I’m super cereal!

5. Медиатех - разработка и сопровождение
1. 120 сотрудников (2016 - 70, 2015 - 30). Отдел разработки - 29.
2. Отделы: разработка, административно-аналитический, продажи,
маркетинг, конвертация, анализа качества, финансовый
3. Полный цикл: от разработки ПО до поддержки в ведении проекта
4. Опыт создания WEB-проектов с 2006-го года.

6. Адстерра - биржа интернет рекламы
● 9 различных форматов рекламы
● Помогаем рекламодателям найти нужный тип трафика
● Помогаем владельцам сайтов получать максимальную прибыль с
рекламы
● Около 180 млн показов рекламы в сутки
● 100+ серверов в 7 датацентрах по всему миру
● Большой стек технологий, который постоянно расширяется.

7. Адстерра - биржа интернет рекламы
● Июль - Октябрь 2013 – рождение проекта. MVP Adsterra ( 2.5 человека
за 3 месяца)
● Июнь - Декабрь 2014 – переход полностью на свое ПО. (6 человек за 6
месяцев)
● Февраль 2015 - Первые проблемы роста, первобытный Scrum

8. Первобытный SCRUM
● Нас все еще мало
● Но задач, почему-то, все больше
● Нужно все это как-то планировать и контролировать
● Илья сказал: “Нам нужен Scrum!”

9. Первобытный SCRUM

10. Первобытный SCRUM. Результаты
Задача Результат
Приоритезация
-
Планирование
+/-
Коммуникация
+
Ответственность
+

11. Нас становится все больше...
● Чето опять не успели в спринт кучу тасков...может ну его нафиг, мы итак
много работаем, к чему эти формальности.
● И вообще народу все больше, занимаются разными вещами, все эти
скрам борды только путают.
● Блин, мы превращаемся в большую компанию, нам нужно планирование,
диаграмма Ганта и прочие прикольные штуки...

12. Адстерра - биржа интернет рекламы
● Июль - Октябрь 2013 – рождение проекта. MVP Adsterra ( 2.5 человека
за 3 месяца)
● Июнь - Декабрь 2014 – переход полностью на свое ПО. (6 человек за 6
месяцев)
● Февраль 2015 - Первые проблемы роста, ломаем Scrum
● Лето 2015 - WaterFuc**ngFall?? (10 человек)

13. «Waterfall»
● Компания растет, вместе с ней потребности, вместе с ней техотдел.
● Появляются подотделы по компетенциям
Основные потребности:
● Разложить жизненный цикл задачи на этапы
● Планировать дату релиза
● Приоритезировать задачи

14. Gantt Chart Example

15. «Waterfall». Результаты
Задача Результат
Приоритезация
+/-
Планирование
+/-
Коммуникация
-
Ответственность
+

16. «Waterfall». Проблемы
● Один за всех и все на одного
● Я разработчик: как написали - так я и сделал
● Во всем виноваты тестировщики!

17. Адстерра - биржа интернет рекламы
● Июль - Октябрь 2013 – рождение проекта. MVP Adsterra ( 2.5 человека
за 3 месяца)
● Июнь - Декабрь 2014 – переход полностью на свое ПО. (6 человек за 6
месяцев)
● Февраль 2015 - Первые проблемы роста, ломаем Scrum
● Лето 2015 - WaterFuc**ngFall??(10 человек)
● Весна 2016 - Самоорганизация?(25 человек)

18. «Free for All»
Основные потребности:
● Децентрализовать контроль
● Свести к минимуму накладки при переходе из этапа в этап
Что сделали:
● Стали собирать команды под проект из спецов всех компетенций
● Команды выбирают ответственного и сами за всем следят
● Мы с Сережей пьем пиво и радуемся жизни (планируем...)

19. «Free for All». Результаты
Задача Результат
Приоритезация
+/-
Планирование
-
Коммуникация
+
Ответственность
-

20. «Free for All». Проблемы.
● Ответственные как-то не выбирались…
● С одной стороны команда под проект, с другой стороны задачи
подотдела по вертикали
● Попытка масштабирования привела к небольшому хаосу...

21. Адстерра - биржа интернет рекламы
● Июль - Октябрь 2013 – рождение проекта. MVP Adsterra ( 2.5 человека
за 3 месяца)
● Июнь - Декабрь 2014 – переход полностью на свое ПО. (6 человек за 6
месяцев)
● Февраль 2015 - Первые проблемы роста, ломаем Scrum
● Лето 2015 - WaterFuc**ngFall?? (10 человек)
● Весна 2016 - Самоорганизация? (25 человек)
● Август 2016 - в России месяц тяжелый…

22. Август. Все сломалось...
● Задачи выполнялись непредсказуемо
● Некоторые делались и, в итоге, выкидывались
● Оторванность от бизнеса не позволяла понимать важность своих
действий
● Как пик кризиса - остановили работу менеджеров почти на неделю

23. Август. Все сломалось...Надо что-то делать
Сережа:
“Юра, а давай сформируем постоянные команды по продуктам, там будут
конкретные ответственные и мы сможем пить пиво!”
Юра:
“Мне кажется, я где-то это уже видел...”

24. За полгода до этого Юра купил книгу и убрал в
шкаф...

25. Адстерра - биржа интернет рекламы
● Июль - Октябрь 2013 - рождение проекта. MVP Adsterra 1.0 - 2.5
человека за 3 месяца
● Июнь - Декабрь 2014 - переход полностью на свое ПО. Adsterra 2.0 - 6
человек
● Февраль 2015 - Первые проблемы роста, ломаем Scrum
● Лето 2015 - WaterFuc**ngFall?? (10 человек)
● Весна 2016 - Самоорганизация? (25 человек)
● Август 2016 - в России месяц тяжелый…
● Октябрь 2016 - Scrum к нам приходит (31 человек)

26. Возьмем все лучшее, что было
Что было хорошо ??? ???
Разбор задач группой
Короткая итерация разработки
Все знают кто и чем занимается
Объективная приоритезация
Коммуникация подотделов
Коммуникация с заказчиками
Периодический «разбор полетов»

27. Узнаем, как это называется в скраме
Что было хорошо Как это называется в скраме ???
Разбор задач группой Planning
Короткая итерация разработки Sprint
Все знают кто и чем занимается Backlog
Объективная приоритезация Grooming + Demo
Коммуникация подотделов Scrum Team
Коммуникация с заказчиками Daily Standup
Периодический «разбор полетов» Retrospective

28. Кто за все это отвечает?
Что было хорошо Как это называется в
скраме
Кто отвечает
Разбор задач группой Planning Scrum Master + Team
Короткая итерация разработки Sprint —
Все знают кто и чем занимается Backlog Product Owner
Объективная приоритезация Grooming + Demo Product Owner
Коммуникация подотделов Scrum Team Scrum Master + Team
Коммуникация с заказчиками Daily Standup Scrum Master + Team
Периодический «разбор полетов» Retrospective Scrum Master + Team

29. Что может быть проще?
Зачем звать кого-то для внедрения?

30. Что может быть проще?
Зачем звать кого-то для внедрения?
Сережа: “Юра, если мы сейчас обосремся, народ уже ни одно нововведение
не примет”
Юра: “Нам нужны авторитеты...”

31. Что может быть проще?
Зачем звать кого-то для внедрения?
Сережа: “Юра, если мы сейчас обосремся, народ уже ни одно нововведение
не примет”
Юра: “Нам нужны авторитеты...”
Приглашать тренеров и консультантов надо прежде всего для придания
большего авторитета нововведениям. И уже во вторую очередь - для
обучения.

32. Разбиться на скрам команды - делов та...
● Изначально команды сформировались на основе групп людей, которые
итак чаще всего работали вместе.
● Плюс команда тех, кто занимался всем подряд:)
● Хотели обойтись малой кровью
● Частично произошла миграция постепенно между командами

33. Разбиться на скрам команды - делов та...
● Изначально команды сформировались на основе групп людей, которые
итак чаще всего работали вместе.
● Плюс команда тех, кто занимался всем подряд:)
● Хотели обойтись малой кровью
● Частично произошла миграция постепенно между командами
● Но в целом - до сих пор постоянно всплывает вопрос про
переформирование команд:(

34. Наши Команды

35. Команда AdsFormat+
На старте Сейчас
● 2 Front-End
● 1 QA
● 2 FrontEnd
● 1 QA
● 1 Backend
● 0.5 DB developer
Пытаются потихоньку выходить за рамки
1 компетенции на человека.

36. Команда DBModules
На старте Сейчас
● 1 разработчик модулей (Back-End)
● 3 DB Developers
● 1 QA
● 2 Data Science
● 7 Developers
Но на самом деле, конечно, не совсем.

37. Команда Application
На старте Сейчас
● 3 Front-End
● 2 Back-End
● 1 QA
● 1 DB developer
● 3 Front-End
● 2 Back-End
● 1 QA
● 1 DB developer

38. FullStack VS T-Shaped VS Single
● Как вы думаете, с какой командой больше всего проблем с
прозрачностью и планированием?

39. FullStack VS T-Shaped VS Single
● Как вы думаете, с какой командой больше всего проблем с
прозрачностью и планированием?
● Но все совсем не так однозначно: мы люди, а не машины.

40. Большие команды VS маленькие
Большие(Application+DBModules) Маленькие (Adsformat+)
● Устойчивость к отсутствию
сотрудников
● Больше возможностей обмена
знаниями
● Мгновенные коммуникации
● Минимум конфликтов

41. Армия VS Семья
Стиль общения во многом зависит от размера команды, но не на 100
процентов. Главное, чтобы устраивало команду.
Строгая организация Неформальное общение
● Повышают дисциплину
● Помогают организовывать рабочее
время
● Наработанные практики помогают
решать проблемы
● Высокая личная ответственность
● Минимум конфликтов

42. Активные VS Пассивные
Капитан очевидность: Лучше, когда команда состоит из активных людей,
которые уважают друг друга(лучше быть здоровым и богатым...)
Активные Пассивные
● Продвигают идеи
● Думают над улучшением команды
● Спорят(в хорошем смысле)
● Не создают конфликтов
● Не задавливают других участников

43. Активные VS Пассивные
Капитан очевидность: Лучше, когда команда состоит из активных людей,
которые уважают друг друга(лучше быть здоровым и богатым...)
Такое вообще бывает?
Активные Пассивные
● Продвигают идеи
● Думают над улучшением команды
● Спорят(в хорошем смысле)
● Не создают конфликтов
● Не задавливают других участников

44. Человеческий фактор
● Некоторые сотрудники не нашли своего места в командах
● Не все хотят заниматься чем-то, кроме “разработки”
● Необходимость отвлекаться от своей специализации нравится не всем
● Перемены для многих - это шок
● “Уравниловка” в командах нравится не всем

45. Скорость VS Качество
● SCRUM говорит много про скорость
● Но мало конкретного про качество
● На старте - это, возможно, и не плохо
● Но со временем создает все больше проблем

46. Скорость VS Качество
● SCRUM говорит много про скорость
● Но мало конкретного про качество
● На старте - это, возможно, и не плохо
● Но со временем создает все больше проблем
● SCRUM не учит Разрабатывать, это просто метод организации
процесса

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

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

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

50. Тех Отдел - лишь часть компании
● Приходится менять взаимодействие с другими отделами
● У вас должна быть для этого власть
● Старые подходы в других отделах тормозят многие процессы внутри
отдела
● Но нельзя просто взять и поменять всю компанию(особенно, когда не
знаешь как)
● Но постепенно пример техотдела распространяет практики по всей
компании
● И надо понимать свою ответственность за это

51. Выводы
Что мы приобрели:
● Мы делаем нужные вещи в короткий срок
● Мы можем расти дальше, не усложняя структуру
● Заказчики знают, чем мы занимаемся
● Разработчики все больше понимают, чем они занимаются
● В разработке все меньше узких горлышек

52. Выводы
А что нас еще беспокоит:
● Состав команд и специализация ее членов
● Не налажен полный процесс поставки ценности от заказа до результата
● Технические проблемы с контролем качества