Приветствие всем!

Выделим такую ошибку (#10), как “технические знания не моё, я всего лишь аналитик”. Но я уже рассуждал на эту тему, поэтому просто отошлю туда: https://shesterov.by/tpost/k90kjs6sa1-it-ba-eto-it
Добавлю только: если чувствуете, что это про вас, почитайте. Вы не сделаете себе хуже, внедрив IT-прокачку в свой план.

Всем привет!

Второй блин 😁 Будем рады критике и любым иным комментам. 🙏
https://youtu.be/4hU3CAkFJsQ?si=nag13XWVSIl-Awxn

Всем привет!

В компании ООО ИКомЧардж (Беларусь, Минск) открыта вакансия на позицию СА: https://rabota.by/vacancy/91269908?from=employer&hhtmFrom=employer

Выпускники ITMINE приветствуются 😉

Дополнительное описание от авторов:

Проекты не большие, но интересные. Например, сегодня надо интегрироваться с Российским банком, а завтра интегрироваться с платежной системой из Индии, Беларуси или Европы (на примере UPI, ЕРИП, PayPal и т.д.). От кандидата требуется: общее понимание работы HTTP методов, уметь читать API спецификацию (читаем API документ, понимаем какие запросы и в какой последовательности надо отправить, «пробиваем API» через Postman, curl и т.д.), умение описать флоу интеграции текстом и с помощью сиквенс диаграммы (в любом инструменте), в целом понимать как работает обмен запросами между системами. Если можете выполнить готовый html запрос (либо чуть подпилить и выполнить) в браузере (либо в другом инструменте) – приветствуется. Желательно – чуть-чуть уметь читать код (в API документации может быть указан небольшой отрывок кода для формирования сигнатуры. Но если вам сложно понять код, можно обратиться за помощью к разработчикам). Опыт как у БА у вас может быть минимальный (возможно только курсы), но техническая база описанная выше должна быть. Если требуется общение с англоязычными заказчиками – почти всегда переписка. B1 минимум. Работа очень интересная – каждый интеграционный проект уникальный и по времени обычно длится до 5-10 дней. Если есть неуверенность – не бойтесь. Рядом много технических специалистов, которые помогут. Всегда можно задать вопрос или попросить рассказать как «это» работает. Отводится время на онбординг (обучение лидом БА + материалы компании + можно задавать вопросы). Первое время – поддержка, далее втянитесь сами. Домен – фин. тех: процессинг платежей. Поддается осмыслению и погружению нормально.

- Когда вы общаетесь, используйте визуальные подкрепления. И неважно, общаетесь вы письменно или устно. Я вот, например, часто делаю вывод о том, что человек — классный коммуникатор (и кайфую от перспективы рабочего общения с ним), когда:
- Если к нему подходит разработчик с вопросом "Че-то я тут не понял, что написано в требованиях", берет его за шкирку и тащит к доске/флипчарту, чтобы маркером помогать доносить мысль.
- Общаясь с заказчиком на звонке, почти всегда шарит досочку в Miro или прочий инструмент как для фиксации того, о чем идет общение, так и для рисования схем в процессе, чтобы задействовать больше каналов.
- В письмах периодически, как и в спеке, что-то рисует: диаграммы, чтобы вместо или в дополнение к тексту ярче донести инфу; макеты, чтобы показать, как это будет выглядеть на UI.
- Вместо описательных отсылок к чему-то делает скриншоты и рисует на них стрелочки ("вот тут кнопка — на ней описка")
- Когда доносит мысль, показывает ее активным жестикулированием (но лучше в меру — чуть поменьше гангста-рэпперов): например, считая пункты, загибает пальцы. Ну а что, это тоже визуализация 😊

В общем, строго рекомендую как минимум просто попробовать. Вероятно, со временем у вас в большинстве коммуникаций также будет срабатывать условный рефлекс "Так, а что я буду показывать в процессе? Как это показать?" Где-то грустит один заказчик, когда аналитик на звонке начинает рассказывать сценарии юз кейсов голосом, читая их со спеки у себя под рукой, а потом, прочитав это минут за 10, спрашивает "Все ли хорошо, есть ли комменты?" Не меньше грустит и разработчик, когда открывает спеку аналитика, окидывает взглядом 50 страниц сплошного текста и понимает, что в ближайшие дни секс его мозгу обеспечен.

Заметка о 4-х ключевых вопросах аналитика перед стартом работ: https://www.artofba.com/post/how-to-take-task-into-work-part2-four-key-questions
Рабочие и жизненные примеры, плюс в целом интересно читается.

Очередной очерк от любимого дядюшки: https://medium.com/analysts-corner/when-use-cases-arent-enough-bb2094f5b01d

От себя: редко встречал использование именно таких таблиц на практике. Зато когда-то на собеседовании мне задали вопрос из этой области: как бы ты описал требования к такому вот проекту (несколько систем между собой активно взаимодействуют, при этом для конечного юзера либо нет операций, либо их одна-две полезных). Я перебрал все, что знаю (разные диаграммы, алгоритмы текстом и пр.). Собеседующий удивился и сказал, что самое элементарное и подходящее я не назвал — юз кейсы (ведь там же есть сценарии, так?). Я начал активно доказывать, что юз кейсы — не для таких ситуаций, и на минут 20 мы ушли в дискуссию. Зато по итогу человек сказал, что редко встречает ситуацию, когда его переубеждают, и был весьма доволен. Может, и вам пригодится 😊

О разнице между верификацией и валидацией ☝️ Огненной недели :)
https://www.youtube.com/watch?v=GJao4qnLHIE

