Какова роль аналитика и его задачи при разработке мобильных приложений?

Если вы задумались о разработке своего сайта или приложения, то уже наверняка знаете, кто должен входить в команду. Это, конечно, разработчики, тестировщики, менеджер проекта, который следит за всем и предоставляет отчеты, и, как минимум, один аналитик. И если остальные ключевые роли и их важность на проекте обычно не вызывают вопросов, то роль аналитика и его задачи понятны не всем. В этой статье мы с аналитиком Марией Плотниковой решили разобраться на конкретных примерах, какие IT-аналитики существуют и какую роль они играют на проекте.

Прежде всего, понятие аналитики очень широкое. Даже если говорить только о сфере IT, есть ряд направлений: бизнес-аналитика, системная аналитика, UX-аналитика, продуктовая, digital intelligence… Мы в компании Siberian.pro сфокусировались на трех областях, а именно системной, продуктовой и бизнес-аналитике. О них и расскажем подробнее.

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

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

Допустим, нужно создать такси-агрегатор. Основной сценарий понятен: пользователь указывает, где он находится и куда нужно попасть, система подбирает машину, пассажир доезжает до места и оплачивает заказ картой либо наличными. Кажется, все просто. Но как быть, если машин мало или ни один водитель не хочет брать заказ? Если у водителя или пассажира плохой интернет и невозможно отследить местоположение? Если по пути пассажиру перезвонили и надо ехать на другой конец города? Да, это, скорее, исключения, но система должна уметь с ними работать. Хороший аналитик опишет решение для таких случаев.

Результат работы бизнес-аналитика — описание верхнеуровневых бизнес-требований (ВБТ), техническое задание (ТЗ) с описанием сценариев в формате use cases и user stories, при необходимости дополненные схемами и диаграммами. Точный список зависит от проекта.

Например, исходное описание нового раздела для ритейл-сети может выглядеть так:

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

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

Описание бизнес-требований — один из основных артефактов проекта, который поможет решить сразу ряд задач.

• Если вы выбираете подрядчика или оцениваете целесообразность разработки, то чем точнее описаны требования, тем меньше разброс в оценках подрядчиков и ниже вероятность, что в ходе разработки появятся дополнительные расходы.
• Большая часть компаний отказывается разрабатывать проекты без предварительного этапа аналитики либо соглашается, но только по модели Time&Material и закладывая большие риски. Грамотно составленное ТЗ экономит бюджет и позволяет получить реалистичный прогноз насчет сроков поставки продукта.
• Вопросы, которые аналитик задает на этапе проработки спецификации, все равно возникнут у команды. И в таком случае возможны два варианта:
• Первый: разработчики будут постоянно вас отвлекать от других дел, а когда не получится отвечать сразу, это повлияет на сроки и может вызвать простои.
• Второй: разработчики будут решать вопросы на свое усмотрение, и, скорее всего, в некоторых моментах ваши мнения не совпадут. Придется переделывать функциональность заново. Если добавить этап аналитики, со всеми вопросами разработчики будут обращаться к аналитику. Как показывает практика, общение с командой занимает до 40% времени работы аналитика.
  

Если у вас уже есть ТЗ — это замечательно! Скорее всего, вопросы у подрядчика все равно возникнут, но их будет значительно меньше. Если нет — опишите своими словами все, что вам известно о проекте. Для чего он нужен бизнесу и как поможет пользователям. Кто эти пользователи и какие возможности у них будут.

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

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

Помимо описания работы системы рекомендуем упомянуть и нефункциональные требования. Нужна ли работа оффлайн? Сколько пользователей вы ожидаете в обычное время и при пиковой нагрузке? Какие браузеры или версии iOS/Android нужно поддерживать? Последнее разработчики закладывают, исходя из тенденций рынка, но если нужна поддержка старых версий, это лучше указать отдельно. Не нужно думать, что нефункциональные требования — мелочи: так, отдельная версия для планшетов может увеличить время на разработку до 1,5 раз.

