Введение

Сегодня поговорим об извечном споре любых IT специалистов — «Что лучше: T‑Shape или I‑Shape». Разберемся сначала с понятиями.

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

T‑Shape специалист — специалист с экспертизой хотя бы в одной области, но при этом разбирающийся во многих других и который может свободно поддерживать общение с другими специалистами на базовом уровне.

Так же выделяют специалистов широкого профиля, у которых нет какой‑то доменной экспертизы. Но я не считаю это хоть сколько‑то эффективной стратегией развития, поэтому о таких мы в этой статье забудем. Далее будет предложена модель, доказывающая превосходство T‑Shape специалиста над I‑Shape.

Модель роста ресурсов

Существует стандартное правило Парето, или правило 80/20 — 20% усилий приносят 80% результата. Давайте посмотрим на это правило на графике для наглядности.

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

По факту именно так и работает любое развитие в любой области или отдельно взятой компании на одной должности: вы очень быстро хватаете какие-то знания и компетенции за первые несколько месяцев работы. А потом уже вы начинаете добирать оставшиеся 20% на протяжении очень долгого периода.

То же самое в целом заметно относительно зарплат специалистов: junior специалисты могут расти на х1.5 каждые полгода, а опытные специалисты хорошо, если будут получать +15% в год.

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

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

Расширенная модель роста ресурсов

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

Программирование — тут я взял навык в общем. Сюда входят: Python, как язык для автоматизации каких‑то своих скриптов для создания прогнозных моделей, автоматических подсчетов какой‑то метрики, автоматизации отчетности и так далее; Airflow — фреймворк для автоматизации скриптов; API запросы к партнерам — для выгрузки данных из партнерских систем и много чего еще.
SQL — язык для исполнения запросов базы данных для выгрузки какой‑то статистики (в случае работы аналитиком данных).
Статистика — один из ключевых навыков аналитика данных.
Знание бизнеса — общее понимание того, для чего в целом нужен аналитик в данной конкретной компании. То есть: откуда идут основные деньги, как выстроена продажа продукта, какое место ты занимаешь во всем этом празднике жизни и так далее.

И естественно, ввиду ограниченности ресурса нельзя иметь 100% компетенций во всех 4 областях. Поэтому давайте представим какого-то конкретного специалиста как набор графиков, которые я показал выше:

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

Наш герой что-то понимает в программировании, но у него достаточно скудные скилы на данный момент.
Очень хорошо знает SQL и может написать любой аналитический запрос. Иногда даже может применить оконную функцию!
На профессиональном уровне владеет статистикой и может посчитать даже А/Б тест на конверсию в платеж на 20 пользователях в каждой группе (если бы 20 человек было на 2 группы, то скорее всего уже не смог бы).
Имеет неплохие знания в бизнес составляющей компании, но ему многому еще предстоит научиться.

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

Пунктиром обозначена область, до которой потенциально можно дорасти.

Вот, теперь другое дело. Теперь все стало понятно. Насколько заполнена область, настолько наш герой и развит интеллектуально в конкретной области.

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

Испытание модели на прочность

Возьмем три классические рабочие задачи для примера, которые аналитик может выполнять в не самой крупной компании (условных средний бизнес, мы уже не скидываем заказчику apk файл для установки его на компьютер клиента, но у нас еще не 100млн MAU):

Автоматизация отчетности — одна из классических задач Data сферы. Всегда есть какие‑то отчеты, которые в первой итерации делаются на коленке в Excel, и всегда возникает светлая мысль ее автоматизировать. Для выполнения такой задачи при наличии готового отчета чаще всего требуется знание Программирования и SQL.
Создание универсальных аналитических запросов — так же одна из классических задач, когда вы создаете внутренний инструмент для аналитиков, к примеру SQL запрос для подсчета АБ теста. Для таких задач в основном требуется знание статистики и ее применимости в разных ситуациях и SQL. Навыки программирования здесь минимальны, так как инструмент не обязан быть отказоустойчивым.
Определение слабых точек продукта — исследовательская задача, которую так же часто делают аналитики, для руководителей продуктом, чтобы они могли выстраивать следующие шаги для развития того самого продукта. Тут очевидно нужно знание бизнес домена, и так же знание статистики, чтобы проверять некоторые сразу всплывающие гипотезы в ходе вашей работы.

Каждая задача может быть разной степени сложности в зависимости от развитости компании. К примеру задача на автоматизацию отчетности может быть простой, если уже есть куча автоматизированных отчетов, и вы можете это сделать по образу и подобию предыдущего, или у вас вообще может стоять система на основе dbt какого‑нибудь, в которую можно просто скормить SQL запрос и он уже все сам автоматизирует, либо может быть вообще тяжело — у вас до этого даже не было Airflow.

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

Почему же все так? Общий ответ: выдерживание внешней тряски решений аналитика должно быть соразмерно его скилам и количеству подпорок, которые поставлены на его решение. Если он решает сложную задачу, то он даже может не знать из-за какой тряски его решение может сломаться. Будь то блокировка API, из-за чего вся автоматизация отчетности ломается, будь то добавление нового проекта, к которому аналитик не был готов, будь то кризис в отрасли, который аналитик не учел в определении слабых точек продукта. Тряска может быть разной, но разные решения выдерживают разную силу тряски.

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

Но давайте разберем на конкретных примерах почему все именно так.

Автоматизация отчетности

У нашего аналитика есть какие-то достаточно хорошие знания в SQL, есть базовые знания про программирование. Максимальная сложность автоматизации его работы может быть в копировании DAGа Airflow, который автоматически обновляет какой-то другой схожий отчет, и изменить в этом DAGe SQL запрос для отчета. Либо же, сформировать качественный Prom в ChatGPT и скопировать as-is код, проверив его на самые базовые логические несостыковки. То есть по факту сложность отчета, который он может автоматизировать, ограничивается проработанностью инфраструктуры компании и сложностью изначального SQL запроса, который уже представлен в отчете.