Приветствие!

Продолжим цикл ошибок, и сегодня — не всегда критичное, но часто раздражающее явление: общение с ЗЛ языком требований решению (#12).
Сразу очертим, когда эта претензия не применима: когда аналитик извлекает требования к решению из ЗЛ, и это контекстно-уместно (“Давай заказчик, толкай мне, что за система нужна и как она должна работать“). Например, у вас что-то наподобие аутстаффинга, и свои аналитики есть на стороне клиента. Эти аналитики обеспечивают вашу команду спекой, пусть даже и не очень качественной, а вы, скорее, переводчик с иностранного для команды. Или же, например, когда заказчик сам уже обладает по какой-то причине спекой в голове и стремится всунуть вам ее в ухо: дает детальное описание того, что он хочет, языком решения; активно интересуется деталями реализации.
Но если (что гораздо чаще встречается) заказчик — бизнес-стейкхолдер и ждёт от вас полную качественную реализацию IT-услуги с минимумом своего вовлечения, то проблема выше — не ок, и ситуацию надо менять.

Пример, который я периодически я привожу на тренингах: представьте, что вы пошли постричься. А заодно представьте, что вы не эксперт в домене стрижки и вообще делаете это у данного мастера впервые. И вот вас спрашивают (требования извлекают, ага…): Вас машинкой с какой насадкой стричь? Сколько сантиметров оставить на висках? Под каким углом прикладывать ножницы к волосне? Если пример не близок, то представьте, что вы отдали машину в СТО, и там посыпались такого же плана вопросы.
Мотивация мастера понятна — человек хочет, чтобы вы спеку написали, а он её бездумно выполнил. Но только вот я лично от подобных вопросов чувствую себя глупым и мне некомфортно от того, что я не могу дать уверенный ответ. К чему это приведёт: хоть глупо и мне, но к этому мастеру я вряд ли приду снова, если будут альтернативы (просто потому, что мне было некомфортно).

А что он мог бы сделать? Как реализовать мои потребности — это требования к решению, его зона ответственности. Если у него есть переживания за них, он может у меня их зааппрувить (но моим языком). Но не извлекать из меня прямыми вопросами! А вот что ему действительно надо сделать, так это понять, что мне от него нужно (требования ЗЛ): “Расскажите, какую стрижку хотите; покажите на фотке; а вот наши фотки, кстати — тыкните пальцем, что нравится”. Его задача — активно помочь мне без своего проф. жаргона выдать мои хотелки.

Чем иногда аналитики жгут в этом плане:
- Э, пиу, заказчик! Смари, какой я словарь данных нафигачил. Проверь плз! (1)
- Какие эндпойнты апишки будем дергать? Мне нужна информация. (2)
- Какие есть ограничения дизайна/требования к операционной среде/атрибуты качества/…? (3)

Что объединяет все эти примеры? Попытка извлечь (прямыми вопросами или через “проверь мой черновик”) требования к решению. Эти требования описывают решение, а потому они часто формулируются языком домена решения (”классические” критерии приемки в US, кстати, избавлены от этой проблемы, именно поэтому есть рекомендации по языку их формулировки). И весьма велика вероятность, что бизнес-кастомеры не знают, как ответить на такое, и плачут. Просто представьте, что вы — не БА и не айтишник и вы обратились к ИТ-аутсорсингу: сайт мне для бизнеса запилите. Вы серьёзно ответите на такие вопросы от аналитика на той стороне?

А что же тогда делать (не считая исключений, описанных в начале)?

1) Примите за отправной факт, что ключевой источник требований к решению — вы. Стейкхолдеры — источники требований ЗЛ. Именно вы проектируете решение с позиции требований, основываясь на требованиях ЗЛ и бизнес-требованиях.

