Практика и опыт Archives – Страница 5 из 53

Закон Конвея и его важность при создании команд

Закон Конвея (Conway’s Law) имеет большое значение для понимания тех сил, что возникают при формировании команд, и того результата, который они могут оказать на команды в условиях длительного и автономного, неуправляемого и некорректируемого воздействия. И, как следствие, для понимания влияния на разрабатываемые командами программные продукты, поскольку за последнее время они стали более сложными и взаимосвязанными, чем когда-либо прежде. Выдержал ли закон об архитектуре программного обеспечения, сформулированный Мелвином Конвеем в далёком 1968 году, проверку временем? Короткая справка: Закон Конвея — “Организации проектируют системы, которые копируют структуру коммуникаций в этой организации”. В конце концов, разработка ПО прошла немалый путь: микросервисы, облака, контейнеры,…

Мероприятия предстоящей недели

В четверг 17 декабря пройдёт вебинар “Не зрелость”, посвященный оценке процессов управления ИТ в интересах руководителя. Ведущий вебинара: Дмитрий Исайченко, управляющий партнёр Cleverics, практикующий консультант с пятнадцатилетним стажем, соавтор и ITIL 4. Программа вебинара: Что такое зрелость системы управления Что даёт оценка зрелости Чего оценка зрелости дать не может Оценка эффективности Целевые аудитории для разных видов оценки Начало вебинара 11:00 по московскому времени Регистрация В пятницу 18 декабря сообщество ИТ-специалистов Infostart проведёт митап “Методологии управления в ИТ”. В программе митапа – 5 докладов от экспертов, применяющих ITSM-методологии, как в международных компаниях, так и в среднем бизнесе. Вопросы, которые обсудим на мероприятии:…

Преимущества DevOps-мышления

Порой нелегко объяснить своему руководителю или коллеге, почему и как DevOps может решить многие из ваших проблем. Эксперты-участники DevOps Enterprise Summit предлагают простые и понятные формулировки, которые могут вам помочь. «Мы разрабатываем целостную систему доставки, от идеи до конечного пользователя, исходя из предположения, что каждое требование неверно, мы неправильно его поняли и/или оно изменится к тому времени, когда мы сможем предоставить решение для него. Чем дольше задержка между запросом и поставкой, тем дороже становится эта проблема.»Bryan Finster, Value Stream Architect, Walmart DevOps Dojo, Walmart «Будущее неизвестно. Приспособляемость – ваше секретное оружие.»Dave Mangot, Principal, Mangoteque «Ежедневная доставка ценности заказчику.»Mick Miller, Senior Product Manager,…

Работаете над повышением уровня психологической устойчивости? Задумайтесь, правильно ли?

Многие организации с гордостью заявляют о том, что они выявили и работают над проблемой психологической устойчивости персонала лишь на том основании, что они провели семинар полгода назад или любезно предоставили своим сотрудникам мобильное приложение, которое поддержит их психическое равновесие и комфорт. Но это, мягко говоря, ничто – делится в своей заметке мыслями по теме Карен Феррис. Да, существуют отличные приложения и отличные компании, которые проводят семинары по корпоративной психологической устойчивости. Но без желания и чёткой приверженности руководства и определённых действий по созданию основы – это пустая трата времени и денег. Повышение психологической устойчивости на работе – процесс непрерывный. Это похоже…

Работать меньше, чтобы сделать больше

Все, а больше всех инвесторы и спонсоры, хотят, чтобы вся команда работала над новыми задачами, фичами, эпиками не останавливаясь. Тем не менее, несмотря на столь жгучее желание, команда не сможет выделить все свое время на новые разработки. Причин тому несколько: Баги случаются, и когда они случаются, то они становятся приоритетом. Нестабильное или нефункциональное хоть в чем-то приложение генерирует не только прямые потери через снижение продаж, но и снижает конверсию, отталкивает лояльных пользователей, вызывает недоверие клиентов. Что делать? – Резервировать время/ресурс, организовывать Emergency lane. Разработка состоит не только из downstream разработки и доставки. В области discovery, в upstream активностях возникает потребность…

Он и тебя посчитал

