Привет, коллеги!
Сегодня поговорим о том, как жизненный цикл программного обеспечения (SDLC) влияет на нашу работу и какие задачи мы решаем на каждом этапе.
SDLC – это структурированный процесс, описывающий все этапы разработки ПО от идеи до поддержки готового продукта. И аналитик – ключевой игрок на каждом из них!
▫️Планирование: Помогаем определить цели проекта, собираем предварительную информацию о потребностях бизнеса.
Пример: Участвуем в совещаниях по определению scope проекта, изучаем бизнес-планы.
▫️Анализ: Собираем и анализируем требования, определяем функциональность системы. Это наша основная зона ответственности!
Пример: Проводим интервью со стейкхолдерами, документируем пользовательские истории, строим Use Case диаграммы.
▫️Проектирование: Участвуем в проектировании пользовательского интерфейса, обеспечиваем соответствие архитектуры будущей системы собранным требованиям.
Пример: Работаем вместе с UX/UI дизайнерами, проверяем макеты на соответствие User Stories, создаем прототипы.
▫️Разработка: Поддерживаем команду разработчиков, отвечаем на возникающие вопросы, уточняем требования.
Пример: Регулярно участвуем в стендапах, консультируем разработчиков по сложным бизнес-правилам.
▫️Тестирование: Участвуем в разработке тестовых сценариев, проверяем соответствие реализованной функциональности требованиям.
▫️Внедрение: Подготавливаем документацию, участвуем в обучении пользователей, помогаем решать проблемы, возникающие при внедрении.
Пример: Создаем руководства пользователя, участвуем в демонстрациях нового функционала, собираем обратную связь..
▫️Сопровождение: Собираем обратную связь от пользователей, анализируем проблемы, участвуем в разработке обновлений и исправлений.
Пример: Ведем журнал ошибок, анализируем отчеты пользователей о проблемах, участвуем в планировании следующих итераций.
Получается, что аналитик – это связующее звено между бизнесом и разработкой на каждом этапе!
Для тех, кто хочет чуть больше погрузиться в тему SDLC подготовили подборку статей:
🖇 SDLC: о жизненном цикле разработки ПО
🖇 Этапы жизненного цикла разработки ПО или что такое SDLC?
🖇 База про жизненный цикл разработки ПО (SDLC): этапы, виды моделей и их различия
🖇 Что такое жизненный цикл разработки программного обеспечения?
🖇 Бизнес-аналитик в ИТ: SLDC, Agile, модели и методологии разработки ПО
🖇 Путь аналитика. Работа над ошибками
🖇 What is the software development life cycle (SDLC)?
🖇 What is the SDLC?
#теоретическиезаметки #подборка #статьи | @notes_analyst
Сегодня поговорим о том, как жизненный цикл программного обеспечения (SDLC) влияет на нашу работу и какие задачи мы решаем на каждом этапе.
SDLC – это структурированный процесс, описывающий все этапы разработки ПО от идеи до поддержки готового продукта. И аналитик – ключевой игрок на каждом из них!
▫️Планирование: Помогаем определить цели проекта, собираем предварительную информацию о потребностях бизнеса.
Пример: Участвуем в совещаниях по определению scope проекта, изучаем бизнес-планы.
▫️Анализ: Собираем и анализируем требования, определяем функциональность системы. Это наша основная зона ответственности!
Пример: Проводим интервью со стейкхолдерами, документируем пользовательские истории, строим Use Case диаграммы.
▫️Проектирование: Участвуем в проектировании пользовательского интерфейса, обеспечиваем соответствие архитектуры будущей системы собранным требованиям.
Пример: Работаем вместе с UX/UI дизайнерами, проверяем макеты на соответствие User Stories, создаем прототипы.
▫️Разработка: Поддерживаем команду разработчиков, отвечаем на возникающие вопросы, уточняем требования.
Пример: Регулярно участвуем в стендапах, консультируем разработчиков по сложным бизнес-правилам.
▫️Тестирование: Участвуем в разработке тестовых сценариев, проверяем соответствие реализованной функциональности требованиям.
▫️Внедрение: Подготавливаем документацию, участвуем в обучении пользователей, помогаем решать проблемы, возникающие при внедрении.
Пример: Создаем руководства пользователя, участвуем в демонстрациях нового функционала, собираем обратную связь..
▫️Сопровождение: Собираем обратную связь от пользователей, анализируем проблемы, участвуем в разработке обновлений и исправлений.
Пример: Ведем журнал ошибок, анализируем отчеты пользователей о проблемах, участвуем в планировании следующих итераций.
Получается, что аналитик – это связующее звено между бизнесом и разработкой на каждом этапе!
Для тех, кто хочет чуть больше погрузиться в тему SDLC подготовили подборку статей:
🖇 SDLC: о жизненном цикле разработки ПО
🖇 Этапы жизненного цикла разработки ПО или что такое SDLC?
🖇 База про жизненный цикл разработки ПО (SDLC): этапы, виды моделей и их различия
🖇 Что такое жизненный цикл разработки программного обеспечения?
🖇 Бизнес-аналитик в ИТ: SLDC, Agile, модели и методологии разработки ПО
🖇 Путь аналитика. Работа над ошибками
🖇 What is the software development life cycle (SDLC)?
🖇 What is the SDLC?
#теоретическиезаметки #подборка #статьи | @notes_analyst
👍8🔥3
📑 Как виртуальная очередь заказов в Такси помогает уехать в пиковый спрос
Автор - Алексей Чубуков, аналитик из команды поиска и назначений водителей в Яндекс Такси.
"В статье я расскажу про виртуальную очередь заказов, которую мы сделали в приложении Яндекс Go. Напомню кратко, как устроен поиск водителей в Такси, поговорим про предпосылки внедрения очереди, посмотрим на то, как устроена очередь и, наконец, обсудим результаты. "
Читать статью
Автор - Алексей Чубуков, аналитик из команды поиска и назначений водителей в Яндекс Такси.
"В статье я расскажу про виртуальную очередь заказов, которую мы сделали в приложении Яндекс Go. Напомню кратко, как устроен поиск водителей в Такси, поговорим про предпосылки внедрения очереди, посмотрим на то, как устроена очередь и, наконец, обсудим результаты. "
Читать статью
👍6
Привет, коллеги!
В прошлый раз мы разбирали, что такое SDLC (жизненный цикл разработки ПО). Сегодня логически продолжаем эту тему и фокусируемся на моделях SDLC. Поговорим о ключевых подходах: Waterfall, Agile, Iterative и других.
На картинках к этому посту вы найдете краткое описание, преимущества и недостатки каждой модели.⬆️
Помните, что это лишь основа! Существует множество гибридных моделей, сочетающих в себе элементы разных подходов. Выбор "правильной" модели SDLC зависит от специфики проекта, бюджета, требований заказчика и опыта вашей команды.
Для более глубокого изучения прилагаю список статей по теме:
🖇 Жизненный цикл приложения и стадии разработки программ
🖇 SDLC и методологии разработки
🖇 Модели жизненного цикла программного обеспечения
🖇 Жизненный цикл разработки ПО: основные этапы и модели
🖇 Как методологии разработки программного обеспечения влияют на запуск IT-проекта?
🖇 Жизненный цикл разработки ПО: как выбрать подходящую модель для вашего бизнеса
🖇 SDLC модели: как выбрать правильный подход к разработке и не завалить проект
🖇 Бизнес-аналитик в ИТ: SLDC, Agile, модели и методологии разработки ПО
🖇 SDLC Models: Types, Phases, and Features
#теоретическиезаметки #подборка #статьи | @notes_analyst
В прошлый раз мы разбирали, что такое SDLC (жизненный цикл разработки ПО). Сегодня логически продолжаем эту тему и фокусируемся на моделях SDLC. Поговорим о ключевых подходах: Waterfall, Agile, Iterative и других.
На картинках к этому посту вы найдете краткое описание, преимущества и недостатки каждой модели.
Помните, что это лишь основа! Существует множество гибридных моделей, сочетающих в себе элементы разных подходов. Выбор "правильной" модели SDLC зависит от специфики проекта, бюджета, требований заказчика и опыта вашей команды.
Для более глубокого изучения прилагаю список статей по теме:
🖇 Жизненный цикл приложения и стадии разработки программ
🖇 SDLC и методологии разработки
🖇 Модели жизненного цикла программного обеспечения
🖇 Жизненный цикл разработки ПО: основные этапы и модели
🖇 Как методологии разработки программного обеспечения влияют на запуск IT-проекта?
🖇 Жизненный цикл разработки ПО: как выбрать подходящую модель для вашего бизнеса
🖇 SDLC модели: как выбрать правильный подход к разработке и не завалить проект
🖇 Бизнес-аналитик в ИТ: SLDC, Agile, модели и методологии разработки ПО
🖇 SDLC Models: Types, Phases, and Features
#теоретическиезаметки #подборка #статьи | @notes_analyst
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👍2🤔1
📑BPMN для аналитиков и тимлидов (часть 1)
Опытный системный аналитик Вожегов Дмитрий в своей статье делится практическими советами по работе с BPMN, начиная с разбора распространенных проблем и ограничений, с которыми сталкиваются аналитики.
Автор планирует в дальнейших статьях подробно рассмотреть особенности проектирования процессов в BPMN, подкрепляя свои тезисы ссылками на проверенные источники.
Читать статью
Опытный системный аналитик Вожегов Дмитрий в своей статье делится практическими советами по работе с BPMN, начиная с разбора распространенных проблем и ограничений, с которыми сталкиваются аналитики.
Автор планирует в дальнейших статьях подробно рассмотреть особенности проектирования процессов в BPMN, подкрепляя свои тезисы ссылками на проверенные источники.
Читать статью
👍3👏2
Привет, аналитики!
Сегодня освежим знания по Agile и поговорим про два популярных фреймворка: Scrum и Kanban.
Как вы помните, суть Agile отражена в Agile-манифесте, где в приоритете: взаимодействие, работающий продукт, сотрудничество с заказчиком и готовность к изменениям
Scrum и Kanban – это про гибкую, итеративную разработку, в которой:
▫️Проект делится на короткие итерации (в Scrum – спринты).
▫️Команда самоорганизуется и работает автономно.
▫️Клиент (или Product Owner) – всегда в процессе.
▫️Главное – работающий продукт, а не горы документации.
▫️Есть backlog – список задач, которые нужно выполнить.
▫️У любой задачи есть вес, приоритет и она всегда актуальна.
▫️Для наглядности используем доски (физические или электронные).
Особенности и принципы Scrum и Kanban описаны в карточках к посту⬆️
А если хотите копнуть глубже, ловите список статей⬇️
🖇 Scrum (скрам)
🖇 Scrum: методология гибкой разработки
🖇 Что такое SCRUM и как он работает
🖇Scrum-подход: что это и как использовать в рабочих процессах
🖇 Разбираемся в Scrum: Руководство с картинками и примерами
🖇 Канбан
🖇 Канбан: как работает метод визуального управления задачами — история, принципы, примеры систем и отличие от других подходов
🖇 Канбан Метод: не магия, а логика. Наводим порядок в хаосе
🖇 Метод Канбан: что это, принципы и инструменты канбан-доски
🖇 Kanban-доски: 10 примеров использования и лучшие практики
🖇 Scrum vs Kanban: сходства и различия двух самых популярных Agile-подходов
🖇 Scrum vs Kanban: в чем разница и что выбрать?
#теоретическиезаметки #подборка #статьи | @notes_analyst
Сегодня освежим знания по Agile и поговорим про два популярных фреймворка: Scrum и Kanban.
Как вы помните, суть Agile отражена в Agile-манифесте, где в приоритете: взаимодействие, работающий продукт, сотрудничество с заказчиком и готовность к изменениям
Scrum и Kanban – это про гибкую, итеративную разработку, в которой:
▫️Проект делится на короткие итерации (в Scrum – спринты).
▫️Команда самоорганизуется и работает автономно.
▫️Клиент (или Product Owner) – всегда в процессе.
▫️Главное – работающий продукт, а не горы документации.
▫️Есть backlog – список задач, которые нужно выполнить.
▫️У любой задачи есть вес, приоритет и она всегда актуальна.
▫️Для наглядности используем доски (физические или электронные).
Особенности и принципы Scrum и Kanban описаны в карточках к посту
А если хотите копнуть глубже, ловите список статей
🖇 Scrum (скрам)
🖇 Scrum: методология гибкой разработки
🖇 Что такое SCRUM и как он работает
🖇Scrum-подход: что это и как использовать в рабочих процессах
🖇 Разбираемся в Scrum: Руководство с картинками и примерами
🖇 Канбан
🖇 Канбан: как работает метод визуального управления задачами — история, принципы, примеры систем и отличие от других подходов
🖇 Канбан Метод: не магия, а логика. Наводим порядок в хаосе
🖇 Метод Канбан: что это, принципы и инструменты канбан-доски
🖇 Kanban-доски: 10 примеров использования и лучшие практики
🖇 Scrum vs Kanban: сходства и различия двух самых популярных Agile-подходов
🖇 Scrum vs Kanban: в чем разница и что выбрать?
#теоретическиезаметки #подборка #статьи | @notes_analyst
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥3
📑 Как документировать GraphQL API: полное руководство для технических писателей
Автор - Денис Ребенок, технический писатель в команде Deckhouse:
"В этой статье разберём:
- что такое GraphQL API и каковы его отличия от REST-like API;
- что такое GraphQL schema и как с ней работать;
- как сделать документацию на GraphQL API красивой и удобной для восприятия;
- как создавать статические справочники для GraphQL API;
- что ещё можно и нужно документировать при документировании GraphQL API.
В конце статьи вы найдёте ссылку на репозиторий на GitHub, который можно скачать, развернуть у себя и использовать, чтобы потренироваться в документировании GraphQL API."
Читать статью
Автор - Денис Ребенок, технический писатель в команде Deckhouse:
"В этой статье разберём:
- что такое GraphQL API и каковы его отличия от REST-like API;
- что такое GraphQL schema и как с ней работать;
- как сделать документацию на GraphQL API красивой и удобной для восприятия;
- как создавать статические справочники для GraphQL API;
- что ещё можно и нужно документировать при документировании GraphQL API.
В конце статьи вы найдёте ссылку на репозиторий на GitHub, который можно скачать, развернуть у себя и использовать, чтобы потренироваться в документировании GraphQL API."
Читать статью
🔥5👍3
📑 Ultimate System Design Checklist
Автор - Невзоров Владимир, инженер HighLoad систем:
"Успешные прохождения System Design Интервью возможны благодаря 3ём факторам:
1. Теоретической проработки архитектуры.
2. Практики решения популярных задач.
3. Умения отвечать на конкретные вопросы по системе.
Благодаря ультимативному чеклисту рассмотрим 3ий пункт подробнее."
Читать статью
Автор - Невзоров Владимир, инженер HighLoad систем:
"Успешные прохождения System Design Интервью возможны благодаря 3ём факторам:
1. Теоретической проработки архитектуры.
2. Практики решения популярных задач.
3. Умения отвечать на конкретные вопросы по системе.
Благодаря ультимативному чеклисту рассмотрим 3ий пункт подробнее."
Читать статью
👍4
Генеральная уборка базы знаний: плюсы, подводные камни, минусов не будет
Автор - Мария Рылик, старший контент-менеджер группы управления пользовательским опытом веб-поддержки «Лаборатории Касперского»:
"В этой статье я расскажу, как мы с командой провели генеральную уборку баз знаний, наступили в процессе на всевозможные швабры грабли, но в итоге помогли и юзерам продуктов, и нашему саппорту: базами знаний стали активно пользоваться, снизилось количество итераций общения по проблеме от первого запроса саппорту до окончательного решения."
Читать статью
Автор - Мария Рылик, старший контент-менеджер группы управления пользовательским опытом веб-поддержки «Лаборатории Касперского»:
"В этой статье я расскажу, как мы с командой провели генеральную уборку баз знаний, наступили в процессе на всевозможные швабры грабли, но в итоге помогли и юзерам продуктов, и нашему саппорту: базами знаний стали активно пользоваться, снизилось количество итераций общения по проблеме от первого запроса саппорту до окончательного решения."
Читать статью
👍7
📑 Когда ТЗ перестаёт быть фикцией: практический путь к отделу системного анализа
От Автора:
"Я пришла в компанию, где системный анализ «формально был», но по факту системные аналитики жили отдельно от разработки и продукта. Итог был предсказуем: аналитики писали ТЗ, которые никто не читал, разработчики ходили к бизнесу напрямую, интерпретировали хотелки «как поняли», в систему прилетали костыли, странные обходные пути и тонны лишней логики, а в прод выкатывалось то, что скорее напоминало мем с качелями «что хотел заказчик — что в результате получилось»."
Читать статью
От Автора:
"Я пришла в компанию, где системный анализ «формально был», но по факту системные аналитики жили отдельно от разработки и продукта. Итог был предсказуем: аналитики писали ТЗ, которые никто не читал, разработчики ходили к бизнесу напрямую, интерпретировали хотелки «как поняли», в систему прилетали костыли, странные обходные пути и тонны лишней логики, а в прод выкатывалось то, что скорее напоминало мем с качелями «что хотел заказчик — что в результате получилось»."
Читать статью
❤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