Анализ и проектирование систем *

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

Меня зовут Мочалин Евгений. Я работаю в технической команде фронтенда медицинской компании СберЗдоровье. В этой статье я хочу поделиться историей, как мы выстроили процессы внутри команды, чтобы работа со всеми продуктами компании была прозрачной, стандартизированной и очевидной для всех сотрудников.

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

Нужна ли аналитику креативность? Работодатели, похоже, считают, что нет или что креативность не важна. Например, на hh.ru всего 10 вакансий «с креативностью» по всей России на момент написания статьи. И только в двух из них (Ozon и «Ростелеком») говорят напрямую, что креативность нужна.

Я работаю с данными почти 20 лет, и из них семь набирала и растила джунов, три — наставник в Практикуме на курсе «Аналитик данных». Предлагаю вместе подумать, а нужна ли нам креативность, как проверить, есть ли она, можно ли её чем-то заменить и как прокачать.

Хабр, привет!

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

Идеальная документация должна выполнять две основные функции...

Гайд для самопроверки бизнес-историй перед отдачей их на ревью лиду аналитики и команде

Достаточно большой опыт работы с бизнес-историями помог мне сформировать список правил для их самопроверки перед финальным показом команде. И в этой статье я хочу поделиться ими с вами.

Часто в больших компания всё поделено на большие системы. А если система «Legacy», т.е. устаревшая, то часто внутри неё собрано очень много разнородного функционала. По сути такие системы представляют из себя монолитных монстров.

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

Границы систем размыты, нет чёткого понимания, что должно входить в систему, а что нет.

Команды сильно специализированы на конкретную систему и не могут участвовать в доработке никакой другой системы.

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

Можно ли исправить ситуацию коренным образом?

Всем привет! Делюсь очередным выпуском нашей рубрики «Открытый микрофон», тема этого выпуска — «Как написать свою первую спецификацию на REST API».

Спикером стала Мария Яковлева. Маша — ведущий аналитик Платформы Сфера, НОТА (Т1 Консалтинг). В интернете много описаний особенностей архитектурного стиля REST, но мало информации о том, как аналитику начать создавать качественные спецификации на REST-методы. Маша поделилась своим опытом и, что особенно ценно, ошибками, допущенными в работе. А ещё Маша систематизировала их, чтобы уберечь вас от них)

Ниже предлагаю расшифровку трансляции, ссылку на сам выпуск оставлю в конце статьи.

Привет, меня зовут Сергей, я ведущий разработчик в DDoS-Guard и человек из мемов xkcd, который любит всё экстраполировать, истовый фанат визуализации данных. Диаграммы и графики решают кучу моих проблем с онбордингом джунов и объяснением задачи исполнителям. 

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

Привет, Хабр!

A/B тестирование позволяет принимать обоснованные решения о том, какие функции или изменения наилучшим образом способствуют улучшению пользовательского опыта и повышению конверсии. Однако, несмотря на кажущуюся простоту проведения таких экспериментов, существует ряд подводных камней, которые могут серьезно исказить результаты. Один из самых заметных и опасных — это так называемая проблема peeking или подглядывания. Эта проблема возникает, когда аналитики и маркетологи начинают слишком рано анализировать данные теста, не дожидаясь его завершения. Такое поведение может привести к неверным выводам и решениям, которые, в свою очередь, могут нанести ущерб бизнесу.

В статье рассмотрим, что такое проблема подглядывания в контексте A/B тестирования как ее решить.

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

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

Всем привет! На связи мы, Мария и Яна из самой драйвовой IT-команды «БАРС Груп». В этой статье расскажем, как создавали инструмент эффективного взаимодействия в IT-команде — базу знаний постановок задач, которые реализует проектная команда. По порядку разберем, почему мы решили создать шаблон, как разрабатывали и как доводили до ума после внедрения и, конечно, о результатах.

Чем похожи дашборд и рекламный баннер? 

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

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

Этот материал может быть полезен для COO, бизнес-аналитиков и топ-менеджеров компаний. Хотя в тексте присутствуют некоторые технические детали, надеюсь, они не будут слишком сложными. Цель материала: показать общую логику, которую мы использовали для извлечения и анализа данных.

