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

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

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

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

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

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

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

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

Все просто.

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

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

Что важно?

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

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

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

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

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

​​Привет!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

​​«Нам не нужен Team Lead». Что делать, если заказчик считает, что управлять командой не надо?
(120 секунд)

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

Спустя несколько недель моей работы, когда были написаны и внедрены регламенты, организована работа команды и все встало на стабильные рельсы, заказчик на общей встрече задал вопрос: «А почему Анастасия не пишет постановки в разработку, как остальные аналитики? Чем она занимается? Мы не собираемся платить за тим.лидство, нам оно не надо. Регламенты она уже написала, все понятно, теперь пусть работает, как остальные.»

Сначала стало грустно на мгновение, потом забавно, как незаметна работа Тим.Лидов, когда ты перестаешь выдавать артефакты, при том, что к КАЖДОМУ артефакту напрямую приложена твоя рука (но об этом же никто не знает:))

В общем-то в моем случае, все закончилось прекрасным менеджментом на стороне моей компании и моими хорошими отношениями с ними, когда менеджмент в ультимативной форме сказал, что считает, что таким количеством аналитиков необходимо управлять. И либо у нас есть тим.лид анализа, либо пусть управление ложится на плечи вашего PO. А PO у Заказчика — отдельная история.

Но я задумалась, как бы я аргументировала необходимость тимлидства команды анализа и value для заказчика от отдельной выделенной роли?

1️⃣ Сократилось кол-во итераций валидации и согласования требований с заказчиком за счет доп. валидации всех требований с моей стороны и вынос на заказчика уже финализированных артефактов (> тратится меньше временных и человеческих ресурсов экспертов со стороны заказчика (точно знаю, что для них это важно, т.к. это тоже деньги компании).

2️⃣ Для экспертов со стороны заказчика есть единая точка входа по всем вопросам: я. Не надо думать и искать, кому задать вопросы.

3️⃣ Для команды история такая же (сначала ко мне — потом на заказчика), в связи с чем сократилось кол-во вопросов, которые в целом выносятся на экспертов и заказчика.

4️⃣ Перестала теряться информация, т.к. появилась структура и внутренняя организация хранения всей информации, стали фиксироваться результаты встреч. Все знают, где и что искать. (> сократилось кол-во “переспрашиваний”, возвращений в уже обсужденные вопросы и т.д.).

5️⃣ Всегда есть точное понимание, кто и над чем работает, в каком состоянии работа и практически не возникают блокеры, т.к. тим лид всегда держит руку на пульсе и вовремя митигирует риски, чтобы экономить деньги заказчика, не допуская простоев и задержек.

Пожалуй, в моем конкретном случае, это ключевые преимущества тим.лида, как отдельной роли.

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

Т.е. роль и обязанности Team Lead сильно зависят от уровня коллег, которых предстоит лидить.

Кто для вас Team Lead команды анализа? Нужен ли он? Хотелось бы вам иметь на проекте человека, к которому всегда можно прийти за советом, который всегда поддержит и скорректирует до того, как вы вынесете результаты на оценку клиента? Или если он у вас уже есть, нравится ли вам его работа? ??

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

Всем привет!

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

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

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

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

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

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

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

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

«Зачем?»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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