2) Очевидный вывод из предыдущего: извлекайте из ЗЛ именно требования ЗЛ (тут сделаю трассировку на видео, которое недавно постил: https://www.youtube.com/watch?v=4hU3CAkFJsQ). Осмыслите пример со стрижкой выше. Вам надо понять, каковы потребности у ЗЛ и что им нужно от решения (как они с ним хотели бы взаимодействовать и каким видеть), а не то, как решение должно себя вести — в этом, вероятно не очень ярком акценте, вся суть описанной ситуации.

3) Если вам все-таки нужно требования к решению обсудить с ЗЛ не на стороне вашей команды (например, чтобы зааппрувить подход, выбрать подход из альтернатив, зааппрувить весь набор требований, чтобы получить sign off на них), подумайте, как это сделать так, чтобы ЗЛ все это поняли и не чувствовали себя идиотами.

Для примеров выше:

(1) А вам вот точно нужно получить от заказчика подтверждение требований к данным? Уверены? А зачем? Ему точно не все равно, какая у вас там модель и словарь данных? Может, одобрение надо получить на критерии приемки сторей, содержимое юз кейсов, макеты интерфейса, а требования к данным — это то, что под капотом обеспечивает функциональные поведенческие требования?

(2) Может, использование API — это то, как реализовать потребности стейкхолдеров, а не что им нужно? Точно стейкхолдеру нужно, чтобы вы использовали метод GetGeoData? Или ему все-таки нужно, чтобы на сайте на карте точкой была отображена локация? Обсудите с ним именно этот момент (что именно в плане отображения нужно), а API и методы выберите сами вместе с командой.

3) Да, упомянутая информация важна, но прямые вопросы из разряда “Какие у тебя есть требования к решению” не прокатят. “Смотри, заказчик, сегодня мы обсуждаем требования к операционной среде. Давай я поясню, что это такое: … Соответственно, давай подумаем, какие браузеры будем поддерживать? Предлагаю исходить из того, какие браузеры у нашей целевой аудитории. URL — это ссылка, по которой юзеры будут открывать систему. Есть предпочтения? Хостинг давай обсудим — есть вариант внешнего, есть еще вот такие варианты. Девайсы давай обсудим — пытаемся сделать красивенько на смартфонах?” И т. п.

4) И тут же надо затронуть такой момент, как высылка 100-страничной спеки голубем заказчику с посылом “Читай и подписывай!”. Да, такое часто нужно делать. Но как это сделать так, чтобы его этой спекой не придавило? Обдумайте такие варианты:
а) Обучить заказчика или иных ответственных ЗЛ тому, как это делать: поясните необходимость этого, методику изучения документа, порядок изучения (на что обратить внимание в первую очередь, какие детали можно просканировать, а в какие нужно аккуратно вчитаться).
б) Помогите ЗЛ: устройте ряд встреч по обсуждению спеки, где вы презентуете ключевые вещи и живым языком изложите содержимое.
в) Замените детальные около-технические артефакты на более живую выжимку (да, вы при этом берете риск самостоятельной проработки более мелочных требований). Например, оставьте раздел спеки c требованиями к UI- элементам за рамками изучения заказчиком и попросите изучить только UI-макеты, причем, допустим, в виде динамического кликабельного прототипа.
г) Склонитесь к более простым подходам к хранению требований (например, User Stories) или к активному разбавлению спеки визуальным контентом, который обычно легче воспринимается.

