Аналитик VS продакт, QA, дизайнер

Подборка состоит из нескольких высказываний о взаимодействии аналитиков с представителями других ролей

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

Часто захожу на территорию UX-исследователей, потому что получила навыки проведения пользовательских исследований. На территорию владельца продукта, потому что имею релевантный опыт. Мне приходится заходить еще на территории дизайнера, скрам-мастера и СА. Это возможно до тех пор пока туда пускают. Готова передать задачи смежных областей, тем, для кого они основные. А как у вас складываются отношения с другими ролями?

🎥ПРОДАКТ VS АНАЛИТИК: Зачем нужен аналитик? | Согласен / Не согласен
Чуть меньше 20 мин продакт и аналитик обсуждают взаимодействие своих ролей и стереотипы, которые с этим связаны: про зоны ответственности, кто виноват при провальном запуске и нужен ли аналитик. Мне понравились честные высказывания, которые вполне бьются и с моим опытом.

🗞Взгляд на бизнес-аналитиков со стороны QA
Давняя статья в формате интервью. Lead QA Engineer отвечает на довольно разрозненные вопросы о своей работе и в том числе на вопрос "Что при взаимодействии с бизнес-аналитиками тебя раздражает больше всего?"

🗞Аналитик VS разработчик: как делить задачи без конфликтов
Опыт системного аналитика, который зашел на территорию разработчика. Может быть полезно как одна из точек зрения

🎥Аналитики и тестировщики: что тестирование ожидает от аналитика
Блиц-доклад (20 мин) на Analyst Days #12. Спикер рассказывает о своем опыте временного перехода в роль аналитика и какие выводы из этого сделаны. Как это часто бывает, интересно послушать вопросы из зала

🎥Не убейте друг друга до конца спринта!
Секционный доклад на Analyst Days #16 (40 мин) о взаимодействии системного аналитика и UX дизайнера в одной из задач. Спикеров двое – аналитик и дизайнер. Понравилось описание взаимодействия от каждой из сторон. Аналитик по привычке проектирует полный интерфейс и ожидает от дизайнера, что тот просто "нарисует красиво". Дизайнер видит важную часть своей работы в сборе требований пользователей и проектировании пользовательского пути. Спикеры рассказали о своем опыте совместной работы

#что_почитать #карьера

Моделирование интерфейсов пользователя, инструменты

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

📍Бумага Нет, это не название редактора. Иногда проще нарисовать маркером на листе, если вы проводите встречу в переговорке и несложная картинка нужна для обсуждения
📍Excel Встречала умельцев рисовать диаграммы через функционал фигур Excel и умельцев делать интерактивные фомы ввода, чтобы показать порядок полей и правила валидации. "По сути это среда, которая позволяет не только хранить данные, выполнять расчеты и строить пользовательский интерфейс, это также среда, которая позволяет программировать", цитата из книги И. Корнипаева "Требования для программного обеспечения: рекомендации по сбору и документированию". Я не делала прототипов на VBA, а просто показывала фомы ввода, задавая лейблы, границы ячеек и правила для данных в ячейках.
📍Draw.io В этой рисовалке из геометрических фигур можно собрать вайрфрейм. Использую время от времени этот инструмент, потому что всегда под рукой. С тем же результатом можно использовать Miro, Lucidchart, Balsamiq, Escalidraw, Arti или MS Visio

После знакомства с графическими редакторами использую их для задач по визуализации, потому что возможности покрывают все, что может понадобиться. Не посоветую аналитику делать сложный прототип в графическом редакторе, если результат нужен быстро, а у него ни редактора под рукой, ни навыков работы в нем. Об этом подробнее было тут
📍Figma Известный графический редактор, в котором можно построить что угодно. Если в вашем приложении принята открытая или собственная дизайн-система, то аналитик может искать идеи в готовых примерах или собирать мок-апы из готовых компонент. Вот, например, в Figma Community Material Design Kit, Figma UI kit
📍Pixso Почти полный клон Figma. Есть бесплатная версия, платные тарифы дешевле Figma. Из всеми замеченных минусов – проблемы с быстродействием. Использую для тех же целей и тем же образом, что и Figma

