Антихрупкость в IT или как полюбить изменения

Если на переменах вы больше зарабатываете, чем теряете, вам будет хотеться перемен. В мире, где всё быстро меняется, где конкуренция возвышает одни компании и уничтожает другие, нужно выстраивать работу так, чтобы перемены приносили пользу, а не разрушения.

В докладе поразмышляем как выстроить процессы работы, архитектуру IT-систем и взаимодействия людей, чтобы придать IT-продуктам свойства антихрупкости.

https://13.codefest.ru/lecture/2251

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

6. View Slide

7. View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

25. View Slide

26. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

33. 5. Бизнес
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide