Глава 32. Владение скиллами в компании

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

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

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

Через месяц скиллов десятки. Через три их сотни, и в них уже сам чёрт ногу сломит.

Как это выглядит через полгода Разбор конкретного случая.

Для одной внутренней системы контроля версий существуют три скилла. У каждого свои сильные и слабые стороны. У каждого свой автор.

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

ЧТО ВИДИТ ЧЕЛОВЕК, КОТОРЫЙ ИЩЕТ СКИЛЛ ДЛЯ ТРЕКЕРА ЗАДАЧ

tracker yandex-tracker kickass-tracker bullseye-tracker best-tracker

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

ГЛАВНОЕ ПРО СКИЛЛОВЫЙ ХАОС Зоопарк скиллов без владельцев это не следствие бардака, а нормальный жизненный цикл. Он наступает у всех, кто разрешил свободную публикацию. Планировать надо не то, как его избежать, а то, как им управлять.

Костыль, который работает Решение, к которому пришёл человек из разбора, звучит парадоксально: он написал ещё один скилл.

Владение скиллами в компании

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

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

Признание ценное. Роутер организационную проблему не решает ни хуя, он решает личную. Полезен и не масштабируется.

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

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

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

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

АУДИТ СКИЛЛОВ ЗА ОДИН ДЕНЬ 1. Собери список всего, что сейчас в контексте: скиллы, правила, заметки в памяти. 2. Попроси агента пройтись по каждому и сказать, что устарело, что дублируется, что противоречит другому. 3. Отключи всё, что помечено. Не удаляй, отключи. 4. Поработай неделю. Записывай, чего не хватило. 5. Верни только то, чего не хватило дважды. 6. Обрывки знаний о скиллах, найденные в правилах и памяти, сведи в одно место.

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

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

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

Логика разделения простая. Ошибка в бизнесовом скилле стоит времени одного человека. Ошибка в инфраструктурном расходится по всем, кто его поставил, и это уже пиздец масштабом с отдел.

Владение скиллами в компании

Что бывает без владельца Конкретный ущерб из разбора.

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

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

Схема владения, которая работает Из другой компании, и она проще, чем кажется.

За каждый скилл закреплён владелец по роли, а не по авторству.

Скилл Владелец

Коммерческие предложения Коммерческий директор

Оценка задач Руководитель разработки

Презентации Директор по маркетингу

Работа с системой контроля версий Владелец платформы

Владелец не обязан писать скилл сам. Он обязан принимать изменения и отвечать за содержимое.

НАСКОЛЬКО СТРОГО РЕГУЛИРОВАТЬ Строго. Один владелец, общий репозиторий, изменения принимаются как код, без поблажек. Иначе через полгода зоопарк. Свободно. Любой публикует, рынок сам решает: видно число установок и версий, плохое дохнет само. Что говорит опыт. Свободно работает для бизнесовых, строго нужно для инфраструктурных. Смешение этих режимов и порождает проблему. Чего не хватает обеим схемам. Механизма удаления. Скиллы копятся, потому что удалить чужое никто не решается.

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

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

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

Владение скиллами в компании

не дублирует ли существующий, не лезет ли туда, куда не должен.

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

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

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

Что запомнить Зоопарк скиллов это нормальный жизненный цикл, а не бардак. Планируй управление, а не избегание.

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

Раздели бизнесовые и инфраструктурные. Первым свобода, вторым строгий владелец по роли.

Аудит делай агентом: пусть пройдёт по всему, что в контексте, и назовёт устаревшее.

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

И заведи механизм удаления. Без него хранилище растёт всегда.

← Внедрение и неявное знание · оглавление · Роли: что теперь делает разработчик →

Спросить книгу может любой, кто вошёл в Neuraldeep Hub: агент ищет ответ по тексту и приводит цитату со ссылкой на главу.