Про_БА

Нотации моделирования бизнес-процессов

В своих списках для чтения подобрала несколько статей о нотациях моделирования. Здесь оказались детальные статьи и обзоры о разных нотациях:
▫️VAD (value added chain diagram),
▫️EPC (event-driven process chain),
▫️BPMN (Business Process Model and Notation 2.0),
▫️Flow Charting,
▫️IDEF (Integrated Definition Language),
▫️VSM (Value Stream Mapping),
▫️SIPOC (Supplier, Input, Process, Output, Customer)

📍Моделирование бизнес-процессов – обзор нотаций Обзор восьми нотаций: VAD, EPC, BPMN, Flow Charting, IDEF, VSM, SIPOC

🎥Нотация BPMN: как оптимизировать процесс подбора сотрудников Видео, где моделирование и выявление точек оптимизации показывает Алексей Коптелов, вице-президент ассоциации процессных аналитиков

📍Один пример и три нотации: сравниваем BPMN, EPC и DMN Эта статья в базе знаний Systems.Education интересна четкой структурой, примерами и развернутым резюме по выбору нотаций

📍Карта потоков создания ценности (Value Stream Mapping) Пост в этом канале с рекомендациями по созданию VSM

📍IDEF, EPC и BPMN: как выбрать нотацию для моделирования бизнес-процессов Еще один обзор трех нотаций с примерами

📍5 ошибок при проектировании бизнес-процессов и как их избежать В статье перечислены типовые промахи при работе с процессом. Если честно, то сначала хотела пройти мимо этой статьи, но решила, что статья может пригодиться начинающим

📍Основные нотации моделирования бизнес процессов и их применение Обзорная статья по нескольким нотациям, формат ознакомительный "обо всем понемногу"

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

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

Помните первый букварь?

Почему-то в День знаний больше тянет делиться эмоциями, чем знаниями. Я даже попросила родителей отсканировать мое первое школьное фото.

Здесь модели 6 лет, и она вся еще в летнем настроении. Воротничок съехал, челку пришлось заколоть, волосы выгорели на солнце - вообще непонятно, как там бант держится.

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

А манжеты? А фартук? Я запомнила это всё довольно неудобным, но важным атрибутом ответственного, состоявшегося человечка. Уже в конце сентября я с гордой усталостью труженика говорила приятелям по двору: «Некогда мне тут с вами, мне ещё дневник заполнять, манжеты пришивать и фартук гладить».

Обратите внимание: на обложке букваря тоже персонаж в почти таком же белом фартуке. Уверена, что не только у меня сохранилось фото с этой обложкой, где большая буква «А» на синем фоне 🙂 Это учебник под редакцией А. Горецкого, по которому все учились в конце 80-х. В нём были яркие картинки, ребусы и разбор по слогам «Ма-ма мы-ла ра-му».

К нему прилагались прописи с красной обложкой, в которых нужно было писать буквы красиво и с правильным наклоном.

Когда я пошла в школу, я уже умела читать, на уроках слегка скучала. Вот только первыми оценками были двойки. Потому что читать и писать нужно было не как хочешь, а по строгим правилам.

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

Кто-то хранит до сих пор свои шедевры с уроков труда?

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

Если вы сегодня как-то причастны к празднику — я вас искренне поздравляю и даже немного завидую 🙂

А всем нам, непричастным, пожелаю новых учебных целей на ближайший год. Когда ещё планировать учебу, как не в понедельник 1 сентября?

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

Искусство говорить «нет» в работе аналитика

Знакомый диалог?
- Задач на 24 часа в сутках, а тут еще одна срочная!
- Заказчик подкинул новую фичу. Когда, простите, этим заниматься?

Нужно магическое слово «Нет». Не истеричное «Нет, я и это должен делать по-вашему?» или «Cил нет!». Обоснованное «Нет», за которым стоит стратегия, не просто эмоция.

Впервые человек учится говорить «нет» в возрасте 2-3 лет, когда осознает себя чем-то отдельным от папы и мамы. Тогда речь идет о прогулках, каше с комочками и игрушках. Когда игрушки сменяются дедлайнами и ответственность больше, приходится заново учиться говорить «нет». Вдруг обидится заказчик или начальник подумает, что я не командный игрок? Не проще ли согласиться?

Спокойный мотивированный отказ – суперсила взрослого профессионала, который осознает свои интересы. Как и всякая суперсила, она может сделать вас сложным игроком в команде, приходится выбирать 💁‍♀️

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

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

Новое требование может привести к необходимости пересогласовать бюджет и план закупок. Начальник экспедиции не является единственным владельцем бюджета. Его интересы могут пересекаться с интересами других участников. Например, судового кока, который уже придумал меню на весь период экспедиции. Не хватает информации о причине запроса. «Нет» или «Может быть» оставят вопрос нерешенным и, если причина запроса веская, она может стать барьером для всей задачи.

