Часто участники проектов со стороны бизнеса жалуются, что не могут связать работу, которую выполняют разработчики, с тем, чего они хотят достичь.
Разберемся в причинах и возможных решениях проблемы.
На старте нового проекта важно определить и не упускать из виду саму миссию и цели будущего продукта. Хорошо, когда у заказчика есть техническое задание с описанием будущей функциональности
в проекте. Или он уже определился с технологиями, описал несколько десятков фич и просит нас реализовать задуманное.
В этом случае в работе будут только руки и мы не сможем критически взглянуть на все решения, которые реализуем. Без знания пути, которым заказчик пришел к существующим решениям мы не сможем разделить с заказчиком ответственность за достижение целей проекта.
Мы можем изменить это, если каждый в команде будет понимать
(а лучше и разделять) цели бизнеса. Тогда любое наше решение будет приниматься исходя из реальных потребностей бизнеса. Осознанный выбор архитектуры и подходящего стэка технологий — путь к более дешёвым и быстрым решениям по достижению поставленных целей.
Но как определить реальные цели бизнеса? Как понятным образом донести их до команды?
Это mind map, объединяющий цели проекта, целевую аудиторию
и её воздействия. Если целевая аудитория совершает эти действия, то бизнес заказчика движется к достижению поставленных целей.
В основе тимбилдинг модель Гибба — Дрекслера — Вайсборда:
Зачем мы здесь? Кто мы? Что мы делаем? Как мы достигнем цели?
Это действительно простая и быстрая техника визуализации гипотез относительно других методик. Команда разработки и заказчик совместно строят систему приоритетов, основанную на поставленных бизнес-целях.
Содержание статьи
Поможет избежать
- Случайных приоритетов
- Ненужной фукциональности
- Неверных исходных предположений
- Расползания границ проекта
Способствует
- Визуализации границ проекта и основных гипотез
- “Мудрости толпы”, карта создается совместными усилиями команды разработки и бизнеса
Учитывает принципы дизайн-мышления
- Дивергентная фаза: генерирование альтернатив
- Конвергентная фаза: выбор из альтернатив
Развивает принципы адаптивного планирования разработки
- Разработка — измерение — корректировки
- Облегчает получение обратной связи через целенаправленное тестирование гипотез и короткие циклы разработки
- На карте проект оказывается разделенным на этапы
и это помогает избежать катастрофических ошибок
Благодаря карте мы измеряем расстояние, на которое продвинулись
к цели и решаем совместно с заказчиком, стоит ли продолжать движение в избранном направлении или сменить вектор движения, предпринять какие-то другие действия. Если достигли цели, перестраиваем KPIs и продолжаем инвестировать в эту часть карты, развивая продукт в этом направлении.
В целом, Impact mapping разделяет и развивает ценности «гибкой разработки». Визуализация, проверка гипотез и короткий цикл разработки. Если что-то не получилось, рекомендуем относиться
к таким ситуациям, как к экспериментам, продемонстрировавшим отрицательный результат, которые в долгосрочной перспективе экономят ресурсы за счет планомерного сужения количества гипотез.