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

Мы проводим сейчас набор на курс. Группу планируем стартовать с 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 Дэвида Аллена и Джедайские техники Максима Дорофеева — эти книги сильно помогли разгребаться в условиях потока дел, плюс как аналитику дали повод еще что-то упорядочить 😊

Сегодня довольно простая проблема на повестке дня, и наверняка вы ее прекрасно знаете и избегаете, но полноты ради не могу не очертить — нечеткие action items (посылы к действию) (#16).

Заканчивается митинг, и участники с повышенным чувством собственной важности готовы разбежаться по комнатам, ведь, как известно, чтобы проблему решить, надо собраться и усердно о ней поговорить. И один только душный аналитик заводит свою душную шарманку: Так, стоп, делать-то что будем по итогу встречи? Кто и когда это будет делать?

Это весьма нередкое явление в практике. Проблема уже описана: отсутствие посыла к действию там, где он уместен, или нечеткий посыл к действию.

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

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

- (В контексте получения информации) Я тут не понимаю, мне сложно. В голове уже какой-то хаос.
- (В беседе с разработчиком или менеджером) У меня проблема, я не знаю как решить.
- (В общении с заказчиком):
- Мы просуммировали пункты, которые обсудили на звонке: а)..., б)…, в)…
- Вот предлагаемые нами варианты решений: а)…, б)…, в)…
- (В беседе с коллегой-аналитиком) Вот мой документ. Написаль!
- (И снова в беседе с менеджером) Я вчера написал документ...

Основная проблема с отсутствием ожидаемого действия от собеседника — это трата времени. Иногда собеседник угадает, что вам нужно. Иногда — не угадает или не захочет гадать, потому вы перекладываете эффорты по прояснению коммуникации на него. Мы даже как-то с коллегами договорились, что человеку можно не отвечать, если он не сформулировал явно, что он хочет. В итоге в подкорку въелось, что даже если action item очевиден, он все равно нужен в явном виде. Аналитик на то и аналитик, что делает неявные вещи явными во имя чистоты коммуникаций.

- Я тут не понимаю, мне сложно. В голове уже какой-то хаос. Не мог бы ты помочь его прояснить, ответив на следующие вопросы? (то есть не “я в домике, я ничего не понимаю и отказываюсь даже думать о том, где именно непонятно”, а “я провел анализ, дистиллировал непонятные моменты и облек их в вопросы”)
- У меня проблема, я не знаю как решить. Вот эту часть раскопал, а тут у меня затык. Поделись идеями, если они у тебя есть, как мне двигаться дальше.
- Мы просуммировали пункты, которые обсудили на звонке. Изучите их, пожалуйста, и прокомментируйте те, с которым не согласны или где есть поправки.
- Вот мой документ. Изучи его, пожалуйста, на предмет полноты, правописания, плюс за любые иные комментарии буду очень признателен!
- Я вчера написал документ. И да, не всегда обязательна, но часто полезна и создаст о вас крутое впечатление такого рода приписка. Это FYI, чтобы держать в курсе касательно моей занятости. Доступен для новых задач.

Посыл тут не сложен. Суть всего-лишь в том, чтобы это делать. Кстати, в письменной коммуникации нас ещё учили выделять (например, болдом) посылы к действию, чтобы сразу было ясно по сканированию, че тебе надо от получателя. Please, provide you answers/feedback. Please, confirm/approve.

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

Вот идёт ретроспектива:

Коллеги, у нас в спринте был косяк — багов наклепали по самые уши. Что будем делать? - > А давайте внедрим код ревью! - > А давайте!

К чему может привести завершение обсуждения на подобной ноте? К тому, что на следующей ретроспективе встанет вопрос: Кто делал код ревью? Епт, ну что вы за люди, ну почему никто не делал?

И тут все просто. Не прозвучало, что такое внедрять, кому внедрять и когда внедрять. Я и сам до сих пор нередко попадаю в эту ловушку. Легко собраться и нагенерить в воздух варианты решений для сложной проблемы, а потом уйти с осознанием “Ну, я сделал все, что мог”. И да, иногда, когда кто-то на встрече говорит "Стоп, решаем, какие конкретно шаги кто делает и когда”, порой хочется его стукнуть (ибо думать, кому чем конкретно заниматься и тем более к какому сроку — больнее). Но, как вы понимаете, надо. Было у вас такое: Ребята, давайте соберёмся ->Давайте! Спустя месяц. Блин, так и не собрались :( Давайте поактивнее, поактивнее. Да, это бытовой пример, и тут нет манагера, который назначит ответственных и поставит срок либо получит оценку на него, но суть проблемы все равно видна. Если вы (или человек, выполняющий роль менеджера в контексте) не решили и не проговорили, кто, конкретно что и к какому сроку будет делать (или же когда будет очередная точка среза, в которой анализируем прогресс и либо оставляем как есть, либо что-то корректируем), это вполне себе может уйти в небытие.

В беседах с заказчиком и им подобными аналогичное актуально, только с поправкой на то, что это внешние для вас стейкхолдеры (ну то бишь, естественно, аккуратнее с постановкой им задач и прочим командно-приказным оттенком). Если вы в процессе беседы выработали экшн айтемы с любой стороны, суммаризируйте обязательно их в конце и/или в минутах встречи: Дальнейшие действия: Вася-БА доработает документ и пришлёт на изучение в течение недели; Пётр-заказчик не позднее среды уточнит и пришлёт параметры доступа к системе, чтобы аналитики могли туда зайти и поковыряться.

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

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

How to deal with a spicy client — не помешало бы раскрытие деталей и конкретные практические советы по каждому пункту, но если вы уже бывали в подобных ситуациях, то описанное отзовется.

Waterfall to Agile: A Necessary Mindset Shift For Business Analysts — будет полезным как для тех, кто не работал в контексте agile, так и для погруженных в ту самую его вариацию, в которой этот mindset пока еще не внедрен (agile — это концепция работы для команды, а не набор процессных практик, чего, к сожалению, не понимают многие agile-команды). Тут снова не хватает практических деталей и примеров (это вообще постоянная боль иноязычных “статей” 🙂), но тем не менее может быть полезным освежить представление.

Steal these guidelines for your next meeting — классные посылы для фасилитирования встреч с некоторыми интересными идеями.

What Apple’s Vision Pro Tells Us about User Stories — просто интересное чтиво об известном кейсе.

Салют!

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

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

Поехали с примерами:

1) Вы извлекаете требования из заказчика, и в письме вы сформулировали следующее:

Джон, доброго дня! Я бы хотел уточнить, сколько в вашем отделе сотрудников? Спасибо заранее за ответ — живи долго и процветай!

Какой могла бы быть моя реакция, будучи я заказчиком: Блин, а нафига им это? Может, они шпионы? Чего они сюда лезут?

Соответственно, ответ вполне себе может быть таким: Добрый день, Василий. Хотелось бы уточнить, а как это связано с запросом на разработку?

Что произошло: аналитик сформулировал вопрос, который вне контекста может вызвать недоумение. Переписка затянулась, эмоций добавилось. Значит ли это, что такие вопросы задавать нельзя? Нет, конечно, у вас вполне может быть обоснованная мотивация. Только вы не подали контекст в качестве обертки вопроса.

Сравните с таким вариантом:

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

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

2) Вы пишете ПМу (или поставьте сюда любого иного человека и любую иную тематику): Коля, привет! Вот моя спека!

Тут проблема перекликается с предыдущей заметкой (экшн айтемы), но акцентируем внимание именно на контексте. Дополним это тем, что нагруженный по самые помидоры ПМ общался с вами по этой теме неделю назад. И вот он судорожно листает окна, будучи высокопродуктивным ПМом, и видит такое от вас. И в голове мысли: какая б... спека? Че он хочет? И с плохо скрываемым раздражением пишет ответ: Ты о чем вообще?

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

