Ранее я писал, как совершенно точно не получить повышение на работе. Сегодня хотел бы рассказать, как гарантированно не стать профессиональным руководителем и навечно остаться «управляющим бровями».

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

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

Но перед этим прочтите, пожалуйста, пост Дениса Сиденко про «управление бровями» (Линкадин под блокировкой, чтобы блок отобразился, поставьте какой-нибудь плагин с автоматическими прокси или врубите vpn):

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

Хочешь сделать хорошо — сделай сам.

Лучшего программиста делают тимлидом. Лучшего продавца — РОПом. Лучшего дизайнера — арт-директором.

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

Есть хорошее мысленное упражнение. Начать управлять так, как будто вам оторвало руки. То есть, вы можете ставить задачи голосом и письменно, но не можете сами ничего делать. Обучать (об этом ниже), мотивировать, координировать можно.

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

Невозможно быть руководителем на 80 %. Вы либо управляете, либо исполняете. А кроме того, невозможно управлять системой, будучи её частью.

Не обучать

Обучать трудно и страшно. Трудно, потому что умственно тяжело систематизировать собственные, часто хаотичные знания. Да и некогда, потому что см. предыдущий раздел. Страшно, потому что у выучившегося сотрудника вырастут зарплатные запросы, он может уволиться или вас подсидеть. Поэтому он никого никогда не обучает и не отправляет на обучение. Только вот увы, отдел опять не растёт. И любая проблема, которая будет прилетать в ваше подразделение, будет решаться только вашими руками.

Да и в конце концов, вас же никто ничему не учил, вы всё сами постигли, правильно? Чем они лучше?

Рост зарплатных аппетитов — это нормально. И это ваша забота, время от времени наведываться к вышестоящему начальству и убеждать, что фонд оплаты труда не должен быть ниже фонда рекрутинга.

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

Что касается подсиживания. Если ваш топ-менеджер или гендиректор или кому вы там подчиняетесь, такое допускает, это к лучшему, работать на него не надо.

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

Давать распоряжения и инструкции только устно

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

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

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

Да, тут есть другая крайность. Можно дорегламентироваться до многостраничных мануалов, которые будет трудно воспринимать (как, например, в айти-подразделениях «Комуса»). Но в целом, и это лечится, просто не требуйте от новичков знания их наизусть, пусть ознакомятся и разок на практике их пройдут и всё получится. Читайте правило про обучение.

Не давать сколько-нибудь детальных планов

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

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

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

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

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

Не координировать людей

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

Важная для недоменеджера особенность отсутствия координации — в случае неудач будет очень легко найти виноватых.

Понимание того, что вы делаете важную и востребованную работу, очень важно, оно уменьшает выгорание и повышает производительность.

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

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

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

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

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

Бизнес-проблема

Не стесняйтесь в начале инструкции написать причину, по которой она возникла. Иными словами, бизнес-проблема, которую она решает. Например: «В детализациях для подрядчиков, в каждой задаче в обязательном порядке должен быть указан НМА, чтобы вести по ним учёт капитализации. Чтобы избежать ошибок, был внедрён механизм автоматического поиска задач, закрытых в данном месяце без указания НМА с выгрузкой списка таких задач в таблицу, чтобы менеджеры могли его просмотреть и руками указать НМА. Инструкция описывает, как это сделать». Пусть читающему будет понятно, зачем именно эта инструкция нужна. 

Указание должности

Достаточно очевидный пункт, но о нём почему-то забывают. Обязательно указывайте, для кого предназначена эта инструкция. Новички, отправленные знакомиться с инструкциями, будут благодарны за понимание, какие документы им читать, а на какие можно забить. 

Пишите простым языком

Когда я только начинал карьеру в должности системного аналитика, шеф постоянно твердил мне: «Твои концепты, планы, техзадания, инструкции должны быть написаны так, чтобы их мог прочесть и понять любой сотрудник компании, от гендиректора до уборщицы». Наверное, для техзаданий такое упрощение нужно не всегда, но инструкции и регламенты нужно стремиться описывать максимально простым языком, никаких бинормальных функций деструптивного лаплассиана. Если вводите специфический термин — напишите расшифровку.

Пишите, как делать правильно

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

Доступность

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

Краткость

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

Простота названий

Давайте файлам или страницам с инструкциями очень простые и понятные названия. Книги Ильяхова про пиши сокращай вам в помощь. Если инструкция описывает, как давать оптовым клиентам скидки, назовите её: «Скидки для оптовых клиентов». Не надо придумывать МБОУ ГБУ ЛСДУЗ ЙЯФЯЮ.

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

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

— А почему ты не сделал %действие%?
— Не знал, что его нужно делать. / Не знал, что это — моя сфера ответственности.

Импульсивный руководитель может сказать: «Не хотите по-хорошему? Нате тогда вам регламент!» и зарегламентировать всё подряд. Плохой подход. Опыт показывает, что разработка ПО — сфера «постоянных изменений». Регламент необходим, но он не должен быть похож на проверку самолёта на готовность к вылету.

 

Зачем нужен регламент?

Плюсы:

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

Минусы:

 В условиях «постоянных изменений» нужно не лениться держать регламент актуальным.
 Для «творческих» сотрудников составить регламент можно далеко не всегда.

Регламент необходим, когда:

 В компании больше одного отдела.
 Регулярно возникают повторяющиеся проблемные ситуации.

 

