Привет! Меня зовут Дарина Кухтина, я работаю лидом маркетинговой аналитики в геймдев-компании и наставником на курсе «Аналитик данных» в Практикуме.
На основном месте работы я провела много интервью и со временем стала уделять софтскилам не меньше внимания, чем хардскилам. Если вторые хотя бы понятно, как прокачивать, то для развития «мягких навыков» нет чёткого рабочего алгоритма. И если закрыть глаза на нехватку софтскилов при найме, потом с сотрудником могут быть проблемы.
В этой подборке я расскажу, какие софтскилы, на мой взгляд, особенно важны для аналитиков данных, как специалисту найти свои слабые места и что поможет развить те или иные навыки.
Что такое софтскилы и почему они важны для аналитиков данных
Софтскилы — это навыки, которые не относятся к конкретной профессии, а, скорее, характеризуют самого человека. Они могут быть связаны с личной эффективностью и планированием, общением с коллегами и заказчиками, умением не только выполнять задачи, но и выходить за их рамки.
Такие скилы важны аналитику данных, потому что его цель — не просто написать рабочий код или построить красивый график, а ответить на вопрос бизнеса и помочь заказчику принять решение. Для этого недостаточно решать задачи по ТЗ — нужно уметь критически мыслить и понимать истинный запрос заказчика. Компании часто вообще не важно развитие хардскилов аналитика, если его уровня хватает для выполнения задач. В отличие от большинства разработчиков, аналитикам не так важно оптимизировать код и делать его максимально грамотным. Какие-то задачи и вовсе можно решить, не прибегая к программированию. И тут на первый план выходят именно софтскилы.
С ростом в профессии такие навыки будут только важнее — особенно если развиваться как менеджер. Примерно с уровня мидл-плюс аналитик может стать наставником для джуниоров или брать управленческие задачи. Надо будет ещё больше общаться с людьми и быть таким специалистом, которому будут доверять.
Развитию софтскилов способствует культура обратной связи, когда можно спросить у руководства и коллег, довольны ли вашей работой, вовремя ли вы сдаёте результат и приносит ли он пользу. Если в команде такой культуры нет, проверьте себя по списку навыков, которые мы указали ниже. Возможно, над чем-то стоит поработать, не дожидаясь недовольства коллег и заказчиков.
Какие софтскилы особенно важны для аналитиков данных
Недоверие к данным
Данные данными, но здравый смысл никто не отменял — даже если все тесты говорят, что средний рост человека 2 м 17 см, а медианная зарплата в России 200 тысяч рублей, это не повод приносить такие результаты заказчику. В данных могут быть ошибки или ложные корреляции, которые окружают нас повсюду. На одном сайте даже собирают такие нелепые совпадения.
Опасность абсолютного доверия к данным в том, что с ним можно сделать ошибочные выводы, особенно если результаты совпадают с желанием заказчика. Поэтому я рекомендую аналитикам сверять данные с наблюдениями из жизни, схожими исследованиями других компаний и мнением коллег. Или можно загуглить, что пишут другие люди по этому поводу.
Способность работать с нехваткой данных
К сожалению, полную картину мы часто не знаем: какие-то данные конфиденциальны, другие забыли записать, третьи потерялись… Поэтому нужно привыкнуть, что нехватка данных — это нормально, и даже так можно найти ответ. Пример из практики: мы с командой думали, какие новые языки кроме английского добавлять в игру. Прямо отвечающих на вопрос данных не было, поэтому мы нашли проценты англоговорящих людей в разных интересующих нас странах. Один из самых маленьких оказался во Вьетнаме. Пришлось прийти к неудобному для всех выводу: нужна вьетнамская локализация.
Если аналитика не говорит, что какое-то решение очевидно правильное, можно не искать альтернативные данные, а просто выбрать один из вариантов. Например, когда A/B-тест не даёт внятных результатов, используйте внешние вводные: стоимость того или иного решения, сложность внесения изменений и количество времени, которое на это уйдёт. Используя эти вводные и посоветовавшись с командой, можно принять решение даже при недостатке данных.
Критическое мышление
Бывает, что заказчик или руководитель просит посчитать слишком много метрик. Казалось бы, это и есть работа аналитика, но не совсем. Действительно ли есть смысл во всех этих расчётах и какая за этим всем стоит задача? Можно ли её решить с меньшим количеством данных? Эти вопросы помогут сэкономить время, корректнее сформулировать задачу и получить более релевантные результаты.
Есть более сложные техники работы с критическим мышлением — подробнее о них можно почитать, например, в этом материале.
Умение признавать ошибки
Аналитику важно признавать ошибки как можно раньше. Чем быстрее вы сообщите заказчику, что сделали неверный вывод, тем меньше вероятность, что он внедрит это решение или запустит его в разработку. Стоимость такой ошибки минимальна — опыт неприятный, но заказчик не потеряет деньги и, скорее всего, не откажется от ваших услуг.
Пример из практики: работая с командой над игрой, мы сделали A/B-тест, чтобы выбрать подходящую иконку. Закупили аудиторию, пришли к выводам, решение было внедрено. Через пару дней мы обнаружили, что конверсия стала ужасной. Оказалось, что мы, делая приложение для американской аудитории, закупили аудиторию из Мексики. А американцы ожидаемо не поняли, почему у них в приложении появилось изображение Дня мёртвых, который отмечают мексиканцы. Клиент очень злился, но всё закончилось хорошо.
Чтобы прокачать этот навык, нужно усвоить, что на работе за ошибки двойку не поставят. И не воспринимать неадекватные реакции (а они бывают) на свой счёт. Ещё можно проработать эту тему с психологом. Лично мне помогло.
Способность доводить проект до результата
Ещё одна присказка аналитика — мы измеряем работу не усталостью, а результатом. Если бы измеряли усталостью, то хорошим специалистом был бы тот, кто считает максимум метрик, даже если они не нужны. Неважно, аналитик просто сложил два числа на бумаге или написал огромный код, главное — решение.
Чтобы узнать, развит у вас этот навык или нет, подумайте, много ли результатов ваших исследований не привели к изменениям в продукте? И бывало ли такое, что вам несколько раз ставили одни и те же задачи? Этот навык я часто проверяю на собеседованиях, спрашивая кандидата о самом большом успехе в работе. Если он говорит не про улучшение продукта, а про сложный код или систему графиков, то, возможно, он сфокусирован не на результате или не доводит задачу до конца.
Чтобы развивать этот навык, концентрируйтесь на цели, а не на средствах. И чаще спрашивайте у руководства, пригодились ли полученные данные и какие на их основе были внесены изменения. В общем, не заканчивайте работу на выгрузке результатов, старайтесь приносить пользу и после.
Умение общаться с коллегами
Это важно для каждого, кто работает с людьми. Во-первых, по девять часов в день сидеть в офисе с теми, кто тебе отвратителен, просто вредно. А во-вторых, если среди коллег нет дружелюбного отношения, никто не поможет в критический момент.
Если с коммуникацией что-то не так, возможно, проблему стоит обсудить с личным или корпоративным психологом. Но вот несколько моментов, которые можно ввести в рутину самостоятельно. Первое — принимать и давать обратную связь бережно и благодарить за критику. Второе — самому проявлять активность и предлагать помощь другим. Порой этого достаточно.
Умение общаться с заказчиками
Правильно сформулированный вопрос даёт 90% ответа. Если вы его не слышите и не можете понять, в чём заключается «боль» заказчика, то в лучшем случае потребуется гораздо больше итераций. А в худшем заказчик просто откажется от сотрудничества.
Заметить нехватку этого навыка легко: вам либо прямо говорят, что недовольны качеством работы, либо просто не предлагают задачи. Ну, или решению задачи предшествует много попыток, тупиковых исследований и выводов, которые не пригождаются заказчику.
Уметь общаться с заказчиками — это не просто соглашаться и работать по известному алгоритму, но и быть всецело заинтересованным в результате. А значит, иногда спорить, мягко поправлять заказчика и предлагать альтернативные решения.
Умение презентовать результаты
Аналитику важно представлять свою работу так, чтобы полученные выводы применялись в продукте. Поэтому стоит подавать информацию в наглядном виде, с картинками и текстом, написанным понятным языком и без снобизма.
Намекнуть на недостаток навыка может несоответствие вашего вывода и реакции на него. Например, вы говорите, что благодаря новому решению повысили выручку в два раза, но все воспринимают это равнодушно, будто ничего не случилось. Ещё один знак, что люди не понимают вас, — это большое количество уточняющих вопросов. Или если отправляете результат текстом, а вас просят созвониться и продублировать информацию устно.
Есть много статей, книг и учебных программ о том, как работать с текстом и развивать ораторское мастерство. Чтобы научиться объяснять сложные вещи простым языком, я бы рекомендовала пересказать ваши доклады родственникам, не связанным с IT. Если они поняли всё или почти всё, то навык рассказчика у вас есть. А если говорить о визуальном представлении результатов, могу посоветовать бесплатный курс в Практикуме по созданию презентаций.
Умение планировать
Соблюдать договорённости и сроки важно для любого специалиста. От срыва дедлайнов страдает репутация, а ещё копятся задачи — легко набрать такой объём работы, от которого начнётся прокрастинация.
Если вы часто просите о переносе дедлайнов, делаете всё в последний момент или засиживаетесь допоздна в офисе, это признак неумения планировать. У каждого свой рецепт личной эффективности, но мне особенно помогают несколько вещей. Во-первых, я фиксирую все задачи в гугл-документе, чтобы ничего не выпадало из фокуса. А во-вторых, рассказываю о своих планах коллегам на ежедневных и еженедельных встречах. Публичность дисциплинирует и тренирует навык планирования.
На курсе «Аналитик данных» в Практикуме студенты не только осваивают инструменты для работы, но и учатся работать в режиме спринтов над проектами. Кроме того, будущие аналитики данных общаются с коллегами и наставниками, а в конце обучения — работают над резюме, портфолио и самопрезентацией в карьерном центре Практикума.
suslovas
С каких пор умение работать с данными стало софт-скиллом? Раньше эти навыки были обязательны для любого, кто занимался наукой от физики до психологии, а теперь выделили в отдельную профессию.
Первый пункт про недоверие к данным - это вообще за гранью. Как можно не доверять данным с которыми ты работаешь? в чем тогда смысл такой работы? Вопрос не про доверие, тут вопрос про умение их интерпретировать и работать с ними, при чем работать и на этапе их сборки. Вы привели примеры данных, которые на уровне здравого смысла некорректны. а что делать с данными, которые не так очевидны? А что делать с данными, которые корректны, но контринтуитивны? Тут надо задаваться всегда вопросом о методике сбора данных и правдивости источника, но чего точно не должен делать профессионал, так это опираться на личный опыт и "здравый смысл". Например я смотрю на статистику, где написано. что в мире 10% населения чернокожие и опираясь на личный опыт могу сказать. что ну это же бред, я за всю жизнь их видел человек 10, тут явная ошибка в данных и наоборот, в статистике написано что 90% населения европеоиды и решают, что ну да, вполне соответствует моему опыту. все верно. Так что проверка данных - это нормальный процесс. а не вопрос доверия к ним.
Тоже самое и с корреляциями, в науке давно научились с ними работать, а специалисты по данным, вроде как, до сих пор удивляются. Любые корреляции данных в рамках эксперимента. которые не связаны с гипотезой могут быть только восприняты как предмет для отдельного исследования, но не как материал для вывода, потому что при сборе большого количества метрик очень высокая вероятность, что две метрики будут вести себя случайно похоже. Верно и обратное - если вы не видите прямой связи между метриками. это не значит. что ее нет, вопрос в интерпретациях.
Вот вам, например, интересные данные, которые согласно вашей статье нам нельзя нести заказчику - средняя продолжительность жизни вич-положительных превышает среднюю продолжительность жизни здоровых по состоянию на 2016 год. При этом процент хронических заболеваний у них выше и манифестация раньше. Согласитесь. с точки здравого смысла - это же бред. Ну и странная корреляция между высокой частотой хронических заболеваний и высокой длительностью жизни, что казалось бы должно быть наоборот. Но если мы как-раз таки займемся вопрос интерпретации и сбора данных, то выясним. что вич-положительные обращаются к врачам гораздо чаще и охотнее, чем их "здоровые" соседи, а значит получают помощь раньше, но и выявляют проблемы у них чаще и раньше, за счет более аккуратного слежения за здоровьем и регулярным медицинским процедурам, живут дольше.
Так что доверять данным можно и нужно, если вы качественно провели их проверку и это не вопрос софт-скиллов, это вполне себе хард-скилл исследовательская задача.
Darina_Kukhtina Автор
Привет!)
Спасибо большое за такой развернутый комментарий.
Умение работать с данными в целом, я, конечно, не называла софтскиллом -- лишь некоторые аспекты, которые, на мой взгляд, невозможно "выучить".
Мне кажется, что про "недоверие" -- это вопрос формулировок) Я согласна с тем что Вы говорите, текст в абзаце показывает то что стоит валидировать данные, и я использую именно такую формулировку чтобы еще сильнее подчеркнуть важность этого процесса. На моей практике многие начинающие специалисты этого не делают -- относятся к данным как истине, в которой не может быть ошибок, и я хочу еще раз подчеркнуть что не стоит думать что это некие "идеальные" данные, а стоит проверить их, в том числе на здравый смысл. При этом речь не идет про проверку на дубли, например -- это безусловно хардскилл любого аналитика.
По поводу корреляций -- всегда есть соблазн выдать желаемое за действительное, особенно когда заказчик в этом заинтересован и будет доволен результатом. Именно из-за этого я посчитала важным это подчеркнуть. Я неоднократно сталкиваюсь на своей работе с такими кейсами.
Ваш пример про заболевания очень интересный! На мой взгляд, он как раз укладывается в парадигму "недоваерия" к данными. Получил контринтуитивный результат -- проверь что это точно так и пойми почему. Про то что его не стоит озвучивать, конечно, речи нет) Речь идет лишь о том что нужно понимать почему он такой, и уметь объяснить это заказчику. На моей практике, для заказчика этот результат также скорее всего будет контринтуитивен и лучше заранее понять как так вышло)
Итого, на мой взгляд, часть проверок данных безусловно относится к хардам, но часть к софтам)