3) Прочие советы:
3.1) В требованиях должно фигурировать только то, что является уникальным описанием использования интерфейса системой. На занимайтесь копипастом из гайдов, если они доступны для изучения. Например, маппингу данных (инструкции для команды, что передать в запросе и получить в ответе) — да, общему описанию форматов запросов/ответов — нет; как системе реагировать на нестандартные ситуации — да, описанию ошибок из гайдов — нет.
Помним всегда о двух простых вещах: 1) детализация документации сверх необходимого — грусть, т. к. фетиша на длинные тексты у вашей ЦА скорее всего нет, и если что-то можно почитать где-то в другом месте, оставьте это там; 2) владелец информации о бизнесе — вы, о технике — команда, т. е. в информации о том, как в принципе работает сторонний API, они разберутся сами, а вот то, что туда правильного надо передать и что оттуда взять, как красиво представить ответ или печальные ситуации пользователям — это вы.

3.2) Структуризация: вместо грустного технического полотна подайте текст удобно разбитым на главы. Внешний интерфейс -> Точка взаимодействия ->Запрос, ответ, ошибки. Чем меньше документация вызывает изначального отторжения, тем больше шансы того, что работу сделают по ней.

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

Бонусом — простой пример описания таких требований

В этой заметке поговорим про практические советы для User Stories (US). Говорить о них можно много, поэтому в несколько подходов. Для старта такие:

1) Вначале важно определиться с тем, чем для вас и команды US являются концептуально: это элемент бэклога (полезный инкремент продукта, или задача на разработку, если упрощенно) или элемент базы знаний (какая-то постоянная единичка, на которые попилен скоуп решения). В первом случае US как артефакт полезна до тех пор, пока не разработана и не принята. Для такой US всегда найдется место в бэклоге (списке того, что надо сделать) и применимо понятие Definition of Done (т. е. критерий того, что она утратила свою актуальность). Во втором же случае — это кусок спецификации требований, который вы поддерживаете в актуальном состоянии на протяжении всего проекта. Такую историю, когда придет время ее изменить/доработать/удалить, не запихнешь в бэклог и не оценишь как работу, т. к. это описание целевого кирпича, а не того, какое изменение в кирпичную стену надо внести. У каждого подхода есть плюсы и минусы (скорость и простота работы, но сложность в раскапывании того, как система работает в любой момент времени и восприятии полной картины решения VS ровно наоборот). Это решение определит в принципе вашу парадигму работы с документацией, а потому, дабы не делать заметку громоздкой, просто оставлю здесь видео, которым не раз уже делился: https://www.youtube.com/watch?v=qpwcE1rsBNg. Но если лениво смотреть, сигнальте, если хотите разбор обоих подходов.

2) Определитесь с форматом критериев приемки (т. е. требований) для US, чтобы подход был однообразным для читателей. Есть много разных вариантов:

- утверждения от лица персонажа истории
- Gherkin (Given-When-Then)
- своровать формат из Use Cases
- детально и подробно описать UI
- пишем, как пишется (т. е. в произвольном формате), комбинируем форматы и пр.

Выберите то, что по душе, и, как и с любыми иными артефактами, отразите от читателей (в первую очередь, от команды разработки) удобство и ценность. Любой формат хорош тогда, когда от него кайфуют получатели.