Еще об инструментах проектирования интерфейсов
🔅Выбираем инструмент проектирования интерфейсов для аналитика В статье сравнивается несколько популярных инструментов для создания вайрфреймов
🔅Игра «Что, где, когда» с вайрфреймами, мокапами и прототипами Доклад на Analyst Days-11 о том, с какими прототипами работают аналитики на проектах мобильной разработки
🔅Что делать если отключат Figma? Есть ли альтернативы? Статья, где автор сравнил несколько графических редакторов

#инструменты #что_почитать

Подборка про варианты использования

Вариант использования (Use Case) многие выбирают как инструмент описания функциональных требований. Аналитики его встроили в гибкие методологии, несмотря на появление пользовательских историй (User Story). Сложно отказаться от понятных пошаговых описаний, правда? Учитывая почтенный возраст и популярность этой техники, материалов много. В этой подборке несколько разных рекомендаций и точек зрения

📍Use Cases. Что это такое и зачем они нужны? В этой статье есть не только базовое описание, но и рассуждения о пользе вариантов использования для разных ролей: тестировщика, продакта, проджекта

📍Как сделать удобный продукт: на примерах разбираем критерии хорошего Use case в статье точка зрения дизайнеров и продактов на вариант использования и критерии его качества

🎥Use Cases / Варианты Использования. Разбор вопросов и примеров диаграмм и описания (YouTube) подкаст Александра Байкина с участием Михаила Максимова, Александра Белина и Вадима Кривенцова. Два часа интересного разговора, где затронуты очень разные вопросы от "что такое Use Case?" до "как из этого сделать Test Case?"

📍Use Cases and Scenarios - A Comprehensive Guide (ENG) в статье приведено базовое описание варианта использования как техники, перечисление атрибутов варианта использования и пример табличного оформления. Интересно посмотреть пример с точки зрения "как люди делают"

🎥Use case или User story? Хватит выбирать - даешь все и сразу (Дзен) Доклад Михаила Максимова на Analyst Days-13. Сорок минут рассказа о вариантах использования для описания функциональных требований. Доклад для тех, кто уже хорошо знаком с техникой Use Case

#инструменты #что_почитать

Техники оценки задач

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

При вызове такси приложение пишет, что поездка займет 30 мин, а когда по факту получается 20, у клиента появляется ощущение удачно решенной задачи. До исполнения задачи клиенту показали маршрут и время выполнения, никто не обещал доехать за 10 мин. Аналитику тоже будет проще объяснить затраты, если показать маршрут и прогноз времени выполнения задачи.

В моем опыте вопрос "сколько нужно времени на анализ" часто даже не звучит, приходится слышать "надо побыстрее" или "мы оценили всю разработку в Х часов, неужели не хватит на анализ?". Поэтому в роли аналитика полезно оценивать задачи даже если никто об этом не просит. Это важно, чтобы управлять ожиданиями команды и не попасться на манипуляциях с оценками. Можно договориться об уменьшении объема всей задачи или отдельных задач аналитика, если оценку нельзя пересчитать. При этом вспоминается импульсивный стиль менеджмента, при котором сложно договориться, но это уже другая история🤷‍♀️

Выбор метода оценки зависит от имеющихся данных, готовности заинтересованных сторон к разговору, времени на оценку.

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

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

Экспертная оценка (Rough Order of Magnitude, ROM) На основании исторических данных в команде, внешних данных от других команд, экспертного опыта дается оценка задачи. Применяется часто, но здесь главный недостаток в субъективности такой оценки. Скорее всего будет оценен вариант решения, как его понял эксперт, с учетом производительности работы этого конкретного эксперта, для другого исполнителя это может не сработать. Хорошо работает, когда вы сами оцениваете свою же задачу и не забываете учесть возможные риски

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

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

PERT (Program Evaluation Review Technique) или техника трех точек Метод предлагает разделить три сценария выполнения задачи: оптимистичный (O), наиболее вероятный (R), пессимистичный (P). Оценить каждый сценарий в отдельности. Итоговую оценку подсчитать как (O+4*R+P)\6

📚
A Business Analyst's Guide to Estimation Techniques (ENG ) в этом тексте самое ценное – разбор примеров для каждой из техник, что я перечислила выше

Requirements Estimation: How to Create a Business Analyst Timeline (ENG) живой рассказ о том, какие шаги автор блога рекомендует, если к вам пришел менеджер с очередной срочной задачей и спрашивает сколько времени вам на не нужно

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

#инструменты #что_почитать

Летние публикации на этом канале

Подсмотрела у другого автора подсчет оставшихся недель лета. Их оказалось всего две. Уверена, вы не скучали все предыдущие недели лета и оставшиеся две проведете с пользой☀️

Я немного выпадала из этого канала на работу и поездки. Впервые побывала в Нижнем и впервые в Петрозаводске. Тем не менее тут и на Дзен собралось несколько статей:

🔅Гантт, Адамецкий и PlantUml
🔅Подборка докладов с конференций 2024
🔅Аналитик VS продакт, QA, дизайнер
🔅Моделирование интерфейсов пользователя, инструменты
🔅История про детство и компьютер

По тегу #навигация можно найти подборки материалов этого канала. Я начинаю понимать преподавателей, которые советуют студентам свои собственные статьи и методички. По крайней мере я точно уверена, что там написано что-то с чем я согласна 🌱

Как же называется эта книга?
Рэймонд М. Смаллиан. Год издания 2021

Открыла вчера эту книгу. Оригинал относится к 1978му году, первый перевод вышел тремя годами позже, а мне попалось издание 2021 года. Это сборник логических задачек с вводными от автора и детальным разбором решений. Задачи идут от простых бытовых к более сложным логическим комбинациям. Каждый раздел в своем контексте и объединяет задачи на конкретную тему и конкретное логическое правило. Я прошла пока только часть:

📍"Головоломки и дурацкие штучки", где собраны логические заморочки на бытовом уровне. Например: Что произойдет, если всесокрушающее ядро попадет в несокрушимый столб?
📍"Рыцари и лжецы", где рыцари всегда говорят правду, а лжецы всегда врут
📍"Алиса в лесу Забывчивости", где живут львы и единороги, которые врут или говорят правду в конкретные дни недели
📍"Из записок инспектора Крэга" с задачками про расследование преступлений. Одну такую задачку напишу ниже, вы пока подумайте, а я дочитаю и завтра напишу ответ в комментариях 😉

Еще есть задачки про оборотней, зомби и других персонажей. По сложности фантазий напоминает книгу Льюиса Кэррола "Алиса в стране чудес"


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

Я еще не добралась до последних глав, но с удовольствием залипла на задачках средней сложности. Узнала слово "импликация" – это зависимости вида "Если P, то Q".

Кому может быть полезно?
Думаю, что полезно всем, кому интересно потренировать логическое мышление.

#книжки

Что важно для выявления требований?

В выходные прочитала пару постов и статей о сборе\выявлении требований. Столько уже придумано гайдов и фреймворков о том как разговаривать с пользователем, чтобы все выявить! А почему-то не гаснут дискуссии на тему «я все сделал как надо, а они все равно недовольны и меняют требования». Неужели фреймворки не работают? Скорее всего работают, но только для каждого важен свой контекст и точка зрения.

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

