Цитаты из книги «Impact mapping: Как повысить эффективность программных продуктов и проектов по их разработке»

Безусловно, в ходе переговоров разработчики не могут просто заявить, что они потратят все время и деньги, отпущенные на проект. Именно поэтому перед заказчиками открывается возможность попытаться сократить бюджет разработки путем переговоров. С позиции разработчика более эффективно представить исходные гипотезы и риски в максимально наглядном виде и договориться с заказчиком о том, что инвестиции будут осуществляться поэтапно. Если цели сформулированы правильно, то их всегда можно привести к денежному выражению и решить, будет ли получен удовлетворительный возврат на инвестиции.

Тим Браун пишет, что дизайн-мышление — это «танец между четырьмя ментальными состояниями»: дивергентным и конвергентным мышлением, анализом и синтезом.

«ад пользовательских историй».

У многих организаций не получается воспользоваться всеми преимуществами пользовательских историй, поскольку изначально их создают слишком много, пытаясь охватить весь проект и ничего не упустить. Да, при таком подходе необходимость в тяжеловесном предпроектном анализе снижается, но мы все равно остаемся со слишком масштабным списком пользовательских историй. Всеми этими историями необходимо управлять, что приводит к пустой трате времени. Хуже того, если в бизнесе заказчика что-то изменилось и требуется масса усилий, чтобы заново расставить приоритеты или даже вообще разобраться в этих перечнях.

Это происходит потому, что они просят пользователей расставлять приоритеты между функциями, которые предполагается включить в готовый продукт. В итоге пользователи начинают диктовать последовательность разработки. Impact maps позволяют при обсуждении приоритетов сосредоточиться на бизнесе заказчика и необходимых влияниях (второй уровень карты), а не на характеристиках продукта и конкретной функциональности (третий и более низкие уровни). По моему опыту, когда обсуждение осуществляется на втором уровне, вовлеченность пользователей оказывается гораздо выше и им удается принимать более эффективные решения.

С помощью карт мы можем предоставлять заказчику промежуточную информацию о состоянии проекта на гораздо более значимом уровне — делая акцент на реализованных воздействиях или указывая ту область, где мы планируем сосредоточить свои усилия с точки зрения решения бизнес-задачи. Impact maps позволяют нам делать акцент на влияниях, которых мы планируем достичь, а не на конкретной функциональности; в результате спонсоры проекта видят, что мы делаем в данный момент и чем собираемся заниматься в ближайшем будущем. При этом мы сохраняем свободу выбора способов решения той или иной задачи.

Одна из распространенных причин разрыва в коммуникации между бизнесом и разработчиками — поставка осуществляется слишком небольшими инкрементами, которые с точки зрения бизнеса не вызывают сколько-нибудь ощутимых улучшений. В результате проект превращается в бесконечную вереницу вносимых в продукт мелких изменений — при этом может быть утрачено представление об общей картине или крупных преимуществах,

Многие организации применяют схему, которую Дэйв Уэст назвал Water-Scrum-Fall

«Бизнес с нуля» Эрик Рис предложил новаторский подход к дизайну продуктов, процессу разработки и управлению компаниями. В его основе лежат две важные идеи: получение обратной связи через целенаправленное тестирование гипотез и короткие циклы разработки. В книге Риса не слишком много говорится о том, как выбирать гипотезы для тестирования или как приоритизировать процесс тестирования в рамках цикла разработка–измерение–обучение.

Харфорд призывает использовать адаптивное планирование и открыть линии коммуникации между планировщиками и теми, кто «работает в поле».