Немного об ограничениях: https://shesterov.by/tpost/rxt85xd1h1-ogranicheniya-design-and-implementation
Что это такое и как их правильно кушать.

Приветос, амигос!

Снова подборка интересных чтив:

https://habr.com/ru/articles/839900/ (Общие принципы интеграций систем. SA для самых маленьких) - полезные базовые знания из области “качаем техническую базу”.

https://medium.com/analysts-corner/requirements-development-demands-iteration-065a1c6e621c (Requirements Development Demands Iteration) - Карл снова на связи и рассуждает об итеративности разработки требований. Для начинающих, т. к. опытные уже в курсе, что Карл пишет на одни и те же темы, просто чуть разными словами.

https://habr.com/ru/articles/838716/ (<Не>Страшное слово эстимация, или Как я впервые оценивала время на тестирование и перебрала) - частный кейс об оценке работ, который интересно просто почитать и либо сравнить со своим опытом, либо хватануть базу для первого раза.

Помнится, я уже делился этим материалом где-то в анналах комментариев, но скину явно сюда еще раз — как минимум для тех, кто не видел ранее:

https://www.youtube.com/watch?v=qpwcE1rsBNg

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

И где-то рядом также советую глянуть такое еще от Дениса на тему Use Cases vs User Stories: https://www.youtube.com/watch?v=9dOFSY5PoNo

Классное описание сферически идеального получения/выполнения задач. По личному опыту — работа над такими навыками даст значительно больше роста, чем прокачка точечных хард-скиллов для БА, т. к. проактивность — редкий и ценный зверь.

Мы в systems.education при отборе людей в команду опираемся на концепцию Ответственного Исполнителя

Кто это такой?
Если коротко, то это коллега, которому можно поставить задачу и забыть. Но она будет сделана вовремя и качественно.

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

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

С позиции автора задачи это выглядит как управление в Делегирующем стиле Ситуационного лидерства:
- не надо напоминать коллеге про задачу
- не надо заново объяснять задачу
- не надо делать много замечаний
- не надо переделывать работу самому

Салют!

А вот напоминаю / делюсь с новоприбывшими, что есть система навигации по каналу и материалам в нем (как авторским, так и просто рекомендованным): https://gerych.notion.site/bf26ef9770d64637a401a33d086c58a9?v=56b48289ae3d48dc9725059553dbc414

Говорят, довольно удобно 😊

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

https://shesterov.by/tpost/2po262c8v1-it-biznes-analiz-obschii-protsess

Немного про переходные требования и наводящие вопросы: https://www.batimes.com/articles/transition-requirements-the-key-to-adoption/

Букв по ссылке много, но, надеюсь, они полезны 😊
https://shesterov.by/tpost/vfyu7vu3f1-biznes-analiz-analiz-tekuschei-situatsii

Интересная заметка на тему точек роста: https://medium.com/business-architected/5-reasons-you-are-not-getting-promoted-as-a-business-analyst-4159010763b4
Я бы добавил, что на мой взгляд две ключевые вещи, которые определяют рост специалиста, это базовые софт скиллы (прокачка ответственности, проактивности, самоорганизации, коммуникативных навыков, аналитичности) и опыт, и обе важны. Есть, например, курсы, которые обещают сделать mid-аналитика с нуля за три-четыре месяца, что как бы бред - продакшн-опыт в контексте учёбы практически нереально получить.

Пара интересных заметок:

A Fool with a Tool Is an Amplified Fool (https://medium.com/analysts-corner/a-fool-with-a-tool-is-an-amplified-fool-140cd9124ad4) — дядюшка Карл рефлексирует на тему осмысленного применения инструментов и техник.

How To Manage Dangerous Actions In User Interfaces (https://www.smashingmagazine.com/2024/09/how-manage-dangerous-actions-user-interfaces/) — отличная подборка подходов для UI по оформлению важных действий.

Снова буквы подъехали 🙂

https://shesterov.by/tpost/9spcjb2mm1-biznes-analiz-opredelenie-buduschego-sos

В заметке затрагиваются Lean Canvas, Business Objectives Model, бизнес-требования, критерии успеха и бизнес-риски, плюс в целом то, на кой это все нужно и чем может нанести непоправимую пользу.

Любопытный конспект. Чтобы булки не подгорели, подсвечу сразу конец: автор утверждает, что это шутка 🤷‍♂

Написал супер-краткий конспект книги Вигерса. А то тут ходит конспект на 70 страниц, и люди просят краткое изложение краткого конспекта. Итак, специально для тех, у кого нет времени читать ни 700, ни 70 страниц, циничный конспект:

Часть I. Требования к ПО
* Схема на стр. 7. Уровни требований. В реальности вы будете разрабатывать только функциональные требования. Можно почитать стр. 8 и 9, там расшифровка текстом (8 — бизнес-требования и юзер-стори, 9 — функциональные).
Рис. 1-4 на стр. 16 — показано, какие есть этапы в работе над требованиями. Перевод диаграммы очень плохой, приведу свой:

Инженерия требований состоит из разработки требований и управления требованиями. Разработка требований состоит из этапов выявления, анализа, спецификации и валидации.

Прочтите расшифровку диаграммы на стр. 17, если что-то непонятно.

Стр. 42-46 — плач о согласовании требований. Совет Вигерса про участников, которые морозятся, на стр. 45, оцените его применимость:

В позитивном ключе упомяните, что вы в курсе, что они пока не одобрили требования, но проект движется вперед с этими требованиями в качестве базовых, чтобы не задерживать работу. Сообщите им, что если они хотят что-то изменить, для этого есть соответствующий процесс. В сущности, вы действуете так, как будто заинтересованное лицо согласилось с требованиями, but you’re managing the communications closely.

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

Часть II. Разработка требований.
* Бизнес-цели, концепция продукта — никого не интересует, почти никто не пишет.
* Границы проекта. У проекта должны быть границы. Есть что-то, чего мы делать точно не будем. Контекстную диаграмму на стр. 104 никогда не рисуют.
* Классы пользователей — скорее всего, у вашей системы один класс пользователей — ваши пользователи. Или ваш продакт оунер.
* Методы выявления требований — реально вы будете делать только интервью. Стр. 138, цитирую: установите контакт, следите за границами проекта, заранее подготовьте вопросы и предварительные модели, предлагайте идеи, слушайте активно.
* Поиск упущенных требований — стр. 136.
* Варианты использования — разве их где-то ещё пишут? Если не пишете — пропускаете. Или читаете стр. 171-193.
* Бизнес-правила — разве их когда-то вообще писали? И вы не будете. Пропускаете. Ну или читаете главу 9.

Шаблон SRS — единственное, что вам нужно из этой части. стр. 223-234.

* Критерии качественных требований — забейте, это никого не волнует и никто не проверяет.

Формулирование и проверка полноты требований, стр. 243-254. Ну тоже полезно.

* Моделирование, гл. 12. Много разных диаграмм. Реально вам нужна только Sequence Diagram. Но у Вигерса она не описана, ищите где-то ещё.
* Требования к данным, гл. 13 — вам это не нужно. Максимум, нужно понимать, как составлять JSONы, но этого у Вигерса тоже нет.
* Атрибуты качества ПО — гл. 14. Это "нефункциональные требования". Если вы их не пишете — можно пропустить.
* Прототипирование — скорее всего, его у вас нет. Пропускаете.
* Приоритеты, гл. 16. Любопытно, но скорее всего у вас приоритеты требований назначаются по принципу "кто ближе к руководству" и "кто громче всех кричит на совещаниях".
* Рецензирование, в гл. 17 — ну, почитайте, если оно у вас есть. Это скорее для лидов.
* Повторное использование требований, гл. 18. Не бывает.

ЧАСТЬ III. Всё то же самое, но для отдельных видов проектов. Найдите свой.

Часть IV. Управление требованиями . Вы реально ведёте учет разных версий требований, отслеживаете изменения, состояния и связи требований? Или просто пишете один раз документ, отдаете его, и потом никогда его не переделываете? Если так — можно пропустить.

Часть V — забейте. Риски вообще никто никогда не анализирует и не управляет.

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

Вот и всё, не благодарите.

(Если что, это шутка. Но в каждой шутке, как мы знаем, есть доля истины...)

Про скоуп крип и то, как с ним драться: https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/6617/Navigating-the-Treacherous-Waters-of-Scope-Creep-in-Big-Rock-Projects.aspx
Для читавших Вигерса (лучше в масштабе книжки, а не конспекта), ничего нового, но в целом это хороший чеклист для вспомнить, что не стоит упускать. Довольно частая проектная проблема, и как-то даже странно, что многие наступают на эти грабли, хотя решения не то, чтобы сложные.

Салют всем! Ещё одна подборка интересных заметок из сети:

https://medium.com/publishous/how-to-solve-almost-any-problem-with-the-pyramid-principle-b1aeb72eecf6 (How to Solve Almost Any Problem With the Pyramid Principle) - в бизнес-анализе этот нехитрый подход затрагивает problem-solving skills и прослеживается в бизнес-целях и критериях успеха (об этом я писал тут: https://shesterov.by/tpost/2a6p6fv8l1-strategicheskii-analiz-discovery-i-visio ) и в Impact Mapping (https://shesterov.by/tpost/fzh1lezxp1-impact-map-i-user-story-map-kak-bistro-i).

https://medium.com/analysts-corner/the-best-response-to-any-request-for-an-estimate-ed97096a63ae - Карл Вигерс о том, как давать оценки на работы. Полезные советы о том, что стоит брать паузы перед тем, как давать такую информацию, какие факторы учитывать и чем интервалы предпочтительнее фиксированных значений.

https://medium.com/womenintechnology/master-the-art-of-getting-hired-your-ultimate-guide-8448ffdcb644 (Master the Art of Getting Hired: Your Ultimate Guide) - хорошие олдскульные советы о том, как подходить к поиску работы.

Для тех, кто скучал по расширению кругозора, очередная подборка, трямс:

Why I Spend Most of My Time on Defining Reuiqmrents. And How to Do It (орфография автора сохранена): https://medium.com/@eiki1212/why-i-spend-most-of-my-time-on-defining-reuiqmrents-and-how-to-do-it-bdf8861e1045

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

Кстати, недавно в соседнем чатике была очередная дискуссия на тему use cases vs user stories с рядом странных комментов. Кому интересно, вот старенький пост об этом: https://t.me/itmineba/30, https://t.me/itmineba/31, https://t.me/itmineba/32

https://www.linkedin.com/posts/patrickgiwa_business-analyst-vs-product-owner-vs-product-activity-7257421017759805440-HKgC — классный шортрид о PO vs PdM vs BA.

Building Customer-Centric Products with Design Thinking + Templates: https://medium.com/analysts-corner/building-customer-centric-products-with-design-thinking-templates-aa5fb14245bf

Немного о подходе design thinking, но интерес в заметке представляет не он сам, а расшифровка техники Empathy Maps. Отличный подход даже для аналитика при работе с требованиями пользователей.

Пятничный лонгрид — самый длинный из всех, что тут были 🤷‍♂

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

Требования к ПО: что это, какими бывают и почему именно так — подробный гайд:

Часть 1: https://shesterov.by/tpost/uj7cn72vo1-trebovaniya-k-po-chto-eto-kakimi-bivayut

Часть 2: https://shesterov.by/tpost/7txuvphka1-trebovaniya-k-po-chto-eto-kakimi-bivayut

Часть 3: https://shesterov.by/tpost/ykuhybvrz1-trebovaniya-k-po-chto-eto-kakimi-bivayut 

Как обычно, рад любому фидбэку 🙏

Доброго дня 🙂

Добавляю рубрику "Полезные советы" в виде коротких или около того заметок. Ранее мы разбирали типовые ошибки в работе аналитика (кстати, они собраны вот тут: https://docs.google.com/spreadsheets/d/1R4yYvW9WC-cD21JgThQCg3So0SK1os2xkAOWd-rTZlw/edit — чтиво сильно полезное, приводит к росту з/п на 127% и непроизвольному скачку IQ). Теперь рассмотрим другую сторону медали. По традиции постараюсь, чтобы интересно, небанально и практически юзабельно (никаких “мыши, станьте ежиками”).

И сразу первая заметка: требования к внешним интерфейсам.

Контекст, в котором нам нужно жить:

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

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

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

Если же полезный инпут сходу собрать сложно (”а хз, что нам надо — надо смотреть на то, что можешь предложить”), запросто берем шаблон из этой заметки.

2) Чеклист, который в среднем по больнице отлично подходит для этой задачи:
2.1) Что за внешние интерфейсы у нас есть (с чем решению нужно взаимодействовать)?
2.2) Каковы точки взаимодействия с каждым из них:
- методы API, которые нужно использовать
- описание обращения к ним в поведенческих требованиях
2.3) Как нужно общаться в рамках каждой точки взаимодействия:
- маппинг данных между данными решения и запросом/ответом для сторонней системы
- алгоритмы преобразования этих данных в процессе (если актуально)
2.4) Реакция системы на нестандартные ситуации:
- недоступность интерфейса
- отсутствующая информация в ответах
- ошибки, присылаемые внешней системой в ответах