❓ Вариант 1. Отказ с опорой на регламент
Вы: У меня уже согласован план закупок, выбран поставщик, я не могу вносить изменения. Придется обратиться к руководству.
Начальник: То есть просто пойти к директору НИИ? (он пойдет к директору разбираться в ананасах. Этот вариант лучше оставить на случай, если без эскалации никак)

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

✅ Вариант 3. Выясняем контекст и находим «хотелку»
Начальник: Нужны ананасы!
Вы: Почему на ваш взгляд это важно?
Начальник: Ну это же очевидно! Все хотят ананасы! (подозрительная расплывчатость)
Вы: Мне будет проще предложить решение, если мы сможем обсудить контекст такой потребности. (не сдаемся)
Начальник: Моя тёща, она повар с 40-летним стажем, дала рецепт салата! Вы что, спорите с моей тёщей?!
Вы: Мне одинаково сложно спорить и с мнением опытного повара, и с уже согласованным планом закупок. Давайте посмотрим, какое меню согласовал судовой кок? (уклоняетесь от запроса и пытаетесь найти союзников со схожими интересами)

Что если завтра придет таможенник и прикажет вычеркнуть всю свежую рыбу из списка продуктов на борту? Поделитесь в комментариях своими идеями!

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

Карта потоков создания ценности (Value Stream Mapping)

Value Stream Mapping (VSM) - инструмент визуализации и оптимизации процессов. Хотя он разработан в рамках бережливого производства и чаще ассоциируется с продуктовым менеджментом, его применяют и аналитики, что подтверждается, например, Agile Extension к BABOK (откуда взята картинка к этому посту).

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

Главная цель карты - выявить потери и «узкие места». Например, анализируя процесс подготовки требований, можно определить, какой процент времени уходит на согласования и реакцию на входящие вопросы. Важно помнить, что сама по себе карта - только инструмент. Для реальных улучшений необходима мотивация команды и желание оптимизировать процесс.

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

Шаги для построения VSM:

📌Фокусировка и определение команды
▫️Выберите продукт, семейство продуктов или услугу и определите область действия карты потока создания ценности.
▫️Определите получаемую заказчиком ценность, чтобы можно было проследить её истоки.
▫️Соберите кросс-функциональную команду из людей со знаниями бизнес-домена и технических членов команды
▫️Определите владельца карты потока создания ценности из тех, кто имеет глубокое понимание текущего процесса.

📌Создание карты текущего состояния
▫️Определите производственный поток. Наблюдайте за потоком создания ценности или смоделируйте его. Agile Extention к BABOK советует проследить путь продукта, начав с шага, ближайшего к заказчику, и записать, двигаясь в обратном направлении к началу. Ход мысли может развиваться и от первой точки входа в процесс. Можно показать основные и вспомогательные операции двумя связанными последовательностями.
▫️Зафиксируйте поток информации, который жизненно важен для функционирования потока создания ценности. Поток информации включает такие вещи, как заказы, графики, время запасов, время переналадки, время цикла и количество задействованных операторов. Так получится коммуникационный поток в верхней части карты.
▫️Замерьте время. Для каждого шага запишите время обработки (Value-Added Time) и время ожидания (Non-Value-Added Time). Это позволит построить «временную линию» и увидеть общую продолжительность цикла.

📌Создание карты будущего состояния
▫️Определите области для улучшений. Шаги, не добавляющие ценности, являются источником потерь.
▫️Определите метрики улучшений. Основные метрики: полное время цикла(Lead Time, LT) – общее время выполнения шагов процесса, включая согласование, операции возврата, ожидание данных, материалов, объектов, исполнителей и прочих ресурсов; время обработки (Process Time, PT) – время непосредственного выполнения работы, дающей результат процесса, ценный для потребителя; доля работ, выполненных без ошибок (Percent Complete and Accurate, %C/A) - показывает, какой процент работы выполняется без ошибок и доработок.

VSM имеет свои ограничения:
▫️Без общего понимания и желания меняться карта останется просто красивой схемой.
▫️Может выглядеть пугающе из-за большого объема информации.
▫️Не подходит для исследовательских или нелинейных процессов.
▫️Легко увлечься созданием полной и идеальной карты вместо перехода к улучшениям.

📚Статьи о Value Stream Mapping
▫️Value Stream Mapping — инструкция к применению
▫️Value stream mapping как инструмент запуска изменений
▫️BABOK и Lean: строим карту потоков создания ценности для анализа бизнес-процессов
▫️Создание Value Stream Mapping

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

Языковой барьер, шпинат и другие риски бизнес-анализа

