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

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

тем не менее большинство моделей управления акцентирует внимание на конкретных функциях программного обеспечения, а не на людях, для которых оно будет полезным

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

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

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

Поэтому верно сформулированные цели, как правило, соответствуют критериям SMART: они конкретны, измеримы, ориентированы на совершение конкретных действий, достижимы и ограничены во времени.

Поместив ответ на вопрос «ЗАЧЕМ?» в центр impact map, мы получаем возможность убедиться, что все знают, зачем они выполняют те или иные действия. Это помогает командам лучше соотносить свою текущую деятельность с конечной целью, точнее формулировать требования к функциональности и находить оптимальные с точки зрения дизайна решения.

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

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

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