Должностные инструкции нужны бизнесу не для кадровой папки и не для красивого порядка “на случай проверки”, а для того, чтобы работа перестала держаться на догадках. Пока команда маленькая и все друг друга понимают с полуслова, отсутствие внятной инструкции может долго казаться терпимым. Люди “и так знают”, кто за что отвечает, руководитель “всегда может объяснить”, а спорные зоны гасятся вручную. Но как только компания растёт, появляются новые сотрудники, меняются роли, добавляются клиенты, доступы, несколько уровней согласования и больше одного канала коммуникации, всплывает неприятная правда: без ясной инструкции роль начинает жить в голове руководителя, а не в системе.
Именно в этот момент у бизнеса возникают повторяющиеся и очень узнаваемые конфликты. Один сотрудник считает, что он задачу выполнил, а руководитель — что это был только промежуточный черновик. Другой говорит: “Это не моя работа”, и формально у компании нет быстрого и ясного ответа, где проходит граница его ответственности. Третий получает задачу устно, делает её “как понял”, а потом выясняется, что ожидался другой формат результата. На стыках ролей начинается трение: кто должен принимать задачу, кто должен её передавать дальше, кто отвечает за подтверждение результата, что считается завершением этапа и где вообще доказательство того, что работа действительно выполнена. Всё это редко выглядит как большая катастрофа в первый день. Чаще это проявляется как вязкая повседневная потеря скорости, раздражение руководителя, дублирование задач, обиды, споры и ощущение, что люди работают, а управляемости нет.
Поэтому должностная инструкция — это не “переписанный контракт” и не формальная памятка сотруднику. Это рабочий инструмент архитектуры роли. Она переводит ожидания из устной и эмоциональной зоны в управляемую: что делает роль, чего она не делает, где её входы и выходы, какие у неё интерфейсы с другими функциями, как оценивается результат, как фиксируются отклонения, как передаются задачи, в каком виде, кому и по какому критерию. Иными словами, инструкция — это способ превратить “человека в процессе” в понятную и воспроизводимую функцию внутри системы.
Это особенно важно там, где роль связана с клиентами, деньгами, документами, доступами, базами, внутренними шаблонами, согласованиями, handover между подразделениями или управлением чужими задачами. В таких местах размытость инструкции стоит дороже, чем кажется. Сначала это всего лишь “небольшое недопонимание”, потом — затянутое согласование, потом — срыв срока, потом — спор о зоне ответственности, потом — конфликт на выходе сотрудника, а иногда и потеря части контекста, потому что никто заранее не закрепил, что именно должно быть передано дальше и в каком виде.
Эта страница нужна тем, кто хочет не просто написать “список обязанностей”, а собрать должностную инструкцию как управленческий контур: роль, задачи, критерии “сделано”, KPI — только если они уместны, handover, стыки с другими ролями, порядок фиксации ошибок, обновление инструкции и её жизненный цикл. Если вам нужен документ более высокого уровня, который задаёт общие правила согласования, версий и полномочий внутри компании, полезно открыть Положения по организации. Если задача начинается ещё раньше — с условий отношений и кадрового контура роли, полезна страница Контракты с сотрудниками. Если проблема уже шире и затрагивает всю систему документов бизнеса, смотреть стоит на Договоры и документы для бизнеса. А здесь фокус уже на следующем слое: как сделать так, чтобы ежедневная работа перестала спорить сама с собой.
Хорошая инструкция не обещает чудес и не гарантирует отсутствие конфликтов. Но она резко снижает число серых зон, где раньше работали домыслы, привычки и ручные договорённости. А для собственника или руководителя это означает одну практическую вещь: меньше энергии уходит на бесконечное “разруливание”, и больше остаётся на управление и развитие.
Роль существует, а границ у неё нет. В компании есть менеджер, специалист, координатор, руководитель направления, но никто не может быстро показать, где заканчивается его ответственность и начинается чужая. Это критично, потому что без границ функция расплывается, а спор о ней становится бесконечным.
Задачи ставятся, но нет критериев “сделано”. Руководитель считает задачу незавершённой, сотрудник — завершённой. Это критично, потому что вся оценка результата начинает зависеть не от артефактов и контрольных точек, а от настроения и субъективного впечатления.
Есть обязанности, но нет связки с процессом. Инструкция перечисляет общие формулировки, но не показывает, в каком процессе роль работает и с кем взаимодействует. Это критично, потому что реальная работа живёт на стыках, а не в красивых абзацах.
Сотрудник регулярно делает “чуть больше” или “чуть не то”. Это часто признак не плохой воли, а плохой конструкции роли. Это критично, потому that размытая функция сначала создаёт перегруз, а потом — конфликт ожиданий.
В компании несколько похожих ролей. Например, менеджер, координатор, помощник руководителя, project-менеджер, специалист по документообороту. Это критично, потому что без разведения ролей сотрудники начинают дублировать задачи или перекладывать их друг на друга.
Есть handover между ролями, но он происходит хаотично. Задачи, документы, комментарии, статусы передаются в чатах и звонках, без понятного набора того, что считается переданным. Это критично, потому что потери почти всегда происходят именно на передаче.
KPI формально существуют, но вредят качеству. Такое происходит, когда метрики привязаны не к смыслу роли, а к удобству учёта. Это критично, потому that сотрудник начинает оптимизировать цифру, а не результат.
Новые сотрудники входят в роль слишком долго. Им приходится учиться через устные пояснения, личные сообщения и “наблюдение за старшими”. Это критично, потому что стандарт не передаётся через систему.
Руководитель постоянно объясняет одно и то же. Если один и тот же разговор о зоне ответственности повторяется еженедельно, проблема уже не в людях, а в отсутствии зафиксированной роли. Это критично, потому that руководитель становится ручным носителем стандарта.
При ошибках непонятно, это сбой роли, процесса или handover. Всё смешивается в один конфликт. Это критично, потому что организация не может учиться на сбоях и превращать ошибки в улучшения процесса.
Сотрудник уходит, и вместе с ним уходит часть контекста. Неясно, что именно он должен был передать, в каком виде и кому. Это критично, потому that инструкция не держит не только вход в роль, но и выход из неё.
Внутри компании есть разные ожидания от одной и той же роли. Руководитель функции хочет одно, собственник ждёт другое, HR понимает третье. Это критично, потому that инструкция, написанная без выравнивания ожиданий, начинает усиливать разночтения.
Инструкция есть, но она формальная и не используется. Такой документ чаще всего был написан “для наличия”, а не под реальный процесс. Это критично, потому कि наличие текста создаёт ложное чувство порядка.
Изменились процессы компании, а инструкции остались прежними. Это критично, потому that роль начинает жить в новой реальности по старому сценарию, и сотрудники либо вынуждены нарушать текст, либо тормозят процесс.
Есть задачи с повторяемым результатом, но нет стандарта приемки. Это критично, потому что каждая проверка результата превращается в отдельную импровизацию.
Человек работает хорошо, но компания не может объяснить, в чём именно его хороший результат. Это критично, потому that без языка результата нельзя ни масштабировать сильную практику, ни корректно обучать новых людей.
Шаг 1. Разобрать реальную функцию роли. Действие: описываем не название должности, а то, что человек реально делает, какие задачи ведёт, в каких процессах участвует, с кем взаимодействует и какой тип результата должен выдавать. Фиксация: карта роли, её входов, выходов и интерфейсов. Артефакт: исходная модель инструкции под живой процесс. Типичная ошибка: писать инструкцию “по должности”, не разобрав фактическую работу.
Шаг 2. Выделить зону ответственности и границы. Действие: отделяем “обязан”, “участвует”, “согласует”, “эскалирует”, “не отвечает”. Фиксация: блок границ роли и границ ответственности. Артефакт: раздел, который снимает споры “это не моя работа”. Типичная ошибка: писать только список задач без границ и исключений.
Шаг 3. Перевести обязанности в задачи и артефакты. Действие: каждая важная обязанность переводится в наблюдаемое действие и ожидаемый результат. Фиксация: таблица логики “задача → выход → кому передаётся → что считается принятым”. Артефакт: инструкция, по которой можно не только жить, но и проверять результат. Типичная ошибка: ограничиться декларативными обязанностями без понятного выхода.
Шаг 4. Определить критерии “сделано”. Действие: для ключевых задач задаём контрольные точки, критерии приемки и признаки незавершённости. Фиксация: done-criteria по типовым задачам. Артефакт: убирается серая зона между “сделал” и “сделано”. Типичная ошибка: считать, что смысл результата очевиден всем одинаково.
Шаг 5. Решить, нужны ли KPI вообще. Действие: проверяем, применимы ли для этой роли измеримые показатели и не сломают ли они процесс. Фиксация: либо блок KPI/метрик, либо осознанный отказ от них в пользу контрольных точек и артефактов. Артефакт: измеримость без вредной псевдо-математики. Типичная ошибка: добавлять KPI автоматически, потому что “так солиднее”.
Шаг 6. Описать интерфейсы взаимодействия. Действие: задаём, от кого роль получает задачи и данные, кому и в каком виде передаёт результат, кто подтверждает получение, что считается корректным handover. Фиксация: карта стыков и формата передачи. Артефакт: инструкция перестаёт быть текстом “про одного человека” и начинает работать как часть системы. Типичная ошибка: думать о роли отдельно от соседних функций.
Шаг 7. Собрать блок рисков, ошибок и эскалации. Действие: определяем, какие типовые сбои возможны, как они фиксируются, кому эскалируются и какие минимальные данные нужны для разбора. Фиксация: порядок реакции на ошибку или инцидент. Артефакт: роль становится управляемой не только в норме, но и при отклонениях. Типичная ошибка: считать, что достаточно прописать “несёт ответственность”, не определив, что считать отклонением и как оно фиксируется.
Шаг 8. Увязать инструкцию с контрактом и внутренними положениями. Действие: проверяем, чтобы инструкция не спорила с контрактом, положениями и иными смежными документами. Фиксация: карта связей и разграничение уровней документации. Артефакт: пакет документов по роли, а не набор противоречащих бумаг. Типичная ошибка: отдельно писать каждую бумагу и потом удивляться, что они говорят о разном.
Шаг 9. Прогнать инструкцию по жизненному циклу роли. Действие: моделируем путь “вход в роль → типовые задачи → handover → ошибки → изменение объёма задач → выход”. Фиксация: пробелы, лишние блоки, зоны недосказанности. Артефакт: инструкция, которая выдерживает жизнь, а не только чтение. Типичная ошибка: считать текст готовым, не проверив его на сценариях.
Шаг 10. Назначить owner инструкции и режим обновления. Действие: определяем, кто обновляет документ, как фиксируются правки, как сотрудники узнают о новой редакции. Фиксация: owner, цикл пересмотра, журнал версий. Артефакт: инструкция как живой стандарт. Типичная ошибка: сделать документ один раз и оставить его умирать в архиве.
Хорошая должностная инструкция редко работает в одиночку. Она держится на наборе артефактов, которые превращают роль из абстракции в систему. Ниже — практический чек-лист того, что полезно собирать, проверять и проектировать.
Описание реальной роли. Не только название позиции, а фактическая функция в процессе компании.
Перечень регулярных задач. То, что сотрудник делает ежедневно, еженедельно, ежемесячно или по событию.
Карта нерегулярных задач. Чтобы не смешивать ядро роли с эпизодическими поручениями.
Границы ответственности. Что входит в зону роли, что требует согласования, что не является её обязанностью.
Интерфейсы взаимодействия. От кого приходит задача, куда уходит результат, кто подтверждает приём.
Критерии приемки задач. Что считается завершением, а что — лишь промежуточным состоянием.
Список артефактов результата. Файл, письмо, карточка задачи, документ, отчёт, согласование, переданный комплект данных.
Чек-лист handover. Что и в каком виде передаётся между ролями и при выходе сотрудника.
Контрольные точки. Где результат проверяется и кем.
Логика эскалации. Когда роль может решать сама, а когда обязана выносить вопрос на другой уровень.
Порядок фиксации ошибок или инцидентов. Чтобы разбор отклонений не превращался в эмоциональный спор.
Метрики и KPI — только при необходимости. Причём с пониманием источника данных и побочных эффектов измерения.
Связь с контрактом. Чтобы инструкция не подменяла, но и не противоречила кадровому контуру.
Связь с внутренними положениями. Особенно по версиям, полномочиям, статусам документов и правилам взаимодействия.
Owner инструкции. Иначе она быстро деградирует в набор устаревших ожиданий.
Журнал изменений. Нужен, если роль или процесс компании меняются.
Пакет адаптации для новых сотрудников. Инструкция должна работать не только в конфликте, но и на входе.
Примеры типовых сбоев. Они позволяют писать документ под реальность, а не под красивую теорию.
Смежные роли и карта RACI — если применимо. Не как мода, а как способ убрать неясность в стыках.
Правила пересмотра инструкции. Чтобы смена процессов не оставляла текст в прошлом времени.
Главный принцип фиксации здесь простой: инструкция должна описывать не намерение, а проверяемый переход. Не “обязан качественно выполнять задачи”, а что именно сдаёт и в каком виде. Не “взаимодействует с другими подразделениями”, а с кем и по какому событию. Не “обеспечивает контроль”, а какой именно контроль, по каким точкам и где фиксируется результат. Как только текст уходит в слишком общие фразы, он перестаёт быть инструкцией и становится риторикой.
Что делаем: раскладываем реальную функцию роли на ядро задач, границы, интерфейсы и исключения.
Что фиксируем: перечень обязательных функций, зоны ответственности, что требует согласования, где кончается роль.
Что выдаём: раздел “роль / обязанности / границы” + карту взаимодействий.
Зачем это нужно: чтобы команда перестала спорить о базовых вещах и начала работать в одной логике.
Что делаем: переводим обязанности в повторяемые задачи с наблюдаемым результатом.
Что фиксируем: критерии приемки, контрольные точки, форматы результата и статус незавершённости.
Что выдаём: таблицу логики “задача → результат → критерий приемки → периодичность/событие”.
Зачем это нужно: чтобы разговор “сделано/не сделано” опирался на артефакты, а не на эмоции.
Что делаем: проверяем, нужны ли роли метрики, и если нужны — какие именно отражают её смысл, а не ломают его.
Что фиксируем: формулы, источники данных, период измерения, допустимые отклонения и контекст применения.
Что выдаём: блок KPI/метрик + правила измерения и отчётности, либо осознанный отказ от KPI в пользу иных контрольных критериев.
Зачем это нужно: чтобы не создавать вредные оптимизации и ложную управленческую ясность.
Что делаем: описываем, как роль получает задачи и как передаёт результат дальше.
Что фиксируем: входы, выходы, дедлайны, подтверждения получения, формат передачи и правила handover.
Что выдаём: регламент взаимодействия + чек-лист передачи.
Зачем это нужно: потому что на стыках ролей чаще всего теряется и скорость, и ответственность.
Что делаем: задаём, как фиксируются отклонения, какие данные минимально нужны для разбора и когда вопрос поднимается выше.
Что фиксируем: статусы инцидента, сроки реакции, минимум доказательств и путь эскалации.
Что выдаём: блок “риски / эскалация / ответственность” + сценарный план реагирования.
Зачем это нужно: чтобы ошибка становилась материалом для управления, а не только поводом для конфликта.
Что делаем: проверяем, можно ли по инструкции ввести человека в функцию без длинного устного переучивания.
Что фиксируем: минимальный пакет вводных, ключевые задачи первого периода, признаки того, что человек понял роль корректно.
Что выдаём: инструкцию, пригодную для onboarding, а не только для архива.
Зачем это нужно: чтобы новый сотрудник входил в систему быстрее и с меньшим числом искажений.
Что делаем: задаём правила обновления инструкции при расширении или сужении обязанностей.
Что фиксируем: кто инициирует изменение, кто утверждает, какая версия становится новой и где фиксируется переход.
Что выдаём: режим обновления инструкции и owner review.
Зачем это нужно: чтобы документ не начинал жить отдельно от компании.
Что делаем: описываем, как сотрудник завершает текущие задачи, передаёт материалы, статусы, контекст и незавершённые вопросы.
Что фиксируем: перечень handover-артефактов, подтверждение передачи и точки закрытия контекста.
Что выдаём: блок offboarding / handover, связанный с инструкцией и кадровым контуром.
Зачем это нужно: чтобы организация не теряла память вместе с человеком.
Что делаем: проверяем, кто будет владельцем инструкции, как команда узнаёт о правках и как стандарт не деградирует.
Что фиксируем: owner, цикл пересмотра, канал уведомления, правила обратной связи по качеству документа.
Что выдаём: инструкцию как живой стандарт, а не разовый файл.
Зачем это нужно: потому что без режима применения даже хороший документ быстро становится музейным экспонатом.
Ошибка: считать инструкцию вторичной по отношению к контракту. Возникает из мысли, что главное уже написано в кадровом документе. Последствие — ежедневная работа остаётся в серой зоне. Как предотвратить: разводить уровни документов. Что проверить сейчас: описывает ли контракт ваши реальные ежедневные задачи и критерии результата? Обычно — нет.
Ошибка: писать инструкцию под название должности, а не под фактическую роль. Последствие — документ не удерживает живой процесс. Как предотвратить: сначала описывать реальную функцию. Что проверить сейчас: совпадает ли то, что человек делает каждый день, с тем, что вы собираетесь закрепить?
Ошибка: список обязанностей без границ. Последствие — сотрудник не понимает, где его зона заканчивается, а руководитель считает, что “и так очевидно”. Как предотвратить: фиксировать не только обязан, но и границы, и interface points. Что проверить сейчас: где в вашей инструкции написано, чего роль не делает без отдельного согласования?
Ошибка: отсутствие критериев “сделано”. Последствие — бесконечные споры о качестве и завершённости. Как предотвратить: вводить артефакты результата и контрольные точки. Что проверить сейчас: можно ли по вашей текущей инструкции определить, в каком виде задача считается принятой?
Ошибка: KPI ради KPI. Последствие — вредные оптимизации и имитация управляемости. Как предотвратить: использовать метрики только там, где они действительно отражают смысл роли. Что проверить сейчас: не стимулируют ли ваши показатели сотрудника ухудшать качество ради числа?
Ошибка: полное отсутствие handover-логики. Последствие — потери задач и контекста на стыках ролей. Как предотвратить: описывать входы, выходы и подтверждение передачи. Что проверить сейчас: как роль передаёт результат следующему участнику процесса?
Ошибка: инструкция “для наличия”. Она существует, но никто ею не пользуется. Последствие — ложное ощущение порядка. Как предотвратить: писать под реальный процесс и прогонять через сценарии. Что проверить сейчас: когда последний раз кто-то реально ссылался на вашу инструкцию как на рабочий стандарт?
Ошибка: одна инструкция на разные роли. Последствие — документ становится либо пустым, либо противоречивым. Как предотвратить: отделять общее ядро и вариативные блоки. Что проверить сейчас: одинаковы ли по смыслу роли, для которых вы используете один шаблон?
Ошибка: нет owner-а инструкции. Последствие — документ устаревает без хозяина. Как предотвратить: закреплять владельца и период пересмотра. Что проверить сейчас: кто отвечает за актуальность текста?
Ошибка: не увязывать инструкцию с положениями и контрактом. Последствие — документы спорят друг с другом. Как предотвратить: делать связку пакета документов по роли. Что проверить сейчас: нет ли уже сейчас противоречий между обязанностями, контрактом и внутренними правилами?
Ошибка: не описывать ошибки и эскалацию. Последствие — при первом серьёзном сбое команда действует эмоционально и хаотично. Как предотвратить: задавать минимум для фиксации инцидента и эскалации. Что проверить сейчас: как у вас сейчас определяется, что проблема уже требует подключения руководителя?
Ошибка: обучение новых сотрудников идёт только устно. Последствие — стандарт живёт в носителях памяти, а не в системе. Как предотвратить: делать инструкцию пригодной для onboarding. Что проверить сейчас: сможет ли новый человек, прочитав пакет документов, понять роль без часового устного “перевода”?
Ошибка: не обновлять инструкцию при смене процесса. Последствие — текст остаётся в прошлом, а люди работают по новому. Как предотвратить: owner review после существенных изменений. Что проверить сейчас: соответствует ли инструкция текущему процессу компании или прошлому кварталу?
Ошибка: фиксировать только обязанности и не фиксировать результат. Последствие — роль становится списком действий без управляемого выхода. Как предотвратить: добавлять выходы и артефакты. Что проверить сейчас: что именно остаётся после выполнения каждой ключевой задачи?
Ошибка: считать, что хороший сотрудник сам “почувствует” границы. Последствие — часть ролей будет работать нормально только пока в них сидит сильный человек. Как предотвратить: строить систему, а не рассчитывать на талант носителя роли. Что проверить сейчас: переживёт ли ваша роль смену человека без просадки управляемости?
Ошибка: путать контроль с микроменеджментом. Последствие — инструкция становится инструментом давления, а не ясности. Как предотвратить: проверять не всё подряд, а ключевые контрольные точки и артефакты. Что проверить сейчас: где заканчивается полезный контроль и начинается лишняя нагрузка на роль?
Ошибка: не тестировать текст на конфликтных сценариях. Последствие — документ выглядит прилично, но разваливается при первой сложной ситуации. Как предотвратить: делать dry-run на сценариях входа, handover, ошибки и выхода. Что проверить сейчас: выдержит ли ваша инструкция вопрос “что делать, если задача передана без нужного комплекта данных?”
Ошибка: ожидать, что инструкция сама по себе уберёт все конфликты. Последствие — завышенные ожидания и неверная оценка инструмента. Как предотвратить: видеть её как часть системы управления, а не как магию. Что проверить сейчас: какие ещё элементы рядом должны работать вместе с ней?
“Это не моя задача”. Обычно означает, что границы роли не закреплены или закреплены плохо. Первый безопасный шаг: выделить три самые спорные зоны и описать, кто в них отвечает, а кто только участвует.
“Я думал, что результат должен выглядеть иначе”. Обычно означает отсутствие критериев приемки. Первый безопасный шаг: по типовым задачам определить, какой артефакт считается завершением.
“Мы снова потеряли задачу на передаче”. Обычно означает слабый handover. Первый безопасный шаг: описать минимальный формат передачи задач между ролями.
“Нового человека приходится долго вводить вручную”. Обычно означает, что инструкция не работает как инструмент onboarding. Первый безопасный шаг: проверить, можно ли по ней понять роль без устного сопровождения.
“Он хороший сотрудник, но после него другим тяжело подхватить работу”. Обычно означает, что роль держится на человеке, а не на системе. Первый безопасный шаг: собрать карту регулярных задач и выходов по роли.
“По KPI всё хорошо, а результата нет”. Обычно означает, что метрика оторвана от смысла роли. Первый безопасный шаг: проверить, не стимулирует ли показатель вредное поведение.
“Инструкция есть, но никто её не открывает”. Обычно означает формальный документ без связи с реальностью. Первый безопасный шаг: сравнить текст с одной-двумя реальными рабочими неделями роли.
“При ошибке все спорят, кто виноват”. Обычно означает отсутствие блока эскалации и фиксации инцидентов. Первый безопасный шаг: определить минимальный протокол разбора отклонения.
“Руководитель объясняет одно и то же каждую неделю”. Обычно означает, что стандарт живёт только в его голове. Первый безопасный шаг: выбрать самый повторяющийся блок объяснений и превратить его в часть инструкции.
“Роль изменилась, но бумаги ещё не обновили”. Обычно означает конфликт между текстом и реальностью. Первый безопасный шаг: определить, какие изменения уже нельзя оставлять без новой редакции.
“У нас несколько людей в одной функции, но каждый работает по-своему”. Обычно означает отсутствие общего ядра роли. Первый безопасный шаг: выделить неизменяемый стандарт и вариативные части.
“Человек ушёл, и выяснилось, что часть задач была только у него в голове”. Обычно означает отсутствие не только handover, но и описания выходов роли. Первый безопасный шаг: по каждой ключевой задаче определить обязательный выход и место хранения.
“Качество работы оценивается по впечатлению”. Обычно означает, что критерии результата не сформулированы. Первый безопасный шаг: заменить общие слова на проверяемые признаки завершения.
“Каждый руководитель понимает роль по-своему”. Обычно означает, что ожидания по роли не были выровнены до написания инструкции. Первый безопасный шаг: собрать ожидания ключевых стейкхолдеров и найти расхождения до фиксации текста.
Ситуация: в небольшой компании долго работал сильный специалист, который закрывал широкий круг задач и сам удерживал контекст роли. Когда на его место пришёл новый человек, начались постоянные вопросы и провалы на типовых действиях.
Ранний признак: у команды не было единого описания, что именно входит в роль и какой результат по ней ожидается.
Ошибка: принять сильного исполнителя за доказательство сильной системы.
Правильное действие: пересобрать роль через регулярные задачи, выходы, критерии приемки и точки handover.
Артефакт: инструкция стала переносить функцию между людьми, а не только описывать абстрактную должность.
Ситуация: руководитель считал, что сотрудник системно не доводит задачи до конца. Сотрудник, в свою очередь, был уверен, что закрывает всё, что ему ставят.
Ранний признак: в задачах не было форматов результата и правил приемки — только общий список действий.
Ошибка: считать, что обе стороны одинаково понимают завершённость задачи.
Правильное действие: ввести по ключевым задачам критерии “сделано” и артефакты результата.
Артефакт: качество стало обсуждаться не в общем, а по наблюдаемым признакам.
Ситуация: для роли ввели числовые показатели “для контроля”, но сотрудник начал оптимизировать цифры в ущерб качеству handover и полноте данных.
Ранний признак: формально показатели росли, а у смежных ролей увеличивалось количество возвратов и уточнений.
Ошибка: измерять то, что удобно считать, а не то, что отражает реальный результат.
Правильное действие: пересмотреть, какие метрики допустимы, а где лучше оставить контрольные точки и критерии приемки.
Артефакт: система измерения перестала стимулировать вредные оптимизации.
Ситуация: сотрудник в своей части работал нормально, но задачи постоянно “терялись” между ним и следующим участником процесса.
Ранний признак: никто не мог быстро сказать, что именно считается корректно переданным пакетом задачи.
Ошибка: описать роль без интерфейса взаимодействия с соседними ролями.
Правильное действие: встроить в инструкцию блок handover: вход, выход, дедлайн, подтверждение получения.
Артефакт: инструкция начала работать как часть цепочки, а не как isolated документ.
Ситуация: компания изменила внутреннюю структуру, перераспределила задачи и ввела новые инструменты, но инструкции остались старыми.
Ранний признак: сотрудники либо игнорировали текст, либо постоянно “докручивали” его устно.
Ошибка: не назначить owner-а инструкции и не задать цикл обновления.
Правильное действие: ввести owner review и журнал правок при существенных изменениях процесса.
Артефакт: инструкция снова начала описывать реальность, а не исторический архив.
Контракт фиксирует условия отношений, а инструкция — ежедневную механику роли: обязанности, границы, взаимодействия, результат и контрольные точки. Это разные уровни управления.
Размытые роли, отсутствие критериев “сделано”, слабый handover и противоречие между ожиданиями руководителя и тем, что документно закреплено.
Да, но только если метрики действительно отражают смысл роли и не провоцируют вредные оптимизации. Не каждой роли KPI нужны как центральный инструмент.
Сами по себе обязанности без критерия результата мало что держат. Обычно управляемость появляется там, где роль связана с выходом, артефактом и правилом приемки.
Да, особенно если роль несёт клиентский, документный или координационный контур. В маленькой команде одна размытая роль часто бьёт сильнее, чем в большой.
Не “косметически править” слова, а пересобрать её под реальный процесс: границы роли, задачи, done-criteria, интерфейсы и handover.
Иногда можно иметь общее ядро, но почти всегда нужны вариативные блоки. Полная одинаковость ролей в реальном бизнесе встречается редко.
Да, если роль влияет на сроки, деньги, документы, клиентский контур или передачу задач. Тогда инструкция должна держать не только норму, но и отклонение.
Через задачи, артефакты результата, контрольные точки, интерфейсы взаимодействия и правила handover между ролями.
Нет. Но хорошая инструкция заметно снижает число серых зон и делает разбор конфликтов менее хаотичным и более предметным.
С наиболее критичных ролей — там, где проходят деньги, клиенты, документы, координация или высокий риск потери контекста. Не нужно пытаться описать всё сразу одинаково глубоко.
Если в компании уже накопились повторяющиеся вопросы “кто это делает”, “когда задача считается завершённой”, “почему у нас опять потеря на передаче”, начинать лучше не с красивого шаблона, а с диагностики самой роли. Это безопаснее и полезнее: сначала увидеть реальную функцию, а не сразу украшать документ.
Что подготовить для продуктивного старта:
Текущую инструкцию, если она уже есть, даже если кажется формальной или слабой.
Краткое описание того, что человек реально делает в течение недели или месяца.
Примеры типовых задач и в каком виде по ним должен оставаться результат.
Список основных точек взаимодействия с другими ролями.
Примеры конфликтов или недоразумений: “не моя работа”, “не так поняли результат”, “потеряли на передаче”, “неясно, кто отвечает”.
Информацию о том, есть ли у роли KPI, и если есть — как они сейчас считаются.
Понимание, менялась ли роль за последний год и отражено ли это в документах.
Первый безопасный шаг здесь обычно выглядит так: карта роли + три самые частые задачи + один типовой конфликт на стыке ожиданий. Это обратимо, быстро даёт данные и позволяет не тратить силы на декоративную переработку документа. Критерий остановки для dry-run простой: если уже видно, где именно у роли размыта ответственность, чего не хватает в критериях “сделано” и на каком стыке чаще всего теряется задача, значит дальше можно собирать инструкцию предметно и без воды.
Артефакты на выходе:
Должностная инструкция под реальную роль. Не общая болванка, а документ, отражающий фактическую функцию.
Блок обязанностей и границ ответственности. С чётким разделением ядра роли, участия и исключений.
Карта задач и артефактов результата. Чтобы было понятно, что именно остаётся после выполнения ключевых задач.
Критерии “сделано”. По основным задачам и типовым результатам роли.
Блок KPI/метрик — если применимо. Или аргументированный отказ от KPI в пользу иных контрольных критериев.
Карта интерфейсов взаимодействия. Кто кому передаёт задачу, результат, документы и контекст.
Чек-лист handover. Для передачи задач, статусов и контекста между ролями.
Блок рисков и эскалации. Как фиксируются ошибки и когда подключается следующий уровень.
Owner инструкции и режим обновления. Чтобы документ не деградировал после запуска.
Критерии готовности:
По инструкции понятно, где границы роли и где начинаются соседние функции.
По ключевым задачам есть не только обязанность, но и критерий результата.
Команда понимает, в каком виде задача считается переданной и принятой.
Если KPI используются, они не спорят со смыслом роли и не провоцируют вредные оптимизации.
Инструкция не противоречит контракту и внутренним положениям.
Новый сотрудник может понять роль быстрее и с меньшим количеством устных “расшифровок”.
При dry-run на живых сценариях документ выдерживает вопросы по задачам, handover, ошибкам и изменениям.
Есть owner инструкции и понятный режим пересмотра текста.
Количество серых зон “это не моя работа” и “не так поняли результат” начинает снижаться хотя бы на уровне наблюдаемой операционной нагрузки.
Договоры и коммерческие сделки — родительский раздел и навигация по кластеру.
Контракты с сотрудниками — предыдущая услуга и кадровый контур роли.
Сопровождение благоустройства территорий зданий — следующая услуга по порядку раздела.
Положения по организации — если нужно закрепить правила согласования, версии и полномочия на уровне компании.
Договоры и документы для бизнеса — если вы собираете уже не один документ по роли, а систему документов под процесс.
Договорной аудит: 10 договоров за 5–7 дней — если сначала нужно быстро увидеть пробелы и приоритеты правок по текущему пакету.
Услуги для бизнеса — возврат к общей витрине.
Инструкция должна фиксировать, за что отвечает роль, какие задачи обязательны, а где границы. Это снижает конфликты и делает управление предсказуемым.
Если нет критериев приемки задачи, начинается спор “сделано/не сделано”. Мы задаём критерии результата и контрольные точки.
Метрики нужны не всем ролям. Там, где они уместны, KPI должны быть измеримыми и привязанными к процессу, иначе они ломают мотивацию и качество.
Сбои чаще всего на стыках ролей. Инструкция должна описывать входы/выходы: что принимаем от других ролей и что выдаём дальше.
Ошибки неизбежны. Важно, чтобы они фиксировались корректно и превращались в улучшение процесса, а не в конфликт.
Инструкция работает только если ею пользуются. Мы добавляем чек-листы, правила обновления и контроль соблюдения, чтобы стандарт не деградировал.
Фиксируем роль и зоны ответственности, чтобы убрать “это не моя работа” и снизить разночтения.
Переводим обязанности в измеримые результаты и критерии приемки, чтобы управление было доказуемым.
Настраиваем метрики без “вредных оптимизаций”: формулы, источники данных и правила измерения.
Описываем handover между ролями: входы/выходы, дедлайны, подтверждения получения.
Задаём порядок фиксации ошибок/инцидентов и критерии переключения режима реагирования.
Даем чек-листы под роль и процедуру обновления инструкции, чтобы стандарт “жил”.
