О чем все это
В данной статье я бы хотел поделиться своим кейсом работы над фичей для мобильного приложения, статья интересна тем, что выполняя задачи разработчика мне также пришлось выполнять задачи бизнес - аналитика и конечного пользователя(!) своей фичи.
Почему это актуально?
В современном мире, а тем более в России, когда работодатель, если не требует, то хотя бы намекает и ожидает, чтобы ты был "И швец, и жнец, и на дуде игрец" важно научиться выполнять те обязанности, которые изначально по должностной инструкции вам не полагаются, и пусть вы не замените полную штатную единицу бизнес-аналитика (не потому что с вами что-то не так, а потому что у вас обязанностей и по основной специализации хватает), но для работодателя (а возможно и для вас), это лучше чем ничего.
Что можно вынести из статьи?
Как работать с ожиданиями вашего Лида и Владельца продукта
Как понять, что происходит и декомпозировать задачу
И самое главное: как не отчаяться и не потеряться в неопределенности
Важно(!) - ни в ком случае не настаиваю на правильности своих подходов, поэтому любые советы будут приветствоваться.
Сам процесс реализации фичи: сервис по сбору логов мобильного приложения на iOS - будет представлен в следующей статье.
Пару слов обо мне
Мне 29 лет и в iOS - разработке я недавно: полгода учебы + пару месяцев коммерческой разработки. До этого я три года занимался разработкой отчетности на базе хранилищ данных, а перед этим еще 3 года работал в бизнес-консалтинге с уклоном (скорее даже нырянием) в ИТ, внедреняя системы материально-технического обеспечения для промышленных предприятий.
Как все началось
Подключаюсь как-то по скайп к планированию спринта и получаю задачу - написать сервис по логированию действий пользователя в мобильном приложении, в целом задача не звучит как что-то challenging даже для начинающего разработчика, если бы ни одно но:
- Я: как с этой аналитикой будут работать? - тишина
- Я: какие действия будем логировать? - тишина
- Я: какая архитектура (в смысле - передаем на бэк или будет отдельный сервис, в каком виде передаем и прочее)? - тишина
В общем, получилось так, что задача не была особо срочной и никто над ней долго не думал. Аналитик в команде всего один, и тот загружен собственными задачами, поэтому "Спасение утопающих..."
На самом деле не могу сказать, что как-то был выбит из колеи или не понимал, что происходит, опыт в консалтинг научил:
Один в поле воин
Если один в поле не воин, значит рано вышел на поле
(Уже не связано с полем) Привыкай "обтекать" - причем всегда и везде: идешь к сотрудникам из других подразделений, задаешь глупые вопросы, в лучшем случае получаешь в ответ ухмылки и сам ответ, в худшем мягкое "иди н@ ..." и снова ухмылки, но это закаляет: через пару месяцев таких походов вам уже будет все равно на чужие ухмылки вы просто не будете их замечать
Не бойтесь задавать глупые вопросы. Будет тяжело терперь ухмылки и насмешки в свой адрес. Но это закаляет, через пару месяцев вы перестанете на них реагировать. + !!! К тому времени вы узнаете то, что не узнали бы, не задавай вы вопросы
Что дальше?
Что дальше? - А дальше в случае отсутствия четко сформулированной задачи ее нужно сформулировать. Как?
1. Понять цель
Но цель ясна скажите вы: "Написать сервис для логирования действий пользователя" - это средство. Никто не не пишет сервис для сбора логов ради логов или аналитики, аналитику собирают для конкретной цели: на каких фичах мы можем заработать/сэкономить?; какими фичами не пользуются и почему (а нужны ли нам они вообще тогда?); где пользователь проводит больше времени, какими новостями, группами, фото, людьми интересуется? - мы можем это монетизировать? - и снова про деньги.
В общем все ради денег, как правило (или других бенефитов, если вы делаете внутри корпоративное приложение, хотя и в этом случае скорее всего все свидется к деньгам: заменить 3 корпоративные системы одной - чем ни деньги - можно столько сэкономить...)
Постарайтесь думать как Владелец бизнес, а значит "Show me the money" - будет на первом месте.
Итак имеем:
Ищем то, что может принести деньги. Помним, мы пытаемся четко сформулировать задачу. Написать сервис для сбора логов - не задача, а написать сервис, который собирает А,B,С сохраняет в кеше D и раз в сутки в формате E передает на сервер F - это задача.
Результатом первого этапа будет:
(В случае сервиса логов) 30 - 50 накиданных идей того, что нужно логировать в первую очередь, чтобы иметь на этом потенциальную монетизацию в обозримом будущем, например: если ваше приложение - это социальная сеть, то может вы хотели бы логировать лайки пользователей к фотографиям, а также комментариям, чтобы потом использовать machine learning для определения, почему пользователь лайкнул коммент или фото? - Пользователь лайкает кучу фото с изображением разных видов спорта - отлично, рекомендуем ему кроссовки найк новой коллекции.
Идей может быть любое количество, чем больше - тем лучше, на первом этапе можно и нужно охватить как можно больше.
2. Уточнить цель
Теперь вы вернетесь к команде, в первую очередь Лиду, ПрОдукту, бизнес-экспертам, чтобы валидировать свои 30 - 50 идей. Как правило, люди дают емкую обратную связь, когда к ним приходят с конкретикой, но из рук вон плохо формулируют, что они хотят, когда конкретики нет, особенно, если они об этом мало думали.
Дополнительным плюсом будет если вы отранжируете в порядке убывания идеи с наилучши соотношением выгода - затраты на реализацию. Это могут быть какие-то условные баллы, делать анализ окупаемости идей не нужно. Например, можете использовать качественную шкалу, приведенную к количественной оценке:
высокий эффект - 9; приемлемый эффект - 6; низкий эффект - 3
высокие затраты - 9; приемлимые затраты - 6; низкие затраты - 3
Разделите эффект на затраты и получите баллы, чем выше балл, тем более интересной может казаться идея. Помните, что ваша оценка очень субъективна и это норм, вы показываете свое видения эффекта. А дальше ранжируйте любым способом, например ABC анализ в несколько действий.
Если потребуется, ваш анализ отдадут аналитику для докручивания, в любом случае вы вряд ли ошибетесь по самым топовым позициям - пока он докручивает, вам будет чем заняться
Зачем вам все это?
Вы соберете конкретную обратную связь - не так как было в начале (см самую первую картинку), а точные рекомендации, что делать, а что нет
В случае большого приложения, даже если вы напишите универсальный сборщик логов, вы потратите достаточное количество времени, чтобы покрыть этим все приложение. В архитектурах VIPER, Clean Swift на это может уйти много времени, особенно, если вы работаете не с начала проекта, и все не создавалось на ваших глазах
Зачем вам логировать для аналитики то, что не нужно, не говоря про потраченное время (см предыдущий пункт), вы будуте тратить ресурсы мобильного приложения, бэка, стороннего сервиса на обработку того, что не требуется
Вы покажите себя в хорошем свете перед вашим Лидом и Владельцем продукта
3. Уточните целевую архитектуру
Имея на руках понимание, что делать, а что нет, вы можете сосредоточиться на обсуждение целевой архитектуры, для этого вам не требуется понимать бэк или сторонний сервис: вы уточнили бизнес-потребность и готовы выйти на тех людей кто работает с сервисом, в который вы планируете передавать данные. Обратная связь от спецалистов по возможностям сервиса и готовность использовать тот или ной подход позволит вам сформировать структуру передаваемых данных. Например, если вы слышите, что сервис готов работать по rest api (удивительно, правда?), принимать в любое время post запросы без ограничений по объему передавыемых данных, то вы ставите для себя одни границы, если слышите что-то другое, то иные.
Результат этапа:
Картинка целевой архитектуры с ключевыми тезисами
4. Сформировать модель данных
Пройдя все предыдущие пункты вы можете накидать предполагаемую модель данных. Если вы хотите, чтобы ваш сервис был универсальным, т.е. мог быть использован вне вашего приложения, то вы будете строить максимально универсальную структуру ( принимая во внимание обратную связь из пункта 3).
Например, в моем случае структура данных выглядела следующим образом:
метка времени
платформа
модель устройства
метод (переход на страницу, создание, удаление, редактирование объекта)
словарь с параметрами (передаем что угодно)
Если мы хотим залогировать лайк, это может выглядеть следующим образом:
1632683080 (юникс время)
ios
iphone11
create
["photoId": 173761, "like":1]
5. Финализировать описание задачи
Пройдя 4 круга ада фазы анализа мы перешли от: "написать сервис по логированию действий пользователя" к "написать сервис, который собирает А,B,С сохраняет в кеше D, используя модель D1(пункт 4, за исключением некоторых свойств модели, например: зачем хранить в кеше платформу и устройство, если можно передавать на сервер в хедере) и раз в сутки в формате E (пункт 4, но уже со всеми свойствами модели) передает на сервер F.
Теперь вы готовы представить описание данной задачи для финализации с Владельцем продукта, Лицом, Бизнес-экспертами и уже далее приступить к реализации.
Резюме
Наверное, все из нас слышали, что четко сформулированная проблема это уже часть ее решения. Постановка задач на разработку не исключение, четко формулируя задачу посредством ее предварительного анализа вы:
Избегаете ситуаций "почему ты так сделал, мы видели это по-другому". - Таким образом, работаете с ожиданиями Лида всей команды и бизнеса
Понимаете, что вам делать. - Избегаете состояния фрустрации и ловушки "Пойди туда не знаю куда..."
Знаете следующий шаг
P.S. Можно заметить, что первые 2 этапа: Цель и Уточнение цели - являются универсальными и могут быть использованы при решении абсолютно любой задачи.
P.P.S. Обратите внимание, что во время фазы анализа, мы дважды возвращаемся к Лиду, Владельцу продукта и экспертам со стороны бизнес. Таким образом, мы повышаем ценность, поскольку создаем именно то, что нужно; управляем ожиданиями, поскольку "на берегу" договариваемся о том, что будет сделано; хеджируем свои риски сделать не то, что требуется.
