1. Зачем ?
1.1. Не понятно, каким образом анализировать данные опроса
1.2. Оценка может быть интерпретирована как "не высокая"
1.3. Понимать, где находится проблема
1.3.1. На стороне разработки
1.3.1.1. Низкое качество реализации
1.3.1.2. Неадекватный подход к реализации (простое делается сложным)
1.3.2. На стороне бизнес-заказчика
1.3.2.1. Отсутствующий ответ на вопрос "Зачем"?
1.3.2.2. Просят конкретное решение, без анализа самой проблемы
2. Видение результата
2.1. Мы получаем релевантную оперативную информацию по проекту
2.2. Мы знаем какие наши типичные действия после получения результатов опроса (понимаем, зачем нужны опросы и какую ценность они несут)
2.2.1. На основании Lessons Learned вырабатываются типовые сценарии поведения на те или иные ответы
2.3. Результаты такого опроса должны быть включены в Lessons Learned по проекту
2.4. По результатам опросов руководитель проекта будет обязан предпринимать действия направленные на решение обнаруженных проблем
2.5. Опрос должен быть направлен на оценку деятельности всех участников без исключения, как из ИТ, так и коллег из других департаментов.
2.6. проводится как по окончанию проекта, так и по ходу проекта, если проект длительный.
2.7. Результаты всех опросов доступны всем
2.8. Мы знаем, как проводить опрос (ПМ-ам не нужно думать над реализацией - все рецепты уже есть)
2.8.1. Понятно, как создается опросники
2.8.1.1. Может быть одним для всех
2.8.1.2. Может кастомизироваться под каждый проект
2.8.1.3. Для разных участников опросник различен - это понятно
2.8.2. Понятно, как собираются ответы
2.8.2.1. Например, очно в ходе ретроспективы
2.8.2.2. Или в офф-лайне по почте
2.8.3. Понятно, где обрабатывать и хранить ответы
2.8.4. Понятно, кому как и когда рассылать результаты
3. Мозговой штурм
3.1. 1. Проведение опроса привязывается к текущему демо
3.2. 2. В опросе выделяются отдельно: заказчики, ключевые пользователи, простые пользователи (либо их представители)
3.2.1. Таня:
3.2.1.1. Отдельно заказчики
3.2.1.2. Отдельно ИТ подразделения
3.2.1.3. Отдельно команда разработки
3.3. 3. Сделать перечень, кого мы должны выделять (направлен на оценку всех участников, без исключения)
3.4. Проведение опроса привязвывать к периодическому отчету по проекту
3.4.1. Частота может быть ниже, например каждый второй отчет
3.4.2. ... или ретроспективе
3.5. Опросы по ходу проекта
3.5.1. Позволяют мониторить текущее состояние проекта
3.5.2. Являются индикатором адекватности результатов опроса в конце проекта
3.5.2.1. Если в ходе проекта опросы зеленые и красный в конце, то здесь что-то не то
3.6. Вопросы должны учитывать
3.6.1. Все фазы проекта (Таня)
3.6.1.1. Сбор и анализ требований
3.6.1.2. Согласование сроков и ресурсов проекта, планирование, дизайн (подготовка архитектуры и согласование схемы развёртывания)
3.6.1.3. Разработка и тестирование
3.6.1.4. Обучение пользователей
3.6.1.5. Приёмка пользователями
3.6.1.6. Подготовка инфраструктуры и развёртывание сервиса
3.6.1.7. Передача сервиса на поддержку
3.6.2. Все функциональные области
3.6.2.1. Сделать матрицу перекрестной оценки других функциональных областей (например чтобы увидеть кто считает критическую проблему таковой, а для кого это норма)
3.6.3. готовность заказчика (ключевых пользователей) к работе по своему проекту
3.6.4. Проблемы предыдущих проектов
3.6.4.1. После каждого ритуала Lessons Learned пересматривается список вопросов
3.7. При офф-лайновом опросе учитывать желание отвечать
3.7.1. Напоминать о необходимости ответить
3.8. Проводить открытые ретроспективы, куда приглашать всех участников проекта
3.8.1. Кто пришел - того просить прямо на месте заполнить опросник
3.8.2. Если кто-то не приходит по приглашению - отдельно спрашивать
3.8.2.1. Либо ретроспектива скучна
3.8.2.2. Либо проект не нужен
3.8.2.3. И то и другое нужно лечить
3.9. У нас есть список типовых вопросов
3.9.1. Пополняется по результатам Lessons Learned
3.10. Можно использовать изощренный подход типа Kano Survey
3.10.1. Требуется выделить то, что будет аттрибутом качества
3.10.1.1. Отчетность
3.10.1.2. Демки
3.10.1.3. Ретроспектива
3.10.1.4. Промежуточные версии на демо-стенде
3.10.1.5. ...
3.10.2. Можно будет понять, что есть что из наших активностей
3.10.2.1. Мотиватор
3.10.2.2. Демотиватор
3.10.2.3. Must-Have
3.10.2.4. Индиферент
3.10.3. Через дом качества транслировать в практики
4. Организация
4.1. Фазы (Таня)
4.1.1. Передача сервиса на поддержку
4.1.2. Согласование сроков и ресурсов проекта, планирование, дизайн (подготовка архитектуры и согласование схемы развёртывания)
4.1.3. Разработка и тестирование
4.1.4. Обучение пользователей
4.1.5. Приёмка пользователями
4.1.6. Подготовка инфраструктуры и развёртывание сервиса
4.1.7. Сбор и анализ требований
4.2. Стейкхолдеры (Таня, Вася)
4.2.1. Заказчики
4.2.2. Ключевые пользователи
4.2.3. Команда разработки
4.2.4. 1 и 2 линии
4.2.5. 3 линия
4.2.6. Архитекторы
4.3. Проверочные точки (Таня)
4.3.1. Проработанность проекта (предпроект)
4.3.2. Понимание целей проекта
4.3.3. Постановка задач
4.3.4. Информированность о ходе проекта
4.3.5. Наличие критических ситуаций
4.3.6. Достижение проектом (релизом) текущего результата
4.3.7. Причины неудач
4.3.8. Качество поддержки
4.3.9. Соответствие сроков и текущих бизнес-потребностей (Вася)
4.3.10. Соответствие результатов и текущих бизнес-потребностей (Вася)
4.3.11. Аналитическая работа способствует достижению результатов проекта (Вася)
4.3.12. Коммуникации способствуют достижению результата проекта (Вася)
5. Перечень вопросов
5.1. Заказчикам
5.1.1. Удовлетворены ли вы степенью информированности о ходе проекта?
5.1.1.1. Регулярные отчеты о ходе проекта содержат всю необходимую информацию
5.1.1.2. Демонстрация промежуточных результатов проекта является полезной
5.1.2. Удовлетворены ли вы степенью вовлеченности команды проекта?
5.2. Команде
5.2.1. Понимаете ли вы бизнес-задачу, решаемую разрабатываемым сервисом?
5.2.2. Удовлетворены ли вы степенью вовлеченности заказчика?
5.2.2.1. Скорость ответов на уточняющие вопросы
5.2.2.2. Посещение демонстраций/ретроспектив