1️⃣«Знать, а казаться незнающим, — вот совершенство. Не знать, а думать, что знаешь — это болезнь.» Набрела недавно на эту цитату из даосского философского трактата «Дао Дэ Цзин» и формулировки сложились сами собой. Как часто вы идете на встречу с живым желанием услышать что-то новое, а не подтвердить услышанное или выведенное из вашего опыта? Можно пропустить большой пласт информации, если не убрать далеко в сторону кем-то навязанные знания или предварительные выводы.

Например, вы слышите на интервью, что кнопка неудобно расположена, а в голове прокручиваете "ну да, предыдущий аналитик предупреждал, что у них куча капризов" или "это исправлять сложно, так что пойдем дальше". Можно на минуту притвориться, что у вас нет этого знания, и просто спросить "А зачем вы ее нажимаете вообще? Зачем каждый раз так делаете, если неудобно?". Можно узнать, что дело в нелогичном переходе с предыдущей формы, а вовсе не с этой кнопкой, которую сложно подвинуть. И тут мы переходим к следующему пункту.

2️⃣Пользователь может не осознавать того, что мы называем требованиями. Мне нравится как это сказано в книге Синди Альварес «Как создать продукт, который купят»

Ваш потребитель лучше всех знает, что мешает ему в его собственном мире. Но это не значит, что он может облечь свое знание в слова.

Глядя на мир из-под опыта построения ИТ-систем, мы часто ждем формулировок в привычной логике и не получаем их или, что еще хуже, получаем что-то что звучит для нас убедительно, но ничего не значит для говорящего. Он просто сказал что-то, что от него ждут, или придумал налету.

На меня когда-то большое впечатление произвело как Алан Купер определил группу уцелевших пользователей

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

Это фраза из 90х, но и в контексте сегодняшнего дня тоже встречается что-то подобное.

3️⃣Не получится узнать готовый ответ на все вопросы, нужно на основании полученной информации моделировать кейсы и приходить к собственным выводам. Гибкие методологии диктуют нам культуру обратной связи и мы начали ее собирать с ожиданием ответов на многие вопросы. Знать своего пользователя очень полезно, но целью активности должно быть прежде всего наблюдение и сбор информации, а не получение готовых рецептов. Часть требований вы сформулируете сами, на основании моделей, что сможете построить. Хотя и модели, бывает, врут 😊

📚
🔅Что здесь есть о выявлении требований? подборка постов об инструментах выявления требований на этом канале
🔅«Да», «Нет» и «Зачем» не говорить? подборка статей про важность отдельных слов и вопроса "Зачем?"

#мысливслух #что_почитать

Зачем ИТ-аналитикам CJM ?

Когда принялась за пост о CJM, то поняла, что не стану рассказывать как и зачем составляется карта клиентского пути. Это фреймворк, о котором никто не расскажет лучше, чем эксперты в CХ и UX, ниже несколько ссылок с теорией и примерами, которые будут полезны, если вы еще не сталкивались с этим инструментом.

По слову CJM на hh нашлось около тысячи вакансий, из которых 369 отнесены к сфере ИТ. Я познакомилась с этой картой на курсе управления клиентским опытом. Картинка с кучей скриншотов и стикеров – это снимок моего тогдашнего учебного проекта. Когда послушаешь мастеров-исследователей, которые глубоко разбирают мотивацию клиентов, исходя из законов социологии и психологии, то невольно думаешь, а бизнес и системным аналитикам это точно нужно? Прихожу к выводу, что понимание фреймворка точно не повредит и даст некоторое преимущество на рынке труда, но без четкого понимания зачем применяете, ни один инструмент не будет полезным и этот не исключение.

У любого раскрученного фреймворка основной проблемой становится применение "потому что модно", а не потому, что нужно. Кажется, что чем больше и красивее карта, тем полезнее. На деле получается, что карта внушительная, но непонятно, что делать дальше? Нашли какие-то идеи, записали, а сам процесс изменений клиентского пути так и не начался.