Когда-то я бодро говорила, что аналитик переводит с языка бизнеса на язык ИТ. Теперь считаю, что сбор и систематизация информации, выявление потребностей, моделирование предметной области – это точно не про дословный перевод. Хотя, как выяснилось, иногда приходится заниматься и им.

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

Логично же предположить, что когда на стороне заказчика все пишут по-немецки, на стороне исполнителя явно что-то не понимают. Решили организовать перевод исходного документа БТ с немецкого на английский, с последующим утверждением перевода на стороне заказчика. Тогда еще было не очень с машинным переводом. Я вызвалась на роль сервиса по переводу. Зря что ли три года учила немецкий? Интересный вызов. Заодно узнаю, что там на самом деле написано в этих требованиях.

Позже добавились командировки, чтобы мы улучшили контакт со стейкхолдерами. Хотя на немецком многие знали только "Хенде хох!"😊 Наша рабочая группа из менеджеров и аналитиков пару раз съездила в офис заказчика, где нас ждали не только требования, но и культурный шок от непривычного тогда формата офиса и еды.

В офисной столовой мы очень скучали по мясным блюдам. И когда один из коллег обнаружил на раздаче нечто котлетоподобное, мы дружно протянули тарелки, демонстрируя выдающиеся навыки невербальной коммуникации. Никто не удосужился прочитать табличку со словом "Spinat" (шпинат). Оказалось, мы сами не читаем ТЗ, а если не читаешь требования – получаешь не то, что ожидаешь.

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

С тех пор я не перевожу требования, хотя это и правда интересный вызов ☀️

#истории

Сколько техник BABOK используете? В этой подборке их 19

Решила провести аудит своих постов про #инструменты и сравнить с BABOK. Результат: 19 техник из 50 в этом канале упоминались. Кое-что полезное уже есть. Собрала все в один список. Буду рада, если пригодится! ☀️

📍Критерии приемки: Чем отличаются критерии приемки и DOD?
📍Управление бэклогом: Бэклог не может содержать все подряд
📍Бенчмаркинг: Как посмотреть, что делают другие?
📍Мозговой штурм: Мозговой штурм (brainstorm) работает или нет?
📍Decision Analysis: Как можно выбрать одно из двух зол?
📍Анализ процессов: Подборка примеров моделирования в BPMN
📍Оценка задач: Техники оценки задач
📍Фокус-группа: Для чего не годятся фокус-группы?
📍Функциональная декомпозиция: Функциональная декомпозиция
📍Глоссарий: Как это понимать?
📍Интервью: Про ошибки при проведении интервью с пользователями и Интервью на удаленке
📍Item Tracking: Трассировка требований. От хаоса к управляемости
📍Анализ нефункциональных требований: Нефункциональное
📍Приоритизация: Подборка про приоритеты
📍Прототипирование: Что такое прототипы и какими они бывают?
📍Опрос: Мифы о применении опросов при выявлении требований
📍Пользовательские истории: Может ли Agile-коуч писать плохие пользовательские истории?
📍Варианты использования: Подборка про варианты использования
📍Список и карта заинтересованных сторон: С кем важно говорить о требованиях на самом деле?

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

Не рычите на собаку
Карен Прайор, 1999

Эта книга попала в мой список чтения после нескольких семинаров по soft skills. Наконец я ее прочла. Где? Конечно, в поездке.

Мне встретился перевод 2014 года, но оригинал еще старше. О возрасте книги напомнила фраза "выпустили видеокассету".

Автор – биолог и дрессировщица животных. В книге исследования из зоопсихологии показаны на примере дрессировки животных и перенесены на людей. Главный посыл: наказывать неэффективно, работает вознаграждение за правильное поведение. Не нравится поведение? Игнорируйте, замещайте или привяжите к поведенческому маркеру, который постепенно перестанет поступать. Встретили желательное поведение? Подкрепляйте положительно – похвалой, едой, чем-то приятным. Это работает и с начальником, и с занудными родственниками, и с кошкой, считает автор.

Вспомнила как действовали мои бабушки. Одна из них как-то учила меня тактичному молчанию: "Ты не говори деду, что арбуз невкусный, а то больше не пойдет на рынок за арбузом". Так мы вместе игнорировали нежелательное поведение. Другая моя бабушка действовала хитрее, когда сначала моделировала желаемое поведение, а потом за него хвалила. Заметит, как я сорвалась в крик на своего ребенка и скажет: "Какая ты молодец, что не повышаешь голос на сына!" Бабушки понимали и применяли положительное подкрепление.

