​​Интеграционные сценарии. Что такое и при чем тут аналитик?
(30 секунд)

Итак, как вы уже поняли из предыдущих постов, у меня накопилось много интересного про интеграции. Не отписывайтесь, скоро вернёмся к разговорам о «сложных» стекхолдерах)

Итак, одна из очень важных частей описания интеграций — это описание сценариев.

Что вообще такое интеграционный сценарий? Это последовательный набор шагов, которые должна выполнить каждая из сторон интеграции (чаще всего — конечные стороны: система-источник и система-получатель) для решения определённой задачи.

Описание сценариев состоит концептуально из 2-х вещей:

1️⃣ Определить, какие сценарии должны поддерживаться в рамках интеграции;

2️⃣ Описать шаги каждого сценария.

При чем тут аналитик, спросите вы?

Все просто.

Интеграционные сценарии не отвечают на вопрос: как? Сценарии интеграции отвечают на вопросы: кто? и что?

Именно аналитику, владеющему пониманием целей интеграции и процессов внутри систем, проще всего корректно определить и описать сценарии.

Что важно?

Важно не путать сценарии интеграции с sequence diagram, как методом описания межсервисного взаимодействия.

Во-первых, sequence diagram — это просто способ описания, а не сам сценарий, а во-вторых в случаях описания интеграционных сценариев sequence точно не хватит.

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

А потом я расскажу о своём)

--
Поддержать канал

​​Привет!

Пока я тут собираю очередной интересный пост (анонс: про сценарии интеграции и подход, который я люблю использовать для их описания), на бусти вышел животрепещущий гайд: «Как попросить повышения ЗП, чтобы вам её точно повысили»?

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

P.S. по секрету, конец лета/ начало осени — лучшее время, чтобы успеть попросить повышения ЗП. Осенью обычно идут в активный найм, чтобы израсходовать бюджеты, выданные на год, и с повышениями может быть чуть сложнее.

Дерзайте и делитесь своими историями повышения ЗП ??!

​​Может ли архитектор «наложить вето» на бизнес-фичу? Часть 2.
(54 секунды)

Итак, порефлексирую вслух, может ли, на мой взгляд, архитектор накладывать вето на бизнес-фичу?

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

Приведу пример:

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

Является ли это бизнес-фичей или бизнес-требованиями? Нет, не является. Это решение.

И выходит, что мы говорим не о бизнес-фиче, а о необходимости использовать решение.

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

И в таком случае интеграция сервиса — была бы одним из вариантов рассматриваемых решений.

На такой вид «требований» (который по факту являются навязыванием решений) архитектор имеет права накладывать «вето». В том числе потому, что не может определить даст ли такое решение ту ценность, которая необходима заказчику, и оптимально ли оно вообще.

Что же касается действительно бизнес-фичей, то, на мой взгляд, архитектор имеет право задавать вопросы и высказывать сомнения, как собственно, и остальная команда (важно! в корректной и профессиональной форме).

Но задача архитектора предложить оптимальное решение для реализации бизнес-фичи, вне зависимости от его «мнения» на счет её ценности.

Или аргументированно доказать невозможность её реализации (что тоже вызовет множество вопросов к заложенной масштабируемости).

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

--
Поддержать канал

​​Система-витрина. Особенности работы бизнес-аналитика на проектах разработки систем этого класса. Часть 2.
(49 секунд)

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

И в общем-то, это довольно правильно, и абсолютно точно тянет за собой сильного системного аналитика на проект, но начинается все не с этого.

Сегодня я хотела бы выделить топ-3 вопроса, которые решаются практически на любом проекте с системой-витриной Бизнес-аналитиком (с системным бэкграундом). Движение без этих вопросов приведёт к значительным проблемам и сложностям.

Вопрос 1️⃣
Каковы бизнес-цели и бизнес-ценность системы-витрины для заинтересованных лиц?

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

Вопрос 2️⃣
Какие данные будут использоваться в витрине и какие преобразования данных потребуются, чтобы выполнить требования к системе-витрине?

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

Вопрос 3️⃣
Какие системы будут мастер-системами для витрины и какие процессы с данными заложены в этих системах?

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

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

Продолжите мой топ вопросов? Какие вопросы, на ваш взгляд, необходимо проработать, попадая на проект создания «системы-витрины»? ??

——
Поддержать канал

​​Система-витрина. Особенности работы бизнес-аналитика на проектах разработки систем этого класса. Часть 1.
(20 секунд)

Итак, сегодня поговорим про довольно интересный «класс» проектов, на которых разрабатываются системы-витрины.

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

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

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

Если вы знакомы с понятием витрина данных в архитектуре и знаете особенности этой формы хранилища данных, то наверняка поняли и особенности системы-витрины для бизнес-аналитика, т.к. термин на уровень «систем» вышел именно из архитектуры.

Давайте попробуем сначала вместе порассуждать. Сталкивались ли вы с такими системами на проектах? Как считаете, в чем особенность работы бизнес-аналитика на таких проектах? ??

—
Поддержать канал

Всем привет!

Коллеги, на февраль есть немного свободного времени, и я готова взять пару консультаций. Смогу взять только 2, к сожалению, поэтому не расстраивайтесь, если вдруг в этот раз не успеете записаться. Обязательно будет ещё возможность пообщаться лично позже.

Детали по консультациям в закреплённом сообщении и в директе @anastasiia255

Ценность функционала. Почему о ней важно говорить и писать в постановках на разработку?
(16 секунд)

Однажды я пришла на проект, на котором уже работала команда.

Постановки в разработку писались, передавались команде и разрабатывались. Но всех что-то волновало.

Для начала я изучила, что готовит команда анализа, поговорила с аналитиками, и у меня закрались подозрения о проблеме. Потом я поговорила с ребятами из команды разработки, и мои подозрения подтвердились.

Постановки отвечали на вопрос «что?», но не отвечали на один важный вопрос. Более того, на него команде разработки не могли ответить и аналитики, например, на груминг-сессиях.

Догадываетесь на какой?

«Зачем?»

Как думаете, должны ли постановки в разработку отвечать на этот вопрос? Почему всей команде важно или не важно понимать, зачем им тот или иной атрибут/функционал???

——
Поддержать канал

​​Фокусировка при описании фичи и её важность. Почему "растекаться мыслью" плохо?
(40 секунд)

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

В этой постановке было очень много текста и лишних слов. И это первое, что бросилось мне в глаза.

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

И это большая ошибка. В той постановке, которую мне отдали на ревью был полный набор последствий такого «писательства»:

1️⃣ Несостыковки по тексту из-за большого объёма.

2️⃣ Много информации, не относящейся непосредственно к функционалу в текущей постановке. Информация о смежных фичах, которая НИКАК не влияет на текущую, но даёт «объёма» и «массы» постановке.

3️⃣ Синонимичный ряд постоянно заставляет читателя вспоминать синонимы из прошлых абзацев и думать, а точно ли это одно и то же, что было уже раньше или нет (помните, что в идеале в начале каждого проекта должен появится словарь терминов? Вот он должен появиться не просто так. Лучше пусть ваша постановка выглядит «беднее», но будет однозначно интерпретирована).

4️⃣ Присутствие фраз: «не только, но и», «однако», «в случае описанном выше и в случае, описанном, в пункте 5» и т.д. сильно усложняет восприятие и больше путает, чем вносит ясности или удобства.

?Хорошая постановка НЕ равно большая!

Талант — это точно, структурированно, однозначно и просто объяснить в постановке, что необходимо реализовать, а не накатать книгу.

И помните: чем чётче описание, тем меньше текста, а значит больше вероятность, что постановку прочитают внимательно до конца.

Поделитесь своими мыслями. Что думаете на счёт реализации писательского таланта в постановках на разработку или при описании требований? Сталкивались с таким???

——
Поддержать канал

​​Я не могу сказать «нет» владельцу продукта. Он же владелец продукта, он главнее. (с) Часть 2.
(28 секунд)

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

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

Не можете сказать «нет» владельцу продукта? Значит не можете грамотно сказать «нет» ни одному стекхолдеру. Последствия? Плачевные. Стекхолдеры будут вас любит, а команда ненавидеть. Скоуп будет стремительно расти, а доходы от проекта стремительно подать. В общем-то, в какой-то момент с вами просто попрощаются.

Учитесь аргументированно и грамотно говорить «нет» и отстаивать свою позицию.

По-моему скромному мнению, такая иерархия между PO и BA на российском рынке возникла по нескольким причинам.

1️⃣ Перевод Product Owner на русский как Владелец продукта и интерпретация русскоговорящими людьми слова «владелец», как собственник, руководитель, а не как «человек, несущий ответственность».

2️⃣ На рынке «постсоветского» аутсорса (и не только, к сожалению), PO, как правило, это человек со стороны заказчика, а Заказчик — главнее.

? Умоляю, забудьте такие установки! Нет никого главнее, есть общая цель — сделать хороший продукт коллаборативным путем. Будем искать, кто главнее и мериться силой — закончим бурным расставанием и недовольством всех участников проекта.

3️⃣ Слабые BA, которые не хотят брать на себя ответственность и перекладывают его на «того, кто главнее», «того, кто скажет, как» и «того, кому нельзя сказать нет» (читай: поэтому я сделаю так, как он сказал, а когда в меня тыкнут, я скажу, что это он так сказал).

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

——
Поддержать канал