«У нас есть один человек… Без него ни шагу. Он всё знает. Всё чинит. Но если он уйдёт — мы пропали». Слышали такое? Почти в каждой компании, где хоть как-то автоматизирован учёт или бизнес-процессы, есть он. Вокруг него миф, ореол, лёгкий ужас. Ему можно писать в любое время дня и ночи. Он в отпуске — но как будто нет. Он — тот, кто знает, «где лежит нужная галка в настройках», и «что там не так с РСВ по 6-НДФЛ за третий квартал».
Именно он спасал ваш релиз за ночь. Именно он дописал отчёт, «как просили». Именно он держит в голове больше бизнес-правил, чем ваш ERP. Он — эксперт с руками. Бесценный. И… потенциально опасный.
Пока он рядом — всё хорошо. Но представьте, что он заболел. Или уволился. Или просто перегорел. Система зависнет. Команда — в ступоре. Руководство — в панике. Вы — в поиске кадров и психотерапевта.
Кто такой «эксперт с руками»?
На первый взгляд — мечта любой компании. Он быстро реагирует. Делает то, что другим «ещё надо обсудить». Знает систему вдоль и поперёк. Может за 15 минут накатить отчёт, который вы обсуждали месяц. И, если честно, часто спасает ситуацию.
Но вот парадокс: чем больше он делает — тем сильнее на нём всё держится. А значит, зависимость растёт. И если этот человек внезапно выпадет из процесса, вся конструкция может рухнуть как карточный домик.
Таких людей особенно много среди опытных 1С-разработчиков, которые помнят ещё 7.7, писали на 1С 8.1, и знают, как оно на самом деле устроено в базе. У них за плечами десятки внедрений, конфигурации, доработки, интеграции с любыми API. Они привычны к авралам и считают себя неотъемлемой частью бизнес-процесса компании.
Почему так получается?
- Исторически сложилось: был один человек, дали ему задачу, он справился — дали ещё. Потом ещё.
- Нет процессов: когда задачи появляются по принципу «вот письмо, посмотри», никто не думает об архитектуре или разделении труда.
- Культура «героев»: в некоторых компаниях ценится не системность, а «пожаротушение». И у кого шланг длиннее, кто быстрее потушил – тот и победил.
- Формат внедрения «на коленке»: когда проект внедрялся без методологии, без схем, без описания. Всё работает? Работает, ну и хорошо. А кто сделал, чтоб работало? Ну, вы знаете…
Почему это опасно?!
На первый взгляд — всё под контролем. «У нас же есть Коля, он всё знает». Да, знает. Да, делает. Но вот беда: знания, которые не распределены, превращаются в угрозу. И чем глубже этот эксперт укореняется в системе, тем опаснее его отсутствие — временное или навсегда.
1. Риски для бизнеса
Полный стоп при потере человека. Уехал в отпуск. Попал в больницу. Уволился. Просто выключил телефон. И всё — цепочка остановилась: обмен с ФГИС «Меркурий» не идёт, расчёт зарплаты не сходится, документы не печатаются. Система, на которую вы потратили миллионы, работает только при наличии одного человека. Звучит как плохая шутка.
Упущенная выгода и паралич развития. Вы хотите перейти на новую версию УТ? Мигрировать в облако? А Коля говорит: «Не сейчас, там всё сложно». И всё. Вы заложник не технических ограничений — а его загруженности.
2. Риски для проектов.
Невозможность планировать ресурсы. Планируете задачу? Надо спросить Колю. Сколько займёт? Скажет Коля. А если занят? Ждём. А если заболел? Откладываем. Проект управляется не системой — а одним человеком.
Завал по срокам и объёмам. Коля может не сказать, что не успевает. Он привык справляться. Он герой. Но у героев нет менеджеров задач. В итоге: всё критичное — в его голове, а в таск-трекере — тишина. Это опасный контур управления, когда проблемы становятся видимыми только при пожаре.
3. Риски для команды
Выгорание самого эксперта. Если человек незаменим, его не отпускают. Ни физически, ни морально. Он работает ночами. Ему пишут по выходным. Он не спит, но «держит». Пока не выгорел. А потом — всё. В один день. Без предупреждения.
Потеря мотивации у остальных. Зачем другим расти, если всё равно всё делает он? Зачем что-то писать, проектировать, обсуждать — если всё решается «по звонку Коле»? Так вы теряете команду. Развивается не система, а культ личности.
Создание токсичной среды. Эксперт может начать удерживать власть через знания: «Я знаю, не лезь», «Ты не поймёшь», «Там всё сложно». И даже неосознанно — превратиться в узкое горлышко, через которое проходит весь проект.
Как формируется зависимость
Никто не просыпается утром с мыслью: «А не сделать ли нам всю ИТ-инфраструктуру зависимой от одного человека?» Но год за годом, проект за проектом — организации сами, шаг за шагом, строят себе клетку, и даже не замечают этого.
Разберём, как появляется такой сценарий и почему он кажется логичным — до тех пор, пока не становится критичным.
Вначале — всё просто. Был проект, надо было «сделать на коленке». Не до процессов, не до документации. Один человек всё настроил. Система заработала — все вздохнули. Ему стали доверять. И нагружать.
А потом прошло 3 года, бизнес вырос, но архитектура осталась та же: «Если нужно что-то сделать — идите к нему». «Давайте не будем писать задачи, я просто позвоню Коле — он сделает». «Зачем объяснять — он и так всё знает» … Знакомо? В условиях дедлайнов, горящих сроков и постоянного «пожара» — герой с руками кажется лучшим решением. Он удобен, понятен и даёт результат. И герой Коля чувствует себя важным. Его уважают. И он, сам того не замечая, усиливает свою уникальность — уже не просто спасает, а делает так, чтобы без него и не обошлись.
Когда в компании: нет архитектурного описания системы; не документируются изменения; не пишутся пользовательские инструкции; отсутствует внятная база знаний и даже пароль от серверной знает только один «Коля» – вы не в команде, вы в IT-лотерее.
Вот простой жизненный пример в тему: компания внедрила 1С:ERP. Все обмены, расчёты себестоимости и документооборот были разработаны одним сильным специалистом. Он уехал в отпуск. Через 3 дня началась истерика: «Ничего не работает, где документы по себестоимости, где схема обменов?!». Их не было. Были только скриншоты в Telegram и 12 000 строк кода. Проект замер.
Но почему это никто не останавливает?!
Потому что руководству удобно: задачи выполняются, возражений нет, результат есть.
Потому что сотрудникам понятно: «Я пишу Коле — он делает».
Потому что у самого эксперта нет времени на передачу знаний, документацию и обучение. Он постоянно «в деле».
Как распознать проблему заранее?
Проблема с «экспертом с руками» не в том, что он есть — а в том, что он один и система от него зависит. Понимаете? Я хочу сказать, что хороший специалист – это ценность. Но незаменимый специалист — угроза. Поэтому чем раньше вы поймёте, что ваша команда строится вокруг одной фигуры, тем выше шанс успеть всё исправить.
Вот признаки, по которым можно понять: вы движетесь в сторону технологического заложничества.
1. Этот человек не уходит в отпуск. Вообще. Потому что «некому будет». Или «я всё равно на телефоне». Это звучит как преданность, но на деле — признак патологической зависимости системы от человека.
2. Без него не проходит ни одна встреча. Все поворачиваются к нему, ждут его реакции, он — единственный, кто может «объяснить, как на самом деле работает».
3. Он сам себе пишет задачи и сам их закрывает.
Внешне — это эффективность. По сути — отсутствие управляемости.
4. Документации нет. Или она «устарела ещё в том году». Зачем писать, если всё и так знает Коля? Но как только Коля уедет… или заболеет… или просто уйдёт в другую компанию — вы останетесь один на один с загадочной экосистемой.
5. Код, который он пишет, понимает только он. Нет комментариев. Нет шаблонов. Стиль «от руки». Попробуй разберись, где тут отчёт по договорам, а где расчёт бонусов за 2017 год.
6. Доступы централизованы в одних руках.
Пароли, настройки, SSH-ключи, VPN — всё у него. Он «потом добавит», «сам настроит» или «тебе не надо знать, чтобы не сломал». Это уже не эксперт. Это хранитель портала.
Как изменить ситуацию?
Если вы читаете эту статью и киваете – значит, вы уже на пути к решению. Потому что самая опасная зависимость – та, которую отрицают. А вот если вы уже видите, что «у нас всё держится на Коле» — то это уже половина победы. Давайте разбираться, что с этим делать. Спойлер: не увольнять Колю. Он вам ещё понадобится. Главное — перестать делать его центром мира.
Меры на уровне процессов
1. Документировать всё.
Не надо сразу писать многотомник. Начните с малого: Архитектурная схема базы (даже на бумажке — уже хорошо); Таблица обменов: откуда, куда, по каким полям; Мини-инструкции: как запускать расчёт, выгрузку, отправку.
Идеально — завести внутреннюю вики (например, Confluence, или простую 1С-базу), куда всё это будет складываться.
2. Внедрить контроль изменений
Заведите хранилище конфигурации (уж молчу про Git-репозиторий, хотя при желании - только приветствуется); Минимальный CI/CD, пусть даже вручную (выгрузка/загрузка);
Правила: без описания — не помещаем; без теста — не накатываем.
Даже это уже спасает от бардака.
3. Сделать все доступы прозрачными.
Храним логины и пароли в защищённом менеджере доступа; Настраиваем роли: у Колиной учётки нет права быть «богом» везде; Разграничиваем ответственность: админ не равно разработчик и не равно бухгалтер.
Меры на уровне знаний:
1. Создать культуру менторства.
Эксперт с руками не должен быть один. Назначьте ему пару или «ученика». Пусть кто-то ходит с ним по пятам, слушает, записывает, впитывает. Через 2 месяца такой стажировки у вас будет второй человек, который хотя бы понимает, о чём речь.
2. Записывайте экраны.
Попросите эксперта записывать видео своих действий при сложных операциях: выгрузки, настройки, корректировки. Пусть будет 5–10 минут ролика — но они однажды спасут вам релиз.
3. Выделите время на передачу знаний
Прямо запланируйте: раз в неделю — сессия «что я знаю». Просто дележка опытом.
Меры на уровне команды:
1. Ротация зон ответственности
Один месяц — Коля ведёт обмены. Второй — этим занимается Маша, а Коля консультирует. Третий — Пётр, а Коля только наблюдает.Такой формат разрушает культ незаменимости и укрепляет команду.
2. Превратите эксперта в наставника
Вместо того чтобы «разгружать» его от всего подряд — оставьте за ним знания, но снимите с него рутину. Пусть он делает код-ревью, помогает архитекторам, пишет лучшие практики. Не надо снимать с него корону — подарите ему трон, на котором он будет полезен всей команде, а не одиноко тащить на себе проект.
Суть в том, что не надо с перепуга увольнять Колю. Надо сделать так, чтобы без него тоже работало. Он вам сам потом спасибо скажет.
Как правильно встроить эксперта в команду?
Когда зависимость от «эксперта с руками» уже признана, а первые меры начали работать — важно не потерять человека, который много лет тянул систему на себе. Да, его нельзя оставить в роли «всевидящего кодера», но и превращать его в «запасного игрока» — неправильно и небезопасно.
Дайте эксперту новую роль
1. Наставник
Прямо назначьте его тем, кто помогает другим вникать в сложные зоны. Он — не исполнитель, а проводник. Пусть он участвует в код-ревью, отвечает на сложные вопросы, помогает формулировать best practices.
2. Архитектор / методолог
Если он действительно понимает, как всё устроено — логично доверить ему участие в построении новых решений. Только теперь — в рамках процесса, а не по звонку. Пусть он участвует в согласовании архитектуры; подсказывает, где «не надо наступать на грабли». Пусть консультирует команду по стратегиям развития системы.
Дайте возможность делегировать
Эксперты часто не делегируют, потому что боятся: «Если кто-то другой сделает не так — мне потом всё править. Проще сделать самому». Это правда, но это и замкнутый круг.
Чтобы его разорвать: обеспечьте наставничество — человек делегирует и сопровождает; дайте время на передачу — не в нагрузку, а как часть работы; дайте право на ошибку его ученикам — не судите строго первые попытки.
Поддержите социально
Многие «эксперты с руками» боятся потерять статус, когда у них забирают уникальные полномочия. Поэтому важно чётко проговаривать: «Ты нужен, просто теперь по-другому». Показывать, что теперь он не только делает, но и формирует культуру.
Вовлекайте его в проектные комитеты, внутренние митапы, обсуждения сложных кейсов. Пусть он видит и чувствует, что его роль не уменьшилась, а эволюционировала.
Автоматизируйте повторяющиеся действия
Иногда «эксперт с руками» продолжает сам делать рутину просто потому, что никто её не автоматизировал. Сбор логов вручную? Напишите скрипт. Экспорт в Excel — вручную? Постройте отчёт. Обновление базы — руками через RDP? Настройте автозапуск. Чем меньше рутинных действий — тем проще разделять ответственность.
Зафиксируйте всё формально
Новая роль должна быть оформлена: Обновлённая должностная инструкция; Регламент участия в проектах; KPI, ориентированные на передачу знаний, архитектуру, консультации. Это важно и для самого эксперта (чтобы не было ощущения «меня просто отстранили»), и для команды (чтобы не было путаницы).
Как убедить руководство, что это важно?
Руководство редко говорит: «Давайте зависеть от одного человека! Пусть у нас всё держится на нём!». Но, когда приходит предложение всё это переделать, чаще слышен другой вопрос: «А зачем? У нас же всё работает». Ваша задача — донести риск сложившейся ситуации правильно. Не через панику, а через понятные аргументы и бизнес-язык.
Аргументы, которые работают
1. Риски остановки бизнес-процессов: «Что будет, если он внезапно уволится? Что сломается в первые 48 часов? Сколько это нам будет стоить?». Чёткий расчёт последствий, сценарий потерь и сопоставление с текущими затратами сразу повышают уровень внимания.
2. Невозможность масштабирования: «Сейчас у нас одна база. Через 6 месяцев будет две. Через год — интеграция с онлайн-магазином. Кто это будет тянуть?». Невозможность расти – это аргумент, который хорошо понимают собственники.
Предложите не критику, а план. Руководство охотнее воспринимает решения, чем проблемы. Вместо причитаний «у нас всё плохо» предложите чек-лист рисков; план по снижению зависимости: по месяцам, по ролям; список задач, которые можно отдать другим; план трансформации роли эксперта. Ну, а если сам эксперт будет говорить на встрече: «Да, я устал все держать на себе. Давайте перераспределим работу», то это убедит лучше любых слайдов.
Вместо заключения:
Если вы сейчас узнали себя, свою команду или своего «Колю» — значит, пора начать действовать. Не для того, чтобы избавиться от эксперта, а для того, чтобы эксперт стал частью обновленной сильной команды.