А вот такое объявление от нас (вдруг тут есть желающие или желающие у уже прошедших обучение 😊)

Мы проводим сейчас набор на курс. Группу планируем стартовать с 11 марта. Тренер — Герман Шестеров. В группе есть места, плюс мы приятно обновили условия и формат (см. ниже):

📌 ~55 часов тренингов (мы увеличили количество и часов, и занятий), ориентированных на практику, разбор теоретического материала и разбор заданий.

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

📌 100-200 часов внеаудиторной самостоятельной работы (часть которой — с проверкой тренером и разбором результатов)

📌 ~4 мес. основного курса + 2 мес. на дополнительный практический проект (в случае участия в нем). Формат: по будним дням, вечером, 1 или 2 дня в неделю, с 19 до 22, с периодическими свободными неделями для самостоятельной работы

Стоимость обучения – 799$ без участия в дополнительном проекте (цена снижена с 950$) + 299$ за дополнительный проект (он оплачивается отдельно, после прохождения основного курса). Оплата – в BYN, по курсу НБРБ на момент оплаты.

Узнать больше о курсе, а также оставить заявку на обучение можно на сайте. Вы также можете просто написать нам: @itmineby, info@itmine.by или позвонить по телефону +375 29 340-80-90.

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

Что такое требования к данным? Это то, как аналитик видит информацию, которой система должна оперировать. Мы же информационные системы аналитим, агась? В общем, это подвид требований к решению, и многие теоретики относят это к функциональным требованиям (в дополнение к поведению системы).

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

Что имеется в виду под “сторонами”? Смотрите, вот вы начали с того, что кажется вам простейшим и логичным: описали поведение системы (хочу, чтобы система делала сюда, а туда не делала). Нужно ли что-то ещё? В совсем бедных системах — вероятно, нет. Но дальше вы можете подумать: а что, если подать описанное в виде юз кейсов? О, прикольно, повылезало гораздо больше исключительных сценариев, о которых сразу не подумали. А что, если ещё и макеты нарисовать? Ого, а тут вот UX-косяки стали явными. Ну то есть в этом контексте мы фактически одни и те же требования (поведение системы) показали с разных “сторон” — вначале тупо описали текстом то, что система должна делать, потом — объединили это в логические наборы шагов под грифом операций пользователей в системе, потом — показали, как это может быть или точно будет выглядеть на UI для пользователей. И тут несколько плюшек, которые вы получите от этого:

1) В процессе проработки всех этих артефактов вы что-то новое для себя вынесете: упущения в требованиях, внутренние противоречия и прочие недоработки.

2) Обсуждая такие штуки с ЗЛ, вы и им покажете будущую систему с иных углов, а потому — выявите гораздо больше полезной информации. Одно дело, когда вы кинете сторю заказчику с посылом “Читай пункт за пунктом, как система должна себя вести”, и совсем другое — когда вы объясните сценарий использования, плюс визуально покажете UI для него. Ровно аналогично и для команды разработки: им проще будет понять задачу и разработать ее без ошибок, если они и юз кейс прочитают, и на UI посмотрят.

Это еще не все 🙂 У информационных систем есть множество иных аспектов, о которых стоит как минимум подумать, а как максимум — проработать в плане требований: параметры качества (производительность, доступность, удобство и пр.), операционная среда (браузеры, хостинг, экраны, железо, температура и пр.), внешние системы, с которыми нужно сотрудничать и т. п. Кстати, а часто такие вещи фигурируют в ваших user stories или где-то рядом с ними? 🙂