Что может быть полезно?
🔅Познакомиться с бихевиоризмом – направлением психологии, которое изучает поведение, а не только мысли и чувства. Закрепить или устранить можно только то поведение, которое проявляется. Не видите как ребенок моет руки, и похвалить за это не получится.
🔅Подумать, что не работает при наказаниях. Интересно наблюдать за ходом мысли автора, когда приводятся аргументы для объяснения почему плохо работает наказание за нежелательные поступки. Как наказание и факт поведения сложно связать друг с другом в понимании животного. Как чтобы решить вопрос, нужно разобраться в мотивации. Например, если собака грызёт мебель, важно выяснить причину (скука, стресс, недостаток физической активности), а не наказывать животное.
🔅Научиться поощрять себя за успехи. Когда учитесь чему-то сами хвалите себя за удачи, а не наказывайте за промахи очередными угрызениями совести. Если не получается какой-то прием (например, в теннисе), лучше переключиться на другой и, когда освоите, попробуйте вернуться к изучению прежнего.
🔅Подумать о природе творчества. Понравился пример, когда дельфинов поощряли за неожиданные выдумки и те стали креативными, но неуправляемыми – придумывали неожиданные прыжки или игры с предметами в расчете на поощрение. Вы без труда считаете похожее поведение у кого-то из коллег, которые всех раздражают 😊

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

Кому может быть полезно?
Начинающим тим-лидам, руководителям и преподавателям. Можно познакомиться с полезными идеями или просто убедиться, что ваша бабушка была права, когда не ругала деда за неудачную покупку 😎

#книжки

Подборка о том, как аналитику договариваться с ИИ

Можно подумать, что тема ИИ обошла стороной мои подборки. Как бы не так!

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

Я устала писать документацию — и научила AI делать это за меня Автор этой статьи – QA. Документация здесь – чек-листы и тест-кейсы, которые бывает скучно составлять. В статье честный рассказ о нескольких итерациях запросов к DeepSeek c определением правил и контекста для генерации более точного ответа. Есть высказывание, с которым я не согласилась. Говорят, результат будет лучше, если все запросы вести в одном окне чата. Это спорный момент. Не закрывайте чат, если ваш вопрос всегда в одном и том же контексте и стиле, но если сначала речь об окне регистрации в мобильном приложении, а потом о генерации отчета в pdf, то я бы начала разговор заново. Иначе на основании прежнего контекста можно получить неожиданный совет о генерации отчета в окне регистрации пользователя мобильного приложения.

AI Prompt Engineering for Business Analysts (EN) Пост в англоязычном блоге. Здесь о том как и для чего можно составить промпты для помощи БА. Как – итеративно, для чего – ускорить работу над рутиной и освободить время для более творческих задач. Здесь интереснее посмотреть примеры промптов.

Промт-инжиниринг для аналитиков по фреймворку КОМПОЗИТОР Авторский подход к составлению промптов, основанный на метафорах

Каталог ИИ-промтов по анализу и проектированию ИС Подборка промптов в базе знаний Школы Системного Анализа собрана в формате страничек в notion, к которым можно пройти по ссылке с основного лендинга

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

Трассировка требований. От хаоса к управляемости

Недавно мне пришлось обсуждать такой вопрос: есть 83 тест-кейса, видимо, уже неактуальных. Как в таком объеме понять откуда они взялись и оценить актуальность?

Чтобы понять как отвечать на такие вопросы, нужно вспомнить, что такое трассировка (traceability). Многие помнят, что это – систематическое отслеживание связей между артефактами. За этим прослеживается груда теории и скучной рутины, но непонятно как это работает. Почему так?

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

В BABOK есть хорошая классификация связей (в новый BAST перекочевало только общее описание). Выбирайте, что важно трассировать именно вам, чтобы не получать сумбурный набор ссылок.
🔅Следование - одно требование является производным от другого. Например, функциональное требование следует из бизнес-требования.
🔅Зависимость – одно требование зависит от другого. Например, невозможно реализовать поиск по списку, если не реализован сам список.
🔅Реализация/удовлетворение - связь между элементом реализации и требованиями, которым он удовлетворяет. Например, связь между функциональным требованием и компонентом решения, реализующим это требование.
🔅Проверка – определяет удовлетворяет ли решение требованию. Например, тест-кейс проверяет удовлетворяет ли решение функциональному требованию.

Как хорошо, что уже давно не нужно делать никаких таблиц с матрицами трассировки! Достаточно оставить ссылку в статье. Главное, сделать это вовремя и по заранее выбранным типам связей 😎

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

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

Нефункциональное

В выходные снова заглянула в отложенные статьи. Выбрала несколько статей о нефункциональных требованиях (НФТ). Уверена, что многие здесь сталкивались с формулированием требований к безопасности, производительности, совместимости, доступности и не только. Здесь несколько статей как раз об этом.

Требования безопасности: пособие для аналитика Эта статья пролежала в моем списке почти год, но от этого нисколько не потеряла в качестве 😉 Речь о том как формируются требования к безопасности информации, какие разные интересы при этом могут быть затронуты и как разные виды НФТ могут конфликтовать с требованиями безопасности. Понравилось, что разобран пример, рассказано о модели угроз и выставлении приоритетов требованиям безопасности.

