Любой производственный процесс сильно зависит от уровня зрелости команды, которая этот процесс исполняет. Команда с низким уровнем зрелости сможет исполнить простой процесс, при этом он должен быть досконально описан. Команда с высоким уровнем зрелости сможет выполнить сложный процесс, при этом нет необходимости вдаваться в детали, поскольку что-то команда будет делать просто в силу своей высокой зрелости.
При оценке уровня зрелости команд возникают проблемы, связанные с тем, что для каждой команды уровень зрелости определяется своим собственным набором критериев. Одна команда считает себя зрелой потому, что просто используют Git для хранения исходного кода, другая — с выстроенной моделью ветвления, защищенной основной веткой, тегировнием, — считает себя незрелой из-за того, что еще не может внедрить практику обратных слияний в ветки разработки.
Технический менеджмент нуждается в объективной и единой для всех команд оценке уровня зрелости для того, чтобы понимать, насколько принятый процесс разработки может быть реализуем, и в каком направлении команды должны расти.
Помочь в этом должна модель зрелости команд. Модель зрелости — это набор критериев, связанных с принципами, процессами и практиками, которым должны соответствовать команды, чтобы считаться зрелыми. Хорошо прописанная модель зрелости помогает понять возможность исполнения командой её обязанностей и определить зоны роста команды. Её задача — выровнять в командах одновременно уровень и полноту принципов, процессов, практик, технологий и инструментов, которые мы считаем необходимыми для работы.
Модель зрелости или, как мы её еще называем, «Чек-лист зрелости» — это таблица, в которой собраны критерии, позволяющие определить, каким уровнем зрелости обладает команда. В общем случае все критерии можно сгруппировать в три группы: принципы, процессы и практики.
Раздел «Принципы» содержит критерии, которые должны помочь выяснить соответствие «образа мыслей» команды тому, что требуют принятые в Банке подходы разработке. Если команда ментально не готова нести ответственность за продукт целиком, а видит в нем только код, который ей надо написать — она не сможет работать в рамках продуктового подхода. Поэтому в первую очередь мы хотим понять «идеологию» команды. Наперед скажу, что этот раздел наиболее сложен для оценки.
Следующий раздел — «Процессы» — позволяет понять, насколько хорошо команда ознакомлена с внутренними процессами и как они функционирую с «технической» точки зрения. Если метрики процесса позволяют нам понять, что процесс в целом не работает так, как надо, то контрольный лист по процессу дает нам понимание, почему именно это происходит. Наряду с метриками, оценка зрелости команд по процессам позволяет получить обратную связь и выявить «узкие места» в организации деятельности.
Наконец, третий раздел — «Практики» показывает внутреннюю возможность команды осуществлять свою деятельность. Там мы определяем, обладает ли команда, как единое целое, набором технических компетенции и владением необходимыми инструментами, позволяющими ей осуществлять свою деятельность.
Фактически, наша матрица зрелости построена на базе трех «китов»:
- Возможность выполнения деятельности — «практики»
- Готовность выполнения деятельности — «принципы»
- Правила выполнения деятельности — «процессы»
Также для каждого критерия из чек-листа зрелости определяется, как именно оценивается данный критерий, к кому в команде можно обратиться с вопросом по данному критерию и тип оценки (про оценки будет рассказано позже).
Надо отметить, что модель зрелости не является скрижалью, выбитой в граните. Она может меняться со временем, с появлением новых потребностей в навыках, которыми должна владеть команда, или с отказом от инструментов, которыми мы пользовались ранее. Матрица зрелости — живой организм, в развитии которого должны принимать участие все сотрудники.
Поскольку наш чек-лист зрелости начинался с оценки правильности соблюдения производственных процессов, нам было важно понимать, что процессы функционируют на должном уровне стабильно, в течение длительного времени, и существует заинтересованность команд в улучшении этих процессов. Поэтому в качестве оценки была принята шкала следующего вида:
- Никогда — команда никогда не соответствовала критерию
- Иногда — редко, но команда удовлетворяет критерию
- Регулярно — команда удовлетворяет критерию на регулярной основе, хотя есть периоды времени, когда критерий не соблюдается
- Постоянно — команда постоянно соответствует критерию зрелости
Из шкалы видно, что для нас важны исторические данные по оценке зрелости. Оценка зрелости для нас — это не какая-то одномоментная акция, когда мы оценили уровень зрелости и забыли, а постоянный непрерывный процесс.
Понятно, что существуют критерии, которые сложно оценить по такой шкале. Например, критерий «Команда использует корпоративный GitLab для управления версиями исходного кода», который был добавлен в момент перехода на GitLab, скорее всего не может быть оценен по вышесказанной шкале. Ответ «иногда» в этом случае звучит достаточно глупо. Для таких критериев шкалу упростили до варианта «Да/Нет», где «Да» соответствует оценке «Постоянно», а «Нет» — «Никогда». Соответствие оценок нужно для получения единообразных результатов.
Непосредственно определение уровня зрелости команды проводится в двух форматах:
- Самооценка силами команды
- Аудит сторонним сотрудником
Поскольку, как мы говорили выше, для нас важен постоянный прогресс команд и их соответствие всем новейшим требованиям, оценка проводится один раз в квартал. Один раз команда оценивает себя сама, а в следующий раз проводится аудит силами технического менеджмента. Аудит со стороны необходим для коррекции погрешностей самооценки команды и увеличения ее объективности. Оценка может искажаться как в сторону повышения — «завышенная самооценка», так и в сторону понижения — «заниженная самооценка». Какие-то команды считают, что «и так сойдет» и ставят себе оценку «Постоянно», а кто-то, страдая, видимо, комплексом самозванца может поставить себе «Иногда» на устоявшуюся практику.
Модель зрелости содержит пояснения, как правильно оценить критерий, а также указание на роль, к которой в первую очередь мы должны обратиться с вопросом об оценке критерия. Полученные результаты мы фиксируем в опросном листе. На основании данных опросного листа формируется диаграмма, так называемый «Радар зрелости» который показывает соответствие уровня зрелости команды требования технического менеджмента. Глядя на «Радар зрелости», мы можем определить проблемные места и сформировать вектор развития команды на следующий квартал.
Также мы агрегируем оценки по всем командам, чтобы получить «среднее по больнице». В этом случае «Радар зрелости» покажет нам, какие именно элементы проседают для всех команд в целом. Это явный признак недоработки технического менеджмента и руководителей функциональных подразделений. Понимание таких проблем помогает сфокусировать работу технического менеджмента над повышением уровня зрелости компании в целом.
Команды не должны воспринимать оценку зрелости, как инструмент деления команды на хорошие и плохие, с последующим наказанием плохих.
В первую очередь модель зрелости — это инструмент, в котором нуждаются сами команды. Она показывает, где в команде существуют проблемные места, которые помешают ей хорошо выполнять свою работу. Команда сама должна стремиться к оценке своего уровня.
Оценка зрелости — это как поход на профилактический осмотр к врачу. Никто не накажет вас за ухудшившееся зрение или за повышенный холестерин. В первую очередь это нужно вам, чтобы скорректировать свою дальнейшую жизнь.
Модель зрелости выгодна и техническому менеджменту, и самим командам. Технический менеджмент получает объективную унифицированную оценку способности команд выполнять поставленные перед ними задачи. Модель зрелости определяет направления работы технического менеджмента по росту инженерной культуры в Банке, задавая единую планку, к которой надо стремится.
Для команды это возможность понять свои сильные и слабые стороны, а также возможность постоянного прогресса, понимания, какого уровня необходимо достичь и к чему стремится.
Плюсом является стандартизация подходов на всем производстве. Людям становится проще переходить из команды в команду, проще становится организовать совместную работу команд над какими-то сложными решениями, улучшаются коммуникации.
Модель зрелости также способствует внедрению новых подходов и саморазвитию команд. Как говорилось выше, модель зрелости не является чем-то незыблемым, она постоянно изменяется, подстраиваясь под изменение компании. И инициатором этого изменения может являться команда, освоившая новый инструмент, или сформировавшая новый подход.