Как GitLab сохраняет скорость решений: практика DRI

Ситуация: входящих мнений много, а решения нет

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

GitLab описывает другой порядок работы: у каждого решения есть Directly Responsible Individual, или DRI. Этот человек ведёт работу, собирает данные, оценивает варианты и принимает решение. Важно не само название роли. Важна ясность, у кого находится следующий шаг, когда мнения уже собраны

Как устроен механизм

В handbook GitLab принят двухфазный подход. Сначала команда собирает входящие данные и точки зрения. Затем DRI принимает выбор. Участники могут дать информацию и возражения, но право закончить решение не растворяется между всеми комментаторами

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

Практика поддерживается документом. В разделе о принятии решений GitLab ссылается на шаблон decision issue. А в инженерных процессах компания предписывает фиксировать решения в issues с понятными названиями, метками и ссылками на связанную работу. Так следующий участник видит не только итог, но и контекст, из которого он появился

Где это применено в действительности

Это не внешняя рекомендация GitLab для клиентов. DRI описан как принцип работы самой компании. GitLab применяет роль для проектов, инициатив и направлений работы, а в руководстве по большим инженерным инициативам закрепляет раннее назначение DRI за планированием и декомпозицией проекта

В handbook есть и операционный пример: команда инфраструктуры назначает DRI для эпика, закрепляет за ним основное право решения в своей области и требует документировать решение в GitLab issues. Внутри компании это связывает распределённую работу, асинхронные комментарии и один момент, когда выбор должен быть сделан

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

Что здесь близко к МетаРешениям

МетаРешения требуют не угадывать правильный ответ, а сделать основание выбора видимым: где факт, где допущение, чья перспектива нужна и какая улика может изменить курс. DRI создаёт для этого управленческую рамку:

Вопрос -> владелец -> данные и перспективы -> варианты -> выбор -> запись основания -> пересмотр при новой улике

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

Как применить в небольшой компании

На ближайшей развилке назначьте одного DRI. Это может быть не собственник, а тот, кто ближе всего к задаче и сможет собрать материал. До выбора попросите его заполнить одну страницу:

Если DRI не может назвать критерий пересмотра, решение пока выглядит как уверенное мнение. Если владельца нет, следующий шаг почти наверняка зависнет на согласовании

Если хотите разобрать такую развилку до того, как она превратится в цепочку встреч, пройдите мини-разбор МетаРешений

Источники

Разберите одну управленческую развилку

Пять вопросов помогут отделить факт от версии и выбрать следующий проверяемый шаг

Пройти мини-разбор