Мы в 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) Реакция системы на нестандартные ситуации:
- недоступность интерфейса
- отсутствующая информация в ответах
- ошибки, присылаемые внешней системой в ответах

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