Вы можете сэкономить на бизнес-аналитике, выбрав вместо тяжеловесной разработки по модели Fixed Price более гибкую разработку на основе Time&Material. Вместо того, чтобы писать требования на всю систему перед разработкой, можно будет двигаться вперед небольшими итерациями, каждый раз описывая часть системы, которая войдет в ближайший релиз. Добавив на проект продуктовую аналитику (о ней расскажем позже), вы сможете после каждой итерации отслеживать, как продуктом пользуются реальные люди, что им нравится, что вызывает сложности, чего они хотят. Так в работу пойдет только то, что нужно рынку, а вы сэкономите на разработке функционала.

Например, в начале 2020 года наш заказчик — сеть продуктовых магазинов — решил попробовать внедрить технологию Scan&Go. Ее суть в том, что покупатель в торговом зале сканирует штрихкоды, складывая товар в корзину, оплачивает в приложении и выходит с покупками, минуя кассы. На тот момент это была передовая технология, набиравшая популярность на Западе.

Наши аналитики начали анализ конкурентов и рисков безопасности и занялись проработкой ТЗ… когда грянула пандемия. Количество покупок в магазинах упало в разы, а доставка стала пользоваться небывалым спросом. Работы в направлении Scan&Go были быстро свёрнуты, и вся команда сфокусировалась на разработке интернет-магазина в существующем приложении лояльности. Вместо того, чтобы тратить миллионы на проработку раздела, который нельзя запустить, заказчик в краткие сроки получил интернет-магазин. Сервис быстро стал одним из самых востребованных разделов и заслужил высокие оценки пользователей. Он успешно развивается и по сей день.

Системный аналитик продолжает работу со сценариями, которую начали заказчик и бизнес-аналитик. После того, как сценарии описаны, системный аналитик соотносит их с реальностью. Если реальность не позволяет реализовать «придуманный» заказчиком и описанный бизнес-аналитиком сценарий, именно системный аналитик скажет, что нужно делать по-другому. Он предложит решения или изменит сценарий и проследит, чтобы в сопутствующих артефактах (например, в дизайне) всё соответствовало реальности.

Помимо этого системный аналитик прорабатывает техническую реализацию. Изучает API сторонних систем, описывает требования к интеграции, совместно с архитектором и разработчиками продумывает архитектуру и оптимальные способы реализации. В каком-то смысле системный аналитик — переводчик с языка бизнеса на язык программистов и обратно.

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

В разных компаниях роли могут распределяться по-разному, где-то задачи системного аналитика выполняет архитектор либо tech lead, где-то это доверяют разработчикам. В Siberian.pro аналитик — отдельная роль, но обычно системный аналитик и бизнес-аналитик — это один человек.

В зависимости от проекта артефакты могут отличаться. Наиболее распространенные — спецификация API в формате OpenApi 3.0 (описание взаимодействия разных частей системы: клиента и сервера), схема интеграции, модель данных, описание совместной работы «железа» и программы.

Описание технической реализации и ограничений гарантирует, что система реализуема с технической точки зрения, и что разные её части будут работать согласованно. Разработчики будут одинаково понимать, как она должна работать. Это позволяет одновременно разрабатывать разные части системы, сократить расходы на созвоны и переписку и избежать многих переделок. Также описание технической реализации значительно уменьшает затраты на поддержку проекта и упрощает погружение новых участников. А если вы решите сменить подрядчика, документы помогут новому партнеру быстро понять, как все устроено, и работать эффективно.

Если предполагается разработка с нуля, мы рекомендуем доверить выбор технологий, архитектуры и особенностей реализации исполнителю. Даже если у вас есть технические эксперты на своей стороне (или вы — эксперт), то лучше будет не диктовать свой взгляд, а организовать созвон с технической командой подрядчика и обсудить ваш подход. Вы сэкономите, как минимум, время: на коммуникации, споры о подходах и архитектуре.

Если же требуется доработка существующей системы или множество интеграций, лучше всего предоставить документацию на эти системы. Если вы опасаетесь, что конфиденциальная информация может быть использована во вред компании, предложите подрядчику подписать NDA. Эта документация неизбежно понадобится на проекте, а, предоставив её заранее, вы сэкономите время. Отсутствие документации влечёт за собой пробелы в архитектурных решениях и переделки.

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

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

Продуктовый аналитик, даже из другой компании, поможет сформулировать цели создания продукта, показатели, по которым можно отследить, достигнута ли цель и посоветовать систему для отслеживания результатов. Благодаря этому можно составить отчеты, которые будут в реальном времени показывать, как пользователи взаимодействуют с продуктом. Это поможет скорректировать план развития, добавить или убрать фичи. Некоторые системы создают отчеты автоматически, но другие, например, мобильная аналитика в Amplitude, требуют создания вручную. Тут опять поможет продуктовый аналитик.

Также мы в Siberian.pro помогаем работать с отзывами пользователей на маркетах. Постоянное отслеживание жалоб и предложений пользователей помогает повысить рейтинг приложения. Наш рекорд — прогресс оценки в Google Play с 3,2 до 4,8 за месяц. Разработчики быстро начали изучать жалобы и решать проблемы, и пользователи оценили высокую скорость ответов и исправления ошибок.

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

Прежде всего, продуктовая аналитика помогает ответить на три вопроса.

• Достиг ли продукт той цели, ради которой был разработан?
• Как с ним работают пользователи в реальной жизни?
• Что нужно сделать, чтобы улучшить результаты?

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

В первую очередь, не игнорировать этот аспект работ. Иначе вы потратите силы и средства на разработку продукта, который не будет востребован среди пользователей и не принесет выгоды. Либо у вас не будет возможности отследить, приносит ли продукт прибыль и стоит ли его развивать.

Чтобы сократить расходы, прежде всего, определите 1-2 основных цели, ради которых нужен сайт или приложение. Их не должно быть много: попытка одновременно увеличить продажи B2B и B2C, повысить лояльность, рассказать о новостях компании и ускорить подбор персонала, скорее всего, будет безуспешной. Как правило, пользователь приходит с конкретной задачей и быстро покидает сайт или приложение, если не видит, как ее достичь.

Определившись с целью, подумайте о показателях, которые помогут отследить ее достижение. Так, для цели «увеличить прибыль» показателями могут быть средний чек, количество покупок на пользователя, количество пользователей и объем продаж. Для постановки целей и задач удобно использовать схему SMART. Даже просто подумав над этими вопросами, вы сможете лучше осознать направленность вашего проекта и получить лучшие результаты при меньших затратах.

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

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

Если нужно разработать несложный проект (например, лендинг для одного продукта), на фриланс-бирже легко найти человека, который сделает проект в одиночку. Такой специалист и задачи проясняет, и код пишет, и тестирует. Нередко это оправданно: не нужно ждать другого человека, чтобы продолжить работу, весь контекст проекта в одной голове, потери информации минимальны, расходов на коммуникации мало.

Чем сложнее задача, тем больше компетенций требуется для решения. Тут совмещение ролей начинает играть против проекта: сложно быть экспертом во всех областях. Согласитесь, странно пытаться «сэкономить», убрав из команды iOS-разработчика и передав обе платформы специалисту по Android. Так и аналитик — специалист с определенным спектром задач и компетенций, и его работу специалисту другого профиля будет выполнить сложно. Совмещение ролей на сложных проектах почти всегда значит, что качество работ пострадает, а сроки растянутся до бесконечности.

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

Здесь нужно затронуть вопрос оценки проекта и того, из чего она складывается. Какую бы модель вы не выбрали для разработки проекта — Fixed Price, Time&Material или любой смешанный способ ценообразования, итоговая сумма напрямую зависит от стоимости часа специалиста. Клиент — первый, кто заинтересован в сбалансированном качестве и стоимости на проекте.

Если нанять дорогих специалистов для решения простых задач, это будет излишней тратой денег. А если поручить джуниорам сложные задачи, они могут не справиться или сделать продукт низкого качества, который придётся переделывать. Мы рекомендуем привлекать архитекторов и лидов для ревью ТЗ и решения сложных задач, поручив проработку и написание ТЗ аналитикам.

Основная задача аналитика на проекте — обеспечить, чтобы:

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

Совокупность этих факторов определяет успешность проекта и удовлетворенность от его создания. Часть задач аналитик выполняет вместе с другими членами команды, часть — самостоятельно.

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

#аналитика #mobile #mobileapp #аутсорс #программирование #product #project #разработка #разработчики #мобильноеприложение #приложение #карьера #личныйопыт