В своей недавней заметке Олег Скрынник начал диалог на тему диагностики продуктовых команд, как потока. Думая о теме со своей стороны, больше с ракурса уютной внутрикомандной работы, где все (хочется надеяться) друг друга знают, притёрлись к особенностям и лёгким странностям соратников, и слаженно (потому что как ещё это можно видеть изнутри?) работают, я особенно зацепилась за вопрос привлечения сторонних консультантов к диагностике. То, что это – хорошая практика ясно: взгляд со стороны, отсутствие замыленности, ведь консультанты находятся вне жизни команды. Но так ли тут всё однозначно и просто, как кажется на первый взгляд? Сама процедура регулярной диагностики достаточно прочно ассоциируется…

Диагностика продуктовых команд как поток

Представим, что у нас есть продуктовая команда. Ну или группа людей, которые очень хотели бы таковой стать. Ну или мы хотим, чтобы они стали – не суть. Предположим, что с этой командой мы какое-то время поработали: разобрались в её рабочем процессе, особенностях, составе, области ответственности… Реализовали набор практик, помогающих работу/результаты структурировать, визуализировать, организовывать, измерять и улучшать. Всё на основе важных принципов и исходя из определённого, нового продуктово-гибкого mindset’а (это слово я на русский перевести затрудняюсь). Итого: первоначальные инвестиции сделаны, далее ожидается более самостоятельное движение этой команды вперёд. Возникают важные управленческие вопросы: как убедиться, что команду можно “отпускать в более свободное…

Учёт доступности? А можно как-то попроще?

На днях, когда я в очередной раз рассказывал про управление доступностью на курсе ITIL PPO, мне задали такой вопрос: “а можно как-то попроще?”. Вопрос, в общем-то, правомерный, особенно с учётом комплексности картинки, которая в тот момент рассматривалась. Действительно, для того, чтобы обеспечить комплексный учёт доступности не только на уровне ИТ-систем и их компонентов, но и на “бизнес-уровне”, нужно много чего реализовать и в техническом, и в организационном отношении. Как показывает [мой] опыт, способность к измерению доступностью сильно зависит не только от наличия хороших технических возможностей (читай, продуманного мониторинга и управления событиями), но и очень и очень человеко-зависима. На всякий случай…

Новый сезон вебинаров CleverTALK: регистрация открыта

Уже на следующей неделе начнётся новый сезон вебинаров CleverTALK, регистрация уже открыта. В программе: 12 ноября. Технический долг: как бороться с невидимым врагом. Ведущая: Светлана Сапегина. Регистрация 18 ноября. ITIL в 2020 и 2020 в ITIL: как этот год повлиял на содержание ITIL 4 и что в ITIL 4 может быть особенно полезным в 2021. Ведущие: Роман Журавлёв и Олег Скрынник. Регистрация 26 ноября. Ключевые принципы и практики высокопроизводительной продуктовой команды. Ведущий: Олег Скрынник. Регистрация 10 декабря. Опыт организации продуктовой команды: часть 2. Ведущая: Светлана Сапегина. Регистрация 17 декабря. Каталог услуг 2021 (тема уточняется). Ведущий: Дмитрий Исайченко. Регистрация

Технический долг: как не стать жертвой невидимого врага

Зачастую о техническом долге говорят как о плохо сделанной работе. Но брак есть брак, он порождает отходы, а не долги. А технический долг может накапливаться незаметно и становится видимым, только когда бороться с ним уже очень сложно. Когда на рынке открывается долгожданное окно возможностей, что вы выберете: адаптацию и развитие вашего продукта в максимально короткие сроки или проработку качества? Каждый раз выбирая скорость, вы закладываете бомбу замедленного действия под разработку, и очень важно вовремя остановить обратный отсчет, пока не произошло фатальных разрушений. Как понять, когда и какие действия по управлению техническим долгом следует предпринимать? Кто соучаствует в работе над техническим…

Технический долг и беклог

Не могу оторваться от темы беклога, ведь это именно то место, где принимаются решения. Продолжу о вопросах вокруг технического долга и способности команды инвестировать в его уменьшение. Идеальные продукты не существуют, каждый из них имеет свой набор компромисов. Модули и функциональные блоки приложений развиваются в разные стороны, с разной скоростью, для удовлетворения разных потребностей. Изменяются, форматы, масштабы, нагрузки, накапливаются данные. Работы по развитию выполняют люди. Инженеры принимают архитектурные и технические решения исходя из контекста конкретного момента. В какой-то момент, по прошествии времени, члены команды могут высказать пожелания по переработке отдельных компонентов приложения для того, чтобы существующий код и архитектура не…

Портал №1 по управлению цифровымии информационными технологиями

Практика и опыт

Портал №1 по управлению цифровыми
и информационными технологиями