1. Контекст (разработки)
   1. Реферат в школе
   2. Научно-исследовательская работа
   3. Разработка ПО
   4. Обучение студентов
   5. Любой проект!
2. Симптомы
   1. Момент, о который спотыкаются
   2. Симптом - это не проблема, которую надо решать. Снятие симптома не делает заказчика/пользователя счастливым
3. Проблема
   1. Заказчик приходит с решением, которое он видит. Обычно это решение призвано снять симптом
   2. Снимая симптомы мы не удовлетворяем клиента.
   3. Имея такой симптом, мы не можем ограничивать хотелки или ставить приоритеты работы
   4. Нам неоткуда брать технологические ограничения
   5. Это приводит к раздуванию проекта, неоптимальным (или случайно оптимальным) технологическим решениям. У нас провальный проект.
   6. Конфликты в команде
4. Решение: что нужно сделать
   1. Описать контекст
   2. Выявить настоящие проблемы
   3. Определить конкретные цели
   4. Сформировать решение, которе поможет достичь целей
   5. Отобразить задачи из решения на разрабатываемое ПО
5. Решение: Изучение контекста
   1. Никто сразу не ответит на вопрос "Какие у вас проблемы?"
   2. Вопросы
      1. Как это делается сейчас?
         1. Какие есть альтернативные решения?
      2. Почему это не устраивает?
      3. Что нравится в текущем решении?
      4. Почему это перестало устраивать именно сейчас?
   3. Уже на уровне изучения контекста проект может закрыться!
6. Решение: Выявление проблем
   1. Проблема (триггер) это
      1. Решить проблему
      2. Получить новую возможность
      3. Снизить потенциальный риск
   2. Проблема должна иметь прямой выход на деньги!
   3. Формулировка проблемы
   4. Симптомы мы тоже не выкидываем, они могут дать критерии: метрики процессов, числовые и качественные характеристики желаемого результата
7. Решение: Определение целей
   1. Цели должны решать проблемы
   2. Должно быть понятно, как именно цель делает счастливым заказчика/потребителя
      1. Сформулирована положительно
   3. Мнемонические правила
      1. SMART
         1. Specific – цель должна быть конкретной
         2. Measurable – цель должна быть измеримой
         3. Attainable – цель должна быть достижимой
         4. Realistic – цель должна быть реалистичной
            1. Уместная
         5. Time bound – цель должна быть ограниченной во времени.
      2. PURE
         1. Positively stated – цели должны быть сформулированы на позитивном настрое, без приставки «не». По принципу «хочу то- то и то- то».
         2. Understandable – цели должны быть понятны всем, а не только Вам.
         3. Relevant –цели должны быть релевантными, то есть в этом случае, находится в общем русле, а не быть «оторванными» от текущей ситуации.
         4. Ethical – цели должны быть этичными.
      3. CLEAR
         1. Challenging – цели должны содержать некий вызов. То есть цель может быть решена только с Вашим участием.
         2. Legal – цель должна быть в рамках закона.
         3. Environmental – цель не должна наносить вред окружению. У нас есть такое выражение – «идти по головам…», так вот это неправильно, когда цель указывает на какой – то негатив, который можно принести другим.
         4. Appropriate –цель должна быть уместной, это как если бы мы пытались топором закручивать винт.
         5. Recordable-цель должна быть записана. Пожалуй, это самая главная часть этого фильтра, да и не только. Как говорится в поговорке: «Самый тупой карандаш, лучше самой острой памяти». Кстати, дело тут не только в фиксации.
      4. Найти презентацию Кости
   4. У целей должен быть проставлен приоритет
   5. В идеале - 1 цель на проект! Можно 2-3
   6. Стоп-слова
      1. Автоматизировать…
      2. Эффективный…
      3. Интуитивно-понятный…
      4. Быстро…
8. Решение: Построение решения
   1. Задачи
      1. Что мы делаем, чтобы достигнуть целей?
      2. Что мы не делаем, чтобы достигнуть целей?
      3. Задачи накладывают ограничения на используемые проектом средства
9. Решение: Отображение решения на ИС
   1. Задачи формируют блоки работ в проекте и требования
   2. Приоритеты задач помогают формировать план работ
   3. Обычно в начале работ согласуется первый этап (первая версия)
10. Цели (Профит)
    1. Мы имеем согласованное с клиентом видение проблем и решений, это повышает вероятность удовлетворенности клиента, и что он к нам вернется
    2. Имея постановку целей и задач мы понимаем ограничения проекта и фильтр на входящие хотелки
    3. Мы видим ограничения, которые контекст накладывает на технологическое решение и архитектуру
       1. Задачи разделяют проект на подсистемы/модули
    4. С помощью целеполагания мы уменьшаем вероятность конфликтов
    5. Они маленькие по объёму!
11. Что делать?
    1. При входе в продукт требовать эту информацию
    2. При формировании проекта - генерировать её
       1. Вовлекать в это как можно больше людей
    3. Всегда с ней сверяться при построении/перестройке планов
    4. Делать это не только для рабочих проектов