CJM – это таблица или ориентированный граф, отражающий путь потребителя между точками контакта. Мне как-то задали вопрос: Если это такая упорядоченная форма клиентского опыта, то можно же построить автоматическое формирование тест-кейсов на ее основе? Увы, это очень эмоциональный инструмент, каждая команда формирует под свои цели и своим языком. Автоматизация потребуется более сложная, чем if A is not EMPTY do B.

Я применяю CJM при исследовании предметной области или при знакомстве с новой для меня группой пользователей, чтобы упорядочить записи с полученной информацией и соображения относительно узких мест. Команды обычно реагируют на мои записи так: "Ух, как красиво! Но букв много и непонятно, что с ними делать." Так что это просто мой рабочий инструмент, который
🌱помогает мне разложить на шаги пользовательский путь,
🌱рассмотреть каждый шаг детально по слоям, заданным картой,
🌱зафиксировать идеи, чтобы вернуться к ним при выборе функционального решения.
Если составление карты не требуют как часть проектных артефактов (что в моем опыте бывало буквально один раз), то она остается частью моих рабочих материалов. Интересно, а ваших командах бывает нужно составить CJM?

📚
📍CJM: теория и примеры В статье есть примеры, составленные автором для S7, Ашана и Делимобиль. Все примеры в Миро, так что поспешите посмотреть 😉
📍Большое клиентское путешествие Описание основ и целей фреймворка
📍Что такое CJM: на примере покупки «теслы» В статье есть ссылки на примеры карт для Яндекс.Такси и для Самоката

#что_почитать #инструменты

Учебный год и офферы

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

Где-то в семейном архиве есть фото пятидесятилетней давности. На нем десяток широкоплечих парней лет 19ти, с длинными прическами по моде 70х, в брюках-клеш и клетчатых рубашках позируют на фоне доски, у учительского стола. Среди них худенькая застенчивая девушка - преподаватель математики выпускного курса ПТУ, моя мама. В свои двадцать с небольшим она - Ольга Петровна для этих вот парней, среди которых встречались и условно осужденные.

Еще есть фото, где мой отец - молодой преподаватель, у доски внушает студенткам педагогического института что-то из мат.анализа. Студентки улыбчиво смотрят в объектив, потому что снимок это надолго, а с мат. анализом еще непонятно. И только преподаватель серьезно хмурится на свои меловые зарисовки на доске.

Когда-то коробка с мелом стояла дома в прихожей. Мне из нее нельзя было взять мелок, потому что этот мел для записи линейных многочленов на доске, а не для рисования легкомысленных зайцев на асфальте 🐇 Это когда в 90е в университете даже мел куда-то делся, на лекции брался свой.

В 80х в некоторых семьях на дверце холодильника хранились лекарства или даже конфеты, а в преподавательской семье там были лента для пишущей машинки и пузырек спирта. Папа пишет диссертацию, а ее надо писать буквами на пишущей машинке. Чешской рыже-белой капризной красавице нужно буквы протирать спиртом и заправлять хорошую чернильную ленту, чтобы эти буквы потом можно было прочитать. Такие ценные вещи держат в холодильнике, потому что если лента засохнет, а спирт испарится, то научная мысль может иссякнуть.

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

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

День знаний у каждого свой и в свое время, я это и по семейным архивам знаю и по личному опыту 🌱

#мысливслух #истории

Функциональная декомпозиция

В работе аналитика функциональная декомпозиция выглядит чем-то очень базовым и от этого еще интереснее о ней порассуждать.

Строго говоря, декомпозировать можно не только функции, но и процессы, цели, задачи, роли, компоненты ИТ-архитектуры, источники и результаты работы системы. Аналитики чаще всего имеют дело с функциями. С них обычно начинается любой разговор о будущей системе: "Нам нужно, чтобы система умела....."

Вот такая рекомендация есть в книге "Принципы работы с требованиями к программному обеспечению" Дина Леффингуэлла и Дона Уидрига