НФТ к производительности: расчет нагрузки в rps на практическом примере Требования к производительности системы в большей степени влияют на выбор архитектурных решений. Как видно из названия – речь о том как рассчитать нагрузку в количестве запросов в секунду. Статья меня покорила детальностью и тем, что в ней не просто приведены схемы, но и их код в PlantUML.

(EN) Concept for the successful handling of integral NFRs in Scaled Agile Environments Статья о том, как обеспечивать выполнение нефункциональных требований, особенно требований безопасности, в agile-среде. Как согласовать работу множества команд (архитекторы, разработчики, тестировщики), когда нужно соблюсти НФТ и ничего не потерять в частых релизах? Речь снова о критериях приемки, DoR и DoD, может быть интересно, если вы неравнодушны к вопросам производственного процесса.

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

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

Недавно через несколько «рукопожатий» я познакомилась с командой, которая решила разработать плагин и превратить VSCode в удобную IDE для аналитиков. Их цель - охватить все этапы работы с требованиями, сократив время на документирование.

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

Как раз сегодня 18.07 в 18:00 пройдет сессия для аналитиков, где планируется разбор разбор US по созданию агентов. Если вам близка тема, подробнее в канале разработчиков IDE BAS.

Про приоритеты, которые берегут наше время

Когда-то я обнаружила, что подписана штук на 500+ экспертных каналов в ТГ. Не то чтобы я их пересчитывала, а просто поняла, что могу часами перелистывать тонны постов, пытаясь ухватить что-то ценное.

У этого явления есть название - синдром упущенных возможностей (он еще называется FOMO). Это когда человек думает, что все вокруг узнают что-то интересное, а он – нет. Говорят, придумали еще много синдромов, но мне и этого хватило , чтобы понять, что такое – приоритеты 😉

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

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

В итоге я пришла к такой схеме приоритетов:

📍Жесткий отбор. Разделила на папки по сферам знаний (вот они на скриншоте). Внизу списка папка "Почитать", там в паре каналов (где один подписчик - я) дожидаются своей очереди статьи и посты, которые при первом взгляде показались полезными. Обычно в выходные разбираю. С этими списками как с покупками в магазине, через неделю смотришь и не понимаешь зачем купил? Когда видела заголовок впервые может показаться интересным, а при ближайшем рассмотрении удаляется без сожалений. А вот полезности из этой папки попадают в мои подборки 🌱

📍Четкий фокус. Выбираю для чтения 1-2 ключевые темы и каналы в соответствующей папке, исходя из интересов в момент времени, а не по факту выхода нового контента.

📍Осознанный пропуск. Если в канале накопилось много постов – читаю только пару последних. По крайней мере последнее-актуальное не пропущу, а если что-то прошло мимо — значит, так надо ☀️

Если у вас есть свои лайфхаки, делитесь!

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

Почти все о прототипах в одной подборке

Признаюсь, мне нравится та часть работы аналитика, где нужно визуально моделировать экранные формы. В моем списке для чтения часто находится что-то об этом. Здесь получилась подборка, где можно найти и как сделать прототип, и в чем сделать, и как согласовать с заказчиком ✍️

📍Как правильно разработать интерактивный прототип? В эту статью интересно заглянуть, если вы еще не видели как выглядит в графическом редакторе набор макетов, связанных переходами. Такой вариант прототипа часто называют "интерактивным". Еще в статье рассказ о выборе сценариев для прототипа, его разработке и представлении пользователям.

📍Сила прототипирования: что сработало, а чего следует избегать. Большая статья с картинками-примерами и рассказом, в чем картинки помогли, а в чем помешали в конкретных кейсах. В работе с прототипами много рисков и здесь меня привлекли не только картинки, но и комментарии о недостатках их использования.

📍Каркасное проектирование или wireframes В этом тексте я когда-то рассказала о вайрфреймах и даже придумала к тексту карточки с примерами и советами

📍Здесь 13 лайфхаков взаимодействия с заказчиками с точки зрения дизайнера-проектировщика. Каждый имеет пример-иллюстрацию из процессов создания прототипов. На самом деле получился универсальный подход, полезный в любом деле: выясните терминологию, договоритесь об ожиданиях, получили 20 комментариев – дайте 20 ответов...не буду пересказывать, лучше загляните сами🔅

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

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

ИИ-шный перевод текста vs человеческий

Предыдущий пост я начала готовить с того, что «скормила» текст статьи DeepSeek и вежливо попросила «Переведи, пожалуйста, статью». Можете крутить пальцем у виска, но я правда написала «пожалуйста», сработала привычка. Мы уже некоторое время общаемся, а приказывать приятелям как-то неуместно. Потом взяла и отнесла результат на валидацию лингвисту-переводчику. Вот что мы поняли.

Получился не перевод, а пересказ с искажениями от рассказчика. Искажения местами очень заметные. Например, в первом пункте про декомпозицию руками РО в оригинале написано, что нужно на дейли поискать желающих помочь с декомпозицией и договориться о времени встречи. В пересказе так: «На Daily Scrum PO объявляет: «Нужно разбить 3 истории к следующему спринту». Добровольцы из команды помогают.» Получается – сели дружно на дейли и начали декомпозировать, но в тексте же не об этом. Так мне однажды ученик 5го класса «Гарри Поттера» пересказал – в целом может и верно, но непонятно кто куда на метле летел, причем тут снитч и нимбус?


Рассказчик подбирает смыслы и слова откуда-то из своего опыта. Там же в первом пункте про РО, в оригинале написано, что нужно привлекать команду, а в пересказе я нашла что декомпозируют «PO + разработчики + тестировщики». Упоминание тестировщиков тут вполне уместно по сути, но вот найдете ли в оригинале хоть одного тестировщика во всем тексте? Его тут дорисовала нейро-фантазия (вполне удачно, но не по тексту).

В переводе слово «итерация» местами оказалась словом «спринт». В нашем контексте это смысла не меняет, но если важен именно построчный детальный перевод, то может подвести. Так временами действуют пожилые опытные родственники – «делай, дочка, как я сказала, не ошибешься», иногда срабатывает, а иногда....больно вспоминать 🙈


Никакая вежливость не спасла от подведения итогов. ИИ-шная тяга делать выводы сработала и в переводе, где я с изумлением обнаружила раздел «Итоги», которого нет в оригинале. Решила поправить промпт и попросила «сделай точный перевод текста», но все равно обнаружила раздел «Итоги». Попросила «убери итоги», получила пересказ с абзацем «ключевые выводы». Слово «пожалуйста» не помогает, в подведении итогов DeepSeek неумолим как бухгалтерия в отчетный период.

Здесь напрашивается подзаголовок «выводы», но будет очень похоже, что этот текст DeepSeek написал без меня😉 Так что ни итогов, ни ключевых выводов не будет. Просто мои наблюдения на случай, если вы решите что-то быстренько перевести.

#истории #опыт

5 ошибок декомпозиции User Story и как их избежать

В блоге Майка Кона, наткнулась на полезную статью о декомпозиции историй и решила пересказать основные идеи. Вот как видит автор пять самых распространённых ошибок и способы их исправить. Если тема актуальна, то стоит заглянуть и в оригинал.

Ошибка №1: Разделение историй — задача только Product Owner’а
🚨PO без технического бэкграунда может разделить историю так, что:
• Из нескольких подзадач, 99% работы окажется в одной подзадаче.
• Появятся зависимости между подзадачами, мешающие завершению любой из них в рамках одной итерации.
⚙️Решение:
• Разделение историй — командная работа. PO + команда. Это не означает, что вся команда должна делить каждую историю в полном составе, но деление истории не должно производиться только одним или парой человек для каждой истории. PO и несколько представителей команды делят сначала одну или несколько историй, затем PO и несколько других участников делят следующую и т.д.
• Обсуждение на Daily Scrum. Например, на Daily Scrum PO объявляет: «Нужно разбить 3 истории в следующие пару дней для подготовки к следующему спринту». Несколько человек из команды выражают готовность помочь и определяются с подходящим временем.

Ошибка №2: Разделение по техническим границам
🚨Истории делятся не по функциональным, а по техническим границам, т.е. только с точки зрения команды, а не пользователя или стейкхолдера. Истории типа:
• «Как пользователь, я хочу бэкенд который делает X».
• «Как пользователь, я хочу фронтенд который делает тот же Х».
Таким образом получаются истории, не имеющие для пользователя никакой ценности сами по себе. (Фронтэнд, например, веб-интерфейс, не несет пользы без бэкэнда и\или базы данных)
⚙️Решение:
• Делите по «путям» через историю.
• По путям с точки зрения команды: обычно есть путь, определяющий что происходит, когда все идет правильно, и пути для возможных ошибок.
• По путям с точки зрения пользователя: например, при заказе товаров из корзины пользователь может выбрать варианты доставки. В первой версии можно предположить, что все пользователи получают только один из вариантов, а остальные добавить позднее. Это упростит интерфейс и потребует меньше тестирования.

Ошибка №3: Указание решения истории в самой истории
🚨В самой истории описано как решать эту историю (Если нужно повесить картину на стену, сразу прописывается какой крепеж использовать, вместо простого «Нужно повесить картину на стену»).
⚙️Решение:
• Фокусируйтесь на «что», а не «как».
• Если команда включает в истории слишком много конкретики, то возможно вы делите истории на слишком маленькие под-истории.