Привет, Хабр! Меня зовут Грант, я уже 5 лет занимаюсь backend-разработкой в SimbirSoft, а с 2021 года возглавляю Backend-отдел компании в Краснодаре. В последние несколько лет неоднократно замечаю, что на входном интервью соискатели часто путают принципы разработки. Поэтому в этой статье решил разобрать, как проще их понимать, какие связи между ними прослеживаются, стоит ли учить все или что-то можно пропустить. А еще попробую раскрыть некоторые особенности, какие секреты скрывают популярные принципы разработки.

Всем привет!

Меня зовут Рыловникова Татьяна. Я ведущий аналитик в компании Ви.Тех, а еще идейный вдохновитель клуба Питерских одинэсников, ведущая и автор подкаста «Аналитики у микрофона», докладчик и модератор на конференции АиУП.

Уже несколько лет для профессионального развития мне не хватает только курсов, аттестаций, видео и книг, я бы хотела поделиться с вами моими способами развития, расскажу на своем примере 5 способов, как еще может развиваться аналитик:

1. Обратиться к ментору

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

2. Самому стать ментором

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

3. Книжный клуб

Я столкнулась с тем, что чем более я погружаюсь в профессию, тем более объемной становится литература. Так, например, долго ходила вокруг книги Карла Вигерса «Разработка требований к программному обеспечению». Даже купила ее, начала читать, но, учитывая объем материала, я в нем терялась. Тогда я подумала, чтобы было бы классно читать книгу с коллегами. Сделала на работе книжный клуб для аналитиков, мы читаем по 2 главы раз в 2 недели и обсуждаем их. Главный профит: ребята рассказывают то, что пробовали или хотели бы попробовать и как на самом деле это выглядит на практике. Материал воспринимается намного лучше. А еще у меня прокачиваются организационные навыки.

Всем привет! Думаю многие читали кучу книжек по поводу Hexagonal, Onion, Clean, Layer Architecture и у вас могли остаться спорные вопросы как в сложности понимания материала, так и в реализации данных подходов в ваших проектах. Сегодня я хочу затронуть тему “Организации кода” и показать насколько это важно и легко одновременно на примере Layer Architecture (Слоистая архитектура).

Существует популярный подход к покрытию метриками Celery: он заключается в запуске некоторого процесса, который слушает события из специальной очереди, на основе этих событий обновляются объекты метрик, а фоновый поток сервера отдаёт собранные метрики скраперу. В этой статье подробно разберём события, их жизненный цикл, откуда и как их принимать. Также поговорим про механизм удалённого управления (remote control), какие у него есть возможности и как им пользоваться. Обсудим существующие решения, чем они отличаются, и почему вам, возможно, будет выгодно сделать своё.

Я буквально на поле боевых действий. Люди пишут комментарии, заставляют меня гореть в аду и сменить работу. Люди пишут свои советы.

Проходит день, два, три. На статье больше 68К просмотров и больше 180 комментариев. У меня все так же висит челюсть: материал джуна залетел в «топ». Минутка гордости за себя и свою практику письма. Эту весну я запомню надолго!

Но комментарии...

Всем привет! Меня зовут Вадим, и я QA-инженер в IT-компании Intelsy. С техническим заданием, и в частности с требованиями, лично я имею дело постоянно, поэтому собрал полезную для начинающих и продолжающих специалистов информацию по требованиям к IT-продукту,  их видам, техникам и метрикам тестирования требований. На эту инфу стоит ориентироваться не только аналитикам и тестировщикам, но и остальным членам команды.

Принцип “Не повторяйся” (Don't Repeat Yourself, или DRY), то есть избегай дублирования кода, часто относят к обязательным практикам в программировании. Однако в реальности часто можно увидеть, как в общем коде оказываются концептуально разные блоки, которые похожи только по внешним параметрам. Это неминуемо приводит к ухудшению кода и появлению "костылей", без которых он не работает. Именно поэтому слепое следование принципу DRY не всегда целесообразно! В этой статьей я расскажу про типичные ошибки при использовании этого правила и способы их избежать.