Что надо делать:

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

Привет! Когда будут материалы? VS
Привет! Ты не сказал на созвоне, когда выложишь материалы. У меня как раз есть время их изучить, и было бы круто получить ориентир на то, когда ты сможешь их выложить, чтобы я уже мог активно над ними корпеть.

Привет, твои коммуникационные скиллы — чухня! VS
Привет! Я бы хотел поделиться фидбэком! Ты как-то писал, что открыт к и поощряешь критику, поэтому я тут подумал, что дать тебе честную обратную связь — это как раз то, что окажется полезным, поэтому прошу воспринимать это как желание помочь …

А сейчас я расскажу про бизнес-правила! VS
Итак, смотрите, мы только что поговорили о требованиях и том, какими они бывают. Теперь давайте перейдем к информации по БА, которая лежит рядом с требованиями и может на них влиять. Один из основных примеров тут — бизнес-правила… Слушали когда-нибудь докладчиков, которые как будто бы вбрасывают случайные куски текста в уши без постоянно озвучиваемой логической связки между ними и без напоминания о том, в какой части темы вы вообще находитесь? 🙂

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

Интересное видео о том, каким может быть рабочий день аналитика. Скорее, для начинающих и готовых ворваться в этот странный мир 😊
https://www.youtube.com/watch?v=HDOIVGR21rU

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

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

Уверен, у большинства из нас уже был опыт участия в подобных мероприятиях без подготовки, как были и постфактум эти прекрасные чувство стыда, самобичевание и клятвенные посылы делать в следующий раз “как надо”. Я как тренер, например, всегда готовлюсь к тренингам, включая и те, которые были прогнаны десятки раз. Да, у меня иные задачи, нежели извлечение информации из стейкхолдеров, но это также коммуникационные сессии, и годы проведения тренингов не убрали подготовку, а наоборот показали, насколько легче мне и продуктивнее для других будет, если вложиться в это заранее. В целом, что интересно, я замечал, что такие вещи, как планирование и подготовка к чему-либо, свойственны более сеньористым специалистам. Люди с меньшим опытом расценивают посылы о планировании как информационный шум, плюс часто страдают наивняком в духе “Ай, отожгу экспромтом”. И эту ошибку нужно пару раз таки допустить, чтобы по итогу поменять свое отношение к подготовке.

Собственно, так как посыл “что делать” уже сформулирован, опишем чеклист, который вы можете взять за базу и адаптировать под себя (и да, это именно чеклист — открываете и идёте по нему, отмечая, что сделано, а что нет).

1. Тема + цели + содержимое сессии.
1.1. Для начала вам нужно определить, чему будет посвящена сессия. Это весомо повлияет на весь дальнейший план. У вас не было такого, когда начальник говорит “Давай сегодня в 3 созвонимся и поговорим”? Или еще более печальная вариация: “Я тут на перспективного клиента вышел. Он готов на созвон в 14.00, давай впрыгнем и пообщаемся, м?" То ужасное чувство, когда ты не понимаешь, что это, зачем и о чем.

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

1.2. Вы можете пойти еще дальше и сформулировать цели, т. е. что вы хотите от сессии получить на выходе: ответы на вопросы X, Y; выработанный план с исполнителями и сроками для Z и т. п.

1.3. Также стоит продумать вопросы/пункты для обсуждения и план того, как вы в рамках сессии будете это покрывать. Пример для тех, кто пока еще в поиске работы и не испытывал еще прелести продакшн-коммуникаций на себе: если вам назначили собеседование, обдумайте ту часть, которая в зоне вашего контроля, заранее. Это могут быть следующие вещи (поверьте, вы забудете учесть многое, если будете спонтанно и судорожно думать на ходу):
- Как я буду отвечать на типовые вопросы, да и, вероятно, на неродном языке: о себе, денежные ожидания, кем я вижу себя в хрустальном шаре через 5 лет и т. п.
- Что я хочу узнать о компании (в Интернете полно типовых чеклистов, из которых можно выбрать актуальное): удаленка/офис, отпуска, больничные, техника, команда, механизм получения бабосиков и пр.