Но теперь давайте задумаемся о риске такой автоматизации. Что будет, если за день данных придет в 1000 раз больше, чем должно было прийти, или что будет, если партнер, данные которого забираются по API, опоздает с их отправкой, а что будет, если случиться все сразу, а в инфраструктуре компании не предусмотрены такие сценарии, и наш испытуемый должен был бы сам от них защититься? Правильный ответ думаю все уже знают — все будет плохо и отчет сломается (в лучшем случае сломается только отчет).

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

Создание универсальных аналитических запросов

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

Но давайте опять подумаем: что может пойти не так? Что будет, если добавиться какой‑то новый проект, который еще не включили в общий Pipeline сборки данных, а данные по АБ тесту нужны уже сейчас, к примеру, нужно посчитать AБ тест для куммулятивного ARPU? Правильный ответ — нужно это предусмотреть и посчитать данные из сырых данных. Но наш аналитик, к сожалению не умеет писать оконные функции, поэтому он даже не предусмотрел такой сценарий. Рисков в этом меньше, потому что в худшем случае метрика эта не посчитается в рамках его скрипта, но у других аналитиков осадочек останется.

Именно из-за подобных моментов навык не может быть прокачан на все 100%.

Определение слабых точек продукта

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

Но давайте на конкретном примере:

Задача: перераспределить рекламный бюджет, чтобы он был более эффективным и мы увеличили ROAS до максимального.
Наш аналитик делает исследование и видит, что есть какие-то источники трафика классические (к примеру VK Ads, Yandex Direct и тд), а есть какие‑то странные источники трафика, где мы платим не за показ рекламы, или не за клик на нее, а за действие пользователя внутри игры. Он видит, что эти дураки из маркетинга вливают огромные бюджеты на классические рекламные каналы, и мало денег вливают в каналы с CPA биллингом. «Казалось бы, честная сделка» думает наш аналитик.
Наш аналитик что‑то слышал про то, что количество бюджета, которое мы можем пролить за день, прямо пропорционально ставке, которую мы выставляем сетке за определенное действие внутри игры (то есть сколько мы платим сетке за то, что пользователь совершил действие, которое нам надо). Так же наш аналитик посчитал, что эффективная ставка в два раза выше, чем стоит сейчас.
Рекомендация аналитика: зарезаем косты на классические источники трафика в два раза, а то, что зарезали, перенаправляем на CPA источники трафика и увеличиваем ставку на этих источниках трафика в 2 раза.
CMO к этим рекомендациям прислушался и так и сделал. Маркетологи пытались CMO что‑то объяснить, попытались объяснить, что так делать не надо, но аналитик уже популярно объяснил почему они дураки, и СМО их за таких теперь их считает.
Что произошло дальше? Аналитик не учел, что на такие сетки не просто так тратиться мало бюджета. Мало бюджета на них тратиться потому, что у них модель монетизации в том, что они продают эту рекламу у других участников рынка, выдавая какие-то бонусы за дохождение до этого действия в продукте, который закупил рекламу. И он не знал о двух проблемах этих сеток: у них мало приложений, которые согласились размещать у себя такую рекламу и, самое важно, такие сетки могут залить от 20 до 80 процентов фродовых пользователей, за которых клиент заплатит деньги, но они этому клиенту не принесут денег.
Как итог: ROAS уменьшился на 20%.

Чего не хватило нашему аналитику? Казалось бы, статистически все верно, но бизнесово он не учел несколько ключевых факторов в принятии решений маркетинговой командой. И как итог: уменьшил прибыль компании в разы (если она конечно осталась > 0).

Вывод по приведенным примерам

Уже на нашей модели видно, что аналитик не может справиться со всеми задачами одинаково из-за скилов, которые у него есть. Более того, видно, что несмотря на то, что наш аналитик ЭКСПЕРТ В СТАТИСТИКЕ, даже универсальный аналитический запрос он сделать не может на экспертном уровне и всегда окажется какой-то запрос, который ему не под силу (к примеру тот, в котором надо использовать оконные функции), и более того, если смешать его экспертность в статистике с отсутствием знания о бизнес-домене компании, в которой он работает, это может принести существенные потери бизнесу. То есть мы уже приходим к T-Shape.

Дальнейшее развитие

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

К примеру:
Наш аналитик послушал советов по развитию T-Shape и прокачал навык в программировании и дотянул навык в SQL. Какую задачу он может взять, после того, как навыки автоматизации отчетов и создании универсальных аналитических инструментов прокачаны на 80%?

Он может задуматься над универсальным автообновляемым self-service отчетом по АБ тестам, который позволит компании сократить расходы на ручной подсчет каждого АБ теста.

И после этого вот так начнет выглядеть наша пирамида.

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

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

Подытожывая — пространство задач становиться максимально большим.

Финальное слово

В данной статье я описал очень простую модель построения себя, как большой пирамидки из навыков, и о которой я предлагаю задуматься читателю. Так же я предлагаю задуматься читателю над мыслью: «Имеет ли смысл вышлифовывать одну компетенцию, если на стыке с другой он не сможет выполнить даже средней сложности задачу?». И на последок покажу картинку, которая суммирует все, что было написано до этого: куда можно вырасти из T‑Shape специалиста и куда можно вырасти из I-Shape специалиста, не расширяя профиль своих знаний.

Если вы хотите больше узнать про аналитику данных и увидеть больше статей про развитие в этой сфере — добро пожаловать в мой телеграм-канал.

Развитие специалиста на треугольничках