C-level чаще других используют genAI в ежедневной работе

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

T-shape knowledge
T-shape knowledge

Тогда:

Когда я был специалистом и сам ручками писал код, требования и делал оценки у меня был ограниченный набор доступных мне технологий и фреймворков, которые были забетонированы в проекте. С помощью Х и Y я делал определенный набор вещей в конкретном бизнес домене. Чтобы прокачаться в такой песочнице, ты глубоко разбираешься в каждой функции и методе. Ты очень хорошо понимаешь как это работает, следишь за всеми обновлениями фреймворка, новыми фичами, да и вообще, можешь в уме быстро прикинуть, сколько памяти и CPU time сожрёт тот или иной трансформ объекта. Короче, ты - супер эффективен. Потребность в новых знаниях и разборе "как это работает" очень низкая. Если ты сталкиваешься с какой то неведомой фигнёй, то скорее всего, идёшь обсуждать это со своими корешами-разработчиками, которые, скорее всего, уже огребли такие проблемы.

Интерлюдия:

Поработав в консалтинге у меня осталась хроническая травма: мне ооочень сложно кому-то сказать, "я не знаю. я в этом не разбираюсь. не моя тема". Это хреново. Сейчас понемногу отпускает, но раньше это было так:
-Клиент хочет допилить приложение на R и добавить туда новый модуль с расчётом риск сценариев портфеля? Отлично! "Мы сделаем оценку и вернемся к вам в понедельник утром".
"Пацаны, а кто-то вообще раньше писал что то на R? Нет, конечно."
Ок, берём и читаем ночью и на выходных. Целых 2 дня же еще.

Что сейчас:

Команда выросла, объем задач и поляна большая. То, в чем раньше я очень хорошо разбирался сегодня едва хватает, чтобы поддерживать осмысленный диалог на технических митах. Есть области в которых у нас вообще нет пока еще экспертизы специалистов и тебе это надо как то залидировать. Вы когда-нибудь пробовали нанимать человека на техническую позицию или еще лучше, на позицию тех лида, слабо разбираясь в специфике того, что ему надо будет делать? Очень увлекательное занятие.
И тебе приходится много рисерчить. очень много. Чтобы просто разобраться на самом базовом уровне: как это должно работать по best practices, кто для этого нужен и как это вообще все засетапить. Это общая проблема всего старшего менеджмента.

Все твои кореша-разработчики уже давно в разных корпах на позициях тех лидов или архитекторов, варятся в корпоративных фреймворках и самописном софте. Зачастую с узким диапазоном проблем своих бизнес доменов. Да и будем честны - все уже сгорели по 10 раз, уже мало кто хочет детально обсуждать рабочие проблемы за пределами офиса. Мы же не Baldur's Gate 3 или Expedition 33 обсуждаем, в ином случае получить содержательную инфу будет очень сложно. Их опыт ты в 90% случаев не сможешь переиспользовать.

LLM отлично вывозит роль консультанта для топа. Уже есть практический опыт, как задавать уточняющие вопросы, как понять, что выданный результат выглядит сомнительным буллшитом и раскрутить через валидацию деталей. Докопаться до сути. Когда я пилил свои задачки, мне в целом вообще это было бы не нужно. Ускорить написание кода? Да, возможно. Но в остальном...скорее нет.

Подписаться на канал

Начать дискуссию