2. Капитан шепчет, что нужно выбрать технику для коммуникации. Если мы говорим про извлечение информации, то это всем известные техники извлечения: интервью, воркшопы, опросники, анализ документов, обратная инженерия и пр. Зависать на этом пункте не будем, т. к. это все же в тему непосредственно проведения коммуникаций или извлечения информации. Замечу только, что спонтанно действующий аналитик может, например, владеть только интервью и только в письменном виде — сесть и писем накатать. Много писем. Всегда нужно много писем. Аналитик, который сядет и чутка подумает, может решить: «А что если я вначале зашлю всем пользователям опросник и соберу первичные результаты, а потом устрою интервью с отдельными представителями и уточню неясные моменты вглубь? А потом я еще и соберу их и свою команду на воркшоп, устрою обсуждение и попытаюсь устранить противоречивые моменты».

3. Дополнительные параметры (”логистика”) сессии:

3.1. Подбор участников. Встречалось ли вам, например, такое? а) «Если есть проблема, нужно собраться максимальным количеством человек и усердно о ней поговорить», и по факту половина участников тупо присутствуют в качестве мебели. б) «А давайте устроим переписку по проекту на всех участников (человек эдак 30)!» Как же классно быть частью таких коммуникаций, ммм, эффективный менеджмент! Думаю, понятно, что если вы организатор сессии, то должны присутствовать только релевантные участники — вы должны найти баланс между стремлением сократить размер группы (для повышения эффективности общения) и риском упущения важной информации.

3.2. Ресурсы сессии. Наверное, самый недооцененный компонент подготовки и больвдырказадница начинающих аналитиков, которые это благополучно упускают. Типовые вещи:

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

- Планирование сессии в календарике — это подразумевает инвайты участникам. Где-то это просто считается правилом хорошего тона, а где-то без этого вообще не работают. Рекомендую либо всегда делать такое по умолчанию, либо обсудить полезность такой практики со стейкхолдерами. У меня были ситуации, когда человек не появлялся на встрече с посылом “Ээм, а где событие в календарике? Естественно, я забыл.”

- Проектор, если необходим. Его также часто нужно планировать и занимать заранее. Работа с большим экраном гораздо удобнее, чем собирать вокруг своего ноутбука пять стоящих участников.

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

- Интернет, микрофон, наушники, телефон, камера, блокноты, ручки, диктофон, смартфон, планшет. Тут может быть ваш личный чеклист — главное, ведите его. Любые яркие проблемы с вашей стороны в плане инструментария — это показатель вашего непрофессионализма. “Ой, а у меня интернет слабый, дети киношку качают”. “Ой, а микрофон что-то не работает… как-то я забыл проверить — дайте 10 минут на настройку.” “О, шумы, да? Это я просто в шумной комнате сижу.” Любой инструмент, участвующий в процессе, нужно изучить, владеть им и обязательно проверить его работоспособность — в частности, перед важными сессиями (инструменты имеют свойство ломаться в самый неподходящий момент, ага). Например, если вам еще только предстоят собеседования, обязательно внимательно пройдитесь по этому пункту. Маркеры выше сильно повлияют на восприятие вас интервьюерами.

4. И последнее — подготовка участников. Подумайте над следующими вопросами:

4.1. Нужно ли обучить участников чему-либо, чтобы сама сессия прошла эффективно? Стоит ли, к примеру, тратить время на изучение того, что за техника такая под названием User Stories, если можно дать стейкхолдерам материалы, а саму сессию посвятить работе с ними? Стоит ли тратить время на обучение работе с Zoom? Может ли иметь смысл попросить людей познакомиться с какими-то вещами самостоятельно и заранее?

4.2. Необходимость изучения материалов. Если вы обсуждаете какой-то артефакт, допустим V&S, стоит ли попросить людей ознакомиться с ним до сессии, нежели устраивать сеанс группового чтения на встрече?