И вот мы подошли к сабжу: а что, если попытаться посмотреть на систему не с угла поведения, а с угла того, какая информация стоит в центре системы и как она движется в процессе своей жизни по системе или где-то около нее? И тут на сцену выходит еще одна “сторона” — данные системы.

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

Если по шагам, то что стоит делать… и не жадничать в плане эффортов на это… и да, даже в agile, когда вы сторьки пишете:

1. Когда вы прорабатываете функциональные поведенческие требования, стройте в параллели модель данных (пусть будет называться Logical Data Model, хоть есть и разные взгляды на то, как это назвать). Например, это можно сделать с помощью UML Class Diagram, но есть и иные нотации. Если не знакомы с этой штукой, ссылка выше вам в помощь.

1.1. Делая это, вы как минимум глубже поймете и систематизируете для себя суть того решения, которое вы колбасите. Плюс это отличный повод проработать вопросы, которые модель “ставит” в процессе построения. А они могут быть такими:

- Как данные в системе появятся? Продумано ли это? Какие операции с ними необходимо иметь возможность осуществлять (мы уже упоминали CRUDL в одной из предыдущих заметок, а вот тут можно почитать про это детальнее). Мощняцкая штука!
- Как связаны данные А с данными Б? Связи могут сильно повлияют на поведенческие требования. Например, есть Категории товаров и есть Товары. Если для них актуальна связь вхождения одного во второе, причем композиционная, то при удалении категорий надо продумать каскадное удаление входящих в них товаров.
- В какой множественности связаны данные А с данными Б? Это великолепный источник бизнес-правил и требований, о которых вы практически точно не подумали бы ранее. А сколько в Категории может быть Товаров? А вот три и не больше — такое у нас внутреннее ограничение в компании.

Это яркие примеры. На самом деле надо просто попробовать такое сделать и увидеть, какие инсайты вызовет построение такой модельки.

2. В параллели с этим же, либо чуть позже (но не стоит, конечно, ждать конца проработки поведения системы) сделайте словарь данных: описание атрибутов каждого класса данных из модели. Сослаться на классную обучалку я тут не могу, ибо пока не написали, но если вкратце, то это означает, что Товар имеет Название и Цену. И вам нужно эти параметры обдумать и зафиксировать, а именно: как они называются, обязательны ли они для класса данных, какого они типа и прочие детали, которые описывают как формат, так и процесс получения этой информации.

2.1. По аналогии с первым пунктом: прорабатывайте вопросы, которые в процессе появляются. Например, из типовых:

- Цена для товара обязательна? Может ли на каком-либо из этапов Товар быть пока еще без Цены? А если обязательна, то как мне это предусмотреть на UI во всех формах создания/редактирования Товара?
- Цена — это какой тип данных? Это число, но какое? В какой валюте? Дробные цены могут быть? Сколько знаков в дробной части? Максимальная цена — она есть и какая? Минимальная (0, например, у товара может быть)? Все это порождается бизнес-правилами или “хотелками” ЗЛ? Обсуждая эти вопросы со стейкхолдерами вы можете многое узнать о домене и его отражении в решении. Плюс, естественно, это все даст вам понять, как UI построить в плане внесения или изменения Цены (проверки формата, предотвращение некорректного ввода, подсказки и прочие аспекты UI).
- Если ваши данные импортируются из других программных систем или должны экспортироваться туда, то описанное становится еще более актуальным: вам в любом случае нужно будет продумать, как и откуда получать данные, какие могут быть при этом ошибки и как на них системе реагировать, как синхронизировать форматы данных в вашем решении и источнике/получателе.

3. Понимая картину данных, вы можете взглянуть (еще одна “сторона”) на перемещение (потоки) данных в системе. Для этого есть такой инструмент, как Data Flow Diagrams. Не скажу, что лично мне они сильно помогали (как-то не особо много полезных инсайтов я получал в процессе построения — все они закрывались уже на этапе модели и словаря), но, возможно, вам нанесут пользу. Кстати, контекстная диаграмма (с которой, подозреваю, почти все знакомы) — это часть DFD. И вот контекстная диаграмма на этапе проработки скоупа решения — это прямо огонь-огненный.

