Всем привет! Меня зовут Вера Сапожникова, я аналитик из Контур.Маркета. Это продукт для автоматизации малого и среднего бизнеса. Мы помогаем нашим клиентам вести товароучет, предоставляем кассовое ПО и закрываем сценарии взаимодействия с госсистемами: ЕГАИС, Честный знак и Меркурий.
В прошлом году мы решили завоевать новую ЦА и сделать отдельный продукт на базе Контур.Маркета для продавцов на Ozon и Wildberries, чтобы вести складской учет, обрабатывать заказы из разных маркетплейсов в одном окне, работать с отчетами.
Я вызвалась делать аналитику для этого продукта. Так и началась эта увлекательная история об испытаниях, которые ждут аналитика в стартапе.
А это буквально был стартап, ведь наша команда состояла всего из 6 человек: продакт, аналитик (это я), дизайнер, два разработчика и тестировщик. Я оказалась в условиях, в которых раньше никогда не была: единственный аналитик в команде, горящие дедлайны, неотлаженные процессы, сложности с интеграцией. В статье расскажу, какие сложности возникали на моем пути, и как я их преодолевала.
Как выстроить процесс, когда разработка и аналитика стартуют вместе?
Ресурсы были спланированы таким образом, что разработчики, дизайнер и аналитик приступили к работе по проекту одновременно. И чтобы начать, всем нужна аналитика, но ее нет. А живем мы в жестких дедлайнах, поэтому не можем растягивать разработку во времени.
В таких обстоятельствах мне не оставалось ничего другого, как позвать всех на штурм для генерации концепта. Но если вы решаетесь на такой шаг, то нужно заранее собрать фактуру и уметь отвечать на вопросы о сценарии пользователя и о деталях реализации. То есть, прежде чем привлекать команду, у аналитика должно быть понимание большинства бизнес требований.
Совместная генерация концепта позволит:
держать всю команду в контексте, им будет проще оценить задачу
придумать оптимальную (дешевую) реализацию
Собрать понятный команде концепт можно на доске. Команда сможет опираться на него и начать разработку/прототипы, а у аналитика появится время перенести все на wiki и уточнить детали.
Когда есть концепт, дизайнер уже может начать рисовать прототипы. С понятным концептом проектировать интерфейс и описывать аналитику можно синхронно.
А чтобы как можно скорее занять и разработчика, нужно начать аналитику с описания новых сущностей. Описав модели новых сущностей, разработчик сможет начать реализовывать модельки и инфраструктуру под них. У аналитика же появляется время описать сценарии работы с этими сущностями. Важно, что сущности можно описывать когда уже есть концепт и понимание сценариев, иначе сущности могут не биться с их назначением.
Но, стоит отметить, что в таких сжатых условиях работы нет-нет да и что-то будут кодить без аналитики. Поэтому встанет неминуемая задача зафиксировать всё постфактум. Описанная аналитика однозначно пригодится на этапе тестирования отличить баг от не бага, а еще избавит всю команду от цикличных обсуждений.
Как проектировать интеграцию без доверия к документации?
Теперь про работу с маркетплейсами. Там бардак – расходится информация в базе знаний, инструкциях и в документации АПИ.
Но и мы не подарок:
у нас не описана работа в краевых сценариях
нет описания ошибок и того, как их исправить
в команде нет экспертизы по тому, как работают маркетплейсы
Поэтому мы были готовы к неприятным последствиям. Я писала аналитику с допущениями, учитывая разные варианты поведения системы. И мы все ожидали много багов на этапе тестирования, так что закладывали время на их исправление.
Что еще делали, чтобы минимизировать риски:
Нашли возможность тестить сценарии и данные на бою. Так, я попросила своего брата продавать на WB по схеме «со своего склада», а наш продакт открыл на Ozon магазин по продаже нижнего белья.
На юзабилити-тестировании между делом спрашивали респондентов и о поведении маркетплейсах, задавали вопросы про пользовательский опыт, частоте сценариев. Например, так мы узнали, требуют ли на ПВЗ распечатку документов или можно показать с экрана. Главное не принимать слова пользователя за истину последней инстанции.
Нашли тематические чаты для разработчиков интеграций с маркетплейсами и консультировались там. Казалось бы, нужно писать в техподдержку маркетплейсов. Но, к сожалению, это нам ни разу не дало желаемого результата. Один раз случилось чудо – нам ответили и даже сделали необходимую доработку. Но ждать ответа пришлось месяц))
Чтобы не заниматься самогазлайтингом, когда ты уже сам себе не веришь, что было, а что нет, я советую фиксировать все детали, которые вызывали сомнения. Прям с пруфами: ссылки на разные статьи, скрины переписок, примеры запросов в постмане. Так будет легче доверять своей же аналитике и отслеживать изменения в артефактах на стороне маркетплейсов.
Как поддерживать частые изменения?
Сервисы, с которыми интегрируешься, тоже «живые». Они постоянно обновляют версии АПИ и отключают предыдущие версии.
Маркетплейсы часто добавляют новые фичи, изменяют сценарий обработки заказа и работы с документами. Например, Ozon отказался от акта приема-передачи, который обязательно нужно было предоставлять селлеру в сервисном центре. Теперь ему нужно сформировать штрих-код отгрузки и показать его электронном виде.
В общем, в любом случае придется переписывать аналитику и в последствии менять реализацию готовых задач. Плюс появляется риск того, что какой-то сценарий сломается в нашем сервисе, если мы вовремя не узнаем об изменении и не поддержим его.
Вот что можно сделать, чтобы быть в курсе изменений:
Подписаться на каналы, в которых сообщают об изменениях. Желательно на все.
Просматривать основную доку маркетплейсов на предмет внесения изменений. Особенно, если каналов оповещения об изменениях нет.
Завести процесс, в котором раз в N дней, ты проверяешь, появились ли изменения. Рассказывать команде об изменениях или их отсутствии.
Разделить ответственность с продактом. У нас было так:
аналитик следит за изменениями в существующих сценариях
продакт следит за появлением новых возможностей
И обязательно нужно рассказывать команде, если вносишь изменения в аналитику.
Сложности возникают у многих аналитиков при работе в разных проектах. Так что, думаю, я в этом не одинока. Возможно, вы нашли в моих советах что-то полезное для себя или пережили свой «болезненный» опыт через призму моих рассуждений. В любом случае, через сложности лежит путь к развитию.
Как писать аналитику в условиях стартапа, где процессы не выстроены, экспертиза не накоплена, а задать вопросы некому, я рассказала чуть более подробно в докладе Как проводить анализ в новых продуктах.