Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

Видеозапись выступления https://rutube.ru/video/08e64908455db599e4803b5fb68c976e/

More Decks by Александр Бындю

Other Decks in Technology

Transcript

  1. • Владелец и IT-архитектор Byndyusoft • Методолог, эксперт в Agile

    и Lean • Спикер на профессиональных IT- конференциях • Преподаватель в ВУЗах • Автор книги «Антихрупкость в IT» https://byndyu.ru Александр Бындю
  2. Любит ли кружка изменения? Нет. Становятся ли она сильнее после

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

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

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

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

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

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

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

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

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

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

    воспринимались не как проблема, а как возможность к росту.
  13. Управление сложностью Целенаправленный и постоянный вклад в управление сложностью: 1.

    Постоянный рефакторинг кода и архитектуры для соответствия новым реалиям бизнеса и нашим знаниям о системе. 2. Тотальное автоматизированное тестирование: модульные, нагрузочные, e2e… тесты. 3. Дробление систем на много мелких сервисов, чтобы их было удобно пересобирать в новые логические структуры. 4. Тотальная автоматизация инфраструктуры и оценки внутреннего качества.
  14. Микросервисы Как выбрать 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
  15. Научился печатать код, а что дальше? Зачем этот код? Кому

    это всё надо? Надо вникать в бизнес, уметь отвечать на вопрос «чтобы что?» и понимать каким образом разработка может помочь бизнесу.
  16. Доверие – дешевая коммуникация В квадрате В самая дешевая коммуникация.

    При внешних изменениях это дает: 1. Скорость перестройки в понимании IT-продукта и траектории его развития 2. Скорость перестройки процессов 3. Скорость перестройки архитектуры и кода
  17. Характеристики людей, которые становятся сильнее от изменений 1. Инженеры, которых

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

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

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

    антихрупким, работая в IT. Интервью с Хекслет.