Благодарим за помощь в создании книги компанию ScrumTrek в лице управляющего партнера компании Алексея Пименова
Переводчик А. Олейник
Редактор К. Бычкова
Руководитель проекта А. Василенко
Корректор Е. Аксёнова
Компьютерная верстка А. Абрамов
Дизайн макета и обложки Никола Корач
© Gojko Adzic, 2012
© Provoking Thoughts, 2012
© Издание на русском языке, перевод, оформление. ООО «Альпина Паблишер», 2017
Все права защищены. Произведение предназначено исключительно для частного использования. Никакая часть электронного экземпляра данной книги не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами, включая размещение в сети Интернет и в корпоративных сетях, для публичного или коллективного использования без письменного разрешения владельца авторских прав. За нарушение авторских прав законодательством предусмотрена выплата компенсации правообладателя в размере до 5 млн. рублей (ст. 49 ЗОАП), а также уголовная ответственность в виде лишения свободы на срок до 6 лет (ст. 146 УК РФ).
* * *
Разработка программного обеспечения внутри компаний за редкими исключениями уже давно выделилась в самостоятельную функцию. При этом коммуникация с остальными подразделениями организации, чье функционирование программисты призваны поддерживать своими разработками, зачастую оставляла желать лучшего. Сотрудники других отделов могли в целом не понимать, что такое программное обеспечение, а разработчики, в свою очередь, быть недостаточно осведомленными о потребностях бизнеса, которым занимается компания.
С одной стороны, проблемы с коммуникацией слишком часто приводили к тому, что на выходе получался совсем не тот продукт, который был необходим, или (в лучшем случае) не совсем тот. С другой – они становились причиной неэффективного управления проектами и неоправданного роста затрат. Внедрение гибких методологий позволило существенно ускорить циклы обратной связи и успевать изменять продукт под потребности до того, как закончится бюджет на разработку.
Нам необходимы подходы, которые помогут разработчикам стать полноправными партнерами других подразделений и создавать продукты, с энтузиазмом принимаемые пользователями, а это, в свою очередь, приведет к успеху в бизнесе. В основе сотрудничества разработчиков и заказчиков должна лежать именно эффективная коммуникация. Такой коммуникации мешает различный взгляд на вещи и даже разный словарь, используемый разработчиками программного обеспечения и всеми остальными. Поэтому важно научиться визуализировать проблемы, над решением которых приходится работать совместно, – это даст возможность осмысленно участвовать в разработке независимо от своей предметной области, будучи при этом уверенными, что мы говорим об одном и том же. В качестве инструмента визуализации в гибких методологиях используется принцип «работающее ПО». Его смысл в том, что разработчики быстро реализуют небольшой набор пожеланий к продукту, и это сразу же обеспечивает обратную связь от реальных пользователей. Идеология «работающего программного обеспечения» действительно дает возможность удостовериться, что принятые ранее решения являются правильными, однако эта идеология никак не помогает отбирать из уже имеющегося набора пожеланий к продукту именно те, реализация которых будет наиболее ценной с точки зрения пользователей и вызывать у них максимум энтузиазма.
Множество барьеров на пути эффективного сотрудничества возникает из-за неразделенных, никогда не обсуждавшихся и непроверенных исходных предположений. Специалисты в разных областях исходят из разного набора допущений и гипотез. Если эти допущения и гипотезы сформулировать в явном виде, то получится их своевременно проанализировать и протестировать. В результате все последующие решения будут приниматься гораздо быстрее. Именно с этой точки зрения impact maps (карты влияния) являются эффективным инструментом. Они позволяют в наглядном виде представить ответы на вопросы «ЗАЧЕМ», «КТО», «КАК» И «ЧТО», связанные с проблемой, которую необходимо решить в рамках конкретного проекта.
Подобно тому, как карты автомобильных дорог показывают, какие дороги соединяют большие и малые населенные пункты, impact maps описывают, какой продукт мы хотим создать и как именно с его помощью мы собираемся облегчить жизнь пользователям. При этом следует иметь в виду, что основная цель автомобильной карты не столько давать подробную информацию о городах и других населенных пунктах, сколько четко указывать, как проехать от одного из них к другому. Ее дополнительная цель – помочь нам прокладывать альтернативные маршруты.
Наглядно продемонстрированные на impact maps узлы и предположительные способы обеспечения переходов между ними позволяют вовлекать в обсуждение специалистов любого профиля. Impact maps создают понятный для всех контекст и в явном виде отражают те неопределенности, с которыми будет необходимо разобраться экспериментальным путем. Подобно дорогам, закрытым для проезда или находящимся в стадии строительства, определенные исходные предположения могут оказаться нежизнеспособными или попросту неправильными. Поэтому соответствующие карты и называются картами автомобильных дорог, а не «картами назначения».