3) Лучше помнить про INVEST, чем не помнить. И вот он простым языком (при этом имеем в виду, что это = “в сферически идеальном вакууме US должна быть такой"):

Independent: US не зависит от других US. Это не всегда реализуемо. Но есть плохая зависимость, а есть та, с которой можно жить. Приемлемая зависимость (порядок поставки): Просмотр деталей заявки и Просмотр списка заявок (см. также ниже про Valuable). Без списка сложно выйти на Детали заявки, а потому порядок разработки тут едва ли избегаем — главное учесть подобное внутри бэклога и отразить зависимости между US в явном виде внутри них. Плохая зависимость, которой можно избежать (пересечение): Просмотр заявок для покупателя и Просмотр заявок для админа, если критерии приемки обеих подразумевают разработку списка с нуля. Лучше сделать так, чтобы первая история содержала разработку базового списка, а вторая добавляла новые элементы для админа (например, новые колонки в таблице). Но это подразумевает, что US у вас — это элемент бэклога (т. е. подход номер раз из пункта 1 выше).

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

Valuable: не пренебрегайте компонентом “чтобы что” в формулировке US и не относитесь к нему как к “галочке”. Простой пример: разложим на CRUDL работу с заявкой на сайте. Если по итогам общения с заказчиком/пользователями вы вывели то, что в системе нужны и List (просмотр заявок списком), и Read (просмотр подробных деталей конкретной заявки), то не факт, что это две разных US. Если при попытке выработки ценности US для списка вы приходите в тупик (т. е. никому не нужно просматривать список заявок сам по себе — у этого не будет ценности как самостоятельной законченной операции), то, скорее всего, разрабатывать и поставлять это отдельно от Read смысла нет, т. к. это не будет полезным приростом к системе. Т. е. это может оказаться неотъемлемой частью просмотра деталей заявки (шагом на пути к этому), а такие истории не стоит выделять отдельно.
Также: никаких историй вида “Фронтенд для просмотра заявок”. История — это ценный для пользователей (ибо User story) инкремент, а не задача узкому эксперту. Простой шаблон мышления для оценки этого (работает не всегда, но в абсолютном большинстве случаев): если данную историю добавить в продукт и только ее, то релиз с этой историей даст новую ценность пользователям? Если ответ “нет”, это повод задуматься, где и что сделано не так.

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

Small (enough): достаточно небольшая, чтобы быть удобной для команды в плане разработки и трэкинга (влезает в спринт, назначаема одному человеку, занимает не больше X сторипойнтов — критерии для конкретной команды могут быть разными). А потому вначале обсуждаем сие дело с командой, а потом уже стараемся делать их такими (сохраняя при этом Valuable). Если надо разбить (т. е. команда дала такой фидбэк в моменте обсуждения US), то крутим-вертим SPIDR.

Testable: это тоже о а) наличии требований (критериев приемки), б) качестве требований — конкретно о проверяемости. Тут для знакомых с классикой все просто: никаких “приемлемо”, “быстро” и прочих критериев. Каждый КП должен быть однозначно тестируем с окончательным вердиктом: правильно реализовано или нет.

Бонусом — пример оформления User Story в разных форматах с комментариями.

Ещё одна подборка свежих материалов:

Ключевое про собеседования для Trainee, Junior, Middle и Senior BAs. Планирующим вход/развитие в профессии рекомендую. Вкратце:

Trainee (https://www.youtube.com/watch?v=Z5DLdMT8OZc) — о понимании роли, мотивации и обучаемости; в целом огонь огненный, но натужные мотивационные питчи имхо так себе.

Junior (https://www.youtube.com/watch?v=UW11YTbg-pE) — о знании/понимании теории, её кейсовом применении и силе качественного обучения.

Middle (https://www.youtube.com/watch?v=lnrmkTXRBa4) — базовые советы для CV, обсуждение практического опыта и продвинутые знания. Не уверен, что часть про лидерство — это то, что нужно на этом этапе, но у автора такой опыт.

Senior (https://www.youtube.com/watch?v=zuFHemtmBJc) — снова про CV, портфолио и обсуждение продвинутого опыта, ачивок и всяких-разных ОКРов. Эта часть в моем опыте отзывается меньше всего, однако кусок про красные флаги хорош.

Requirements Quality Is in the Eye of the Beholder (https://medium.com/analysts-corner/requirements-quality-is-in-the-eye-of-the-beholder-fec8d2edd6c4) — маэстро Карл лаконично объясняет, почему требования жгут только тогда, когда их таковыми видит целевая аудитория.

Memoirs of a Business Analyst (https://medium.com/analysts-corner/memoirs-of-a-business-analyst-5addc144441c) — любимый дядюшка делится историей своего тернистого пути. Как минимум увлекательное чтиво.

Are You Confused Between Acceptance Criteria and the Definition of Done (DoD)?(https://medium.com/agileinsider/do-you-know-the-difference-d0a543587b8b) — полезная заметка для тех, кто усердно путает как сами понятия, так и уровень их применения.

Интересный контент, который как минимум можно задвинуть на собеседованиях.

Ивар Якобсон (основоположник юз кейсов аж с 1987 г. и соавтор UML) вместе с коллегами в декабре подготовили гайд Use Cases 3.0 (https://www.ivarjacobson.com/publications/books/use-case-30-ebook).
Попытался вкурить эти 86 страниц, чтобы вам не пришлось. Вот интересное вкратце:

1. Цель (как видится): подружить UC и agile, и UC и user stories.

2. Из документа узнал, что в этом году Якобсон и Коберн (еще один тяжеловес в области UC) выпустили The Use-Case Foundation document с принципами применения UC. Там ничего нового, но интересные моменты в плане терминологии отмечу:

- Supporting actors (именно так, а не “secondary”) — те, к кому дополнительно обращается система для выполнения UC.
- Extensions (именно такой термин) для UC — сценарии, выходящие за рамки базового сценария: альтернативные пути, ошибки, опциональные шаги и пр.

Что несет Use Cases 3.0:
3. UC Slice — “срез UC, представляющий ценность для development stakeholders. Ценность такого slice не имеет отношения к цели актера, выполняющего UC.” Какие бы оттенки сия мудрая конструкция ни несла, в целом это нарезание UC, чтобы девелопить его мелкими итерациями: берем один или несколько сценариев UC (т. е. режем именно по сценариям), называем это slice и девелопим. Напоминает Paths из SPIDR для User Stories, не так ли?🙂

4. Постановка задач на реализацию UC — это User Stories (или Tasks, если в более классических подходах к разработке). Вот и дружба подъехала. Т. е. один UC Slice может быть представлен одной или набором User Stories как задачами в бэклоге, а сам UC или его slice может быть визуализирован с помощью User Story Map. Концепция видится рабочей, правда US в таком подходе (и в примере в книжке) совсем уж мелкими получаются. Отдельно отмечено, что если команда пользует понятие Эпиков, то UC slices “work perfectly as Epics”.

5. Одна из выделяемых практик для UC (в книжке выделяются и описываются практики из области UC, которые можно использовать индивидуально по выбору): Use-Case Storytelling — легковесная подача UC. В отличие от практики Use-Case Authoring, где все по классике. Выделено понятие Use-case Narrative и 4 уровня для него (первые два — для Storytelling, последние два — для Authoring):

Briefly Described: цель UC и его актер.
Bulleted Outline: + шаги базового сценария в виде простого списка, названия extensions и краткое описание constraints (термин, объединяющий предусловия, постусловия и прочие “особые требования”).
Essential Outline: + системно поданные и качественно сформулированные шаги сценариев.
Fully Described: шаблон по классике с блэкджеком и прочими кайфами.

6. Еще одна выделяемая практика: Use-Case Light Modeling (легковесное построение диаграмм). В отличие от практики Use-Case Structured Modeling.

Light Modeling — это ключевые актеры и UC, плюс, опционально, supporting actors и менее значимые UC.
Structured Modeling — полный набор UC, плюс использование Extend, Include и Generalization (как для UC, так и для актеров).

7. Интересные посылы, которые показывают стремление классиков жить модно и молодежно:
- Consider using the Use-Case Light Modeling practice composed together with the Use-Case Storytelling practice as your default choice in Use Case 3.0.
- Use-Case Authoring: Evolve your Use-Case Narratives to provide a formal, detailed specification of the most critical use cases of your system.

Общие впечатления:
Неловко в критическом ключе отзываться о работе титанов, но лично мне читать это было непросто, и дальше пойдёт дерзкий субъектив. Избыточная формализация ряда вещей, неконсистентность раскрытия терминов (что-то несколько раз дублируется, а иное не раскрыто в принципе — что за infrastructure use cases, которые могут описать НФТ, и что за operational use cases?), плюс местами будто из вредности усложненный язык. Также много внимания уделено тому, как UC 3.0 встраивается в подход Essence, а там свои термины (Kernel, Alpha и пр.) — кстати, кто-нибудь этим вообще пользуется на практике?

Если про практическую ценность, то кажется, что те, кто пользовал User Stories обособлено, так и будут их пользовать. Юз кейсы омоложены, причем весьма логично, но единственный действительно полезный сценарий комбинирования техник (имхо) — это увязать базу знаний (спецификацию) в виде UC и бэклог работ в виде US, когда видится ценность иметь и то, и другое. Правда, ко всему этому можно было прийти чисто эмпирически и даже без новомодных терминов.

Сегодня — про скоуп (solution scope, project scope), границы решения (что это, как выглядит и что полезного стоит помнить). Аналитики понимают это как высокоуровневое (”общими мазками”, “с высоты полета птички”) наполнение решения. Т. е. как ответ на вопрос “А что там вообще будет в решении?”, причем не в виде спеки на 300 страниц.
Скоуп полезно формировать и держать в фокусе как 1) на старте проекта (в контексте стратегического анализа/discovery), т. е. когда мы укрупненно прорабатываем, чем будет наполнено решение, так и 2) на протяжении всего проекта, т. к. команде нужно по каким-то единичкам структурировать работу (планировать, отслеживать, итеративно прорабатывать).

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

1. Фичи (Features). Фича — это логический кусок решения. Степень абстракции фич и количество уровней в их картине — на наше усмотрение и должны лишь служить цели иметь скоуп кратеньким, наглядным и полным (об этом ниже). Примеры фич и подфич, которые их детализируют, для Telegram: Работа с сообщениями (Текстовые сообщения, Аудиосообщения, …), Управление контактами (Добавление контакта, Удаление контакта…), Настройки (Картинка профиля, Базовые данные профиля, …).

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

Визуализация — сила, а потому для фич в этом плане можно использовать Feature tree.

2. В Agile-разработке для цели “порубить систему на куски” есть пользовательские истории (User Stories). Если US для этого слишком мелки (а им стоит таковыми быть для удобства разработки), вводят новые уровни структуризации: эпики, темы инициативы, стримы и т. п. Общесистемные нефункциональные аспекты с помощью US также вполне себе можно донести.

US можно визуализировать с помощью User Story Map. И не только визуализировать: эта техника еще и позволяет их планомерно идентифицировать, отталкиваясь от конечных пользователей, когда на входе понимания скоупа нет.

3. Варианты использования (Use Cases). С рядом ограничений, но тоже подходят для целей скоупа. UC акцентируют, что полезного с системой может сделать пользователь. И в этом и есть их ограничение в контексте данной задачи: представьте, если в системе у нас всего одна полезная операция для юзера. Едва ли скоуп из одного элемента будет нагляден. Да и нефункциональные характеристики в виде UC мы не очертим.

Визуализация также в наличии — Use Case Diagram.

Общая рекомендация: использовать 2 для agile-проектов; если же user stories не по душе и нет ни опыта, ни желания постигать их дзен, использовать 1 или 1 и 3 в связке. Go-to подход по умолчанию может быть разным, в зависимости от того, какая среда воспитала в нас аналитика. Для меня, например, это 1, плюс дополнить пунктом 3, если хочется ещё и юзерам поэмпатировать.

Общие советы касательно скоупа (применимые для любой из техник выше):

- Небольшой набор. Скоуп должен быть наглядным в контексте задачи “понять, что вообще будет в системе”. Спеку написать или выделить 300 мелких user stories мы всегда успеем. В то же время это не одна и не две единички: такой набор не раскрывает наполнение системы. Т. е. стараемся выбрать такой уровень абстракции, чтобы уложиться в 4-20 элементов (это пальцем в небо, конечно — решаем для себя, в каком количестве будет наглядным донести наполнение решения до стейкхолдеров разных пород и не привести к коллапсу их мозга в процессе).

- Однородный в плане абстракции. В рамках одного уровня стараемся иметь сходные в плане высоты полета, с которой мы взираем на скоуп, единички. Например, для Telegram “Работа с сообщениями” и “Смена фото профиля” — это ни разу не так. Первое — это огромный в плане наполнения кусок приложения, а второе — мелкая операция.

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

- Формируем в контексте требований. Не на базе компонентов архитектуры и реализации. Фронтенд, бэкенд и база данных — это не элементы скоупа.

- Обзываем единички лаконично. Скоупом часто будут оперировать на протяжении всего проекта (при обсуждении системы, планов, назначении задач, проработке с заказчиком и т. п.). Фичи, US и UC подразумевают название из 1-3 слов (например, Отправка сообщений или Сообщения). Антипример: возможность для пользователей отправлять сообщения разных видов.

- Айдишники. Для большей точности и ещё большей лаконичности аналитики любят присваивать ключевым требованиям уникальные идентификаторы. А куда уж ключевее, чем единички скоупа. Представим, насколько точнее и проще (при правильном подходе) может стать их обсуждение, если ссылаться на них в духе US01 или Ф-16.

- Пользуем многоуровневость. Задача аналитика — наглядно систематизировать информацию. Например, представить скоуп Telegram в виде 50 фич одним списком — так себе подача. Удобнее и понятнее будет воспринимать такое в 2 или 3 уровня: например, функциональные области → крупные фичи → подфичи; темы → эпики → user stories; функциональные области → юз кейсы.

Бонусом — пример подачи скоупа для простенькой системы (приложение Clock для Windows 11) в разных техниках.

Всем салют!

Осмысливаем варианты добавить полезный/интересный интерактив. Есть такие идеи:

1. Cозвоны/стримы, где можно как активно голосом и лицом участвовать, так и просто слушать или комментировать. Как вам сама эта идея и, если отзывается, что конкретно будет полезным? Например:

- Тестовые интервью (то, что раньше делали analyst.by).
- Разбор артефактов с обсуждением и обменом полезными советами.
- Ответы на разные животрепещущие вопросы (например, мини-докладики по темам или просто Q&A по текущим проблемам и активностям).

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

Не уверен, нужно ли такое в целом, поэтому хотелось бы вначале от вас отразить. Чтобы это как-то структурировать, давайте сделаем так:

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

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

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

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

2. Почта — асинхронная коммуникация, если иное не продиктовано условиями работы (корпоративной политикой, ожиданиями стейкхолдеров или спецификой нашей позиции). Моментальный ответ на письма не требуется. Не нужно спешить показывать, как быстро мы умеем реагировать на входящие — письмо не подразумевает мгновенной реакции (в отличие от мессенджеров зачастую). В то же время стоит помнить про рамки, в течение которых нам все же стоит отреагировать, причём хотя бы с ответом “принял, взял в работу, вернусь позже” — о таком, кстати, часто забывают, и для заказчика мы тогда выглядим как молчуны, в черную дыру которых проваливаются письма. Часто по дефолту берут 24 часа на такое, и это хорошая практика. Кстати, срок ответа может быть определен корпоративной политикой, что стоит уточнить.

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

4. Правильно интерпретируем и пользуем СС и BCC. СС (копия) — это режим FYI (держим в курсе). Т. е. письмо — оно не тому, кто в CC, и не подразумевает от этого человека какой-либо реакции (если только сам он не захочет вклиниться).

BCC — то же самое, но ещё и в стелс-режиме. Помним, что reply all не затронет тех, кто был в BCC, и не боимся этого.

5. Подпись — стандарт и практически a must, но лучше иметь и варьировать формальную и неформальную подписи. Я по дефолту настраиваю в клиенте 4: 2 на русском и 2 на английском. Неформальная подпись (если иное не продиктовано политикой компании) — для переписки, когда контакт уже налажен, и ее плюсы в том, что она осознанно делает коммуникацию менее формальной и не занимает много места (так себе, конечно, видеть полотна подписей в письмах на две строчки, а тем более если ещё и с важной инфой о том, как мы бережем бумагу, какой поставили себе антивирусник или какой айфон себе купили).

Тема письма:

6. Никаких пустых тем (да и пустого тела письма — не будьте теми, кто тупо форвардит аттачменты). Рекомендую внедрить две практики: а) формулировка темы до написания текста (заодно поможет словесный фонтан упреждающе сузить), б) ревью письма хотя бы единожды после написания, начиная с метаданных (To, CC, BCC, тема).

7. Префиксы в темах — огненная штука, если есть сквозная тематика. Префиксы помогают быстрому сканированию и настройке авторулов. Задаем себе вопрос: можем ли мы облегчить получателю распознавание писем в контексте сквозной темы? Например, речь про заказчика, у которого есть и иные дела помимо нашего проекта. Если да, то подаем пример — допустим, в виде краткой маркировки проекта.

8. Лаконичность и точность темы. Во-первых, никаких полноценных предложений:
“Спецификация требований” — хороший пример.
“Необходим ответ на документ с требованиями к программному обеспечению.” — плохой пример.

Во-вторых, стараемся делать тему максимально точной. Помним, что по ней, вероятно, будут искать контент.
“Спецификация требований” — хороший пример, если в письме мы метаем в получателя спеку.
“Обсуждение проекта” — плохой пример, потому что половина писем по проекту будут иметь эту тему.

9. Релевантность темы. Да, всегда проще найти какое-нибудь античное письмо от человека, сделать на него реплай и вточить туда совершенно иной вопрос. Но снова помним: по теме будут искать контент. Если серьёзно отклонились от темы, формулируем новую. Избегаем переписок с Васей в течение года по темой “RE: RE: Как дела?”

Тело письма:

10. Структура. Совет для новичков: стоит помнить, что у органично выглядящего письма есть типовая структура. Работает, конечно, не в 100% случаев, и авторская адаптация под ситуацию может на нее сильно повлиять, но как дефолтную схему ее всегда стоит держать в голове: обращение/приветствие -> предисловие (мостик между обращением и смысловым наполнением) -> цель письма/аннотация (важно иметь практически всегда — никаких резких перепрыгов на детализацию) -> детализация (собственно, мясо письма) -> итог/ожидаемые действия -> прощание/завершение.

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

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

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

13. Этот и пункты ниже обусловлены тем, что я выше писал про асинхронность почтовой коммуникации: это когда вы пишете пачку вопросов получателю, через два дня получаете встречные вопросы или отписку “не понял”, после чего цикл повторяется. Т. е. максимальная точность, т. к. наша задача — минимизировать количество подобных ситуаций. Если отсылаемся к чему-то, не стоит надеяться на память собеседника — пишем конструкции вида “В письме “RE: Спецификация” от 5 марта вы писали…” или “В комментариях к issue #543 мы пришли к решению…”.

14. Проактивная обертка. Очень важный пункт, и об этом я уже детально писал тут: https://t.me/itmineba/86 и https://t.me/itmineba/87. Это явно не понравится апологетам коротких писем, но советую осмыслить примеры из заметок и наложить их на вялый обмен письмами по одному в день. Вынесу ключевое: не предполагайте, что собеседник знает/помнит о вопросе столько же, сколько и вы, а потому погружайте его проактивно в контекст.

15. Четенькие посылы к действию. Я также уже это затрагивал: https://t.me/itmineba/83 и https://t.me/itmineba/84. Ключевое оттуда: всегда явно формулируйте, что вы хотите от собеседника, не оставляя это на свободную интерпретацию.

А вот примеры нарушения ряда пунктов и того, как это стоило бы переделать.

Кстати, в рамках курса мы эту часть практикуем, причем с индивидуальным фидбэком 😉

Привет всем!

Можно попробовать для начала стартануть тему с заданиями. Давайте базовые правила очертим:

- Фидбэк буду давать как минимум я, но а) надеюсь, что другие будут подключаться, причем можно в виде дискуссий (я буду только рад), и б) далеко не факт, что на все работы — зависит от активности (минимум на две работы по каждой задаче меня точно хватит).
- Делая задания, вы соглашаетесь на их публичную выкладку и обратную связь. Можно анонимизировать, если важно: кидайте работу мне в личку (@g.shesterov), а я уже выложу в Google-док от себя.
- Предлагаю работы давать в доступном для публичного комментирования Google-документе или ином софте (Miro, Figma etc.) — главное, чтобы комментирование было доступно всем без SMS и регистрации. Кидайте их в комменты, либо, как выше писал, мне в личку.
Прочие условия и наворачивание инфраструктуры будем добавлять по мере итераций и ретро по ним.

Вот для начала вариантик (вдохновлено тестовым из пары компаний) 😊:

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

Что предлагаю сделать вначале:

Сформировать скоуп в виде User Story Map (и/или Use Case Diagram и списка фич с описанием).

Следующим шагом двинемся к детализации элементов (user stories, use cases, требования к данным, требования к UI, макеты). Если кто-нибудь хочет, можно и бизнес-требования с бизнес-контекстом в бонус очертить.

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

Те, кто готов был активничать: ваши комменты и предложения к задаче или условиям тоже велкам🙏

А вот и первые работы. Тем, кто еще делает задание, не стоит смотреть, дабы спойлеров не нахвататься 😊

https://docs.google.com/document/d/1VQQxkMTHQt9lrMNjGUFsN6SsIN2IB5yqDQyj4ZyqbaM

https://docs.google.com/document/d/15oOBmZlEc9u9pX1DXV4HRnK8Zjj-UzqmIPqJQvEZMF8

Cвои комменты добавил. “Положительного” фидбэка по конкретным кускам там нет (чтобы не тратить время, так как суть задания не в этом), но в целом: все что не откомменчено, сделано круто, а потому "авторы жжёте, молодцы и флюиды респекта вам" 😊
Сделал доступ всем на комментирование. Обратная связь от других или иные комментарии, естественно, приветствуются.

Будущие работы, если будут, буду уже в комментарии к этому посту выкладывать (или выкладывайте туда сами).

Ещё одна подборка всякого-разного на почитать на досуге:

10 Reasons To Have a Professional Portfolio (https://medium.com/business-architected/10-reasons-to-have-a-professional-portfolio-26bf6f7e8efa): о том, что аналитикам круто иметь портфолио и как к нему подойти. Мне всегда нравился этот подход, причем будучи на обеих сторонах, а потому рекомендую к осмыслению.

Интересный небольшой (пока) канал по комбинации бизнес-анализа и безопасности IT-систем: https://t.me/AppSecBP. Постов там пока немного, но мне круто зашли в плане расширения кругозора.

Вредные советы начинающему аналитику (https://habr.com/ru/companies/rostelecom/articles/873452/): очередной очерк из рубрики очевидных типовых ошибок, но читается легко и интересно.

Hearing the Customer’s Voice: The Product Champion Approach (https://medium.com/analysts-corner/hearing-the-customers-voice-the-product-champion-approach-55a99e556ad5): дядюшка Карл со своей известной темой про product champions. Полезно вспомнить красивый процесс в вакууме, если труды его читали давно.

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

1. Все мы понимаем, что юз кейс, как и user story, должен нести ценность для пользователя. Но этого мало, дабы их правильно применять. Юз кейс — это обособленный (дискретный, самостоятельный) кусок взаимодействия, и именно в этом контексте стоит осмысливать его ценность. Что это значит? Я трактую для себя это в виде подхода “подошел к решению -> выполнил юз кейс -> ушёл, получив ценность”. И это важный момент, позволяющий лучше осмыслить даже само название: один из вариантов того, как юзер может воспользоваться решением полезным для себя образом.

Возьмем смартфон. Просто “полезная” операция без учета описанного выше — включить экран. Кто скажет, что это для юзера не ценно? Юзер делает это, чтобы впоследствии что-то нужное ему замутить. По аналогии: напечатать символ, перелистнуть страницу, нажать кнопку “Назад”. Разве не ценны для него все эти действия? Ценны, но тут ломается упомянутая выше цепочка, и с точки зрения самой сути техники это опасный (своей бесполезностью) подход. Ну то есть “А давай подумаем, что там юзерам нужно будет? -> Ну… экран включить, страницы листать… -> А зачем? -> Да какая разница? Мало ли зачем он будет страницы листать?” И вот мы скатываемся в то, что нам лень понимать, зачем решение необходимо юзерам, и тупо клепаем фичи.

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

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