Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Разработать процесс организации опроса by Mind Map: Разработать процесс
организации опроса
0.0 stars - reviews range from 0 to 5

Разработать процесс организации опроса

Зачем ?

Почему вы вообще начали об этом говорить и зачем надо что-то делать?

Не понятно, каким образом анализировать данные опроса

Оценка может быть интерпретирована как "не высокая"

Понимать, где находится проблема

На стороне разработки, Низкое качество реализации, Неадекватный подход к реализации (простое делается сложным)

На стороне бизнес-заказчика, Отсутствующий ответ на вопрос "Зачем"?, Просят конкретное решение, без анализа самой проблемы

Видение результата

Что мы хотим получить в итоге?

Мы получаем релевантную оперативную информацию по проекту

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

На основании Lessons Learned вырабатываются типовые сценарии поведения на те или иные ответы

Результаты такого опроса должны быть включены в Lessons Learned по проекту

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

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

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

Результаты всех опросов доступны всем

Мы знаем, как проводить опрос (ПМ-ам не нужно думать над реализацией - все рецепты уже есть)

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

Понятно, как собираются ответы, Например, очно в ходе ретроспективы, Или в офф-лайне по почте

Понятно, где обрабатывать и хранить ответы

Понятно, кому как и когда рассылать результаты

Мозговой штурм

Предложения, которые приходят в голову - просто "навалом". Предложения вставлять отдельными подразделами "МШ". По возможности следить за понятностью.

1. Проведение опроса привязывается к текущему демо

2. В опросе выделяются отдельно: заказчики, ключевые пользователи, простые пользователи (либо их представители)

Таня:, Отдельно заказчики, Отдельно ИТ подразделения, Отдельно команда разработки

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

Проведение опроса привязвывать к периодическому отчету по проекту

Частота может быть ниже, например каждый второй отчет

... или ретроспективе

Опросы по ходу проекта

Позволяют мониторить текущее состояние проекта

Являются индикатором адекватности результатов опроса в конце проекта, Если в ходе проекта опросы зеленые и красный в конце, то здесь что-то не то

Вопросы должны учитывать

Все фазы проекта (Таня), Сбор и анализ требований, Согласование сроков и ресурсов проекта, планирование, дизайн (подготовка архитектуры и согласование схемы развёртывания), Разработка и тестирование, Обучение пользователей, Приёмка пользователями, Подготовка инфраструктуры и развёртывание сервиса, Передача сервиса на поддержку

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

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

Проблемы предыдущих проектов, После каждого ритуала Lessons Learned пересматривается список вопросов

При офф-лайновом опросе учитывать желание отвечать

Напоминать о необходимости ответить

Проводить открытые ретроспективы, куда приглашать всех участников проекта

Кто пришел - того просить прямо на месте заполнить опросник

Если кто-то не приходит по приглашению - отдельно спрашивать, Либо ретроспектива скучна, Либо проект не нужен, И то и другое нужно лечить

У нас есть список типовых вопросов

Пополняется по результатам Lessons Learned

Можно использовать изощренный подход типа Kano Survey

Требуется выделить то, что будет аттрибутом качества, Отчетность, Демки, Ретроспектива, Промежуточные версии на демо-стенде, ...

Можно будет понять, что есть что из наших активностей, Мотиватор, Демотиватор, Must-Have, Индиферент

Через дом качества транслировать в практики

Организация

Возможный порядок (структура), как можно расположить относительно друг друга идеи, нагенерированные в МШ. 

Фазы (Таня)

Передача сервиса на поддержку

Согласование сроков и ресурсов проекта, планирование, дизайн (подготовка архитектуры и согласование схемы развёртывания)

Разработка и тестирование

Обучение пользователей

Приёмка пользователями

Подготовка инфраструктуры и развёртывание сервиса

Сбор и анализ требований

Стейкхолдеры (Таня, Вася)

Заказчики

Ключевые пользователи

Команда разработки

1 и 2 линии

3 линия

Архитекторы

Проверочные точки (Таня)

Проработанность проекта (предпроект)

Понимание целей проекта

Постановка задач

Информированность о ходе проекта

Наличие критических ситуаций

Достижение проектом (релизом) текущего результата

Причины неудач

Качество поддержки

Соответствие сроков и текущих бизнес-потребностей (Вася)

Соответствие результатов и текущих бизнес-потребностей (Вася)

Аналитическая работа способствует достижению результатов проекта (Вася)

Коммуникации способствуют достижению результата проекта (Вася)

Перечень вопросов

Заказчикам

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

Удовлетворены ли вы степенью вовлеченности команды проекта?

Команде

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

Удовлетворены ли вы степенью вовлеченности заказчика?, Скорость ответов на уточняющие вопросы, Посещение демонстраций/ретроспектив