Типичные ошибки

Самых частых ошибок три:

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

 

Алгоритм подготовки регламента.

01	Определение предмета регламента. Осознаём, что именно мы регламентируем. Например: «Регламент работы аналитика: Правила проведения первичной оценки запроса».
02	Определение ответственного. Отвечет за составление регламента ключевой сотрудник, в компетенции которого находится осуществление данного процесса. Например: «Руководитель отдела анализа и проектирования».
03	Собрание. Критично, если описываем процесс, предполагающий участи сотрудников нескольких подразделений. Например: Руководитель отдела анализа и проектирования приглашает для беседы руководителя отдела внедрения, главу техподдержки и главу отдела прямых продаж, объясняет, почему процесс первичной оценки регламентируется. Формируется общая позиция о том, как должен проходить процесс, утрясаются ожидания.
04	Описание процесса. Ответственный сотрудник обсуждает процесс с коллегами и готовит описание ключевых шагов. Иногда на этом этапе выясняется, что есть несколько способов выполнить тот или иной шаг — это возможная точка оптимизации. Также может оказаться, что исходная цель поставлена некорректно, нужен не один, а целая группа регламентов.
05	Рецензия. Первые рецензенты итогового документа — специалисты, которым предстоит данный регламент соблюдать. Фиксируем замечания и предложения, обдумываем, вносим корректировки. Затем документ отправляется сотрудникам, которых собирали на третьем этапе для финальной рецензии.
06	Утверждение. Регламент визируется генеральным директором или директором по развитию, формируется приказ о вступлении в силу, текст размещается в основном хранилище регламентов.

Компоненты регламента

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

 Название и назначение процесса.
 Владелец, инициатор, участники, контролёр процесса.
 Правила запуска процесса.
 Входной артефакт(ы).
 Основной сценарий.
 Выходной артефакт(ы).
 Правила завершения процесса.
 Диаграмма процесса.

Вторая часть — более детальная информация:

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

 

Пример регламента

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

Владелец: Руководитель отдела анализа и проектирования.
Инициатор: Любой сотрудник отдела внедрения, отдела продаж, отдела поддержки.
Участники: Сотрудники отдела анализа и проектирования.
Контролёр: Глава департамента разработки.

Правила запуска процесса:
Инициатор вносит запрос в бэклог, запрос проходит приоритезацию (См. регламент работы с бэклогом) и получает место в общей очереди.
Владелец, получив от сотрудника отдела анализа и проектирования (далее «аналитик») информацию о том, что у него менее двух запросов в активной фазе (См. общие правила работы сотрудников отдела анализа и проектирования), на своё усмотрение выбирает запрос из первой пятёрки очереди и переводит его на этого аналитика.

Входной артефакт:
Правильным образом заполненный запрос в общем бэклоге (См. регламент работы с бэклогом) в состоянии «Первичная оценка».

Основной сценарий:
Аналитик уточняет у инициатора актуальность запроса.
Аналитик организует телекон с представителем заказчика для уточнения бизнес-проблемы.
Аналитик запрашивает у менеджера продукта, кто из разработчиков может проконсультировать по оценке.
Аналитик объясняет разработчику суть бизнес-проблемы, разработчик предлагает решение и оценку.
Аналитик применяет к оценке поправочные коэффициенты (См. формулы первичной оценки).
Аналитик вносит в запрос оценку, уточнённую бизнес-проблему и выработанный вариант реализации.
Аналитик формирует документ «Первичная оценка» (См. пример документа).
Аналитик отправляет документ «Первичная оценка» инициатору.
Аналитик переводит запрос в состояние «Согласование первичной оценки.

Выходной артефакт:
Запрос бэклоге имеет состояние «Согласование первичной оценки», заполнены поля бизнес-проблемы, варианта реализации и оценки в часах.
Документ «Первичная оценка», отправленный инициатору.

Правила завершения процесса:
Положительный сценарий: Инициатор подтверждает готовность заказчика к этапу точной оценки, аналитик переводит запрос в состояние «Очередь для точной оценки», инициализируется процесс точной оценки (См. регламент точной оценки)
Отрицательный сценарий: Инициатор сообщает об отказе заказчика от доработки, аналитик переводит запрос в состояние «Отменено».

Диаграмма:

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

Управление изменениями

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

Общие правила изменения регламентов:

 Регламент обязателен для соблюдения.
 Любой участник процесса может предложить пересмотреть регламент.
 Регламент пересматривается в рамках отдельной встречи.
 По итогам встречи изменения обязательно вносятся в текст регламента.
 Изменения обязательно публикуются в виде приказа.

Необходимы два инструмента: хранилище регламентов и система информирования. 

Хранилище регламентов Лучше всего подходит корпоративная вики. Создаём страницу с базовым регламентом, ссылаемся на дочерние регламенты. Очень важно организовать хранение и доступ так, чтобы у пользователи легко могли найти любой регламент. Вариант чуть хуже — набор документов в Google Docs.

Система информирования Оптимально — корпоративный портал. Приказ в виде поста, пользователи могут нажать специальную кнопку/голосование, чтобы показать, что они с приказом ознакомились. Вариант чуть хуже — рассылка по email. Главное — организовать информирование так, чтобы об изменениях узнали все участники процесса.

 

Резюме

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

P. S. Вот хороший пост о регламентах из телеги: