Люди и конфликты в DevOps

DevOps Meetup at Mail.ru Group, 21-03-2019
Ахмед Шериев (независимый эксперт по DevOps)

Доклад будет посвящен тому, как взаимодействуют и конфликтуют люди в проблемных проектах. Неправильные трактовки гибких методологий и DevOps-практик. Сопротивления при внедрении и ограничения применимости DevOps – поговорим о всём наболевшем.

Transcript

1. Люди и конфликты в DevOps Шериев Ахмед
2. Обо мне • Разработчик • Архитектор • Тимлид • Директор по разработке • Руководитель отдела 2
3. О чем доклад • Трактовки DevOps • Межкомандная коммуникация • Мало про технологии и инструменты • Много про работу со конфликтами и сопротивлением 3
4. Что же такое DevOps?
5. Разработка + Администрирование? Development Operations DevOps 5
6. Временные должности DevOps • DevOps инженер • DevOps команда • DevOps директор • Имеет смысл только в крупных компаниях 6
7. Development Operations DevOps Test 7
11. А как же Agile? Agile Continuous Integration Continuous Deployment DevOps Value 11
12. Заблуждения DevOps • Docker, k8s ≠ DevOps • DevOps инженер ≈ Agile разработчик 12
13. Книги 13
14. Когда хотят внедрять DevOps?
15. Стадии разработки Баги № Версии Доверие Время релиза Требования Документирование Закрытие 15 KPI DevOps
16. Конфликты
17. Разработчики • Менеджеры не знают чего хотят • Слишком часто меняются требования • Требования не понятны • Не дают время на рефакторинг и тесты • «Глупый»/непродуманный дизайн. 17
18. Менеджеры • Разработчики срывают все сроки • Чинят одно ломают то, что работало • Не думают о пользователях 18
19. Тестировщики • Разработчики даже не запускают то что нам дают на тест • Дизайн, требования, реализация не сходится 19
20. Дизайнеры • Мы не аналитики что бы думать о пользователях • Нам некогда перерисовывать под каждый чих • Мы задаем концепт • У нас уникальный дизайн, который не систематизируется 20
21. Конфликты внедрения DevOps
22. Структура конфликтов и возражений • Я останусь без работы (автоматизация) • Дешевле сделать руками (отказ от автоматизации) • Не моя работа (не хочу учиться) • Не трогайте меня! (отказ от сотрудничества) • Чушь какая то (бесполезно) • Кто будет виноват? (отказ от ответственности) • У нас уникальный случай (полезно но не наш случай) 22
23. Рассматриваемые роли Разработчики Администраторы Тестировщики Менеджеры И многие другие Дизайнеры 23
24. Базовый конфликт Development Operations DevOps Изменения Стабильность 24
25. Не моя работа • 1+1 ≠ 2 • Без сотрудничества 1+1 < 2 • При сотрудничестве 1+1 > 2 • Docker, ci/cd 25
26. Нас хотят заменить? • Обслуживание и ответственность за боевые сервера все еще за администраторами • Оплата Курсов 26
27. Кто будет виноват? • Все • Коллективная ответственность = коллективная безответственность • У каждой проблемы есть ФИО • … и чаще всего это руководитель 27
28. Дешевле сделать руками • Посчитайте потраченное время • Посчитайте цену инструментов • Посчитайте экономический эффект 28
29. Тестирование + разработка Development Testing DevOps Изменения Стабильность Соответствие требованиям 29
30. Не моя работа • Разработчик отвечает за качество кода • Тестировщики отвечают за качество на проде 30
31. Нас заменят автоматизаторы • Автоматизируются тестирование стабильных фич/сервисов • Любые фичи/сервисы в разработке тестируются вначале вручную 31
32. Нас заменят автоматизаторы Auto UI End-to-End Integration Unit 32
34. Дизайн + разработка Development Design DevOps Изменения Свобода творчества Качество дизайна 34
35. Типы дизайнеров • Дизайнер полиграфии • Photoshop • Дизайнер UI (знает дизайн платформы) • Photoshop, Sketch, Figma • Дизайнер UX (знает пользователей) • Sketch, Figma • Дизайн-система (видит логику дизайна) • Визуальный стиль • UI Kit • Атомарный дизайн 35
36. Не моя работа • Дизайн – это не то, как выглядит, а то, как он работает (С. Джобс) 36
37. У нас уникальный случай • Даже в уникальном дизайне есть повторяемые элементы 37
38. Не хочу общаться • Запускаемый проект {name}.UiKit • Web • Android • iOS • Единые компоненты как в дизайне UIKit так и в коде UIKit 38
39. Пример библиотеки paradigm (mail.ru) https://design.mail.ru/ 39
40. Это все чушь • Material Design System • Airbnb Design System • Design System Club • Альфа-Банк • Mail.Ru • Яндекс • Рамблер • и т.д. 40
41. Управление рисками • Опытный дизайнер может увеличить производительность команды разработчиков на порядок • Неопытный дизайнер источник большого количества багов 41
42. Художника обидеть может каждый 42
43. Еще книги 43
44. Разработчики + Разработчики DevTeamA DevTeamB DevOps 44
45. Команда универсалов Спринты Team A A B C D • Каждый в команде Full Stack разработчик Плюсы: • Полная взаимозаменяемость • Storypoint-ы • Хорошо подходит для простых проектов Минусы: • Дорого • Трудно найти разработчиков • Невозможно в сложных проектах • Тестирование все еще отдельно Test A B C D 45
46. Кроссфункциональная команда Backend Дизайнеры FrontEnd Тестировщики 46
47. Кроссфункциональная команда Спринты Team A A B C D Плюсы: • Каждая команда самодостаточна • LeadTime меньше Минусы: • Требователен к скилам каждого • Требуется высокий уровень доверия • Требует опытного архитектора Спринты Team B E F G H 47
48. Разработчики + ПМ Development Product Manager DevOps Изменения Быстрые изменения Надежность 48
49. Продуктовые менеджеры • Проверка гипотез • A/B тесты • Быстрая реакция 49
50. Работа с разработчиками • Изменение требований к проекту это нормально • Тесты нужны! • Тесты не про тестирование калькулятора • Тесты разных типов (Unit, Integration) 50
51. Архитектура • Тесты нужно, но этого мало • SOLID • DDD • DSL • FDD 51
52. Это все чушь! • Откуда формируется мнение? • Авторитет (Все на хабре пишут) • Плавали знаем! • В больших проектах: • Это все действительно нужно • Работа разработчика не в том что бы писать код а работа с существующим 52
53. Не хочу общаться с разработчиками • Разработчики должны понимать зачем • Job Story дополнительно/вместо User Story 53
54. Книги для разработчиков 54
55. Архитектура 55
56. Domain Driven Design 56
57. DDD в ФП 57
58. Разработчики + Клиенты (эмпатия) Development Эмпатия к клиентам DevOps 58
59. Разработчики максималисты • Мы делаем приложение не для дебилов! • Надо выдавать права на пользование компьютером 59
60. Вовлеченность • Демонстрация живого пользования продуктом • Разработчики на Юзабилити тестировании • Job Story вместо/вместе с User Story 60
61. Покупают не дрель, а дырки в стене • Jobs To Be Done фреймворк • За что платят деньги? • Почему выбирают ваш продукт? • С чем конкурирует ваш продукт? 61
62. Разработчики + Руководство Development Management DevOps Не бывает плохих солдат, бывают плохие генералы 62
63. Типичный руководитель бизнеса • Большой опыт в разных сферах деятельности • Большой опыт операционной деятельности • Большой опыт управления людьми • Успешный опыт применения KPI • Успешный опыт применения KPI и в IT проектах 63
64. Особенности операционной деятельности • Рутинная однообразная работа • Демотивация • Прогнозируемость 64
65. Проблемы проектной и продуктовой разработки • Мало рутинной работы • Возможно R&D • Отсутствие опыта • При большом количестве R&D или отсутствии опыта невозможно спрогнозировать • Проблема отсутствия опыта 65
66. Типичные ошибки руководителя бизнеса • Путает отсутствие опыта и нежелание работать • Пытается применить стандартные системы мотивации • Пытается применить стандартные системы планирования работ 66
67. KPI • Хорошо подходит для операционной деятельности • Плохо подходит для проектной и продуктовой разработки 67
68. Что делать? • Просите доверять вам • Спрашивайте что надо получить в итоге • Просите ответственности • ИЗМЕРЯЙТЕ, ИЗМЕРЯЙТЕ И СНОВА ИЗМЕРЯЙТЕ! 68
69. Пример 1. Затрачено 300 человеко-часов ≈ 150 тыс. рублей 2. Из них баги на 200 человеко-часов были обнаружены инструментами 3. SonarQube ≈ 15 тыс. рублей в месяц 4. PVS-Studio ≈ 15 тыс. рублей в месяц 5. Экономия 120 тыс. рублей 69
70. Советы руководителю 70
71. Работа с критикой 71
72. Критиковать нормально • Критиковать работу нормально • Критиковать человека нельзя • Критика работы не значит критика личности 72
73. Как критиковать? • Найдите за что похвалить • Сарказм, насмешки, издевки, шпильки недопустимы • Уберите негативные эмоции 73
74. Токсичность 74
75. Мат • Мат все таки недопустим • Оскорбления и унижения наносят ущерб • Токсичность влияет на измерения 75
76. Что почитать? 76
77. Узкая командная культура 77
78. Он нам не подходит, потому что • Не курит • Не пьет • Тату • Возраст • Пол • ВУЗ • И т.д. 78
79. Опыт 79
80. Ему будет у нас скучно • Нанимайте людей опытнее себя • Берите тех кто может самостоятельно работать • Не надо боятся что вас подсидят 80
81. Доверие 81
82. Доверяй! • Доверяй но… измеряй! • Давайте фидбек • Закладывайте в риски право на ошибку 82
83. Мотивация 83
84. Работа с мотивацией • Просите делиться опытом • Организуйте митапы • Обеспечьте участие в митапах и конференциях • Выступайте сами • Не платите за выступления! 84
85. Зарплата 85
86. Я готов работать хорошо за повышение • Обсуждение текущих проблем • План развития • План повышения по итогам 86
87. Управление рисками Долго сидел на рутинной работе: 1. Если учится ради повышения з/п то это редко приводит к успеху 2. Недовольство собой растет 3. Нарастает токсичность и депрессия 4. Демотивация и увольнение 87
88. Управление рисками 1. Проводите 1-1 2. План развития 3. Достижимые цели развития 4. Фидбек 88
89. Резюме • Доверяйте, измеряйте, давайте фидбек • Будьте честны • Будьте открыты к критике и научитесь критиковать • Вкладывайте в обучение и мотивацию • Измеряйте, измеряйте и еще раз измеряйте • Не злоупотребляйте измерениями 89
90. Шериев Ахмед: t.me/AkhmedSheriev akhmed@outlook.com