Команды являются средоточием производства в организациях. Они создают программный продукт и обеспечивают его поставку. Как и любое средство производства, команда требует внимания и своевременного ухода. Компаниям необходимо следить за тем, чтобы когнитивная нагрузка на команду не была чрезмерной (о том, что такое “когнитивная нагрузка“, мы рассказывали в одной из наших предыдущих заметок), поскольку работа в условиях слишком высокой когнитивной нагрузки не позволит эффективно и надёжно создавать и улучшать разрабатываемое программное обеспечение. В своей заметке на IT Revolutions Мэтью Скелтон (Matthew Skelton) и Мануэль Пайс (Manuel Pais) продолжают рассматривать тему и рассказывают об обнаружении и ограничении когнитивной нагрузки для того, чтобы обезопасить поток от снижения скорости и мощности.
Оценка уровня когнитивной нагрузки
Простой и быстрый способ оценить когнитивную нагрузку – это задать команде вопрос (без тени двусмысленности и осуждения, без какого-либо подтекста): «Считаете ли вы, что вы эффективны и способны своевременно реагировать на работу, которую вас просят выполнить?». Хотя это и неточный показатель, ответ поможет в целом понять, чувствуют ли себя члены команды перегруженными.
Если ответ явно отрицательный, организации могут провести дополнительные исследования, чтобы понять, по каким причинам когнитивная нагрузка настолько высока, и предпринять необходимые шаги для её снижения, гарантировав тем самым, что команда снова сможет быть эффективной и проактивной. Дополнительно это повысит и уровень мотивации в команде, поскольку её члены увидят ценность и цели в выполняемой работе.
Бывает, что некоторые компании пытаются оценить предполагаемый уровень когнитивной нагрузки путём использования простых показателей: количество используемых классов, методов, модулей. Такой подход ошибочен, поскольку языки программирования отличаются по этим параметрам друг от друга – у каких-то языков их больше, у каких-то меньше. Команды, использующие больше абстракций и к тому же повторно уже созданные куски кода, будут иметь меньшие, но не обязательно более простые кодовые базы.
То, что действительно должно волновать и заботить при оценке когнитивной загрузки – сложность той предметной области (домена) и проблем, которые решаются при помощи разрабатываемого ПО. Идея использования домена при оценке когнитивной нагрузки гораздо более применима, чем размеры кодовых баз различных языков программирования. Например, для создания и поддержания работы конвейера непрерывной поставки потребуется объединить внушительное число различных инструментов интеграции и тестирования и определённый объём кода для автоматизации. Однако, по абсолютным величинам его объём будет на порядки меньше, чем необходимо для разработки пользовательского приложения.
Использование ограничений в соответствии с уровнем когнитивной нагрузки
Одним из наименее заметных и осознаваемых факторов, создающих помехи при поставке современного программного обеспечения, является постоянно увеличивающийся размер и сложность кодовых баз, с которыми приходится работать командам. Это создает практически неограниченную когнитивную нагрузку на команды. Также это имеет отношение и к командам, не занятым напрямую написанием кода – традиционным командам сопровождения ПО и эксплуатации ИТ-инфраструктуры.
При использовании командного подхода обязанности команды ставятся в соответствие текущей когнитивной нагрузке, с которой она может справиться. Вызванный этим положительный эффект, может повлиять на то, как будут организованы команды, и как они станут взаимодействовать друг с другом в пределах компании. Для команд, участвующих в поставке ПО, такой подход означает применение ограничений на размеры разрабатываемых систем и подсистем, то есть организации не должны позволять разрабатываемой системе вырасти за пределы когнитивной нагрузки команды, ответственной за её разработку.
Что произойдёт, если ввергнуть команду в стрессовое состояние, вызванное выходом когнитивной нагрузки за пределы возможностей? Команда прекратит действовать как высокопроизводительная единица, распадётся и начнёт вести себя как слабо связанная группа отдельных сотрудников, каждый из которых пытается выполнить свои индивидуальные задачи, и которых не заботит, а отвечает ли то, что они делают, интересам команды.
Ограничение когнитивной нагрузки для команды означает ограничение размера подсистемы или области, над которой работает команда. Также команде нужен запас, чтобы на постоянной основе планомерно уменьшать объёмы внутренней и внешней когнитивной нагрузки, с которыми им приходится иметь дело в настоящее время (с помощью обучения, практики, автоматизации и любых других удобных способов).
Использование ограничений на количество и типы доменов
Для начала идентифицируйте и выделите домены, с которыми должна иметь дело каждая команда, и проклассифицируйте их согласно следующим типам:
- простые (большая часть работы имеет чёткую и понятную последовательность действий);
- сложные (необходимо анализировать изменения в течение нескольких итераций с тем, чтобы выйти на верное решение);
- комплексные (необходимо провести множество экспериментов и исследований, чтобы выйти на решение).
Затем нужно детально сравнить домены между собой: как относится домен А к домену Б? Имеет ли он схожую сложность или сложнее (проще)? Нужно убедиться, что классификация доменов правильная.
Общие рекомендации по доменам и командам
1. Каждому домену – по команде.
Назначьте на каждый домен одну команду. Если домен слишком велик, вместо разделения ответственности внутри одного домена между несколькими командами, разделите домен на поддомены, а затем назначьте каждый из них отдельной команде.
2. Одна команда на два-три простых домена.
Команда должна справляться с двумя-тремя простыми доменами. Простые домены обычно чётко регламентированы, затраты на переключение контекста между ними являются небольшими и приемлемыми, так как взаимодействие строго задано и находится в узких границах. Примером простого домена для команды может быть “старая” ИТ-система, в которую эпизодически вносятся незначительные простые изменения. В данном распределении существует риск снижения мотивации членов команды из-за более рутинного характера их работы.
3. Один комплексный домен на одну команду и ничего более.
Команде, ответственной за комплексный домен, не следует более назначать доменов, даже простых. Это связано с потерями, связанными с нарушением течения потока работы (решение сложных проблем требует времени и концентрации) и расстановкой приоритетов (команда будет склонна решать простые и предсказуемые проблемы в моменты их возникновения, что вызовет задержки в решении сложных проблем, которые и являются наиболее важными для бизнеса).
4. Одна команда на один сложный домен.
Необходимо избегать случаев, когда одна команда будет ответственна за два сложных домена. На первых порах кажется, что большой команде из восьми или девяти человек это вполне по силам, но на практике команда будет вести себя как две подгруппы (по одной на каждую область), а ожидается, что каждый из членов команды будет знать об обеих областях, что увеличивает когнитивную нагрузку и затраты на внутреннюю координацию. Вместо этого лучше разделить команду на две отдельные команды по пять человек (наняв еще одного или двух членов), чтобы каждая из них могла быть более сфокусированной на своей области и автономной.
Соответствие размеров разрабатываемого ПО когнитивной нагрузке
Чтобы команды разработки программного обеспечения оставались эффективными и могли успешно развивать свои продукты, необходимо устанавливать границы на размеры разрабатываемых ими подсистем и систем. Вместо того, чтобы проектировать систему абстрактно, следует чётко понимать и очерчивать её границы, чтобы они соответствовали приемлемой когнитивной нагрузке в связанных командах разработки. Вместо того, чтобы выбирать между монолитной архитектурой или архитектурой микросервисов, нужно ориентироваться на доступную ёмкость максимальной когнитивной нагрузки команд. Только тогда можно надеяться на устойчивую, безопасную и быструю поставку ПО. Такой подход к определению границ и размеров ПО приводит к предрасположенности к определенным стилям программной архитектуры, таких как небольшие независимые сервисы.
Для увеличения доступной ёмкости когнитивной нагрузки команды и, соответственно, размеров разрабатываемых подсистем и систем, необходимо создать определённую экосистему, в которой будет работать команда, чтобы максимизировать её когнитивные способности за счет уменьшения внутренних и внешних типов нагрузки:
- обеспечьте командную рабочую среду (физическую или виртуальную);
- сведите к минимуму отвлекающие факторы команды в течение рабочей недели, ограничив собрания, уменьшив количество рассылаемых писем, назначив специальную команду или человека для обработки поступающих запросов и т. п.;
- измените стиль управления, сообщая о целях и ожидаемых результатах, а не зацикливаясь на способах (“как?”) выполнения;
- повысьте качество взаимодействия с разработчиками (DevEx) из других команд с помощью хорошей документации на разработанный код и API, чёткости и последовательности, хорошего UX и других практик DevEx;
- используйте такую платформу разработки, что специально предназначена для снижения когнитивной нагрузки команд, создающих программное обеспечение на её основе.
Активно уменьшая когнитивные издержки с помощью этих и аналогичных подходов, организации могут обеспечить командам больше когнитивной ёмкости для выполнения более сложных вещей в разрабатываемых системах. И наоборот, если в организации нет подходящих для командной работы офисных помещений, передовых методов управления и платформы, поддерживающей командную работу, тогда размер разрабатываемых подсистем и систем, с которыми могут справляться команды, будет меньше. Большее количество мелких деталей требует, чтобы над ними работало больше команд, что требует уже бóльших затрат. Принятие и использование подхода к определению границ и размеров разрабатываемых подсистем с учётом когнитивной нагрузки означает более довольные команды разработки и, в конечном итоге, общее снижение затрат.