Количество функций, которое мы позволяем себе рассматривать, будет существенно влиять на уровень абстракции определения. Для того чтобы справиться со сложностью разрабатываемой системы, мы рекомендуем описывать возможности каждой новой системы или дополнения к уже существующей системе как можно более абстрактно, чтобы в результате получить не более 25-99 функций, причем желательно, чтобы их число не превышало 50.

Как не запутаться в таком количестве функций? Постепенно двигаться от высокого уровня абстракции к более детальному, то есть разбирая каждую функцию на составляющие до того уровня, которым будет проще управлять. Количество уровней зависит от объема и сложности задачи. Для небольших задач достаточно глубины в 2-3 уровня, для сложных потребуется больше.

Как это поможет? Разбирая сложное на небольшие измеримые части можно добраться до детального понимания, отследить как связаны между собой эти части и найти точки улучшения.
📍Это помогает выявлять и документировать требования по четкой структуре, соответственно декомпозиции.
📍Обозримая упорядоченная структура помогает понять объем задачи или изменений. Так проще заметить разрастание объема и не потерять фокус на основных целях.
📍Измеримым под-функциям проще определить приоритет и запланировать затраты на разработку.
📍При обсуждениях проще выстроить общее понимание сложной системы, если разделить составляющие на более простые части.

Было бы нечестно промолчать про ограничения:
▫️За декомпозиций функций можно упустить другие важные вещи: потоки данных или взаимодействие пользователей. Узкий взгляд именно на функции приводит к потере других важных составляющих системы. Я здесь под "системой" имею в виду именно совокупность взаимодействующих объектов, не обязательно автоматизацию.
▫️Декомпозиция часто основана на предположениях о процессах и связях между функциями. Предположения могут быть ошибочными, в результате вместо прозрачности и упрощения привести к путанице и непониманию.
▫️При функциональной декомпозиции остаются без внимания нефункциональные требования, о которых важно не забыть.

Каждый сложный объект допускает несколько альтернативных декомпозиций. Исследование всех альтернатив может быть сложной и трудоемкой задачей, тогда как выбор единственной альтернативы может игнорировать важные возможности и привести к неоптимальному решению (Из BABOK 3.0)

▫️Для сложных систем иерархия функций может оказаться многоуровневой и содержать непростые зависимости между разными уровнями. Обратите внимание, на картинке дерево функций (Feature tree) из статьи К. Вигерса Using Feature Trees To Depict Scope. Здесь всего три уровня, но выглядит ли картина простой?

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

P.S. В этом контексте вспомнила давний обзор статьи о масштабируемой структуре требований, там есть пример декомпозиции в формате mind map.

#инструменты

3 статьи про коммуникации. Подборка

Заглянула в свой расползающийся список для чтения. Я придирчивый читатель, из десятка статей на темы коммуникации с заинтересованными сторонами выбрала три, которые на мой взгляд могут быть полезными.

📍Как провести встречу по сбору требований и не провалиться В этой статье мне очень понравилась первая часть рекомендаций к сбору информации перед встречей. Дальше рекомендации по составлению повестки встречи и фиксации результатов, которые вряд ли удивят аналитиков с опытом

📍Эффективное управление отношениями со стейкхолдерами Это перевод статьи из блога Miro, похоже на инструкцию, где перечислены основные инструменты управления заинтересованными сторонами

📍Берем ответственность за вопросы: как задавать их правильно Статья о роли вопросов в коммуникации, еще в ней есть описание методов "5 почему" и "Score+", может быть интересно, если еще не сталкивались с этими методами

#что_почитать

ИТ инсайды

Собрались вместе с другими авторами в папку "ИТ инсайды". В ней 9 каналов.

Ребята рассказывают очень ярко и эмоционально про свою работу, про тренды в ИТ, про PR, безу и менеджмент.
А еще, про СА и БА, GO, фронтенд и, конечно, AI. И, периодически, делают обзоры с крупнейших ИТ конференций.

Перейти к папке "ИТ инсайды"