Пишем должностные инструкции

Как показывает мой опыт, есть три варианта работы с должностной инструкцией:

• знать, что она должна быть (или даже есть в компании), но никогда её не читать;
• прочитать должностные инструкции при трудоустройстве и забыть о них;
• прочитать её, руководствоваться ей при работе и, при необходимости, предлагать её обновление и улучшение.

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

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

Почему мы мало читаем должностные инструкции?

Немного неожиданных для меня фактов о другом документе - пользовательском соглашении, которое каждый из нас подписывает при установке программы на мобильный телефон, планшет или ноутбук:

• пользовательское соглашение от Майкрософт по размеру между произведениями «Макбет» и «Искусство войны»;
• в среднем активный пользователь популярных онлайн сервисов должен потратить около 250 часов на чтение пользовательских инструкций;
• 97% пользователей в возрасте от 18 до 34 лет не читают соглашений.

Почему так происходит?

На мой взгляд, есть 2 причины:

1. Как правило, мы устанавливаем приложения в момент, когда у нас есть какая-то проблема и нам надо срочно её решить, а это возможно именно с данной программой. Например, нам надо заказать такси, когда мы куда-то опаздываем, или заказать еды когда голодны и т.д. Как вывод: у нас нет времени читать огромный текст с множеством юридических формулировок, нам надо как можно быстрее получить то, ради чего мы и начали скачивать приложение.
2. Пользовательское соглашение составляется компанией-разработчиком с множеством юристов. Все детали соглашения продуманы и в большинстве случаев, на стороне компании-разработчика. Отсюда второй вывод: даже если нам что-то не понравится, ради нас никто это соглашение менять не будет и у нас только 2 варианта: подписать соглашение или никуда не уехать/остаться голодным и т.д. без приложения.

Что в итоге? В итоге мы подписываем не читая и скорее переходим к получению благ от использования приложения.

Должностные инструкции встречаются в похожей ситуации. Нам её дают в первый рабочий день для ознакомления и подписания. У нас такой же выбор: подписать ее и идти менять мир к лучшему, а также зарабатывать деньги на себя/семью/путешествие/ипотеку (а мы ведь ради этого приходим устраиваться в компанию), или уйти домой и остаться безработным. Поэтому видя огромный и сложный документ большинство решает его просто подписать.

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

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

Как сделать  простое и полезное описание роли?

В РФ есть структура, которую следует использовать когда оформляются должностные инструкции (Федеральная служба по труду и занятости: Письмо N 3042-6-0 от 09.08.2007):

В итоге мы получаем достаточно объемный документ, в котором всё, что должен делать сотрудник, собрано не в один список, а разбито по разным блокам согласно структуре.

Чтобы сократить объем текста, объединим всю информацию на 2 категории:

• Обязанности;
• Знания и умения, которыми надо обладать, чтобы хорошо справляться с обязанностями.

В рамках описания  обязанностей следует перечислить регулярные задачи, которые должен выполнять любой человек в этой роли. Важно! Здесь не должно быть всех возможных задач, которые когда-либо кто-либо на просторах интернета описал в своей вакансии или резюме. Задача - ёмко перечислить зоны ответственности с минимально достаточной детализацией (в конце концов речь идёт об аналитиках, кто должен работать не по скрипту, а проектировать новые решения).

Например: 

• Сбор требований по разрабатываемой системе с заказчика;
• Разработка и согласование проектной документации: ТЗ, ОПЗ, ЧТЗ, ПМИ;
• Оценка объема работ аналитика в предстоящем проекте и т.д.

Если у вас ещё нет должной инструкции, то подумайте над вопросами ниже при ее составлении:

• Должен ли аналитик работать с заинтересованными лицами? Если да, то как?
• Должен ли аналитик собирать требования? Если да, какие требования и какими техниками?
• Должен ли аналитик проектировать какие-либо решения? Если да, то какие? Архитектурные? Проектировать пользовательский интерфейс?
• Должен ли аналитик описывать требования к системе? Если да, то по ГОСТу или при использовании других подходов?
• Должен ли аналитик утверждать требования? Если да, то с кем?
• Должен ли аналитик управлять требованиям? Если да, то как?
• И т.д.

Чтобы продолжить этот список вопросов, может помочь моя статья, в которой разобран профстандарт системного аналитика и перечислены направления работы, которые соответствуют той или иной должности.

В результате у нас должен получиться список примерно из 10-20 задач. Больше писать точно нет смысла, их сложно запомнить. 

Как описать границы роли?

Часто встречала, что одни и те же задачи могут выполняться разными ролями в зависимости от компании, отдела или проекта. Например: 

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

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

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

Что нужно знать, чтобы справиться с задачами?

На этом этапе, имея список задач, за которые отвечает сотрудник в этой роли, можно составить и список знаний и навыков, которые ему необходимы.

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

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

• Компетенции и требуемые знания конкретизированы. Например, если сотруднику требуется проектировать бизнес-процессы, то ему достаточно знать нотацию BPMN, а не "все международные нотации".
• Компетенции и требуемые знания должны быть измеримы, то есть должно быть понятно, как будете проверять их уровень и какие результаты сочтёте достаточно хорошими. Например, если в работе требуется использование разговорного английского, то вы можете указать минимальный уровень, начиная с которого, сотрудник сможет выполнять рабочие задачи. Также у вас самих должен быть достаточный уровень языка, чтобы в этом убедиться (или у вас есть тот, кто может проверить уровень английского языка сотрудника за вас).
• Компетенции и знания должны быть необходимы для выполнения перечисленных ранее задач. Нет смысла спрашивать то, что не применяется. Если когда-нибудь появится новый вид задач, то добавятся и новые требуемые знания. Исключения бывают. Например, когда вы знаете стратегию развития компании и отдела и понимаете, что эти навыки пригодятся в ближайшем будущем. 
• Этими компетенциями и знаниями может обладать один человек с соответствующим должности уровнем опыта. То есть если речь идёт о роли стажёра (это, как правило, студент ВУЗа), то не надо от него ожидать 3 лет опыта работы, успешно сданных проектов и свободным владением пятью языками программирования.

Как итог, это похоже на своего рола SMART-критерии, когда мы ставим цели: 

• S — Specific — конкретной;
• M — Measurable — измеримой;
• A — Achievable — достижимой;
• R — Relevant — значимой;
• T —Time bound — ограниченной во времени.

Пример знаний и компетенций для системного аналитика:

• Профильные знания системных аналитиков:
  • Подходы к сбору требований: проблемное и решенческое интервью, анкетирование и т.д.
  • Подходы к описанию требований: User Story, JTBD, Сценарии использования
  • Нотация UML для проектирования решений
  • Нотация BPMN для моделирования бизнес-процессов 
  • …
• Технические знания из разработки ПО:
  • Способы интеграций систем: REST, SOAP и т.д.
  • Проектирование логической схемы БД
  • Написание SQL-запросов для выборки данных
  • …

Заключение

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

Надеюсь, мне удалось убедить вас в нужности описании роли, поэтому добавлю ещё немного общих рекомендаций уровня "спасибо, Кэп!":

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

Удачи и пусть ваши должностные инструкции применяются в работе!

Обязательно собирайте по ним обратную связь с вашей команды и регулярно обновляйте, чтобы план (инструкция) и факт (реальные задачи) совпадали ;)