КЕЙС. Часть 1

Собрала тут для трех разных команд когнитивных партнеров на коленке. Выглядит это как документ с промптами и инструкцией для пользователя, а по сути — ответ на вопрос:

«Как в экосистему клиента затащить клона Ани с ее мозгами, но без ее мерзотного характера?»

Задачи были такие:

▪️Научить мотивированных преподавателей ДПО трекать предпринимательские проекты студенческих команд. ▪️Научить сотрудников корпуниверситета брифовать заказчиков, информаторов и стейкхолдеров программ обучения и делать такой дебриф, чтобы дальше было легко создавать грамотный концепт. ▪️Силами джунов создать таксономию навыков для сложных ролей в небольшой компании, чтобы потом раскатать ее по всему HR-циклу — от HR-бренда до обучения и карьерных треков.

Но история во всех трех случаях была похожая.

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

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

У меня для этого были необходимые условия:

▪️я сама строила методологию: какие решения надо последовательно принять и по каким критериям; ▪️предварительно исследовала компанию и контекст команды и понимала, как бы выполняла эту задачу сама именно в этой экосистеме; ▪️понимала разрыв между текущими возможностями команды и сильным исполнителем; ▪️могла разложить работу: что способен сделать менее опытный человек, что можно отдать машине, а где должен вмешаться человек — иногда не сам пользователь, а подключенный эксперт.

То есть промпты здесь — не продукт.

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

🧙‍♀️Расскажу подробнее про кейс №3 в обезличенном формате, с клиентом согласовано.

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

Одна из задач большого проекта — создать таксономию навыков.

Не табличку ради таблички, а язык, через который компания сможет видеть, сравнивать и развивать разные типы профессиональной работы. Один из референсов для всего проекта — GitLab Handbook: не как источник готовой таксономии, а как пример того, как компания выносит наружу собственную логику работы, принятия решений и взаимодействия.

С готовой таксономией здесь были проблемы.

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

Поэтому мы пошли не от должностей и не от вопроса «какие навыки нужны хорошему сейлзу?». Мы пошли от эпизодов реальной работы.

1. Сначала я раскладываю, какую реальность вообще нужно восстановить 🔻Я знаю, что мне нужно понять про работу человека, чтобы потом построить хорошую таксономию. Это можно представить в виде таблицы — Модели реальности. 🔻Я знаю, какие вопросы нужно задавать, чтобы люди наговорили материал, из которого эту таблицу можно заполнить.

В итоге одна и та же модель работает в две стороны: ▪️человеку служит шпаргалкой для интервью; ▪️машине — рамкой, по которой потом разбирать транскрипт.

Продолжение следует