Scrum для аналитиков. Как мы построили процессы в Кошельке
Иметь целый штат умнейших data-аналитиков, которые виртуозно жонглируют данными, находят инсайты и приносят компании дополнительную ценность — настоящий тренд! Все хотят, и многие даже делают. И еще сталкиваются с некоторыми проблемами:
Аналитиков на рынке мало;
Толковых аналитиков, понимающих, как принести пользу бизнесу, еще меньше;
Как организовать этим редким гениям работу эффективно — не понятно.
Со стороны может показаться, что построить аналитикам процессы просто, но на деле профессия data-аналитика весьма специфична. Процессы для разработчиков и менеджеров уже давно придуманы и обкатаны. Но data-аналитики работают совсем иначе. Они не привязаны к релизам, им не помогают техписы и системные аналитики, как разработчикам. Перенять стиль работы менеджеров они также не могут, ведь перед ними стоят совершенно другие задачи. Часто они вообще работают практически отдельно от команды, предоставлены сами себе. И что они там делают — загадка.
Бизнес совершенно точно захочет получить от аналитиков результат. Но чтобы организовать им комфортные условия работы для достижения этого результата, надо сильно погрузиться в контекст. В этой статье я расскажу об особенностях работы data-аналитиков и поделюсь, как взяла за основу scrum и оставила только каркас, идеологию. Адаптировала в Кошельке процессы, которые успешно прошли тест-драйв длиною в год.
Data-аналитик
Как правило, обучение аналитиков состоит из изучения инструментов: базы данных, статистика, математика, data science. Другими словами, много техники — при этом профессия прикладная. А сама по себе аналитика не дает ценности. Она помогает принимать правильные решения бизнесу. И только когда они их примут — эта ценность появится. Чтобы это случилось, аналитик и заказчик должны друг друга правильно понять на этапах постановки задачи и презентации результатов. Тут я упомянула сразу несколько особенностей, которые раскрою ниже.
Аналитик только частично участвует в создании продукта. Он продумывает ТЗ на разметку статистики новой функциональности и создает задачи на разработку, продумывает и запускает эксперименты. В остальном это творческая работа, которая не привязана к релизам. То есть аналитику нет смысла работать в основных спринтах своей команды, в которых живут задачи на разработку и тестирование.
В то же время это создает ощущение оторванности от общего процесса. Хочется ощущать себя частью команды, чувствовать свой вклад в общее дело —, а взаимодействие происходит в основном с заказчиком задачи. Дальше аналитик предоставлен сам себе.
В процессе разработки есть переводчик с языка бизнеса на язык, понятный программисту — системный аналитик. Data-аналитику с этой задачей приходится справляться самостоятельно. Понимание контекста — один из самых важных аспектов работы аналитика. Без него сложно хорошо сделать задачу, не впасть в фрустрацию и в целом оценить полезность проделанной работы. Часто заказчики пытаются помогать аналитикам, когда прописывают, что именно аналитику надо сделать. Я имею ввиду не просто «помоги мне вот с этим», «я хочу вырастить конверсию», «давай проведем тест», а чётко прописанный уже скорее запрос: «выгрузи мне показатель X за время t», «выведи метрику [методика расчета метрики] на дашборд», «посмотри, менялась ли конверсия сценария Y в период между t1 и t2», и в том же духе. Наверное, это быстрый путь, но не самый эффективный. Это лишает аналитика инициативы придумать решение лучше, отбирает у него творческую составляющую работы, делая из него просто исполнителя. А главное — это тормозит его погружение в контекст бизнеса. Ведь он не понимает, для чего он смотрит динамику конверсий, выгружает данные и за чем на самом деле хочет следить продуктовый менеджер, когда просит его автоматизировать уже придуманную формулу на дашборд.
То, как аналитик оформляет результаты своей работы, — еще один важный аспект. Часто ему сложно переключиться с языка сложных терминов на язык, понятный заказчику, оформить все в доступном виде, «навести красоту». А поскольку работа аналитика — приносить не основную ценность бизнесу, а дополнительную, то многим заказчикам проще махнуть рукой и принять решение самостоятельно, чем добиваться от аналитика простого разъяснения.
Предоставленные сами себе аналитики, к которым заказчики обращаются напрямую, могут также столкнуться с большим потоком задач с горящими сроками. Оценить важность «срочной» задачи, когда давят стресс и дедлайн, бывает сложно. А отказать в задаче для многих еще сложнее.
Давайте соберем все особенности работы data-аналитика вместе:
Оторванность от создания продукта и работы остальной команды;
Необходимость понимать бизнес-контекст и разговаривать с заказчиками на одном языке;
Инициативность в переработке постановки задачи и предложении лучшего решения;
Умение презентовать свою сложную работу простым языком;
Оторванность от конечной ценности для бизнеса и потеря ощущения собственной пользы.
Команда, в которой работает аналитик, сильно влияет на характер его задач и тоже накладывает свою специфику.
В продуктовых командах обычно все задачи идут от менеджера продукта. Работа в продуктовой команде, как правило, спланирована, а из внезапных срочных задач бывают исследования аномалий в бизнес-критикал метриках. Продуктовый менеджер должен понимать работу каждого члена своей команды и, конечно, знать свой продукт лучше всех. На курсах продактов учат самостоятельно разбираться в базовой аналитике, находить ответы на несложные вопросы, проводить аналитические исследования. Это хорошо на этапе, когда в продуктовой команде нет своего аналитика. Но когда он появляется — надо передать ему задачи, выделить зону его ответственности и набраться терпения, пока аналитик погрузится в контекст продукта. Хороший продакт-менеджер точно знает, что ему надо от аналитика. И поскольку тривиальные задачи он может выполнить сам, иногда привлекает аналитика просто как «руки» на те задачи, с которыми самостоятельно справиться уже не может. У аналитика это подрывает ощущение собственной экспертизы и чувство своей «территории». И, к сожалению, это иногда приводит к тому, что продакт совершает ошибки, тесты проводятся с нарушениями, выводы делаются неправильные.
В операционных направлениях всё совершенно наоборот. Менеджер по продажам, аккаунт-менеджер или маркетолог скорее придут за экспертизой аналитика. Их задачи, как правило, будут проще, быстрее в выполнении и принесут быстрый дофамин. Только в таких направлениях заказчиков у аналитика много, их работа сложно планируется и (чаще всего) с горящими сроками.
Scrum для data-аналитиков в Кошельке
Перед тем, как я приступлю к тому, как же мы в итоге решили все эти проблемы процессами, немного добавлю именно нашего контекста для общего понимания.
Приложение «Кошелёк» — это продукт с b2b2c формой бизнеса и матричной организационной структурой. У нас есть продуктовые юниты, которые создают разные части приложения, есть большие отделы продаж и аккаунтинга наших партнеров, команда монетизации и марткетплейс, на котором размещаются партнерские предложения для конечных пользователей. А также support, маркетинг, финансовый отдел и другие. Уровень аналитиков тоже разный: от junior до senior. Все команды используют для task-треккинга Jira.
Мы используем все артефакты скрама: спринты, дейли, демо, ретро –, но делаем это немного по-своему.
Спринты. Еще совсем недавно все без исключения data-аналитики работали в одном едином аналитическом спринте. Длина спринта — одна неделя. Каждый выполнял задачи своего направления, но спринт был общим. Так нам было удобно выстраивать аналитические процессы, обкатывать их и подправлять, настраивать вид задачи в джире и много чего еще. Сейчас, когда этап постоянных переделок и экспериментов позади, мы добавили во все пространства других команд тип задачи Data-Analytics Task и продублировали туда все свои поля и шаблоны. Часть аналитиков теперь работают в спринтах команды, и мы наблюдаем, чтобы всем было комфортно. У операционных направлений чаще всего спринтов нет. Аналитики этих команд продолжают работать в общем спринте аналитиков.
Сама суть спринта по скраму в том, что в итоге вы командой создаёте какой-то конечный кусочек продукта, релиз. Конечно, в этом смысле мы используем скрам не по назначению. Но что нам удобно — мы точно знаем, чем мы будем заниматься неделю. И даже с большим бэклогом задач неделю можно не вспоминать о нём, чтобы он не давил.
Планирование спринта. Планируемся мы еженедельно каждый со своим лидом направления: менеджером продукта или руководителем операционной команды. Они помогают нам приоритизировать задачи, так как лучше всех понимают, какие из них важнее. А также, что немаловажно, берут на себя ответственность за то, что какая-то задача не попадет в спринт. Это особенно важно в работе операционных направлений, где заказчиков может быть много. Что удобно в этом случае для заказчиков — они примерно понимают, когда будет сделана их задача. Нет необходимости регулярно спрашивать аналитика по всем таскам о сроках.
Мы втягиваем руководителя направления в планирование работы его аналитика. Не все из них готовы уделять свое внимание этому каждый день. Это ещё одна причина, почему спринты — удобный для нас формат. Есть еженедельные встречи, на которых менеджер и аналитик планируют работу на неделю. Можно работать и по канбану, но только тогда, когда менеджер готов ежедневно держать контакт с аналитиком по задачам.
Случалось, что продакт-менеджеры формулировали задачи для своего аналитика прямо на планировании спринта. В итоге аналитик наспех оценивал задачи, не попадал в оценку и не успевал закончить все задачи в спринте. Тогда мы разделили часовую встречу для таких команд на 2: полчаса в начале дня на обсуждение новых задач, затем аналитик самостоятельно оценивает задачу, и уже на второй тридцатитиминутной встрече — планирование спринта. По сути, грумминг, но тоже не в классическом варианте.
Работа в спринтах упростила нам выполнение каких-то больших важных задач, пусть и без дедлайнов, но полезных. Обычно мы брались за те, у которых были горящие сроки и активные заказчики. В итоге большие инициативы все время откладывались. Теперь мы заранее оформляем их в эпики, декомпозируем на задачи и распределяем на будущие спринты. Кажется, что несложно выделить процентов 30–40 ресурсов аналитика на что-то важное, но с отложенной пользой.
Вброс задач в уже запущенный спринт. Конечно, он случается, и в этом нет ничего критичного. Тогда лид направления просто должен оценить важность задачи на вброс: важнее ли она тех, которые уже взяты в спринт. Если задача включается в спринт, то в том же объеме сторипоинтов задачи должны быть выброшены —, но с обязательным указанием причины.
Такая процедура, пожалуй, приучила заказчиков, особенно операционных направлений, планировать задачи заранее. Аналитик не чувствует своей вины за то, что взял задачу в спринт, но не сделал, потому что переключил свое внимание на вброс.
Вбросить в спринт задачу можно, только всё же у нас есть одно важное правило — минимальный срок завтра. Это означает, что мы не возьмемся за задачу, которую поставили и просят сделать вот прямо сейчас. У таких задач есть плохие последствия. Дедлайн «срочно сейчас» вызывает стресс, в котором не всякий аналитик быстро сориентируется, придумает для задачи правильное решение. А главное, не каждый лид направления сможет спокойно оценить приоритет таких задач. В итоге зачастую ничего хорошего по таким задачам не получается.
Конечно, мы не просто в ультимативной форме просим соблюдать это правило. Как только мы его ввели, мы собрали с наших заказчиков все запросы, которые обычно возникают у них внезапно и срочно, и снабдили их дашбордами и инструментами для самостоятельного использования. О том, как мы автоматизировали наш Ad-hoc, можете почитать в статье «Как мы автоматизировали выгрузки и другие Ad-hoc задачи аналитика с помощью Zeppelin».
Задача на data-аналитика. Выше я уделила много внимания тому, что аналитику важно понимать контекст и проявлять инициативу в выборе решения задачи, и тому, что зачастую нам сложно почувствовать пользу для бизнеса от своей работы. Для решения этих проблем мы добавили шаблон в описание задачи на data-аналитика. Чтобы снизить порог входа, мы добавили примеры, как описать самые типовые задачи, и обоснование, для чего мы усложнили жизнь нашим заказчикам и какая на самом деле для всех польза от нового шаблона.
Шаблон описания задачи на data-аналитика выглядит так:
Предыстория: Проблема / Вопрос: Решение: (заполняет аналитик) Ожидаемый результат: (заполняет аналитик, согласовывает с заказчиком) Конечная цель: Вклад: |
«Предыстория» позволяет аналитику погрузиться в контекст задачи, откуда она идет. Часто заказчики думают, что это либо ненужная информация, либо все и без того в контексте. Но это не так.
«Проблема / Вопрос» заставляет сформулировать, что же в итоге случилось, конкретизировать вопрос к данным. Мы много времени потратили на переделывание задач, в которых «Проблема / Вопрос» не были прописаны явно. А ещё этот пункт — и есть импульс для придумывания аналитиком решения проблемы, способа ответить на поставленный вопрос.
«Решение: (заполняет аналитик)» — этот пункт стал настоящим облегчением для тех заказчиков, которые говорили «у меня есть задача, но я пока не понимаю, как ее поставить». Это случалось, когда заказчик думал, что должен продумать решение. А это работа аналитика. Получается, что, немного усложнив описание задачи, мы на самом деле упростили ее постановку. Но были и те заказчики, которым не хотелось тратить время на заполнения вотэтоговсего, а было проще написать конкретно, что им надо. Я уже упоминала, чем плох такой подход. И принятие, что мы все работаем по одним правилам, помогло нам найти контакт и с ними.
«Ожидаемый результат: (заполняет аналитик, согласовывает с заказчиком)». Например, ответ на вопрос, инсайты, дашборд. Или подробнее: excel-файл, выгрузка в csv. Чем подробнее описан этот пункт, тем меньше разочарования ждет заказчика, когда аналитик придет к нему с готовой задачей. Каждый живет в своей парадигме, и важно проговорить все такие моменты.
«Конечная цель:» помогает аналитику лучше понять, сделана ли уже задача или от него требуется ещё что-то. С этим тоже могут быть проблемы — не все чувствуют момент, когда уже можно остановиться и, например, завершить исследование.
«Вклад:» призван помочь в приоритезации задач в спринт и заодно донести до аналитика ценность его работы. Этот пункт может вызвать затруднения. Мне помогает задать вопрос «а что будет, если эту задачу не сделать?». Так задача из «выгрузи мне показатель Х помесячно за год» может превратиться в »… так мы сможем пройти инвестиционную комиссию». Описанная таким образом задача точно попадет в спринт с высоким приоритетом, а аналитик почувствует важность своей работы.
Оценка задач. Когда задача описана, аналитик продумывает решение, согласовывает его с заказчиком и оценивает задачу. Если это необходимо, дополнительно общается с заказчиком голосом и вообще не избегает коммуникаций. Для нас оптимальной стала оценка задач в сторипоинтах. Кому-то покажется сложным: как это, оценить работу в попугаях, ведь проще оценить задачу в часах? Но наша практика показывает, что мы тогда скорее задачу недооценим, а в конце спринта будем ломать голову, почему в итоге у нас не получается 40 часов. Еще оценка во времени может привести к торгу с лидом направления, что не может быть приятным. Ведь, на его взгляд, задачу можно сделать в 3 раза быстрее. А сторипоинты для них абстрактная величина.
Мы для себя решили, что задача на 1 сторипоинт — это что-то простое, где не сильно требуется наше внимание, что мы уже делали раньше. Например, это может быть простая выгрузка, график в Amplitude.
У нас бывают задачи на 1, 3, 5 и 8 сторипоинтов. Внимательный читатель заметит, что нет задач на 2 сторипоинта. А это сделано специально, потому что где 2, там и 3. И лучше немного перезаложить. Так же нежелательны задачи на 8 сторипоинтов, их лучше декомпозировать. Потому что чаще всего это оценка означает просто «много», что, согласитесь, имеет посредственное отношение к планированию.
Еще одно правило — мы не берем в спринт больше сторипоинтов, чем сделали в предыдущем спринте. Ни к чему героизм, выше головы не прыгнешь. Нам важно не давать заказчикам ложных ожиданий. И если мы взяли задачу в спринт, значит стремимся ее закончить. Конечно, когда наша продуктивность растет, и мы успеваем закончить все, что взяли, раньше окончания спринта, мы с лидом добираем задачи из бэклога.
Такие оценки (и в целом спринты) открыли глаза нашим заказчикам на то, что ресурс аналитики ограничен. Сторипоинты дают им возможность планировать нагрузку на аналитика даже в этих абстрактный попугаях. Вот 3 задачи на одинаковые выгрузки суммой на 9 сторипоинтов, а вот задача на автоматизацию этих выгрузок на 5 сторипоинтов. Уже нагляднее, чем вот 3 простых задачи и одна сложная. А еще так легче понять, когда пора открывать вакансию на дополнительного аналитика в направление.
Дейли. Несмотря на то, что аналитики не работают все вместе над созданием единого продукта, нам все еще важно и полезно синхронизироваться. Наши дейли начинаются в 10 утра и длятся 30 минут. И это еще одно отступление от скрама, в котором дейли — это 15-ти минутные стендапы коротко по статусам.
В условиях удаленной работы дейли в 10 начинают наш рабочий день, дисциплинируют и помогают сохранить темп. У нас нет цели синхронизироваться по статусам. Мы определили цели дейли для себя так:
Синхронизироваться по тому, кто чем занимается. Иногда случается так, что работа одного из нас может как-то повлиять на работу другого.
Сообщить о победе или проблеме. Поделиться успешно выполненной задачей всегда приятно. Другие аналитики точно смогут оценить проделанную работу, а заодно и вдохновиться опытом коллеги. Мы с удовольствием помогаем друг другу, когда возникают сложности. Возможно, кто-то из нас уже был в подобной ситуации.
Именно на этой встрече мы решаем, кто кому с какой задачей сможет помочь. Получается не сидеть долго над той задачей, которая никак не поддается решению. И у всех нас периодически может такое возникнуть, независимо от опыта.
Тайминг в 30 минут позволяет нам уделить внимание каждому (нас сейчас 11 человек в функциональном направлении data-аналитики). А заодно у нас есть время на шутки, истории, что даёт нам то самое ощущение командности, которое не всегда получается выстроить в команде продуктовой или операционной.
Демо.В конце спринта мы проводим демо работы аналитиков. С ростом сложности задач мы стали проводить его реже. И в целом это необязательное мероприятие, но очень полезное. На нём обычно выступает от двух до четырёх аналитиков. Проходит демо в виде презентации, запись которой мы выкладываем в общие каналы в slack.
Мы рассказываем о самых важных или интересных своих задачах. Упор всегда делаем на ценность для бизнеса: какие проблемы были, как мы их решили, как наши заказчики будут использовать то исследование или инструмент, который мы для них сделали.
Какая польза от демо:
Мы тренируемся презентовать результаты своей работы. После демо мы можем обменяться фидбеками, понять, что можно было бы улучшить в подаче материала. Также мы тренируемся, когда смотрим выступления коллег по команде, запоминаем интересные приёмы, что было хорошо и особенно понравилось.
Мы вдохновляемся работой друг друга. Дейли дает нам общее понимание, но не позволяет взглянуть на задачу в целом. А на демо у нас получаются будто небольшие митапы.
Мы вдохновляем других. Часто случалось, что инструмент или исследование, который сделал аналитик одного направления, навело на интересные идеи коллег другого направления.
Мы расширяем представление компании о том, чем занимаются data-аналитики, что умеют. Потому как аналитика — это нечто дополнительное, неочевидная часть работы других, наши результаты могут потеряться и не быть прозрачными. Потеряться не в том смысле, что их не найдут, а скорее, что в широком смысле их упустят.
Ретро. О, мы очень любим наши ретро. Некоторые даже шутят, что наши ретро напоминают психологические кружки. Опять же, мы работаем в разных командах. Поэтому классическое ретро, на котором коллеги, работающие вместе, обмениваются фидбеками — не наш формат.
На наших ретро мы обсуждаем, что нам понравилось в прошедшем спринте и что мы бы хотели изменить. Не конкретный план действий, но что нам не понравилось. Мы стараемся обсуждать прямо все. Потому что удовлетворенность работой складывается тоже из всего. Я могу смело сказать, что ретро — это то мероприятие, которое является источником всех наших изменений. Благодаря нему мы оперативно поднимаем волнующие нас вопросы, находим им решения и, как минимум, но всё же важно, спускаем пар. На них нет наших непосредственных руководителей, и мы можем смело открыто высказываться.
Я с уверенностью скажу, что наши ретро — одна из причин нашей низкой текучки и тёплой командной атмосферы. Потому что мы всегда открыты, поддерживаем друг друга, помогаем, радуемся успехам, делимся позитивным вайбом.
Ещё это важный инструмент для тимлида. Как у аналитика и лида направления формально есть встреча по планированию работы, так и тут это формальная встреча, на которой тимлид берет себе в работу решение каких-то организационных задач, чтобы исправить беду, возникающую у аналитика.
Из того, что не раскрыла
Отличие работы data-аналитика от работы менеджера. Почему я всё же считаю, что аналитику нужны спринты, а не свободное плавание?
Во-первых, самое главное — это специфика самих задач. Тут, как и с разработкой, надо погрузиться в суть задачи, держать фокус. Исследования требуют большой концентрации внимания. Спринты позволяют нам сократить коммуникации во время недели и перенести их ближе к планированию.
Во-вторых, хотя это относится скорее к аналитикам, работающим в операционных командах, у аналитика может быть много заказчиков. И нам очень удобно планировать этот большой поток задач с разных сторон раз в неделю.
И в-третьих, мы не создаём ценность для бизнеса сами. Но нам важно ощущение собственной полезности. Спринты и демо дают нам ощущение проделанной работы, прогресса.
Финалочка
В заключение скажу, что совершенно необязательно брать какую-то методологию и соблюдать её в точности. В основе всех этих подходов первоначально лежит своя философия. И важно на самом деле понять именно её: почему, как и для чего возник этот инструмент.
Самое главное — помнить, что процессы — это тоже инструмент. Они должны актуализироваться, улучшаться. И, как любой инструмент, процессы созданы, чтобы помогать всем работать эффективнее. Нет единого рецепта, но есть каркас, который поможет выработать свой уникальный эффективный рабочий процесс.
