Если на переменах вы больше зарабатываете, чем теряете, вам будет хотеться перемен. В мире, где всё быстро меняется, где конкуренция возвышает одни компании и уничтожает другие, нужно выстраивать работу так, чтобы перемены приносили пользу, а не разрушения. В докладе поразмышляем как выстроить процессы работы, архитектуру IT-систем и взаимодействия людей, чтобы придать IT-продуктам свойства антихрупкости. https://13.codefest.ru/lecture/2251

1. Антихрупкость в IT
Как полюбить изменения
май, 2023

2. ● Владелец и IT-архитектор Byndyusoft
● Методолог, эксперт в Agile и Lean
● Спикер на профессиональных IT-
конференциях
● Преподаватель в ВУЗах
● Автор книги «Антихрупкость в IT»
https://byndyu.ru
Александр Бындю

3. Любит ли кружка изменения? Нет.
Становятся ли она сильнее после
изменений? Нет, потому что она
хрупкая, изменения ее разрушают.
Кружка не хочет изменений, она
старается их избегать.

4. Любят ли бактерии изменения?
Вряд ли, потому что многие
погибают.
Становятся ли они сильнее после
изменений? Да.
Бактерии не стараются избежать
изменений.
Эволюцию устойчивых к антибиотикам «супербактерий»
воспроизвели в миниатюре
https://nplus1.ru/news/2016/09/09/megapetridish
0 0
1 1
10 10
100 100
1000

5. Тезисы из мира IT
1. Если на переменах ваш IT-продукт больше
зарабатывает, чем теряет, вам будет хотеться перемен.
В обратном случае обратный эффект.
2. В IT-системе, работающей на пределе возможностей
(качество кода, качество архитектуры, качество
автоматизации,...) и поэтому хрупкой, малейшие
перемены ведут к непредсказуемым последствиям.
3. Хрупкость равно нелюбовь к случайности.
4. Нелюбовь к случайности означает повышенные риски
при неминуемых изменениях.

8. Какими свойствами должно обладать ПО, процесс и
разработчики, чтобы можно было постоянно делать
повороты?

9. Аксиома:
Вашу систему будут
постоянно менять.

10. Безопасно
и дешево
вносить
изменения
Направления для исследования
антихрупкости в IT:
1. Процессы: ТЗ, инструменты
управления
2. Внутреннее качество IT-систем
3. Отношения Заказчик–
Исполнитель
4. Люди
5. Бизнес

11. 1. Процессы

12. Жесткое ТЗ пытается
законсервировать
случайность.
Как следствие, изменения
(случайности) будут
разрушать процесс и систему.
Изменения точно произойдут,
значит всегда будут жертвовать
качеством.
Техническое задании:
методология, риски, ограничения,
варианты оформления

13. ТЗ, которое полюбило случайности

14. Должна быть
визуализация целей
и гипотез, готовая к
изменениям
Заказчики и исполнители:
1. Понимают зачем создаётся IT-
продукт.
2. Принимают бизнес-цели и готовы
взяться за их достижение.
3. Понимают стратегию достижения
результата и приоритеты.
4. Понимают критерии успешности
IT-продукта.
Мастер-класс по нюансам Impact
Mapping

15. 1. Целостное видение IT-
продукта.
2. Точки входа, точки выхода и
переходы пользователей.
3. Линии жизни действующих
лиц и точки их
взаимодействия друг с
другом.
Схематизация опыта с CJM и
Service Blueprint. Практика
гибридной нотации
Должна быть
визуализация
клиентского опыта,
готовая к изменениям

16. Должна быть
визуализация функций
системы, готовая к
изменениям
1. Понимание ценности каждой
истории.
2. Визуализация приоритетов.
3. Описание функций системы.
4. Удобная нарезка релиза.
Руководство по сбору требований
в формате User Story Mapping

17. 1. Отклоняться от курса можно и нужно, когда это необходимо.
2. Сохраняем открытость к изменениям.
3. Метод управление вторичен, главное, чтобы была дешевая
коммуникация (Kanban, Scrum).

