решение проблемы целеполагания -k8凯发
-
контекст (разработки)
- реферат в школе
- научно-исследовательская работа
- разработка по
- обучение студентов
- любой проект!
-
симптомы
- момент, о который спотыкаются
- симптом - это не проблема, которую надо решать. снятие симптома не делает заказчика/пользователя счастливым
-
проблема
- заказчик приходит с решением, которое он видит. обычно это решение призвано снять симптом
- снимая симптомы мы не удовлетворяем клиента.
- имея такой симптом, мы не можем ограничивать хотелки или ставить приоритеты работы
- нам неоткуда брать технологические ограничения
- это приводит к раздуванию проекта, неоптимальным (или случайно оптимальным) технологическим решениям. у нас провальный проект.
- конфликты в команде
-
решение: что нужно сделать
- описать контекст
- выявить настоящие проблемы
- определить конкретные цели
- сформировать решение, которе поможет достичь целей
- отобразить задачи из решения на разрабатываемое по
-
решение: изучение контекста
- никто сразу не ответит на вопрос "какие у вас проблемы?"
-
вопросы
-
как это делается сейчас?
- какие есть альтернативные решения?
- почему это не устраивает?
- что нравится в текущем решении?
- почему это перестало устраивать именно сейчас?
- уже на уровне изучения контекста проект может закрыться!
-
решение: выявление проблем
-
проблема (триггер) это
- решить проблему
- получить новую возможность
- снизить потенциальный риск
- проблема должна иметь прямой выход на деньги!
- формулировка проблемы
- симптомы мы тоже не выкидываем, они могут дать критерии: метрики процессов, числовые и качественные характеристики желаемого результата
-
решение: определение целей
- цели должны решать проблемы
-
должно быть понятно, как именно цель делает счастливым заказчика/потребителя
- сформулирована положительно
-
мнемонические правила
-
smart
- specific – цель должна быть конкретной
- measurable – цель должна быть измеримой
- attainable – цель должна быть достижимой
-
realistic – цель должна быть реалистичной
- уместная
- time bound – цель должна быть ограниченной во времени.
-
pure
- positively stated – цели должны быть сформулированы на позитивном настрое, без приставки «не». по принципу «хочу то- то и то- то».
- understandable – цели должны быть понятны всем, а не только вам.
- relevant –цели должны быть релевантными, то есть в этом случае, находится в общем русле, а не быть «оторванными» от текущей ситуации.
- ethical – цели должны быть этичными.
-
clear
- challenging – цели должны содержать некий вызов. то есть цель может быть решена только с вашим участием.
- legal – цель должна быть в рамках закона.
- environmental – цель не должна наносить вред окружению. у нас есть такое выражение – «идти по головам…», так вот это неправильно, когда цель указывает на какой – то негатив, который можно принести другим.
- appropriate –цель должна быть уместной, это как если бы мы пытались топором закручивать винт.
- recordable-цель должна быть записана. пожалуй, это самая главная часть этого фильтра, да и не только. как говорится в поговорке: «самый тупой карандаш, лучше самой острой памяти». кстати, дело тут не только в фиксации.
- найти презентацию кости
- у целей должен быть проставлен приоритет
- в идеале - 1 цель на проект! можно 2-3
-
стоп-слова
- автоматизировать…
- эффективный…
- интуитивно-понятный…
- быстро…
-
решение: построение решения
-
задачи
- что мы делаем, чтобы достигнуть целей?
- что мы не делаем, чтобы достигнуть целей?
- задачи накладывают ограничения на используемые проектом средства
-
решение: отображение решения на ис
- задачи формируют блоки работ в проекте и требования
- приоритеты задач помогают формировать план работ
- обычно в начале работ согласуется первый этап (первая версия)
-
цели (профит)
- мы имеем согласованное с клиентом видение проблем и решений, это повышает вероятность удовлетворенности клиента, и что он к нам вернется
- имея постановку целей и задач мы понимаем ограничения проекта и фильтр на входящие хотелки
-
мы видим ограничения, которые контекст накладывает на технологическое решение и архитектуру
- задачи разделяют проект на подсистемы/модули
- с помощью целеполагания мы уменьшаем вероятность конфликтов
- они маленькие по объёму!
-
что делать?
- при входе в продукт требовать эту информацию
-
при формировании проекта - генерировать её
- вовлекать в это как можно больше людей
-
всегда с ней сверяться при построении/перестройке планов
- делать это не только для рабочих проектов