4. Если так получается, что какая-то сущность данных у вас имеет “сложную жизнь”, т. е. активно меняет состояния в процессе жизни (например, Товар может быть в режиме черновика, потом — одобрен, забронирован, доставлен, заархивирован), то дабы эту жизнь понять и по аналогии с описанным выше найти пробелы, о которых вы ранее и не думали, на помощь спешит UML State Machine Diagram. Также клевая штука, когда есть необходимость посмотреть на жизненный цикл класса данных и уложить его в голове/обсудить со стейкхолдерами.

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

Вот тут можно освежить в памяти, что такое рефайнмент в agile — просто и по существу: https://medium.com/@eiki1212/5-activities-of-product-backlog-refinement-a96671070ce0

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

В чем суть:

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

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

1. Актер вставляет банковскую карту в банкомат.
2. Система предлагает актеру ввести ПИН-код карты.
3. Актер вводит ПИН-код и подтверждает ввод.
4. Система отображает список доступных операций с банковской картой.
5. Актер инициирует операцию снятия наличных средств.
6. Система предлагает актеру указать сумму для снятия средств.
7. Актер выбирает интересующий его вариант суммы из отображенных на экране.
8. Система отправляет запрос вторичному актеру на вычет запрошенной суммы из баланса актера на счету, привязанном к текущей карте.
9. Система получает подтверждение о вычете суммы со счета актера от вторичного актера.
10 Система выдает в слот для наличных средств запрошенную актером сумму.
11. Система печатает чек, отражающий детали выполненной операции по снятию наличных средств.

Собственно, простейшая ошибка, которую вы можете совершить касательно поведения системы, — это не подумать о том, что может пойти не так.
Как не сделать ошибку? А довольно просто: возьмите каждый шаг базового сценария (если вы, конечно, не в форме эссе это описывали, а систематизировали, как выше, плюс атомаризировали шаги). И спросите свое критическое мышление: а что в шаге может пойти не так, как заложено сценарием? Желательно пока что ограничиться действиями актёра в системе и событиями системы (включая ее внешние зависимости), а не рандомными факторами окружающей среды (например, актер палец сломал о клавишу банкомата или банкомат провалился под землю из-за внезапно начавшегося землетрясения). Да, там тоже могут лежать требования разного вида, но это уже более продвинутый вариант.

3: Человек может ввести код неверно? А может он не цифровую клавишу нажать, а что-нибудь типа Enter случайно?
8, 9: Бабосиков на счету может не хватить? Сервис проверки этого факта может не быть доступен (ну вот сломался и лежит)? Сетка, по которой надо запросы на проверку отправить, может отвалиться?
10. Налички может не хватить?
11. Бумаги может не оказаться? А краски?
Человек на любом шаге до завершения операции может захотеть отменить ее?

После того, как вы поднатужились и крепко подумали, далее нужно:
а) Решить, будете ли вы что-то с каждым ответвлением делать или же забьете на это. Второй вариант, конечно, так себе, но бывают вопросы бюджетов, сроков, приоритетов и пр.
б) Если таки нужно сие учесть, то решить, как: предотвратить внештатную ситуацию ИЛИ обработать ее по факту наступления. Тут есть общее rule of thumb: предотвращение ошибки лучше уведомления о ней по факту совершения. Но опять-таки иногда в игру вступают бюджеты, сроки, ограничения технологий и пр. факторы.

в) Описать желаемое поведение системы в требованиях (текст, диаграммы, макеты).

Погнали проектировать банкомат мечты:

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

8, 9: Проблему со средствами на счету мы не предотвратим (мы не знаем заранее, какую сумму человек хочет снять). Единственное (в виде брейнсторма): мы можем проактивно проверить баланс сразу после выбора операции снятия (желательно в фоне, дабы не подвисал сам сценарий операции), и если у актера там 0, то можем вывести уведомление об этом в уголке. Именно уведомление, а не непробиваемую стену перед выбором суммы — актер ведь может в фоне через телефон закинуть деньги на счет, увидев такое. Это просто пример рассуждений, чтобы было понятно, какие вещи стоит осмыслить.

