Недавно нам понадобилось оформить должностные инструкции для разработчиков. Раньше таких документов не было, поэтому готового процесса их обсуждения тоже не существовало. Можно было собрать совещание, разослать файл с правками или просто подготовить окончательный вариант от лица руководства.
Вместо этого мы завели репозиторий в GitLab.
Если документ описывает работу программистов, почему бы не редактировать его так же, как мы редактируем код?
Руководитель как maintainer
Я сам вырос из разработки: был программистом, затем тимлидом, а позже перешёл в руководство. Разработка при этом никуда из моей жизни не исчезла. Я по-прежнему отвечаю за фронтенд-направление и обычно хорошо понимаю, как управленческие решения выглядят с другой стороны.
У руководителя в такой ситуации есть соблазн решить всё самостоятельно. Кажется, что это быстрее: внимательно прочитать документ, убрать лишнее, добавить нужное и принести готовый результат. Тем более команда привыкла доверять руководителю защиту своих интересов.
Но должностная инструкция касается не только руководителя. Она описывает работу людей, которые каждый день будут жить с её формулировками. Поэтому мне хотелось дать им не символическую возможность «оставить замечания», а нормальный способ менять текст.
Получилась знакомая разработчикам модель: руководитель не единственный автор документа, а скорее его maintainer.
Документ как код
Исходный документ мы перевели из офисного формата в Markdown и положили в отдельный проект. Основную ветку защитили, всем участникам дали возможность создавать ветки и merge request, а спорные или достаточно крупные вопросы стали оформлять как issues.
Каждое изменение можно было обсуждать отдельно. Кто-то предлагал новую формулировку, кто-то задавал вопрос в комментариях, после обсуждения текст обновлялся и отправлялся на повторное согласование. Небольшие независимые изменения не мешали друг другу, а история решений сохранялась автоматически.
Финальное утверждение всё равно оставалось за директором. Для него пришлось завести аккаунт и коротко показать, как устроен GitLab: где читать изменения, как оставлять комментарии и как ставить approve. В этом была определённая ирония: обычно руководство внедряет сотрудникам новые процессы, а здесь разработчики принесли руководству merge request.
При этом Git не превратил процесс в голосование. Ответственность никуда не исчезла, и последнее слово осталось у того, кто отвечает за документ. Изменилось другое: до принятия решения каждый мог предложить поправку, увидеть аргументы остальных и понять, почему в итоговую версию попала именно эта формулировка.
Что получилось
Документ довольно быстро перестал быть монолитным файлом, который кто-то один правит целиком. Обсуждение разделилось на конкретные темы: обязанности, границы ответственности, уровни разработчиков, названия должностей. Одни изменения приняли сразу, другие уточняли в несколько заходов, третьи могли не пройти согласование.
Это оказалось удобнее общего совещания. На совещании несколько тем неизбежно смешиваются, разговор уходит в сторону, а формулировки приходится восстанавливать по памяти. В issue остаётся вопрос, в merge request — точное решение, а в комментариях — контекст. К обсуждению можно вернуться через день и продолжить с того же места.
Ещё одно преимущество — изменения стали небольшими. Не нужно было принимать или отвергать весь документ сразу. Можно согласиться с одной поправкой и не согласиться с другой. Для внутренних регламентов это особенно полезно: большой официальный текст часто выглядит незыблемым просто потому, что непонятно, с какого места начинать его менять.
Демократия не означает всеобщего участия
Я ожидал, что процесс заинтересует большую часть отдела. На практике активно участвовали только три человека. Остальные читали, но не предлагали изменений — или вообще решили не тратить на это время.
Сначала это немного разочаровало. Возможность высказаться была, инструмент всем знаком, тема касается каждого. Казалось, что должны включиться почти все.
Но право участвовать не создаёт обязанность участвовать. У людей есть основная работа, свои приоритеты и разная чувствительность к формулировкам в регламентах. Кроме того, в команде уже сложилось доверие: многие считают, что руководитель внимательно проверит документ и при необходимости защитит их интересы. Такое доверие снижает желание самостоятельно разбирать каждый пункт — и это тоже нормальный выбор.
Зато обсуждение названий должностей привлекло заметно больше людей. Это было ближе, конкретнее и напрямую связано с профессиональной идентичностью. Оказалось, что уровень участия зависит не только от открытости процесса, но и от того, насколько человек чувствует связь вопроса с собой.
Из молчания вообще трудно делать однозначные выводы. Оно может означать согласие, доверие, нехватку времени или просто отсутствие интереса. Поэтому открытый процесс важен не количеством комментариев, а тем, что молчание не является единственно доступным вариантом.
Что здесь технологического
GitLab в этой истории не был просто хранилищем файлов. Он задал правила взаимодействия:
- исходный текст всегда доступен;
- основную версию нельзя незаметно переписать;
- любая правка имеет автора;
- разные предложения можно обсуждать независимо;
- решение и его аргументация остаются в истории;
- участвовать можно асинхронно и без отдельного совещания.
Ничего из этого не требует именно Git. То же самое можно организовать и другими средствами. Но для программистов GitLab уже является рабочей средой: им не нужно осваивать ещё одну корпоративную систему и привыкать к ещё одному формату обсуждений. Знакомый инструмент резко уменьшает расстояние между мыслью «здесь что-то не так» и конкретным предложением по изменению текста.
Несколько выводов
Техно-демократия — не когда все голосуют за каждую запятую. Это скорее устройство процесса, при котором возможность влиять на решение встроена в используемые инструменты.
Такой процесс не отменяет иерархию и не снимает ответственность с руководителя. Он делает эту иерархию прозрачнее: видно, кто предложил изменение, кто его обсудил, кто согласовал и какая версия стала итоговой.
Он также не гарантирует массового участия. Открыть двери — ещё не значит, что все захотят войти. Но даже несколько заинтересованных участников могут заметно улучшить результат, а остальные сохраняют возможность подключиться тогда, когда вопрос действительно окажется для них важным.
Для меня главным результатом стал не сам документ. Интереснее оказалось проверить, можно ли применить привычную культуру разработки к управленческой задаче. Оказалось, что можно: дробить большую проблему на issues, предлагать решения отдельными ветками, обсуждать конкретный diff и собирать общую версию через review.
Возможно, небольшому отделу и не нужна демократия в масштабе парламента. Иногда достаточно защищённой основной ветки и права каждого открыть merge request.