4.3. Обдумайте обязательно, полезным ли будет донести до стейкхолдеров повестку/агенду сессии. Если не хватает опыта для принятия осознанного решения — just do it. Тема эта весьма избита, и Интернет пестрит шаблонами и примерами — главное, не стремитесь обязательно накидать туда горы текста. Иногда один небольшой абзац — это уже отличная агенда, которая точно лучше описанного в первом пункте кейса с ПМом. Осмыслите следующие компоненты повестки (ее, кстати, можно в инвайт запихнуть, но имейте в виду, что не все такое видят и зачастую просто жмякают Accept машинально):
- Темы/цели — то, что вы обдумали в первом пункте, стоит сделать явным для участников (как в примере с внезапно прилетевшим чайка-ПМом, участникам тоже может хотеться обдумать, что и в каком ключе они будут доносить).
- Участники — ситуации могут быть разными, и иногда знать, кто будет на встрече, другим участникам таки нужно.
- Когда и сколько будет длиться.
- Где (ссылка в случае онлайна) будет проходить.
- Детализация — какие вопросы будут обсуждаться. Вероятно, люди смогут обдумать и подготовиться тщательнее, если они будут понимать в деталях, о чем на встрече будет идти речь. А может они еще и возьмут с собой кого-то, кто шарит в этом вопросе.
- Сопроводительные материалы для подготовки до встречи, если таковая необходима.

Сегодня — о документации аналитика, и в первую очередь — о документировании требований в контексте постановки задачи на разработку или накопления базы знаний. Перечислю типовые ошибки (пусть это суммарно будет ошибка #18 — косяки в написании документации) и советы на их базе по написанию и оформлению документации, которые качнут вас на десяток левелов в глазах потребителей ваших трудов. Цель тут — не детализация каждого пункта вглубь, а широта охвата, чтобы вы могли взять себе это за чеклист и при желании пытаться в дальнейшем делать ваши письмена круче, поэтому это будет просто набор пунктов разной степени важности одним большим списком. Те, кто прошел тот или иной курс от ITMINE в последние пару лет, увидят много знакомых вещей, которые мы либо транслировали в виде чеклистов, либо правили/комментировали в работах, но все равно надеюсь, что пост будет полезным даже для выпускников — хотя бы освежить в памяти. Ну и постараюсь вкратце, дабы прямо совсем не перегрузить, но если нужно что-то раскрыть — сигнальте.

1) Использование синонимов для обозначения одних и тех же вещей. Критичность: высокая. Например, в спецификации требований вы используете слова «экран», «форма», «страница» для обозначения одного и того же UI-элемента. Или, что еще опаснее, используете в описании бизнеса заказчика синонимичные термины («заявка», «заявление», «запрос»). Последствия: ошибки в требованиях, усложнение их поддержки, вопросы или неверная трактовка со стороны читателей. В контексте технических терминов выберите наиболее точный и используйте только его. В контексте домена заказчика создайте глоссарий терминов и дайте каждому точное определение. Если есть синонимы, которые не меняют значение, укажите их в глоссарии, но в текстах все равно используйте только одно из значений.

2) Пассивный залог в формулировках вместо активного («кто что делает»). Критичность: высокая, если это относится к требованиям. «Когда пользователь нажимает на кнопку «Сохранить», должна появляться форма подачи заявки.» В данном примере последствия несущественны — едва ли кто-то поймет это как мистическое явление, а не как действие системы. Но часто бывают ситуации, когда понимать исполнителя необходимо, как в контексте бизнеса, так и требований, причем и вам (для полноты информации, с которой вы работаете), и читателям. А пассивный залог его скрывает: «Когда клиент подает заявку, она обрабатывается в течение пары дней». Гораздо удобнее ввести себе в жесткое правило использовать только активный залог, чтобы и самим заметить нехватку информации, и у читателя не оставить вопросов. «Когда пользователь нажимает на кнопку «Сохранить», система должна отобразить форму подачи заявки.»

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

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