Ошибка №4: Спайки для каждой истории
🚨Команды создают спайки (исследовательские задачи) даже для простых историй, чтобы «убрать все риски».
Решение:
• Спайки нужны только при высокой неопределённости. Некоторая неопределенность присуща каждой истории, и спайки должны быть использованы лишь в особых случаях с действительно высокой неопределенностью.

Ошибка №5: сразу внедрять все бизнес-правила
🚨Команда пытается реализовать все правила сразу, даже если это значительно усложняет разработку.
Пример, мобильное приложение для банка:
• Правило: «Не выдавать кредиты общей суммой > $10 млн».
• Вместо полной проверки в первой версии можно:
1. Сделать базовую заявку без проверки существующих кредитов.
2. Добавить проверку в последующих итерациях.
⚙️Решение:
• Постепенное усложнение. Сначала разрабатывается более простой вариант, потом внедряются бизнес-правила, если это упрощает работу.
• Важно: Не выпускать в эксплуатацию версию без критичных правил!

Моя "любимая ошибка" здесь под номером 3 🌱

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

Подборка про UX, теория и рабочие инструменты

У вас тоже есть папка "почитать", которая растет быстрее, чем свободное время? В выходные заглянула в свои запасы и выбрала статьи про UX. Здесь и простые советы, которые работают на практике, и история в лицах, и неочевидные лайфхаки на примере кошек 😉

📍Что должен знать продакт о машинном переводе интерфейса: кейс с результатами Автор делится опытом внедрения ИИ для локализации интерфейсов. Написано продактом и для продактов, но как всегда интересно заглянуть в чей-то опыт.

📍UX-проектирование на кошке Осторожно, в статье много фото одной трехцветной кошки! Статья о построении интерфейса для кошки-пользователя дверного проема. Мне очень понравился пример работы UX-специалиста с отсылкой к теории. Рекомендую заглянуть и в комментарии к статье об ответственности и бенефициарах такого проектирования, вдруг вы об этом еще не думали ?

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

📍Дорогая, что-то пошло не так. Гид по пустым состояниям и ошибкам + шаблоны на все случаи Руководитель группы UX-редактуры рассказала о текстах сообщений с примерами в картинках. Хотя статье уже почти два года, она точно будет полезна, если вы работаете с текстом.

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

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

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

Здесь должен быть текст. Профессиональный UX-райтинг
Майкл Дж. Меттс, Энди Уэлфл, 2024

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

Книга о том, как создавать тексты в интерфейсах от создания стратегии до вопросов взаимодействия с командой разработки. Написано ясно, легко читается. В тексте есть примеры, отсылки к конкретным приложениям и историям. Один из авторов приводит примеры из написания текстов, которыми чат-бот общается с пользователями, есть интересные моменты: несложные, но такие, что не замечаешь пока кто-то не покажет. Для меня минус книги в том, что мысли объясняются много раз, разными словами и еще обобщаются в конце разделов. Если у вас уже есть опыт в UX, то может выглядеть раздражающе.

Перевод вышел через 4 года после оригинального издания в 2020 году и это заметно по некоторым отсылкам к статистике 2018-2019 гг. и примерам. Немного странно читать что-то капитанское вроде: "теперь не нужно выходить из дома, чтобы пополнить банковский счет" 😉

Что может быть полезно?
Особенно меня подкупило с каким уважением к работе с текстом пишут авторы. Одна из первых глав называется "Не извиняйтесь за себя" и в ней говорится о фокусе и значимости разных ролей при проектировании пользовательского опыта. И в том числе о важности текста.

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

Когда вы принимаете решение, оказывающее влияние на чей-то опыт, вы занимаетесь проектированием.

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

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

Интересно было почитать об инклюзивности и доступности. Каким должен быть текст и как расположен, чтобы он работал при использовании скринридеров, которые превращают текст на странице в аудио?

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

Кому может быть полезно?
В начале книги написано, что она для технических и UX-писателей с оговоркой, что кем бы вы себя ни называли: дизайнером, UX-писателем или специалистом по контент-стратегии, "если вы пишете текст, с которым взаимодействуют пользователи, книга поможет применить к этому процессу дизайн-методики".
Думаю, будет интересно всем, кто хоть раз задумывался почему его сообщения в интерфейсе всё ещё раздражают пользователей? 😊

#книжки

☀️Пятничный дайджест историй

Иногда вместо экспертных статей пишу истории "около IT" . Обычно эти тексты занимают у меня больше времени, чтобы личный опыт превратить в слова. Собрала здесь несколько текстов, вдруг вы пропустили что-то из этого?