Доступность банковского сервиса: предотвратить проблему в контексте банкомата мы не можем, но можем, например, сделать так, чтобы банкомат периодически пинговал сервис, и повесить уведомление о его недоступности или недоступности сети на UI до старта операции. Обидно ведь, да, если человек прошел все шаги, а в конце ему система такая: “Сорян, ты все это зря делал, у нас тут нетворк коннективити проблем”. Плюс, естественно, проверка системой этого в конце, после подтверждения суммы, и юзер-френдли уведомление об этом, если коннект не случился в ключевом моменте.

10: Можем предотвратить беду с нехваткой налички? Да, но опять-таки в контексте не самой налички, а сценария использования. И снова мы можем повесить уведомляшку об этом на UI прямо на старте использования банкомата (бабла нет, не подходи ко мне!), плюс не дать начать сценарий снятия денежек.

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

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

Ну и представьте, что в продакшн пошла система без учета всего описанного 🙈 Аналитик, девелопер, тестировщик — все дружно отключили мозг, попивая смузи. И вот только не надо тут про аджайл (запилим черновик системы, а потом допилим на основе фидбека) — таким черновым банкоматом кто-то будет пользоваться, ругая при этом мам разработчиков (что нередко нынче встречается, в эпоху MVP). Проработка упомянутого — не rocket science, а элементарное ожидание от команды и аналитика в первую очередь.

Продолжаем подсвечивать типовые ошибки, и на этот раз у нас неверное понимание сути бизнес-правил и, как следствие, неправильный (читай, бесполезный) процесс работы с ними (#15).

Многие (реально многие) думают, что бизнес-правила — это какие-то чуть-чуть особенные требования (которые, например, касаются бизнеса чуть больше, чем прочие требования — вообще вариантов трактовки “по наитию” я встречал вагон и тележку) : нужно, чтобы вот тут, в хедере, было лого компании. Ну типа как это о компании, о бизнесе.

Что такое на самом деле бизнес-правила (буду в заметке использовать БП, хоть вне ее это и легко спутать с бизнес-процессом)? Умных определений много, но давайте сформулируем по-простому: это какое-то принятое “правило” из окружающего решение контекста. Заметьте, это не требование (TO BE относительно решения), а информация из контекста (AS IS или TO BE для домена, государства, мира, галактики и пр.). Кто-то может поспорить, являются ли по науке “правила” за пределами бизнеса (локального домена) частью этого понятия, но я рекомендую их таковыми считать — и далее вы увидите, почему.

Ещё раз, БП — не требования (т. е. формулировки того, что нужно от решения ЗЛ, или каким решение должно быть). БП — это, грубо говоря, источники требований (как и стейкхолдеры, внешние системы, документация и пр.). Например, требование “На UI сайта должен присутствовать логотип компании” может в качестве источника иметь пожелание стейкхолдера (спонсор так хочет), а может — БП (согласно брендбуку компании все ПО компании должно иметь ее логотип на UI). Обратите внимание на формулировку: раз это не требование, то и формулировка не относится к нашему целевому решению — она относится к бизнесу, отрасли, государству и т. п.

Отсюда вытекает ключевое свойство БП: они существуют вне решения, безотносительно него. Будет решение / не будет — на актуальность БП это слабо влияет (есть более тонкие случаи, но оставим это за рамками текущего формата).

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

Итак, есть требования, рождённые воспаленным мозгом ЗЛ, а есть БП с разной степенью изменчивости. Требования, которые от ЗЛ, — это “хотелки”. Их сделал раз — и дальше спи спокойно, пока ЗЛ не прибежит с новой хотелкой. БП же может естественным образом меняться (например, ставка рефинансирования в стране X) или относительно никогда не меняться (формула расчёта скорости в физике).

Соответственно, а что это все нам дает в практическом плане:

Если вы а) зафиксируете БП в отдельном месте, собранные воедино, б) пометите для них важные для вас вещи (например, область деятельности — компания, отрасль, государство и пр.; изменчивость — ежегодная, не меняющееся и т. п ), в) в явном виде дополнительно сформулируете в нужном месте требования к решению, порождаемые этим БП, и сделаете трассировку одного на другое, то, во-первых, вы жжете, возьмите с полки пирожок, а во-вторых — вы резко улучшили процесс управления требованиями:

