Бюрократия или нет

— Вот ты про доки пишешь. Бюрократию мы и сами можем наплодить.
Как это всё должно реально помогать, а не стать ведром воды с бумагой?

Ждал этого вопроса и да, «выношу из комментов», нравится мне это дело.
Особенно нравится тем, что в хорошем вопросе уже есть половина ответа.

Правильный вопрос и сомнение заключается именно в практической, прикладной нужности: не документо-писателям, а реальному рабочему процессу.

Вот вам первый простой ответ. Для каждого дополнительного документа должно быть прямо и непосредственно понятно, как именно он приносит пользу, и какую проблему решает.

Все остальные (для которых проверка не выполняется) по умолчанию записываются в балласт и бюрократию. Их надо или убрать, или доработать. Пользу всегда надо доказать, и уметь ее доказывать, с примерами и с практической частью.

Первый критерий: функция

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

Они не всегда обязательны, и не все документы такие. Но с функциональными документами сложнее накосячить.

В общем случае, для «документов» должно быть понятно и даже прописано:

• для чего он
• какую задачу решает / проблему адресует
• как им пользоваться
• когда им пользоваться
• кто его использует / кто обязан, кому обязан

Не стесняйтесь прописать это в самом документе.
Пример:

• Здесь написано о том, чем мы руководствуемся в своих инженерных решениях.
• Чтобы наши решения работали предсказуемо, со стандартами качества и единообразно.
• Написаны общие принципы, и предметные чеклисты. Принципам надо соответствовать, чеклисты надо проверять.
• Любое инженерное решение, которое мы выкатываем наружу или внутри, нужно сверить с этим документом, а расхождения — обработать и адресовать.
• Используется всегда, пока явно не указано обратное (с причиной).
• Любой сотрудник любой инженерной группы и компании целиком должен руководствоваться этим документом и имеет право предполагать, что коллеги делают точно так же.
• Расхождения между желаемым (документ) и действительным (реальность) должны быть выявлены, и получить план по исправлению
• Расхождения может заметить и отметить любой сотрудник, а контролировать соответствие и исправлять — руководители инженерных групп и их подчиненные сотрудники

Вот вам практический пример, отвечающий на вопрос «как конкретно эта штука должна у нас работать». Написано конкретно, понятно, и лежит в предсказуемом месте (прямо в документе). Сказать «я не в курсе был» уже не получится.

В этом примере пункты еще недостаточно подробные, чтобы быть готовой инструкцией; тем не менее, они описывают, что «с этим всем» описанным следует человеку делать, и как. Подробные детали уже далее можно найти в процессе («пофиг как», лишь бы результат) или прописать отдельно уже предметными руководствами (когда «не пофиг, как»).

Функция и функциональность может существовать не для конкретной бумажки, а для конструкции целиком. Но она должна быть.

Пример конструкции:
— есть стандарт (ГОСТ) чего угодно, он определяет требования и результаты
— есть нормы (СН), они определяют принципы и подходы, чтобы соответствовать требованиям
— есть договор и/ли регламент, у него есть функция: надо делать по нормам, чтобы результат соответствовал стандарту

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

Второй критерий: польза

Следом вторая проверка. «Как это всё должно помогать», из исходного вопроса.
Вот вы мне и ответьте. Любой документ, принцип, подход, регламент, должен уметь приносить пользу и описание, как конкретно он должен это сделать.

Польза должна быть конкретной и целевой.

• конкретная: в чем именно заключается полезное действие, и как оно соотносится с затратами. Потому что бюрократия не бесплатная, процессы не бесплатные. Люди и задачи не бесплатные. Если дрочки явно больше чем пользы, конкретность страдает — сумма отрицательная. Хочется положительную (и кстати, как вы собираетесь её мерить?).
• целевая: кому конкретно эта польза должна поступить. Причем в рабочих процессах и в целевой функции в разрезе бизнеса, а не самим бюрократам чтобы оправдать собственную нужность. Регламенты ради регламентов, и процессы ради процессов — достаточно вредная и весьма дорогая затея. Бывает так, что пахать придется одним, а пользу получат другие. Так бывает, структуры сложные; но сделайте это как минимум понятным и прозрачным.

Ограничения и рамки нужны для увеличения пользы, не наоборот.

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

Мерить пользу «вчера в деньгах, сегодня в часах, завтра в рисках» — вот так нельзя. Величина и подход должны обеспечивать сравнимость (а больше ничего не должны).

Третий критерий: практичность

Документы предполагают рамки, ограничения и требования. Так надо, так не надо. Так хотим, так не хотим.

Если бы у вас практика уже соответствовала вашим представлениям о прекрасном, вам и документы нафиг не нужны — зачем, всё и так хорошо, очевидно же. Значит, практика или уже отличается, или может отличаться. А это риски и потенциальные проблемы. Проблем вы не хотите.

Практичность — это про описание жесткости требований к практике. И у жесткости есть кривая эластичности.

• Слишком жесткие требования = «бесполезный закон», жесткость которого компенсируется невыполнимостью (и на него кладут болт, ввиду оторванности от реальности).
• Слишком мягкие требования = забавная «хотелка», которую игнорируют ввиду необязательности (кладут болт, ввиду отсутствия ответственности).

Истину придется искать посередине, и в процессе корректировать, подкручивать.

Это приводит нас к заключительному критерию:

Критерий maturity

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

Проблемы вы решаете инструментом; не заранее, а по необходимости.

Обычно лампочка меняться не хочет. Бардак несущий, разброд ситуативный, исполнители чего-то делают и оно как-то работает.

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

Хорошие подходы становятся best practices, операции — инструкциями, критерии — чеклистами, ожидания — регламентом, цепочки — процессами.
Подростковый бунт («шапку надень — ну мааам!») и неизбежные острые края нужно пережить, осознать пользу, донести её до людей.

Осознанное решение «нет, нам тут пока рано в формализацию», не доросли — это нормальное решение.

Иногда разные части, отрасли, отделы, сферы растут и взрослеют в разном темпе. Некоторые не взрослеют никогда, им важно оставаться экспериментальными, со всем сопутствующим бардаком (у которого есть смысл и профит). Окей, тоже не беда. Каждому своё и в свое время.

В сухом остатке: если бюрократическая часть не проходит указанные критерии — её нужно или выкинуть, или переделать (выкинуть и переделать).

Не надо стесняться заново оценить, и даже выбросить неоптимальное. Мир меняется, потребности меняются.

Hope that helps.