18. Бюджетирование,
готовое к изменениям
1. Объем работы обговаривается в начале
проекта, но является предметом для
изменения.
2. Всё самое важно успеть к сроку.
3. Глубина проработки задач и конечный
список этих задач могут менять во время
работы.
4. Риски делятся поровну между
разработчиками и заказчиком.
5. Внутреннее качество системы становится
очень важным. Поэтому код, тесты,
внутренний дизайн, архитектура и
автоматизация должны быть высокого
качества.
Управление проектом по Fix Time, Fix Budget,
Flex Scope (FFF)

19. 2. Внутреннее качество
IT-систем

20. IT-продукты внутри должны быть устроены
так, чтобы изменения в продукте
воспринимались не как проблема, а как
возможность к росту.

21. Управление сложностью
Целенаправленный и постоянный вклад в
управление сложностью:
1. Постоянный рефакторинг кода и
архитектуры для соответствия новым
реалиям бизнеса и нашим знаниям о
системе.
2. Тотальное автоматизированное
тестирование: модульные, нагрузочные,
e2e… тесты.
3. Дробление систем на много мелких
сервисов, чтобы их было удобно
пересобирать в новые логические
структуры.
4. Тотальная автоматизация
инфраструктуры и оценки внутреннего
качества.

22. Микросервисы
Как выбрать IT-архитектуру: от
хаоса до микросервисов
https://blog.byndyu.ru/2020/04/it.ht
ml
Эволюция архитектуры
https://blog.byndyu.ru/2020/04/blog
-post_14.html
Скрытые расходы при переходе на
микросервисы
https://blog.byndyu.ru/2020/12/blog
-post.html

23. 3. Отношения Заказчик-
Исполнитель

24. Отношения между заказчиком и
исполнителем должны включать в себя
любовь к изменениям.

27. 4. Люди, которые
строят антихрупкое
ПО

28. Научился печатать код, а что дальше?
Зачем этот код? Кому это всё
надо?
Надо вникать в бизнес, уметь
отвечать на вопрос «чтобы
что?» и понимать каким
образом разработка может
помочь бизнесу.

29. Принимаем осознанные решения
Кнопочное мышление против целостного IT-продукта

30. Доверие – дешевая коммуникация
В квадрате В самая дешевая
коммуникация.
При внешних изменениях это дает:
1. Скорость перестройки в
понимании IT-продукта и
траектории его развития
2. Скорость перестройки
процессов
3. Скорость перестройки
архитектуры и кода

31. Основа для отношений
Заказчик-Исполнитель

32. Характеристики людей,
которые становятся сильнее
от изменений
1. Инженеры, которых хотят использовать
свои головы, а не только руки.
2. Мотивированная и
высококвалифицированная команда, а
значит дорогая.
Считайте заранее будет ли это выгодно в
вашем случае.
3. Высокая вовлеченность Заказчика,
который готов тратить на взаимодействие
свои ресурсы.

33. 5. Бизнес

34. Книга «Теория ограничений. Основные подходы, инструменты и решения», Дмитрий Егоров
«Матрица изменений» Голдратта

35. Не любят и не принимают
изменения, даже в ущерб себе

36. Любят и хотят изменений

37. Сколько стоит антихрупкость?
Сравнить ценность достижения бизнес-цели и
накладные расходы.
“Накладные” расходы:
1. Выстраивание процессов и использование
инструментов
2. Вкладывание в управление сложностью и
внутреннее качество IT-систем
3. Выстраивание отношений Заказчик–
Исполнитель
4. Подбор и обучение сотрудников
5. Работа на уровне бизнеса для поддержания
открытости к изменениям

38. Шансы
на успех

39. Давайте вместе собирать практики!
Направления для исследования
антихрупкости в IT:
1. Процессы: ТЗ, инструменты
управления
2. Внутреннее качество IT-систем
3. Отношения Заказчик–Исполнитель
4. Люди
5. Бизнес
Присылайте мне ваши мысли на эту
тему.
0 0
1 1
10 10
100 100
1000

40. Ссылки
1. Сайт книги «Антихрупкость в
IT»
2. Как стать антихрупким, работая
в IT. Интервью с Хекслет.

41. Спасибо за внимание!
Есть вопросы?
Бындю Александр,
IT-архитектор
Byndyusoft
Обратная связь
по докладу