Impact Mapping — инструкция по применению
Вторая статья из серии инструкций по инструментам, которые помогут сделать лучше ваши продукты и жизнь клиентов.
Impact Mapping — это мощный инструмент продакт-менеджера для декомпозиции цели развития продукта через призму влияния на ее достижение клиентов, инвесторов и других заинтересованных лиц.
Для чего применяется Impact Mapping?
Как строить Impact Map?
Для построения IP вам потребуется:
Вся карта влияния строится по отношению к цели, которую необходимо достичь. Ваша задача последовательно ответить на четыре ключевых вопроса: Зачем? Кто? Как? Что?
Пример использования
Приложение YoTask — мобильное приложение для ведения «списка» (специальный термин, своеобразная CRM в мире сетевого бизнеса), взаимодействия со структурой и контроля показателей работы сети.
Сначала строим полноценную ветку ответов на вопросы. Не обсуждайте детали реализации “что”, задача упражнения построить карту, а не детальный план.
Далее продолжаем строить отростки первой ветки:
После переходим к другим веткам (Кто?) и делаем по аналогии:
В данном примере Impact map строился с каждым (Кто?) отдельно, для экономии времени заинтересованных лиц.
По итогу мы получили: цель, пользовательские истории которые ведут к цели и задачи, которые необходимо реализовать для создания пользовательского опыта.
Кстати, вопреки распространенному заблуждению, чтобы сформировать бэклог из карты влияния, необходимо взять не конечную колонку “Задачи”, а колонки “Кто?” и “Как?” — которые образуют собой пользовательские истории.
Impact mapping, юнит-экономика и PDCA: грамотное управление разработкой ecommerce
Зачастую клиенты обращаются к разработчикам как к волшебникам — с надеждой, что те создадут чудо-ИТ-продукт. Он решит все проблемы: приведёт толпы клиентов, увеличит продажи, снизит издержки. Вот только без усилий самого заказчика и без точных экономических расчётов это невозможно.
Оценивают ли заказчики экономический эффект от внедрения каждой фичи? Ставят ли разработчикам только те задачи, которые стопроцентно приведут к результату?
Практика показывает, что планирование со стороны заказчика, конечно, есть, но бэклог задач, поставленных перед разработчиками, редко соотносится с целями и задачами бизнеса и ещё реже пересматривается.
А ведь после месяцев разработки без понимания экономического эффекта легко прийти к отрицательным результатам и выйти за границы бюджета.
Другая проблема — конфликты интересов отделов и департаментов. Чтобы команда работала эффективно и проект достигал целей быстрее, часть задач в бэклоге должна иметь высший приоритет, а часть — более низкий.
Если у разных отделов (на стороне заказчика) нет понимания, что их задачи справедливо отодвигаются в угоду другим задачам, порождается большое количество домыслов и конфликтов.
Как именно подойти к вопросу планирования управления разработкой с учётом перечисленных проблем, рассмотрим в этой статье.
Эдвард Деминг сформулировал модель непрерывного управления качеством PDCA: plan — do — check — act («планирование — действие — проверка — корректировка»). Цикл PDCA тесно связан с философией agile и также призывает нас действовать короткими итерациями, находиться в тесной связи с реальностью и каждый раз проверять, идём ли мы в нужную сторону.
В одной из своих статей мы уже обсуждали, что программное обеспечение по agile — это запутанные системы с большим количеством факторов, причинно-следственные связи между которыми неясны. При заказе разработки любому заказчику сложно предвидеть все проблемы, с которыми столкнутся программисты, и сформулировать требования к готовому продукту.
Но есть эффективные способы, которые помогут добавить ясности и упорядочить работу. Давайте подробно рассмотрим методику Impact Mapping и юнит-калькулятор как один из прикладных инструментов DDDM (принятие решений на основе данных, data-driven decision making).
Метод Impact Mapping помогает чётко формулировать цели проекта в соответствии с целями всего бизнеса. Для этого нужно построить интеллект-карту с ответами на четыре главных вопроса.
Главное последствие использования карт влияния — чёткое решение бизнес-задач заказчика, а не функциональность ради функциональности.
Допустим, в ИТ-компанию приходит заказчик — владелец крупного интернет-магазина одежды и обуви с запросом на срочный редизайн сайта.
Проектные менеджеры не могут взять задачу с такой формулировкой, потому что это не соответствует data-driven-подходу в принятии управленческих решений.
Сначала нужно спросить зачем и определить цель проекта, затем оцифровать её, записать в числовом выражении. Иначе будет невозможно оценить результаты и сделать выводы («мы молодцы, достигли цели» или «мы не смогли достичь цели, давайте думать, почему и как это исправить»).
Например, после совместного обсуждения может выясниться, что бизнес-цель заказчика — рост продаж на 1,5% в ближайшие три месяца.
Проектным менеджерам необходимо сделать Impact Mapping вместе с заказчиком, и картина может получиться такой: добиться увеличения продаж на 1,5% можно четырьмя способами.
Метод Impact Mapping можно применять и для b2b-проектов, например оценивать процент использования портала при заказах (в идеале — 100 %). Для CRM- или BPM-системы целевым показателем может быть процент пользователей, работающих в CRM, от общего количества сотрудников.
В случае с нашим заказчиком, который хотел редизайн, возникает вопрос: возможно, редизайн ему вовсе не нужен? Чтобы это узнать, сравним все варианты решения и выберем самый выгодный. Полезный метод для такого сравнения — юнит-экономика. Он также помогает проверить, как ваши ценности соотносятся с реальными действиями.
Рассмотрим более подробно полезнейший инструмент: юнит-калькулятор, который мы сами всегда используем для ecommerce-проектов и рекомендуем использовать всем до того, как приступить к задаче на разработку.
Каждое действие (разработка каждого кусочка функции) в идеале должно быть связано с какой-то ценностью проекта. Зелёная кнопка или новый дизайн — всё должно как-то изменить метрики проекта и как-то окупиться. Ведь если разработка не связана с ценностью для бизнеса, затраты на разработку будут казаться заказчику очень высокими.
Юнит-экономика наглядно показывает рентабельность каждого изменения в проекте или проекта целиком: сколько зарабатывает (или теряет) бизнес с каждого заказа, с каждого пользователя, каждого конечного покупателя.
Для этого удобно использовать юнит-калькулятор в виде Excel-таблицы. Давайте рассмотрим самый упрощённый вариант такого калькулятора (на самом деле в юнит-экономике гораздо больше влияющих факторов и гораздо более сложные формулы, но на этом примере мы сможем уловить главные принципы расчёта).
В этой таблице мы меняем значения во влияющих ячейках (поток пользователей или потенциальных клиентов, конверсия, число платящих, доход на одного платящего, сколько в среднем платит клиент, издержки на каждой продаже или комиссия, число покупок на одного платящего), чтобы увидеть изменение значений в зависимой ячейке (gross profit, или доход).
В качестве влияющих ячеек можно добавлять любые факторы вашего конкретного бизнеса. Например, разные каналы продаж, стоимость привлечения новых пользователей, изменение затрат на логистику.
В некоторых случаях, получая задачи от клиентов, мы предлагаем им сначала воспользоваться юнит-калькулятором и оценить, какое влияние окажет внедрение новой фичи и как изменится доход.
Зачем нам это?
Не можем позволить себе работу в стол; дефицит квалифицированных разработчиков и требование рынка постоянно что-то улучшать приводят к тому, что бэклог проекта всегда больше, чем может сделать команда в реальности. Фичи, которые хочет внедрить клиент, нужно сортировать по приоритетам, а от некоторых и вовсе отказываться.
Сейчас мы работаем над ecommerce-проектом для крупного ювелирного бренда. Оплата заказов в их интернет-магазине ведётся на сайте банка. Клиент хочет переделать чекаут и сделать форму оплаты прямо на сайте.
Чтобы взять эту задачу в работу, проектному менеджеру нужно соотнести её ценность с конечными бизнес-целями проекта.
Основной проблемой может стать отсутствие аналитики. Что делать, если никто никогда не отслеживал, какой процент потенциальных покупателей «отваливается» на шаге оплаты? Действительно ли оплата через сайт банка плохо влияет на продажи?
Если разница в конверсии нулевая или незначительная, выгоды от изменения формы оплаты не будет, зато в это время мы не сможем сделать какие-то другие, более значимые функции. Эффект же может быть вообще противоположным: покупатели будут опасаться платить сразу на сайте, что снизит продажи. Без аналитики состояния «до» невозможно понять, хуже или лучше станет «после».
В этом примере сначала нужно подключить веб-аналитику, чтобы собрать данные для обоснованного решения. Если увидим, что проблема действительно есть, будем менять форму оплаты по циклу PDCA: спланировали — изменили — измерили — если результат не удовлетворил, откатили назад.
При заказе разработки клиенты обычно воодушевлены. Им кажется, что теперь-то найдётся та самая волшебная таблетка, которая решит их проблемы. Они фокусируются на ИТ, забывая о конверсии и рентабельности.
После работы с ФРИИ (Фондом развития интернет-инициатив) мы твёрдо усвоили, что составлять Impact Mapping и считать юнит-экономику каждого проекта необходимо до старта работ. И потом при внедрении любых новшеств постоянно их пересматривать и пересчитывать.
В идеале это должен делать заказчик. Но бывает, мы видим, что решения касательно разработки принимаются без учёта конкретных цифр, и в таких случаях готовы помочь консультацией.
Так мы развиваем у наших заказчиков data-driven-подход к принятию управленческих решений, и результаты этой работы нас радуют: bad features сведены к нулю, бизнес-цели клиентов достигаются быстро.
ну вот. Я про PDCA и запутанные среды, а вы опять про Путина! 😉
Интересно, какой процент магазинов могут себе позволить такую разработку. Судя по размаху подхода, то тут стоимость на разработку будет выше прибыли 95 процентов интернет-магазинов.
все интернет-магазины с оффлайновой сетью могут позволить.
Чтобы посчитать юнит-экономику, не нужно быть ни математическим гением, ни ярдовой компанией.
Для этого есть огромное количество практик для этого (тактические: юнит-экономика, Матрица Эйзенхауэра, Scrum Planning Poker, стратегические: Impact Mapping, юнит-экономика).
Часто клиенты убеждены, что разработка сама по себе без нормального целеполагания даст экономический эффект (вот эти вот все «Лишь бы сделать правильную архитектуру», «Сделать UX дизайн», «Реализовать фич больше чем у конкурента»). Не удивительно, что этого не происходит. И чтобы решить эту проблему, клиенты начинают использовать методики упорядоченных систем (техническое задание например).
Методы, которые применяются в упорядоченных системах, не обеспечивают достижения целей бизнеса в запутанной среде (любая разработка выше совсем элементарной).
Думаю, большинство интернет-магазинов даже не располагают данными, обьем которых достаточен, чтобы можно было оценивать статистически значимые изменения. Т.к. на ту же конверсию форм влияет куча переменных, а ведь их все надо определить, измерить и учесть при расчете погрешности.
Погрешности бывают, но те данные, которые можно получить с помощью настройки Гугл.Аналитики, достаточны для принятия большинства управленческих решений.
Определяем конверсию по разным сегментам. Интересуют два: C1, CN (первый покупатель, последующие покупки).
Очень частая ошибка в измерениях C1/CN. Это легко исправляется)
Я имею в виду, что повышение конверсии формы на 10%, допустим, со 100 до 110 заказов, может быть связано как с изменением формы, так и с изменением ценности предложения (у других сейчас дешевле/нет/плохие условия доставки и т.п.), суточной/недельной и выше динамикой спроса, погодой, праздниками, новостями, изменением характера трафика или вообще входить в стандартный разброс.
Словом, малые выборки показательны только на периодах, когда они становятся большими, однако на больших периодах возрастает количество и роль неизвестных факторов. Ведь так?
Это да. На маленьких цифрах (маленький трафик, малое количество заказов, маленькая история измерения) сложно делать выводы на причины.
Несколько соображений конкретно по интернет-магазинам:
Воронка нижних уровней как правило не подвержена очень сильным колебаниям на протяжении месяца: если в чекауте до заполнения всех полей доходило от исходного числа 15%, то так и доходят. Даже сезоны со скидками вроде черной пятницы не приводят к сильным колебаниям конверсии там, так что можно попробовать так наблюдать. Так что я бы посоветовал посмотреть туда.
Не станем говорить про A/A/B тесты потому что у маленьких проектов нет денег на поддержание сложной инфраструктуры с тремя версиями проекта (мы же говорим про целеполагание в разработке, с маркетингом можно обойтись только GTM+Google Experiments)
Impact Mapping: четыре первых этапа эффективного метода разработки
Главный редактор RB.RU
Rusbase публикует отрывок из книги консультанта по стратегиям разработки ПО Гойко Аджича «Impact Mapping: Как повысить эффективность программных продуктов и проектов по их разработке», которая вышла на русском языке в издательстве «Альпина Паблишер». Рассказываем о первых шагах Impact Mapping и объясняем, почему вам это нужно, даже если вы не собираетесь переходить на Agile.
Что такое Impact Map?
Смысл продуктового дизайна — найти и протестировать потенциальные решения, которые могли бы быть полезны. Здесь критически важны не столько сами по себе причины и вызываемые ими следствия, сколько проверка самих гипотез, их соединяющих. Реальную ценность удается создавать в тех случаях, когда предположения подтверждены данными неоднократных практических экспериментов. Impact maps — это, по сути, карты гипотез, связывающих причины со следствиями. Они помогут вам понять, какие вопросы следует задавать — и это гораздо труднее, чем находить верные ответы.
Подобно тому, как карты автомобильных дорог показывают, какие дороги соединяют большие и малые населенные пункты, impact maps описывают, какой продукт мы хотим создать и как именно с его помощью мы собираемся облегчить жизнь пользователям. При этом следует иметь в виду, что основная цель автомобильной карты не столько давать подробную информацию о городах и других населенных пунктах, сколько четко указывать, как проехать от одного из них к другому. Ее дополнительная цель — помочь нам прокладывать альтернативные маршруты.
Наглядно продемонстрированные на impact maps узлы и предположительные способы обеспечения переходов между ними позволяют вовлекать в обсуждение специалистов любого профиля. Impact maps создают понятный для всех контекст и в явном виде отражают те неопределенности, с которыми будет необходимо разобраться экспериментальным путем. Подобно дорогам, закрытым для проезда или находящимся в стадии строительства, определенные исходные предположения могут оказаться нежизнеспособными или попросту неправильными. Поэтому соответствующие карты и называются картами автомобильных дорог, а не «картами назначения».
Impact maps помогают визуализировать исходные гипотезы, которые и проверяются впоследствии опытным путем.
Бесчисленное множество программных продуктов не оправдывает вложенных инвестиций. Главная проблема — в неправильных заданиях и плохой коммуникации. Миллиарды тратятся впустую из-за того, что заказчик не может точно сформулировать цели, а исполнитель неверно воспринимает задачу. На выходе — продукт, который никому не нужен.
Но должны же существовать эффективные методы работы! Таким мы считаем impact mapping — метод разработки, помогающий еще на стадии стратегического планирования организовать сотрудничество специалистов. С его помощью вы обеспечите соответствие разрабатываемого программного обеспечения исходным целям. Этот инструмент универсален и подойдет как для Agile-проектов, так и для классического проектного подхода.
Четыре начальных этапа Impact Mapping
1. Цель
Центральная часть impact map должна отвечать на самый важный вопрос: зачем мы это делаем? Это цель, которую мы стремимся достичь.
Может показаться, что стремление в самом начале проекта получить ясный ответ на этот вопрос — всего лишь проявление здравого смысла. Однако мой опыт показывает, что лишь немногие из разработчиков точно знают, какие бизнес-цели преследует заказчик. Иногда их описывают в каком-либо формальном документе, но чаще всего бизнес-цели существуют лишь в головах заинтересованных лиц.
Даже в тех редких случаях, когда бизнес-цели доводятся до разработчиков, они зачастую сформулированы весьма смутно.
Исследование, проведенное Гэри Кляйном на материале аварийно-спасательных служб и армейских подразделений, показало, что при осуществлении любой деятельности люди на местах должны понимать конечные цели операции, иначе они не в состоянии правильно реагировать на непредвиденные проблемы. Если очередной релиз или проект в целом позволяет достичь поставленной бизнес-цели, то это успех с точки зрения бизнеса, даже если в итоге разработанный продукт будет отличаться от того, что было предусмотрено первоначально.
В то же время, если программный продукт точно соответствует задуманным спецификациям, но при этом не позволяет решить поставленную бизнес-задачу, его следует признать провальным. Это верно даже тогда, когда разработчики не без оснований обвиняют клиента, что он сам толком не понимает, чего хочет.
Поместив ответ на вопрос «ЗАЧЕМ?» в центр impact map, мы получаем возможность убедиться, что все знают, зачем они выполняют те или иные действия. Это помогает командам лучше соотносить свою текущую деятельность с конечной целью, точнее формулировать требования к функциональности и находить оптимальные с точки зрения дизайна решения.
Обозначенная цель дает разработчикам инструмент для пересмотра первоначальных планов по мере поступления новой информации. Поэтому верно сформулированные цели, как правило, соответствуют критериям SMART: они конкретны, измеримы, ориентированы на совершение конкретных действий, достижимы и ограничены во времени.
Цели не должны описывать сам продукт, процесс его создания или устанавливать границы проекта. Они обязаны объяснять, почему данный продукт будет полезен.
Целям следует определять проблему, которую предстоит решить, а не воспроизводить решение. Избегайте включать в описание цели какие-либо конструктивные ограничения, касающиеся готового продукта.
Попробуйте сначала сформулировать, в чем состоит бизнес-ценность проекта, а затем объяснить, каким образом в результате осуществления задумки ситуация изменится, — обозначив при этом цели в качестве этапов постепенного приращения бизнес-ценности. Это особенно эффективно, если у вас уже есть набор ключевых показателей, по которым будет оцениваться эффективность данного продукта.
Для коммерческих продуктов и организаций старайтесь формулировать цели таким образом, чтобы связь с зарабатыванием денег была очевидной.
2. Действующие лица
Первый уровень impact map дает ответы на следующие вопросы: на чье поведение мы хотим воздействовать? Кто сможет произвести желаемый эффект? Кто способен помешать? Кто является потребителем или пользователем нашего продукта? На кого наш продукт повлияет? Это и есть те действующие лица, чье поведение может сказаться на результатах проекта.
Джеральд Вайнберг Автор и преподаватель антропологии и психологии разработки ПО определяет качество как «ценность, предоставляемую кому-либо». Чтобы обеспечить высокое качество результатов, мы сначала должны выяснить, кто эти люди и какую ценность они хотят обрести, воспользовавшись продуктом или результатами нашего проекта.
В дополнение к тем, кто непосредственно получит ценность от пользования нашим программным продуктом, мы также должны учитывать интересы множества других людей, чьи решения будут так или иначе влиять на успех продукта или исход проекта. Программное обеспечение работает не в вакууме, и редко когда изначально удается поставить под контроль поведение всех действующих лиц, так или иначе с ним связанных.
У людей есть свои собственные потребности, цели и предпочтения, которые имеют значение, если мы действительно хотим достичь какой-либо бизнес-цели. И тем не менее большинство моделей управления акцентирует внимание на конкретных функциях программного обеспечения, а не на людях, для которых оно будет полезным. Затем где-то в середине работы из ниоткуда появляется новое действующее лицо, и все коренным образом меняется. Как вариант, кто-то с достаточными полномочиями может вообще неожиданно приостановить разработку.
Impact maps заставляют задуматься обо всех, кто принимает решения, а также о разных группах пользователей и разных категориях клиентов. Определившись со списком действующих лиц, мы приобретаем способность лучше расставлять приоритеты в своей работе.
К важным действующим лицам относятся конечные пользователи, а также внутренние или внешние по отношению к проекту люди, принимающие решения. Алистер Коберн советует искать действующих лиц трех типов:
Необходима максимальная конкретность. Избегайте слишком общих терминов. Постарайтесь определять круг лиц в таком порядке: конкретные персоны, целевые пользователи, действующие лица, вовлеченные в проект в силу своей роли или занимаемой должности, группы или отделы.
На втором уровне нашей impact map необходимо соотнести действующих лиц с нашей бизнес-целью. При этом нужно получить ответы на следующие вопросы: как должно измениться поведение действующих лиц? Как они могут помочь нам достичь цели? Как они могут создать нам препятствия или помешать добиться успеха? Это и есть те влияния, которые мы стремимся осуществить.
Энтони Ульвик писал, что ключом к успешной разработке продукта является понимание, какую именно работу клиенты хотят видеть выполненной при помощи вашего продукта. Это помогает рассмотреть различные технические варианты решений и проанализировать те из них, что могут привести к желаемым результатам. К тому же это позволяет сфокусировать разработку на решении задач, стоящих перед пользователями.
Перечисляя на втором уровне impact map желательные влияния, мы указываем, каких изменений в поведении действующих лиц мы хотим добиться.
Это способствует разработке более точных планов и четкой приоритизации. На нашем пути к достижению ключевых бизнес-целей разные действующие лица будут разными способами как помогать, так и мешать нам. Некоторые из влияний станут конкурировать друг с другом, между некоторыми обнаружатся противоречия, а какие-то из них дополнят друг друга. Мы вовсе не обязаны заниматься всеми влияниями без исключения; однако если их не учесть при определении границ проекта, то будет очень трудно определить приоритеты и сравнить разные варианты решений.
Поскольку impact maps имеют иерархическую природу, то с их помощью становится очевидно, кто именно должен оказать необходимое влияние и как именно оно поспособствует достижению цели. Визуализация позволяет выявить, какие влияния будут наилучшим образом способствовать достижению цели и какие риски могут поджидать нас на этом пути; все это позитивно сказывается на расставлении приоритетов.
Не стремитесь перечислить все возможные запросы данного действующего лица. В список должны войти только те влияния, которые действительно помогут вам продвинуться к основной цели.
Список влияний — это не список функциональных возможностей будущего продукта. Избегайте перечисления исключительно «программистских» идей — на этом этапе в фокусе внимания должны находиться бизнес-аспекты проекта.
В идеале следует описать те изменения, которые произойдут в поведении того или иного человека, а не просто его поведение после развертывания продукта. Опишите, чем его будущее поведение будет отличаться от возможного на данный момент. Поэтому вместо того, чтобы просто указать на impact map «продавать билеты», следует использовать иные формулировки, например, «продавать билеты в пять раз быстрее».
Учитывайте не только позитивные, но и негативные или прямо препятствующие достижению цели влияния.
У важных действующих лиц часто есть несколько способов помогать или препятствовать благополучному исходу проекта. После того как вы идентифицируете одно из вероятных влияний данного лица, не останавливайтесь и поймите, какие еще способы воздействия на исход проекта есть в его распоряжении.
4. Поставляемый функционал
Теперь можно переходить к обсуждению границ проекта. Третий уровень impact map призван ответить на следующий вопрос: что мы можем сделать, чтобы добиться необходимых влияний? Имеются в виду ожидаемые результаты проекта, поставляемые функциональные возможности и организационные изменения, которые могут потребоваться в этой связи.
Планы разработки и документы, описывающие требования к готовому продукту, зачастую похожи на списки покупок и не содержат каких-либо внятных пояснений, почему тот или иной функционал будущего продукта является столь важным. Если не установить четких связей между бизнес-целями и списком желаемого функционала и не поддержать эти связи с помощью перечня необходимых влияний, то будет невероятно сложно договориться о том, в какой потенциально возможный функционал следует инвестировать, а в какой нет.
Impact map показывает, какие именно желательные влияния должны быть оказаны при помощи заявленных функциональных характеристик. Это помогает разделить проект на независимые этапы, каждый из которых обладает самостоятельной бизнес-ценностью, тем самым позволяя получить ценные с точки зрения бизнеса результаты как можно раньше.
Четкая иерархичность impact map позволяет объединить связанные между собой функциональные характеристики в группы, сравнить их и воздержаться от чрезмерного инвестирования в удовлетворение запросов наименее важных действующих лиц или наименее значительные влияния.
Это также помогает отказаться от реализации тех частей проекта, которые на практике не способствуют достижению ни одной из важнейших целей. И, наконец, увязывая функциональные возможности продукта с желаемыми влияниями и бизнес-целями, impact map позволяет визуализировать цепочку рассуждений, в результате которых заинтересованные лица приняли решение включить в готовый продукт ту или иную функцию. Это делает логику принятия решений более очевидной.
Рекомендации
Не пытайтесь с самого начала отметить все до единого элементы. Вы сможете уточнить тонкости в несколько итераций по мере продвижения разработки.
Рассматривайте свое первоначальное представление о готовом продукте в качестве факультативного: что не все желаемые функциональные возможности в итоге будут непременно реализованы.
На ранних этапах проекта старайтесь не погружаться в излишние детали, вы сможете уделить им внимание позже. Поначалу вас интересует только функциональность самого высокого уровня. Позже вы всегда сумеете разложить эту функциональность на составляющие более низких уровней.
Даже когда необходимость в новом программном обеспечении кажется очевидной, нередко есть альтернативные способы решить бизнес-задачу, не прибегая к разработке продукта. Так, для вовлечения в онлайн-игру новых игроков иногда оказывается дешевле разместить рекламу, чем потратить месяцы на переделку имеющейся платформы. Не отказывайтесь от любых вариантов, которые помогут оказать необходимое влияние.
Туда же попадает полезный non-fiction, который упоминался на Rusbase по тегу #Books.