1) Поддержку требований в актуальном состоянии. Вы не просто запилили то, что сказали, а пометили себе или иным ЗЛ периодически чекать актуальность правила и менять решение, когда нужно (например, по мере выхода новых гос. постановлений и иных изменений контекста). Смотрите на разницу: а) Заказчик, какая тут ставка налога? Глаголи, а мы запилим. б) Это относится к БП, а потому мы собрали это в одном месте под грифом “Государственные постановления”, чтобы ты, заказчик, со своей стороны мог всегда отследить, какие постановления имеют отражение в нашем решении, и уведомить нас, если выйдут новые или отменят старые.

2) Change management. Прибегает заказчик и говорит, что вот тут, мол, логотип надо поменять. И вы, такие, а) Сэр йес сэр, поменяем! б) Ээ, стоп, это брендбук компании? Точно ему можно противоречить? А он ещё актуален? Если нет, то вот тут и тут тоже, может, стоит поменять, плюс впредь иметь полную свободу действий в оформлении UI?

3) Реюзабилити информации. БП кросс-проектны в масштабах отделов/компаний, а иногда даже — в контексте рынков (например, формат currency в US — такой; GDPR в ЕС регулирует такие вот вещи). И если держать их отдельно и применять на разных проектах в масштабе компании-заказчик или еще шире, это может всем облегчить работу и сделать её тупо качественнее — вы больше заметите, учтете, предусмотрите сходу, без лишних поисков информации и пыток стейкхолдеров.

Несомненно можно найти и прочие бенефиты описанного выше (хотя бы даже то, что вы один раз уяснили налоговую ставку, поняли, что это распространяется на все требования в контексте решения и не будете, как попугаи, повторять “Заказчик, а на этой странице как посчитать? А на этой? На этой? -> Вы че, дебилы, я вам пять раз уже пояснял!”). Что можно порекомендовать в плане работы? В целом, это прослеживается выше, но дополнительно:

БП не извлекаются прямым вопросом “Какие у вас БП?”. В сферическом проекте в вакууме вам могут сказать “Вот наш документ с БП”, ибо ведение каталога БП организации рекомендуется умными теориями бизнес-менеджмента. Однако чуть чаще, чем никогда, вам придётся самим их подмечать. Пример:
Вот тут нужно, чтобы человек мог положить товар в корзину, и не больше четырех! -> Так, стоп, почему не больше четырех? -> Ну у нас так принято. ->Это какое-то правило в компании? Почему оно так? Ну ок, пометим себе. И тут вы поняли, что это не просто пожелание Васи-стейкхолдера, а принятая в компании политика. Вы проницательно подметили, что в компании есть БП (БП-01: Покупатель не имеет права приобрести более 4-х товаров в рамках одного заказа), поместили это в каталог БП (отдельный раздел в вашей спеке или страничка в Confluence), оттрассировали требования в нужном месте на это БП (например, критерий приемки в истории: "При попытке добавления пятого товара в корзину я вижу уведомление о том, что не могу иметь более четырех товаров в одном заказе (см. БП-01)") — собственно, все, база для пожинания плодов классной организации информации построена.

Поговорим о книгах 😊 Может, кому-то пригодится:  https://www.thebagirl.com/business-analyst-books/

Кстати, а у кого какие книжки прямо вот серьёзно повлияли на проф. развитие? Огонь, если поделитесь 🙏

У меня лично либо таких книг было немного, либо это было уже так давно, что импакт позабыт. На тему бизнес-анализа это, очевидно, Вигерс — все, что было после него на тему работы с требованиями, казалось уже сильно вторичным. Плюс GTD Дэвида Аллена и Джедайские техники Максима Дорофеева — эти книги сильно помогли разгребаться в условиях потока дел, плюс как аналитику дали повод еще что-то упорядочить 😊