Выбор типа командной структуры определяется двумя ключевыми факторами: структурой задачи, стоящей перед командой, и окружающей средой, в которой команда работает. Если задача четко определена, состоит из независимых частей и не требует нестандартных решений, то предпочтительнее команда, построенная на деловых отношениях. Такие задачи могут быть например, рутинным техническим обновлениям, где важно соблюсти сроки и качество. Если же задача требует инноваций, творческого подхода или решения проблем с высокой неопределенностью, то эффективнее будет команда с сильными социальными связями. Важно также учитывать внешнюю среду: в агрессивной или токсичной среде более стабильны команды на деловой основе, тогда как в стабильной и дружественной среде могут эффективно работать команды-«семьи».

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

Эффективные методы работы с системным сопротивлением организации включают: 1) Формирование коалиции поддержки изменений из руководителей разных уровней и подразделений. 2) Создание видения изменений, которое резонирует с ценностями и целями организации. 3) Разработка плана изменений с четкими этапами и промежуточными результатами, поддающимися измерению. 4) Усиление коммуникации на всех уровнях организации для уменьшения неопределенности и слухов. 5) Выявление и поддержка первых сторонников изменений, создание сети адвокатов преобразований. 6) Предоставление обучения и ресурсов, необходимых для успешной адаптации к изменениям. 7) Внедрение пилотных проектов для демонстрации успешности подхода в ограниченном масштабе. 8) Изменение системы вознаграждений и показателей эффективности для поддержки новых поведений. 9) Постоянный мониторинг прогресса и оперативная корректировка плана изменений. 10) Укрепление новых практик через интеграцию в процессы, системы и культуру организации, чтобы предотвратить возврат к старым методам.

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

Абсолютная безопасность и поддержка в продуктовой команде невозможны, потому что команда работает в условиях коммерческой деятельности, где результат напрямую связан с возвратом инвестиций. Каждый потраченный рубль на развитие, обучение и комфорт должен иметь обоснование и приносить выгоду. Кроме того, участники команды являются наемными специалистами, их мотивация в первую очередь связана с личными интересами, и если команда не докажет свою эффективность, ее могут расформировать. Состав команды динамичен - люди переезжают, переходят на другие должности, выгорают, что делает понятие полной защищенности нереалистичным.

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

Основные проблемы при внедрении сервисно-ресурсной модели включают стремление заказчиков «внедрить слона» — попытку сразу перейти на высокий уровень зрелости, не проходя промежуточные этапы. Часто проектные команды сталкиваются с перегрузкой функционалом, когда пытается «засунуть» в проект максимальное количество «фишек». Это приводит к сложности поддержки системы в промышленной эксплуатации и непониманию реальной ценности многих внедренных элементов.

Ценность «гарантии» обеспечивает уверенность в том, что добавленная ценность через развитие (utility) не будет обесценена из-за недоступности или некачественной работы услуги. Она измеряется через комбинацию доступности услуги, активной пользовательской базы и управления рисками (снижение негативных или усиление положительных). Ценности «полезности» (основная разработка) и «гарантии» не суммируются, а перемножаются, поэтому игнорирование «гарантии» может обнулить общий результат.

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

Принцип разделения полномочий в контексте RBAC заключается в том, что критически важные операции должны выполняться разными людьми, чтобы предотвратить мошенничество или ошибки. Например, в банковской системе один сотрудник (роль "Операционист") может инициировать платеж, но его проведение должно быть одобрено другим сотрудником (роль "Контролёр"). Эти полномочия не могут быть объединены в одной роли и не могут быть назначены одному сотруднику. Это обеспечивает взаимный контроль и повышает безопасность операций, минимизируя риски, связанные с злоупотреблением полномочиями.