Анализ на входеПОТЕРЯННЫЙ УСПЕХ ПРОЕКТА

Контекст В самом начале проекта вы получаете пару страниц исходных пользовательских требований и указание приступать к подготовке ТЗ.

Что нужно сделать аналитику в этот моменты чтобы потом ТЗ не стало диагнозом провала проекта?

ThinkersWare

1. Понять ситуацию2. Не наступи на грабли3. Вперед в прошлое4. Назад в будущее5. Результат

Думай головой

Задай себе вопросыКт

о зд

есь

?! • Кто за что отвечает?

• Кто что писал?

• Компетенции• Полномочия

Что

тут

… • Месиво уровней и типов требований

• Что подразумевается

• ТОЩО

Заче

м э

то ?

! • Не могу• Не хочу• Боюсь• Юный

конструктор• Заточки

ThinkersWare

1. Понять ситуацию2. Не наступи на грабли3. Вперед в прошлое4. Назад в будущее5. Результат

Думай головой

Завет им. Грабли

1. Нужно потому что нужно

2. Не сомневаться в том что это все что они хотят

3. Принять все тяготы данных архитектурных решений

4. Сразу расписывать детально требования

5. Оставь все как есть, ибо так записано

6. Скрестить ужа и ежика

7. Зацементировать ТОЩО

Диагноз Павлова1. Новичок

◦ Придумывает как сделать не зная платформы◦ Нет альтернатив◦ Верит на слово

2. Боится высоты◦ Системный VS Бизнес аналитик

3. Коробочник◦ Привычка работать в рамках инструмента

4. Честный◦ Заостряет проблемы не попробовав найти решение

5. Скромный◦ Со всем согласен, не может возразить

ThinkersWare

1. Понять ситуацию2. Не наступи на грабли3. Вперед в прошлое4. Назад в будущее5. Результат

Думай головой

Вперед в прошлоеИсходные проблемы

Бизнес цели

Задачи системы

Заинтересованные лицаФичи

Проектные ограничения

Архитектурные решения

ThinkersWare

1. Понять ситуацию2. Не наступи на грабли3. Вперед в прошлое4. Назад в будущее5. Результат

Думай головой

Побежали туда-сюда

Initial requirements

Statements In/Out Scope

Constraints Decision

FR / NFR

ThinkersWare

1. Понять ситуацию2. Не наступи на грабли3. Вперед в прошлое4. Назад в будущее5. Результат

Думай головой

Результат1. Восстановлены цели, задачи

2. Определены заинтересованные лица

3. Зафиксированы исходные требования

4. Зафиксированы все новые пожелания клиента

5. Согласовано что есть в рамках что нет в рамках

6. Зафиксированы решения и допущения

7. Описаны функциональные и нефункциональные требования

… дает эффект1. Минимизация рисков “тощо”, “несколько”

2. Определен инструмент фильтрования по настоящим целям и приоритетам

3. Определен настоящий scope

4. Минимизация рисков несоответствия возможностям

5. Ликвидированы токсичные требования

6. Найдены новые проекты

7. Добавлен нолик к проекту

Спасибо за внимание!

Антон Витязь Куратор проекта “ThinkersWare”Консультант, аналитик

E Anton.Vityaz@gmail.comT +380 66 0043-073