📌История про детство и компьютер (который в детстве мне казался магическим и даже вредным, хотя у него было собственное имя)
📌 Аналитик с опытом может быть новичком! (о нюансах онбординга, зонтике в шкафу и ностальгии)
📌 Давний пост о мотивации и ориентире на результат (с цитатами из мультика и семейными историями)
📌 Как из меня не получилось звезды учебного ролика (и вообще не удалось быть собой)
📌 Учебный год и офферы  (о фото в семейном архиве, пишущей машинке и опыте преподавания)

Может, у вас было что-то похожее? Делитесь!

#истории

Почему ТЗ есть, а результата нет? (подборка)

Когда-то переход от заказной разработки к внутренним проектам принес мне прозрение: настоящие исследования — это не просто поговорить с парой выделенных экспертов и сделать ТЗ из того, "что сказали". С тех пор я одержима поиском ответов на вопросы вида "чтобы что?" (оказывается, за ним скрываются самые важные инсайты).

В выходные наткнулась на очень качественный вебинар на эту тему (он первый в списке) и следом собралась небольшая подборка.

🎬Когда вроде все сделали правильно – а заказчик недоволен. Опытные коллеги-аналитики на учебном примере разобрали, что нужно понять для хорошего результата и какими инструментами. Действительно качественный материал, где затронуты и определение контекста, и анализ ключевых показателей, и поиск проблем через root cause analysis и диаграмму Исикавы.

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

🔖Требования vs Реальность: Почему в ТЗ находят «дыры» и как это исправить. Здесь акцент именно на способы передачи информации, а не на выяснение проблем. Если честно, в этой статье мне почему-то не захотелось нажать на добавку кармы на Хабре, тем не менее есть вполне реалистичные примеры неполных требований и рекомендации по составлению документа ТЗ.

🗞Заметить слона, или Подводные грабли IT-проектов Автор статьи поделился своим мнением обо всем понемногу – об инфраструктурных вопросах, о сборе обратной связи от заказчика, о нюансах состава работ по ТЗ.

📃С кем важно говорить о требованиях на самом деле? Снова публикация в Дзен-версии этого канала. Здесь о нюансах выявления заинтересованных сторон.

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

Из БА в СА это всегда рост?

Дождь над Финским заливом, отпуск и новое в папке каналов "Про анализ". Встретила несколько постов о ролях аналитиков с комментариями в духе "Я вырос из БА до СА/ разработчика" – и задумалась. Почему принято называть ростом переход в другую роль, хотя это по сути смена навыков и контекста? Почему мы пытаемся оценивать карьеру какими-то ступенями, хотя это забег длиной в 40+ лет со сложными поворотами?

Знаете детский стих "Мама – летчик? Что ж такого!" с финалом "Дело было вечером, спорить было нечего." Так и слово "рост" в этом контексте, если разобраться, даже не предмет спора.

Когда я в середине девяностых планировала поступать на мех-мат, друзья и знакомые крутили пальцем у виска. Заводы закрывались, инженерам жилось непросто. Самые амбициозные шли поступать на экономистов или юристов. В моём вузе на математические специальности, скорее всего, был недобор. Родители убедили, что математика – это знание, из которого можно развиваться куда угодно. Не знаю, просчитывали ли они на 20 лет вперёд, но оказались правы: красный диплом по прикладной математике открыл мне многие возможности.

Первой строчкой в трудовой было "инженер-программист". Звучит солидно, но на деле оказалось пыткой для моего темперамента. Он с трудом выдерживал написание кода с 8:00 до 17:00 при минимуме общения. Терпение и дисциплина помогают решать задачи и временами меня хвалили, но запасы этих качеств за неполных три года истощились.

Примерно тогда же, когда закончилось терпение, в мой город пришла заказная разработка, а с ней - новые роли в производстве ПО. Так я оказалась в тестировании. Через пару лет я уже в роли QA лида и снова темперамент протестует против составления баг-репортов и тест-кейсов. Распределять задачи команде неплохо, но где же исследования и драйв неопределенности? 😎

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

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

Прошло всего-то лет 15, и названий аналитиков больше одного. Каждый считает свой путь единственно верным. Если пытаться стать тем, что в тренде, без учета вашего темперамента и склонностей, то ближе к завершению карьеры можно обнаружить себя героем рассказа Жванецкого: "Зато я скажу теперь сыну: "Парень, я прошел через всё. Я не стал этим и не стал тем. Я передам тебе свой опыт!"😊

Уже никто не назовет безумием мой диплом по математике. А вот когда называю себя бизнес-аналитиком, многие удивляются "как же такая взрослая и все БА". Теперь БА это уже не про fullstack и "изучение предметной области за три дня". Названия изменились, а мы с моим темпераментом все те же. И мы друг другу очень благодарны за профессиональный рост и возможность не застрять в роли, которая не по душе 🌱

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

#мысливслух #карьера