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

При составлении impact maps проект оказывается разделенным на небольшие этапы, а это помогает избежать катастрофических ошибок

визуализируя исходные предположения и обозначая связи между функциональными возможностями продукта, желаемыми влияниями и бизнес-целями, мы облегчаем себе задачу подбора эффективных метрик, позволяющих адекватно оценивать обратную связь и отбирать жизнеспособные идеи. РАЗРАБОТКА

Харфорд называет этот контрольный список «принципами Пальчинского» в честь русского инженера Петра Пальчинского, еще в начале XX века сделавшего вывод, что «проблемы, с которыми мы сталкиваемся в реальном мире, более сложны, чем мы думаем», поскольку им свойственно как человеческое, так и локальное измерение и высока вероятность, что эти факторы не останутся стабильными ввиду изменяющихся обстоятельств. Я уверен, что подобные ситуации знакомы любому, кто имеет хоть какой-то опыт участия в реальных проектах по разработке программного обеспечения. Чтобы решать такие проблемы, Харфорд призывает использовать адаптивное планирование и открыть линии коммуникации между планировщиками и теми, кто «работает в поле».

После того как мы договоримся, чего именно, в каком количестве и как быстро мы хотим достичь, становится гораздо легче оценить, является ли данная задача вообще осуществимой. В книге «Конкурентный инжиниринг» (Competitive Engineering) Том Гилб показывает, каким образом выбор измеримых целей помогает убедиться в их правильности и сфокусироваться на их реализации. Именно акцент на измеримости позволил мне остановить несколько обреченных на провал проектов прежде, чем они начались; в конечном итоге удалось синхронизировать ожидания всех заинтересованных сторон и сформулировать новые цели, которые были одновременно и измеримыми, и реалистичными.

Ключевым признаком здесь является измеримость — если цель измерима, то легче определиться и с остальными обязательными элементами. Например

быть реализованы в течение определенного срока.

Недостаточно просто заявить, что мы будем фокусироваться на бизнес-целях, — важно быть уверенными, что это правильно выбранные цели. Многие проекты терпят неудачу не потому, что они не имеют бизнес-целей, а потому, что цели сформулированы нечетко, конфликтуют с другими задачами или же они не были сообщены людям, которым поручена их реализация. Для обозначения верно выбранных бизнес-целей Скотт Беркун использует обозначение SMART: такие цели конкретны, измеримы, ориентированы на совершение конкретных действий, достижимы и должны

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

Эта проблема характерна не только для IT-индустрии. Как показали исследования поведения командующих офицеров и командиров танковых взводов армии США, если сообщать личному составу только ответы на вопросы «что» и «как», невозможно должным образом подготовить его адекватно реагировать на непредвиденные проблемы. Однако именно этим грешат многие модели, использующиеся в настоящее время для управления требованиями. В быстро меняющихся ландшафтах (таких как разработка программных продуктов) гораздо важнее дать участникам ответы на вопросы «зачем» и «чего следует опасаться».

Неудовлетворительное управление требованиями. Потенциальные преимущества от разработки продукта не были четко обговорены или были завышены.