ну и срочное включение, потому что я проехала 22 км по ЗСД и не умерла 🚲🙈

налетаем!

🚀Открыты регистрация и приём докладов на Analyst Days 23

Конференция пройдет 20-21 ноября 2026 года в Москве и онлайн-форматах

➡️Для подачи заявки на выступление переходите по ссылке

➡️Больше информации для докладчиков вы найдёте здесь

Мы ждём ваши доклады!🙏🏼

⚡️билеты
⚡️афиша
⚡️скидки
⚡️видео

тут мой дорогой коллега Иван @ananas_na_prirode написал очень классную статью про свой продукт, рекомендую к прочтению (ну и давайте поддержим Ваню)!

если вы на выходных немного засвинерились, то вам понравится атмосфера на картине Питера Брейгеля и спецзадание - найти хрюшу!

#лицодляважныхпереговоров

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

что было первым - анализ или дизайн? мы сначала пишем, и потом рисуем? или делаем это одновременно?

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

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

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

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

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

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

дружим командами, друзья, разделяем и объединяем зоны ответственности, но и про картинки из пэйнта не забываем!

хороших всем длинных выходных!

пока ехала в такси, водитель спросил откуда я и зачем приехала. а закончился разговор знаете чем - правильно, ИИ!

сказал, что слышал, что IT-сфера умирает! пришлось поддержать беседу, так сказать 🙈

Мы с моей сообщницей Наташей @analysisnotanalytics вот только провели мастер-класс по определению стратегии работы с рисками по MEAT. Презентацию оставлю в комментарии.

Добавлю про полезные материалы для аналитиков по работе с рисками:
- Вигерс, Глава 32 Требования к ПО и управление рисками
- BABOK, 10.38 Анализ и управление рисками

Спасибо участникам за активное участие!
Был классный вопрос, а в какой момент аналитик должен работать с рисками? Пишите свои ответы в комментарии. Я тоже напишу свой) и кажется спойлер: об этом можно будет рассказать на Analyst Days)

П.с. Я ещё рассказала про продукт, над которым работаю — усилитель звука Апелиотис. И неожиданно у аудитории появился интерес) можно записать в Продвижение — рассказ о продукте на профессиональных конференциях)

П.п.с. Смотрите, какой мы колокольчик нашли! И его использовали для уведомления о завершении раундов) 🔔

П.п.п.с. В MEAT есть упущение — там нет Усиления риска как стратегии. Но это тоже можно использовать. Рассказала пример из жизни на мастер-классе

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

я в этой картине всегда видела не наездника, а наездницу, так что пусть это будет ещё одним напоминанием мне (и всем), что girls can do anything!

а вообще произведение называется "Фантазия", сотворил его Кузьма Сергеевич Петров-Водкин 🥃

#лицодляважныхпереговоров

пока сил на образовательный контент не набрала, но зато показываю вам мистера булочку в рубрике 🐕

заряжает на цветение, урожай и настоящее лето!

#лицодляважныхпереговоров

у IIBA (International Institute of Business Analysis) есть целый образовательный раздел - KnowledgeHub.

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

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

наслаждаемся!

#лицодляважныхпереговоров этой недели будет вдохновлено недавней дискуссией в чате с коллегами (и мемами)!

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

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

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

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

штош, очень хочется надеяться, что классных событий для аналитиков будет только больше (и главное чтобы качество не снижалось).

приветы всем вчерашним спикерам и до встречи на новых конференциях!

обещала ж развить тему автора в требованиях, так вот приступим (я недоговорила!).

в любом тексте, и в требованиях / техническом задании в том числе, всегда есть две стороны – автор текста (кто написал), и читатель - тот, для кого этот текст создаётся.

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

есть ещё одна роль, которую часто забывают и исключают из нелитературных текстов - это персонаж, он же фактически посредник между автором и читателем.

кто может было «персонажем» в спецификации? пользователь, от имени которого мы пишем сценарии? бизнес? представители заказчика?

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

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

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

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

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

что это - опыт и привычка или всё же стилистические отличия текста? оставим вопрос открытым (и жду ваши догадки).