📑 Когда ТЗ перестаёт быть фикцией: практический путь к отделу системного анализа
От Автора:
"Я пришла в компанию, где системный анализ «формально был», но по факту системные аналитики жили отдельно от разработки и продукта. Итог был предсказуем: аналитики писали ТЗ, которые никто не читал, разработчики ходили к бизнесу напрямую, интерпретировали хотелки «как поняли», в систему прилетали костыли, странные обходные пути и тонны лишней логики, а в прод выкатывалось то, что скорее напоминало мем с качелями «что хотел заказчик — что в результате получилось»."
Читать статью
От Автора:
"Я пришла в компанию, где системный анализ «формально был», но по факту системные аналитики жили отдельно от разработки и продукта. Итог был предсказуем: аналитики писали ТЗ, которые никто не читал, разработчики ходили к бизнесу напрямую, интерпретировали хотелки «как поняли», в систему прилетали костыли, странные обходные пути и тонны лишней логики, а в прод выкатывалось то, что скорее напоминало мем с качелями «что хотел заказчик — что в результате получилось»."
Читать статью
❤5👍4
Опыт ВТБ по миграции SAP BW/4 HANA: что помогло уложиться в сроки и сохранить функциональность
Авторы - Михаил Синельников, лидер кластера импортозамещения аналитической отчетности в ВТБ и Владимир Ведяков, ИТ-лидер проекта со стороны компании «Сапиенс Солюшнс»:
"Мы описали в этой статье перенос системы аналитической отчетности SAP BW/4 HANA на импортонезависимый стек. В этом материале представлен наш практический опыт: ключевые решения, подходы к планированию, особенности реализации и выводы, которые могут быть полезны командам, работающим с аналогичными задачами."
Читать статью
Авторы - Михаил Синельников, лидер кластера импортозамещения аналитической отчетности в ВТБ и Владимир Ведяков, ИТ-лидер проекта со стороны компании «Сапиенс Солюшнс»:
"Мы описали в этой статье перенос системы аналитической отчетности SAP BW/4 HANA на импортонезависимый стек. В этом материале представлен наш практический опыт: ключевые решения, подходы к планированию, особенности реализации и выводы, которые могут быть полезны командам, работающим с аналогичными задачами."
Читать статью
👍4
Проектирование в условиях нестабильности: от функционального хаоса к архитектурной устойчивости
Автор - Игорь Стряпков, главный архитектор в Cloud X:
"В работе мы постоянно сталкиваемся с тем, что современные системы программного обеспечения все больше живут в условиях постоянных изменений: новые требования, изменяющиеся бизнес‑правила, новые технологии, расширение функциональности. Однако большинство архитектурных подходов, таких как функциональная декомпозиция, не учитывают эту реальность. В результате команды сталкиваются с высокой стоимостью изменений и непредсказуемыми срывами сроков.
Но мы на своем опыте убедились в том, что разработка в условиях нестабильности — это подход, который признает изменчивость требований как данность и предлагает систематические методы создания архитектур, способных эволюционировать вместе с бизнесом. Другими словами, на сегодня меняющиеся требования — это не отклонение от нормы, а естественное состояние разработки. И поэтому я хотел бы подробнее поговорить о том, как превратить постоянные изменения из угрозы в конкурентное преимущество."
Читать статью
Автор - Игорь Стряпков, главный архитектор в Cloud X:
"В работе мы постоянно сталкиваемся с тем, что современные системы программного обеспечения все больше живут в условиях постоянных изменений: новые требования, изменяющиеся бизнес‑правила, новые технологии, расширение функциональности. Однако большинство архитектурных подходов, таких как функциональная декомпозиция, не учитывают эту реальность. В результате команды сталкиваются с высокой стоимостью изменений и непредсказуемыми срывами сроков.
Но мы на своем опыте убедились в том, что разработка в условиях нестабильности — это подход, который признает изменчивость требований как данность и предлагает систематические методы создания архитектур, способных эволюционировать вместе с бизнесом. Другими словами, на сегодня меняющиеся требования — это не отклонение от нормы, а естественное состояние разработки. И поэтому я хотел бы подробнее поговорить о том, как превратить постоянные изменения из угрозы в конкурентное преимущество."
Читать статью
👍5
Привет, коллеги! 👋
Сегодня предлагаю обсудить тему: стейкхолдеры и эффективное взаимодействие с ними. 🤝
В карточках к посту вы найдете определение, кто такие стейкхолдеры и их условную классификацию
А далее перейдем к некоторым рекомендациям о том, как выявлять заинтересованные стороны, анализировать их нужды и выстраивать продуктивное сотрудничество.
1. Выявление стейкхолдеров:
▫️ Мозговой штурм: начните с мозгового штурма с командой - кто может быть заинтересован в проекте или затронут им? Не ограничивайте себя - сначала запишите всех, кто приходит в голову.
▫️ Анализ документации: изучите устав проекта, бизнес-план, организационную структуру. Там часто указаны ключевые лица и подразделения.
▫️Интервью с ключевыми лицами: спросите у руководителей и экспертов, кого еще стоит включить в список.
▫️ Постройте диаграмму, показывающую границы системы и взаимодействующие с ней элементы. Сразу станет понятно, кто стейкхолдер.
▫️Не забывайте о "скрытых" стейкхолдерах: иногда существуют группы, которые не очевидны на первый взгляд, но тем не менее важны (например, будущие пользователи, регуляторы).
2. Анализ стейкхолдеров:
▪️Матрица "Влияние/Интерес": разместите стейкхолдеров на матрице, чтобы определить, с кем нужно активно взаимодействовать, кого достаточно информировать, а кого нужно просто мониторить:
- Высокое влияние/Высокий интерес: Управляйте внимательно (ключевые стейкхолдеры)
- Высокое влияние/Низкий интерес: Держите в курсе
- Низкое влияние/Высокий интерес: Информируйте
- Низкое влияние/Низкий интерес: Мониторьте
▪️Анкетирование и опросы: соберите информацию о потребностях, ожиданиях и опасениях стейкхолдеров.
▪️SWOT-анализ стейкхолдеров: определите сильные и слабые стороны, возможности и угрозы, связанные с каждым стейкхолдером.
3. Взаимодействие со стейкхолдерами:
▫️Определите оптимальные каналы коммуникации: кому-то удобнее получать информацию по электронной почте, кому-то на совещаниях, а кому-то через систему управления проектами.
▫️Регулярные встречи: организуйте регулярные встречи для обсуждения прогресса, проблем и изменений.
▫️Прозрачность: будьте открытыми и честными в своих коммуникациях.
▫️Активное слушание: уделяйте внимание мнению стейкхолдеров, задавайте вопросы, уточняйте детали.
▫️Управление ожиданиями: четко обозначайте, что вы можете и не можете сделать.
▫️Гибкость: будьте готовы адаптироваться к изменяющимся потребностям стейкхолдеров.
▫️ Документируйте все коммуникации: ведите записи встреч, протоколы решений, чтобы всегда иметь возможность вернуться к обсужденным вопросам.
Познакомиться чуть подробнее с методами выявления, анализа и управления стейкхолдерами помогут статьи:
🖇 Кто такие стейкхолдеры: Таблица интересов стейкхолдеров, Карта заинтересованных сторон, Матрица стейкхолдеров
🖇 Анализ стейкхолдеров проекта
🖇 Как построить коммуникацию между стейкхолдерами проекта
🖇 Карта заинтересованных сторон – инструмент анализа проектного окружения и бизнеса в целом
🖇 Как подружиться с людьми, от которых зависит проект
🖇«Нормально же общались»: кто такие стейкхолдеры и как избегать с ними конфликтов
#теоретическиезаметки #подборка #статьи | @notes_analyst
Сегодня предлагаю обсудить тему: стейкхолдеры и эффективное взаимодействие с ними. 🤝
В карточках к посту вы найдете определение, кто такие стейкхолдеры и их условную классификацию
А далее перейдем к некоторым рекомендациям о том, как выявлять заинтересованные стороны, анализировать их нужды и выстраивать продуктивное сотрудничество.
1. Выявление стейкхолдеров:
▫️ Мозговой штурм: начните с мозгового штурма с командой - кто может быть заинтересован в проекте или затронут им? Не ограничивайте себя - сначала запишите всех, кто приходит в голову.
▫️ Анализ документации: изучите устав проекта, бизнес-план, организационную структуру. Там часто указаны ключевые лица и подразделения.
▫️Интервью с ключевыми лицами: спросите у руководителей и экспертов, кого еще стоит включить в список.
▫️ Постройте диаграмму, показывающую границы системы и взаимодействующие с ней элементы. Сразу станет понятно, кто стейкхолдер.
▫️Не забывайте о "скрытых" стейкхолдерах: иногда существуют группы, которые не очевидны на первый взгляд, но тем не менее важны (например, будущие пользователи, регуляторы).
2. Анализ стейкхолдеров:
▪️Матрица "Влияние/Интерес": разместите стейкхолдеров на матрице, чтобы определить, с кем нужно активно взаимодействовать, кого достаточно информировать, а кого нужно просто мониторить:
- Высокое влияние/Высокий интерес: Управляйте внимательно (ключевые стейкхолдеры)
- Высокое влияние/Низкий интерес: Держите в курсе
- Низкое влияние/Высокий интерес: Информируйте
- Низкое влияние/Низкий интерес: Мониторьте
▪️Анкетирование и опросы: соберите информацию о потребностях, ожиданиях и опасениях стейкхолдеров.
▪️SWOT-анализ стейкхолдеров: определите сильные и слабые стороны, возможности и угрозы, связанные с каждым стейкхолдером.
3. Взаимодействие со стейкхолдерами:
▫️Определите оптимальные каналы коммуникации: кому-то удобнее получать информацию по электронной почте, кому-то на совещаниях, а кому-то через систему управления проектами.
▫️Регулярные встречи: организуйте регулярные встречи для обсуждения прогресса, проблем и изменений.
▫️Прозрачность: будьте открытыми и честными в своих коммуникациях.
▫️Активное слушание: уделяйте внимание мнению стейкхолдеров, задавайте вопросы, уточняйте детали.
▫️Управление ожиданиями: четко обозначайте, что вы можете и не можете сделать.
▫️Гибкость: будьте готовы адаптироваться к изменяющимся потребностям стейкхолдеров.
▫️ Документируйте все коммуникации: ведите записи встреч, протоколы решений, чтобы всегда иметь возможность вернуться к обсужденным вопросам.
Познакомиться чуть подробнее с методами выявления, анализа и управления стейкхолдерами помогут статьи:
🖇 Кто такие стейкхолдеры: Таблица интересов стейкхолдеров, Карта заинтересованных сторон, Матрица стейкхолдеров
🖇 Анализ стейкхолдеров проекта
🖇 Как построить коммуникацию между стейкхолдерами проекта
🖇 Карта заинтересованных сторон – инструмент анализа проектного окружения и бизнеса в целом
🖇 Как подружиться с людьми, от которых зависит проект
🖇«Нормально же общались»: кто такие стейкхолдеры и как избегать с ними конфликтов
#теоретическиезаметки #подборка #статьи | @notes_analyst
👍6🔥5❤3
📑 Поиск по подстроке — ответ системного аналитика на собеседовании
Автор - Наталия Пляко,
бизнес и системный аналитик, руководитель проектов:
"Привет всем! Данная статья адресована начинающим свой путь в системном анализе и призвана помочь ответить максимально просто на один из самых частых вопросов системному аналитику на собеседовании. Мне данный вопрос задали на 3х из 5ти технических интервью, а это значит, что в теме надо разобраться. Поехали!
Вопрос: на сайте есть форма с полем поиска чего-либо по названию и кнопка, при нажатии на которую должен быть выведен результат поиска. Проблема в том, что пользователь не помнит название. Как реализовать поиск?"
Читать статью
Автор - Наталия Пляко,
бизнес и системный аналитик, руководитель проектов:
"Привет всем! Данная статья адресована начинающим свой путь в системном анализе и призвана помочь ответить максимально просто на один из самых частых вопросов системному аналитику на собеседовании. Мне данный вопрос задали на 3х из 5ти технических интервью, а это значит, что в теме надо разобраться. Поехали!
Вопрос: на сайте есть форма с полем поиска чего-либо по названию и кнопка, при нажатии на которую должен быть выведен результат поиска. Проблема в том, что пользователь не помнит название. Как реализовать поиск?"
Читать статью
👍4❤1
От стейкхолдеров к требованиям: с чего начать?
Привет, коллеги!
В прошлый раз мы с вами разобрали, кто такие стейкхолдеры и как с ними взаимодействовать.
Вы уже составили свой список ключевых лиц, наметили стратегию коммуникации... И теперь возникает самый важный и сложный вопрос: «Что же делать дальше?» 🤔
Частая ошибка новичков (да и опытных тоже) - сразу переходить от списка лиц к сбору «хотелок». В результате мы получаем винегрет из пожеланий, технических идей и личных мнений, из которого почти невозможно собрать целостную картину проекта.
Главный секрет на этом этапе - научиться отделять истинную Потребность от предложенного Решения.
▪️Решение - это то, ЧТО человек просит сделать. Часто это уже готовое, иногда неоптимальное, техническое предложение.
▪️Потребность - это то, ПОЧЕМУ он это просит. Это коренная проблема, боль, цель или желаемый результат, который стоит за запросом.
Классический пример:
- Что говорит стейкхолдер (Решение): «Мне нужна еще одна кнопка «Экспорт в PDF» в правом верхнем углу отчета».
- Что может быть на самом деле (Потребность): «Мне еженедельно приходится тратить 2 часа, чтобы вручную сводить данные из этого отчета в презентацию для руководства. Мне нужно быстро получать данные в удобном для презентации формате».
Видите разницу? Если мы слепо реализуем «кнопку», мы можем упустить возможность создать автоматический еженедельный отчет-презентацию, который сэкономит не 10 минут на клик, а 2 часа работы в неделю.
Практический шаг: как это делать?
Прежде чем проводить массовые интервью, начните с малого. Возьмите своего ключевого стейкхолдера и подготовьтесь к первой беседе.
Вопросы-помощники для выявления потребностей:
- «Расскажите, как вы сейчас выполняете эту задачу? Опишите ваш обычный день» (понимание текущего процесса).
- «С какими сложностями или рутиной вы сталкиваетесь? Что отнимает больше всего времени?» (выявление боли).
- «Какой идеальный результат для вас? Что изменится, когда проблема будет решена?» (понимание цели).
- Уточняющие вопросы на любое предложенное решение: «Почему это важно? Как это решит вашу задачу?»
Ваша цель первой встречи - не записать список функций, а понять контекст, бизнес-процесс и настоящие цели.
Итог: Переход от стейкхолдеров к требованиям начинается со смены фокуса. Фокус на ЛИЦА (кому важно) меняется на фокус на ПРОБЛЕМЫ (что важно и почему).
В следующих постах мы разберем ряд методов сбора требований - от классических интервью и воркшопов до анализа документов и наблюдения. Вы узнаете, как выбрать правильный инструмент под задачу и как комбинировать их, чтобы собрать полную картину.
@notes_analyst
Привет, коллеги!
В прошлый раз мы с вами разобрали, кто такие стейкхолдеры и как с ними взаимодействовать.
Вы уже составили свой список ключевых лиц, наметили стратегию коммуникации... И теперь возникает самый важный и сложный вопрос: «Что же делать дальше?» 🤔
Частая ошибка новичков (да и опытных тоже) - сразу переходить от списка лиц к сбору «хотелок». В результате мы получаем винегрет из пожеланий, технических идей и личных мнений, из которого почти невозможно собрать целостную картину проекта.
Главный секрет на этом этапе - научиться отделять истинную Потребность от предложенного Решения.
▪️Решение - это то, ЧТО человек просит сделать. Часто это уже готовое, иногда неоптимальное, техническое предложение.
▪️Потребность - это то, ПОЧЕМУ он это просит. Это коренная проблема, боль, цель или желаемый результат, который стоит за запросом.
Классический пример:
- Что говорит стейкхолдер (Решение): «Мне нужна еще одна кнопка «Экспорт в PDF» в правом верхнем углу отчета».
- Что может быть на самом деле (Потребность): «Мне еженедельно приходится тратить 2 часа, чтобы вручную сводить данные из этого отчета в презентацию для руководства. Мне нужно быстро получать данные в удобном для презентации формате».
Видите разницу? Если мы слепо реализуем «кнопку», мы можем упустить возможность создать автоматический еженедельный отчет-презентацию, который сэкономит не 10 минут на клик, а 2 часа работы в неделю.
Практический шаг: как это делать?
Прежде чем проводить массовые интервью, начните с малого. Возьмите своего ключевого стейкхолдера и подготовьтесь к первой беседе.
Вопросы-помощники для выявления потребностей:
- «Расскажите, как вы сейчас выполняете эту задачу? Опишите ваш обычный день» (понимание текущего процесса).
- «С какими сложностями или рутиной вы сталкиваетесь? Что отнимает больше всего времени?» (выявление боли).
- «Какой идеальный результат для вас? Что изменится, когда проблема будет решена?» (понимание цели).
- Уточняющие вопросы на любое предложенное решение: «Почему это важно? Как это решит вашу задачу?»
Ваша цель первой встречи - не записать список функций, а понять контекст, бизнес-процесс и настоящие цели.
Итог: Переход от стейкхолдеров к требованиям начинается со смены фокуса. Фокус на ЛИЦА (кому важно) меняется на фокус на ПРОБЛЕМЫ (что важно и почему).
В следующих постах мы разберем ряд методов сбора требований - от классических интервью и воркшопов до анализа документов и наблюдения. Вы узнаете, как выбрать правильный инструмент под задачу и как комбинировать их, чтобы собрать полную картину.
@notes_analyst
👍9❤2🔥2
Как написать AI-ТЗ из одной фразы заказчика: пошаговая инструкция по методике SARD от идеи до спецификации требований
"Эта статья — демонстрационный пример, иллюстрирующий пошаговую методику преобразования одной вымышленной бизнес-фразы заказчика в полноценное техническое задание (ТЗ) с помощью инструментов искусственного интеллекта (ИИ). В качестве исходной фразы для демонстрации выбрана бизнес-идея, приписываемая гипотетическому Сэму Альтману: «Помогите мне сделать GPT настолько незаметным, что люди перестанут бояться сингулярности»."
Читать статью
"Эта статья — демонстрационный пример, иллюстрирующий пошаговую методику преобразования одной вымышленной бизнес-фразы заказчика в полноценное техническое задание (ТЗ) с помощью инструментов искусственного интеллекта (ИИ). В качестве исходной фразы для демонстрации выбрана бизнес-идея, приписываемая гипотетическому Сэму Альтману: «Помогите мне сделать GPT настолько незаметным, что люди перестанут бояться сингулярности»."
Читать статью
👍4
📑 Кому выгоден перманентный пожар: экономика тушения в ИТ
Автор - Светлана Пурик:
"Борьба с последствиями плохого ТЗ иногда ценится выше, чем работа по его предотвращению.
Кратко о парадоксе: все ругают костыли и авралы, но они повторяются вновь и вновь. Значит, это кому-то нужно? Посмотрим на экосистему проекта не с технической, а с экономической и карьерной точек зрения."
Читать статью
Автор - Светлана Пурик:
"Борьба с последствиями плохого ТЗ иногда ценится выше, чем работа по его предотвращению.
Кратко о парадоксе: все ругают костыли и авралы, но они повторяются вновь и вновь. Значит, это кому-то нужно? Посмотрим на экосистему проекта не с технической, а с экономической и карьерной точек зрения."
Читать статью
👍7
Фильтруй. Переиспользуй. Собирай. Почему DITA — идеальный формат для разработки сложной технической документации
Автор - Александр Клименков, техлид, технический писатель, программист:
"DITA расшифровывается как Darwin Information Typing Architecture. Фактически это формат, основанный на XML, со своей стандартизированной схемой DTD. Формат DITA предназначен для разметки исходного текста документов с помощью специальных тегов. Набор тегов в этом формате специально разработан для того, чтобы было удобно форматировать текст пользовательской или технической документации.
В этом формате предусмотрено несколько удобных механизмов, которые позволяют здорово упростить жизнь автору текста. Например, в DITA есть очень удобные средства для фильтрации и повторного использования контента. Из исходных файлов в формате DITA с помощью свободно распространяемого набора скриптов DITA-OT (Open Toolkit) можно собрать документы в различных форматах: HTML, PDF, EPUB, CHM и других.
Давайте познакомимся с этим форматом поближе."
Читать статью
Автор - Александр Клименков, техлид, технический писатель, программист:
"DITA расшифровывается как Darwin Information Typing Architecture. Фактически это формат, основанный на XML, со своей стандартизированной схемой DTD. Формат DITA предназначен для разметки исходного текста документов с помощью специальных тегов. Набор тегов в этом формате специально разработан для того, чтобы было удобно форматировать текст пользовательской или технической документации.
В этом формате предусмотрено несколько удобных механизмов, которые позволяют здорово упростить жизнь автору текста. Например, в DITA есть очень удобные средства для фильтрации и повторного использования контента. Из исходных файлов в формате DITA с помощью свободно распространяемого набора скриптов DITA-OT (Open Toolkit) можно собрать документы в различных форматах: HTML, PDF, EPUB, CHM и других.
Давайте познакомимся с этим форматом поближе."
Читать статью
👍6
Как продакт и аналитик работают в одной задаче: три кейса из практики
Автор - Маша,продакт ITSM 365 в Naumen:
"В этой статье делюсь тремя кейсами и практическим опытом взаимодействия аналитика и продакта в одной задаче: почему это иногда превращается в хаос, и как мы перестраивали процессы, чтобы этого избежать."
Читать статью
Автор - Маша,продакт ITSM 365 в Naumen:
"В этой статье делюсь тремя кейсами и практическим опытом взаимодействия аналитика и продакта в одной задаче: почему это иногда превращается в хаос, и как мы перестраивали процессы, чтобы этого избежать."
Читать статью
👍3🤔1
📑 BPMN для аналитиков и тимлидов (часть 2)
Автор - Вожегов Дмитрий, системный аналитик:
"В первой части мы обсудили недостатки стандарта BPMN, которые важно учесть до начала моделирования, чтобы сделать проектирование процессов понятным, однозначным и эффективным.
В этой статье мы перейдём к практике: начнём проектировать процессы и обсудим три важных аспекта:
- выбор архитектуры процесса: монолитная или микросервисная;
- выбор вида BPMN-схемы: взаимодействие или хореография;
- выбор подхода для начальной декомпозиции процессов: случайные или детерминированные подпроцессы."
Читать статью
Автор - Вожегов Дмитрий, системный аналитик:
"В первой части мы обсудили недостатки стандарта BPMN, которые важно учесть до начала моделирования, чтобы сделать проектирование процессов понятным, однозначным и эффективным.
В этой статье мы перейдём к практике: начнём проектировать процессы и обсудим три важных аспекта:
- выбор архитектуры процесса: монолитная или микросервисная;
- выбор вида BPMN-схемы: взаимодействие или хореография;
- выбор подхода для начальной декомпозиции процессов: случайные или детерминированные подпроцессы."
Читать статью
🔥5👍4
📑 Хранилища данных. Обзор технологий и подходов к проектированию
Автор - Марина Зенкова
"В этой статье будут рассмотрены основные подходы к проектированию архитектуры хранилищ данных (DWH), эволюция архитектур, взаимосвязь Data Lake, Data Factory, Data Lakehouse, Data Mesh c DWH, преимущества и недостатки подходов к моделированию данных. Материал будет полезен тем, кто работает с корпоративными данными: аналитики, инженеры и архитекторы данных."
Читать статью
Автор - Марина Зенкова
"В этой статье будут рассмотрены основные подходы к проектированию архитектуры хранилищ данных (DWH), эволюция архитектур, взаимосвязь Data Lake, Data Factory, Data Lakehouse, Data Mesh c DWH, преимущества и недостатки подходов к моделированию данных. Материал будет полезен тем, кто работает с корпоративными данными: аналитики, инженеры и архитекторы данных."
Читать статью
👍6
Ну кайф же! Продолжаем есть оливье и мандарины. А если еще и на онлайн-уроки залететь?
Приглашаем на бесплатные уроки🎓по архитектуре и интеграциям.
Учиться никогда не поздно. А если поздно, то завтра выходной.
➡️ Открывайте уроки
ПО ССЫЛКЕ.
👇
@studyit_help_bot
—
Скидка на полный курс от канала
1 000₽ по промокоду NOTES
до 31 января
Приглашаем на бесплатные уроки🎓по архитектуре и интеграциям.
В современном IT-мире сложно представить востребованного аналитика, тестировщика, разработчика, проджекта, который бы не разбирался в Web-интеграциях и API.
Учиться никогда не поздно. А если поздно, то завтра выходной.
ПО ССЫЛКЕ.
👇
@studyit_help_bot
—
Скидка на полный курс от канала
1 000₽ по промокоду NOTES
до 31 января
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
📑 Цикл статей: Kafka для начинающих
Автор - Никита Дымко
Java Backend Developer
1. Откуда такой спрос и зачем нужна эта технология
2. Работа с брокером сообщений на практике
3. Гарантии доставки на практике и настройка идемпотентности
4. Работа с оффсетами на практике
5. Работа с Kafka транзакциями на практике — когда они нужны, а когда только вредят?
Автор - Никита Дымко
Java Backend Developer
1. Откуда такой спрос и зачем нужна эта технология
2. Работа с брокером сообщений на практике
3. Гарантии доставки на практике и настройка идемпотентности
4. Работа с оффсетами на практике
5. Работа с Kafka транзакциями на практике — когда они нужны, а когда только вредят?
👍8
Ребята, приглашаю на бесплатный вебинар, где Андрон Алексанян - эксперт в области аналитики и CEO школы аналитики Simulative — в прямом эфире разберет все важные аспекты в работе аналитика, а также расскажет как получить оффер быстрее других.
Это очень полезное событие для тех кто только зашел в аналитику и для тех, кто хочет в нее зайти в ближайшее время. Особенно если вы не понимаете, какие навыки действительно важны или боитесь, что без опыта вас не возьмут на работу. Кстати тут разберут и возрастной аспект: как стать аналитиком в 30/40/50 лет и т.д.
На вебинаре будет:
— Покажем реальные примеры, как оформить резюме и портфолио, чтобы привлекать внимание;
— Обсудим какие отклики работают, а какие сразу отправляют в корзину;
— Изнанка найма: инсайдерский взгляд на процессы отбора
💬 Всем зарегистрировавшимся Simulative пришлют полезный материал — карту компетенций аналитика данных со всеми нужными инструментами для освоения.
Please open Telegram to view this post
VIEW IN TELEGRAM
📑 Бережливое производство и имитационное моделирование для анализа и оптимизации бизнес-процессов
Автор Анна Вичугова:
"Как посчитать длительность и себестоимость выполнения бизнес-процесса с помощью имитационного моделирования, а также улучшить его методами бережливого производства: практический пример интерактивной симуляции"
Читать статью
Автор Анна Вичугова:
"Как посчитать длительность и себестоимость выполнения бизнес-процесса с помощью имитационного моделирования, а также улучшить его методами бережливого производства: практический пример интерактивной симуляции"
Читать статью
🔥6👍5🤔1
📑 Архитектура через призму сложности
Автор - Сергей Баранов:
"Типовая ситуация: в проект приходят умные люди, менеджеры внедряют эффективные процессы, а проект все равно превращается в болото. Фичи разрабатываются месяцами, релизы откладываются, а на ретроспективах все жалуются на зависимости. При этом на схемах все выглядит красиво: микросервисы, CI/CD, облака. Что с этим миром не так?
Понятно, что «не так» может быть что угодно и как обычно it depends, но здесь и сейчас разберем одну из возможных причин, а именно ситуацию, при которой архитекторы и техлиды работают только с одним видом сложности – технологической. Рисуют квадратики, проводят стрелочки, выбирают базы данных. Реальность разработки при этом гораздо сложнее: в любом проекте одновременно живут три вида сложности, и они постоянно влияют друг на друга. Игнорируя хотя бы один из них, получим легаси с техдолгом вселенских масштабов уже через полгода (при современных условиях может и быстрее)."
Читать статью
Автор - Сергей Баранов:
"Типовая ситуация: в проект приходят умные люди, менеджеры внедряют эффективные процессы, а проект все равно превращается в болото. Фичи разрабатываются месяцами, релизы откладываются, а на ретроспективах все жалуются на зависимости. При этом на схемах все выглядит красиво: микросервисы, CI/CD, облака. Что с этим миром не так?
Понятно, что «не так» может быть что угодно и как обычно it depends, но здесь и сейчас разберем одну из возможных причин, а именно ситуацию, при которой архитекторы и техлиды работают только с одним видом сложности – технологической. Рисуют квадратики, проводят стрелочки, выбирают базы данных. Реальность разработки при этом гораздо сложнее: в любом проекте одновременно живут три вида сложности, и они постоянно влияют друг на друга. Игнорируя хотя бы один из них, получим легаси с техдолгом вселенских масштабов уже через полгода (при современных условиях может и быстрее)."
Читать статью
👍7❤3🤔1
🚨Наконец-то! Для системных и бизнес-аналитиков — актуальные навыки и новые инструменты из двух направлений в одном курсе «Системный и бизнес-анализ»
🚀Записывайтесь на 3 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями, задавайте вопросы и обсуждайте свои кейсы!
🌀Вебинар 1: «Зависимость нефункциональных требований и качества продукта»
27 января в 20:00 мск
На вебинаре разберём:
1. Что такое нефункциональные требования и как они классифицируются
2. Основные критерии качества и какие из них наиболее применимы к цифровым продуктам
3. Как выстраивать трассировку нефункциональных требований на критерии качества
🌀Вебинар 2: «Готовим процесс к автоматизации: от BPMN к данным и интерфейсам»
4 февраля в 20:00 мск
На вебинаре разберём:
1. Простой пример бизнес-процесса в BPMN и ключевые элементы модели
2. Как «подняться вверх» от BPMN к показателям и метрикам процесса
3. Как «спуститься вниз» от BPMN к структуре данных и экранным формам
🌀Вебинар 3: «Описываем Use Сase на примере сервиса доставки»
18 февраля в 20:00 мск
На вебинаре разберём:
1. Преимущества и ограничения подхода с использованием use case
2. Как на примере сервиса доставки правильно выделять варианты использования и определять их границы
3. Форматы описания use case и особенности их взаимосвязей
Записывайтесь ➡️ OTUS.RU
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, ERID: 2W5zFGRV4wS
🚀Записывайтесь на 3 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями, задавайте вопросы и обсуждайте свои кейсы!
🌀Вебинар 1: «Зависимость нефункциональных требований и качества продукта»
27 января в 20:00 мск
На вебинаре разберём:
1. Что такое нефункциональные требования и как они классифицируются
2. Основные критерии качества и какие из них наиболее применимы к цифровым продуктам
3. Как выстраивать трассировку нефункциональных требований на критерии качества
🌀Вебинар 2: «Готовим процесс к автоматизации: от BPMN к данным и интерфейсам»
4 февраля в 20:00 мск
На вебинаре разберём:
1. Простой пример бизнес-процесса в BPMN и ключевые элементы модели
2. Как «подняться вверх» от BPMN к показателям и метрикам процесса
3. Как «спуститься вниз» от BPMN к структуре данных и экранным формам
🌀Вебинар 3: «Описываем Use Сase на примере сервиса доставки»
18 февраля в 20:00 мск
На вебинаре разберём:
1. Преимущества и ограничения подхода с использованием use case
2. Как на примере сервиса доставки правильно выделять варианты использования и определять их границы
3. Форматы описания use case и особенности их взаимосвязей
Записывайтесь ➡️ OTUS.RU
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, ERID: 2W5zFGRV4wS
Привет, коллеги!
В прошлый раз мы с вами научились отделять потребность от решения. Но как же эту потребность выявить? Первый и самый важный инструмент в арсенале аналитика - интервью.
Интервью – это не просто «разговор», а структурированный метод, позволяющий глубоко понять контекст, мотивацию и неочевидные проблемы стейкхолдера.
Суть метода в том, что у вас есть план и ключевые темы, но нет жёсткого сценария. Вы ведёте беседу, адаптируя вопросы по ходу дела, чтобы исследовать интересные детали.
Практический пример:
Ситуация: Вы разрабатываете новый внутренний сервис для подачи заявок на отпуск.
Ваш стейкхолдер: Мария, руководитель отдела маркетинга.
Её запрос-решение: «Хочу, чтобы заявку можно было подавать из нашего мессенджера. Так будет быстрее».
Как провести интервью, чтобы выявить потребность?
1. Вопрос на понимание контекста: «Мария, расскажите, как сейчас выглядит процесс согласования отпуска в вашем отделе? Опишите, пожалуйста, шаг за шагом».
2. Вопрос на выявление проблемы: «С какими сложностями вы или ваши сотрудники сталкиваетесь чаще всего? Что больше всего раздражает или отнимает время?»
3. Уточняющий вопрос на «решение»: «Вы упомянули мессенджер - что именно в текущем процессе заставляет думать, что мессенджер ускорит дело?»
4. Вопрос на выявление цели: «Представьте идеальный сценарий. Что должно происходить, когда сотрудник хочет в отпуск?»
Вероятный результат такого интервью:
Окажется,что главная боль - не в способе подачи, а в том, что заявки «теряются» в длинных email-переписках, непонятен их статус, и Марии приходится постоянно напоминать HR о согласовании. Её истинная потребность - прозрачность и контроль над процессом, а не скорость отправки.
Решением может стать не интеграция с мессенджером, а, например, система с трекингом статусов, автоматическими уведомлениями и единым журналом заявок.
Как видите, успешное интервью — это подготовленный, но гибкий диалог, где вы помогаете стейкхолдеру осознать и сформулировать его истинную потребность.
А на картинках к этому посту вы найдете еще несколько рекомендаций по подготовке и проведению интервью⬆️
#теоретическиезаметки | @notes_analyst
В прошлый раз мы с вами научились отделять потребность от решения. Но как же эту потребность выявить? Первый и самый важный инструмент в арсенале аналитика - интервью.
Интервью – это не просто «разговор», а структурированный метод, позволяющий глубоко понять контекст, мотивацию и неочевидные проблемы стейкхолдера.
Суть метода в том, что у вас есть план и ключевые темы, но нет жёсткого сценария. Вы ведёте беседу, адаптируя вопросы по ходу дела, чтобы исследовать интересные детали.
Практический пример:
Ситуация: Вы разрабатываете новый внутренний сервис для подачи заявок на отпуск.
Ваш стейкхолдер: Мария, руководитель отдела маркетинга.
Её запрос-решение: «Хочу, чтобы заявку можно было подавать из нашего мессенджера. Так будет быстрее».
Как провести интервью, чтобы выявить потребность?
1. Вопрос на понимание контекста: «Мария, расскажите, как сейчас выглядит процесс согласования отпуска в вашем отделе? Опишите, пожалуйста, шаг за шагом».
2. Вопрос на выявление проблемы: «С какими сложностями вы или ваши сотрудники сталкиваетесь чаще всего? Что больше всего раздражает или отнимает время?»
3. Уточняющий вопрос на «решение»: «Вы упомянули мессенджер - что именно в текущем процессе заставляет думать, что мессенджер ускорит дело?»
4. Вопрос на выявление цели: «Представьте идеальный сценарий. Что должно происходить, когда сотрудник хочет в отпуск?»
Вероятный результат такого интервью:
Окажется,что главная боль - не в способе подачи, а в том, что заявки «теряются» в длинных email-переписках, непонятен их статус, и Марии приходится постоянно напоминать HR о согласовании. Её истинная потребность - прозрачность и контроль над процессом, а не скорость отправки.
Решением может стать не интеграция с мессенджером, а, например, система с трекингом статусов, автоматическими уведомлениями и единым журналом заявок.
Как видите, успешное интервью — это подготовленный, но гибкий диалог, где вы помогаете стейкхолдеру осознать и сформулировать его истинную потребность.
А на картинках к этому посту вы найдете еще несколько рекомендаций по подготовке и проведению интервью
#теоретическиезаметки | @notes_analyst
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥2