Энциклопедия маркетинга, https://www.marketing.spb.ru

Адрес документа: https://www.marketing.spb.ru/lib-comm/dm/Selling_Ideas_with_Pictures.htm
Обновлено: 20.11.2017

Как представить идею путем ее визуализации

Дэн Роэм; пер. О. Медведь Глава из книги «Визуальное мышление. Как «продавать» свои идеи при помощи визуальных образов»
Издательство "Манн, Иванов и Фербер"

Кто наши клиенты?

Потребительский кризис

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

Итак, нам уже известно, как выбрать правильную структуру, — для этого мы воспользуемся Кодексом визуального мышления, а поскольку в данном случае наша проблема касается людей («кто» наши клиенты), Кодекс рекомендует начать с портрета, или с качественного представления.

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

Портреты: общие правила построения

  1. Не усложняйте. Помните: ваша цель заключается не в том, чтобы достичь уровня мастерства Рембрандта, — по сути, излишне детальный и проработанный рисунок неизбежно привлекает к себе слишком много внимания аудитории и отвлекает от идеи, которую вы намерены до нее донести. Чем проще, тем лучше: старайтесь визуально «телеграфировать» идею, а не живописать картину.
  2. Украшайте миниатюрными рисунками составляемые вами списки. Цель создания портрета в бизнесе — стимулирование неожиданных количественных идей, которые возникают, когда рука и воображение работают в унисон; визуальное отражение кого-либо или чего-либо (независимо от реальной похожести и деталей) всегда порождает новые идеи, которые могут так и не возникнуть при составлении обыкновенного перечня.
  3. Описывайте визуально. Если вы ограничены во времени (а в бизнесе времени всегда не хватает), помните, что рисунки всегда будут более эффективны, если сравнивать какие-либо объекты, а не описывать их. Сравнительные портреты могут представлять собой простейшие схематичные рожицы-смайлики, но даже такая минимальная визуализация оживляет объекты и делает их более запоминающимися.

Запомнив эти правила, вернемся к созданию портрета нашего клиента. Структуру мы уже выбрали, а теперь ответим на пять вопросов модели SQVID. Итак, каким должен быть рисунок — простым или прорисованным в деталях? Учитывая, что это наша первая попытка графически изобразить своего клиента, лучше остановиться на чем-то более простом. Количественным или качественным? Поскольку это портрет, рисунок по умолчанию будет описывать качество.

Видение или исполнение? На данном этапе мы пока не обсуждаем ни того, куда бы мы хотели прийти, ни того, как это сделать, так что этот вопрос к нашему рисунку не относится: просто пропустим его. Индивидуальные характеристики или сравнение? Поскольку мы будем рассматривать весь диапазон клиентов, лучше выберем сравнение. Изменение или обычное состояние, т. е. статус-кво? Учитывая, что в итоге мы надеемся определить клиентскую базу, на этой стадии наш портрет должен отражать ситуацию статус-кво, но, в зависимости от того, что мы обнаружим, возможно, впоследствии нам придется изобразить изменения. Суммируя все вышесказанное, приходим к тому, что исходная структура нашего портрета будет довольно простой: лаконичный портрет нескольких типов клиентов, что-то вроде ©©©. Итак, мы наконец готовы приступить к рисованию.

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

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

А позволяет ли нам такое представление самих себя найти какую-либо идею относительно того, как бы нам представить своего основного клиента? Что, если мы дорисуем и его?

Даже такой рисунок с минимальным количеством компонентов дает некоторое представление о взаимосвязи между нами и клиентом и помогает нам представить, как следует подойти к созданию его портрета.

Если уж мы собираемся показать людей, то почему бы снова не начать с себя? Это ничего не скажет нам о наших клиентах, но, нарисовав себя (то, что мы знаем очень хорошо), мы определим нужные рамки для обдумывания того, как изобразить их.

Итак, это мы: на картинке начинают появляться смайлики, о которых мы уже не раз упоминали.

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

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

Теперь, прежде чем приступить к демонстрации нашего творения, нам остается сделать только одно — снабдить все элементы пояснительными подписями.

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

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

Хотя наша картинка предельно проста, это очень полезный «каркас» для отражения других качественных характеристик наших клиентов. Например, недавно проведенное маркетинговое исследование показало, что каждый из выявленных нами типов клиентов ожидает от наших бухгалтерских программ конкретных свойств и функций. Поскольку клиенты — руководители фирм в конечном счете ответственны за все (и плохое, и хорошее), к чему приводит использование наших программных продуктов их сотрудниками, они хотят иметь программы, доступные для их персонала, но недоступные другим пользователям; иными словами, они прежде всего стремятся к безопасности. Торговый персонал желает иметь продукт, способный облегчить его задачу — продавать услуги своей компании; следовательно, им нужно программное обеспечение с хорошей репутацией, для них главное — пользующийся спросом бренд. Бухгалтеры, разумеется, выше всего ценят точность и стабильность и стремятся к надежности используемых ими программ. А инженеры всегда хотят иметь программы, которые без труда совмещаются с другими системами и легко поддаются модернизации, т. е. их главное требование — гибкость программного обеспечения. Как видите, список пожеланий довольно велик, и его намного легче усвоить, прибегнув снова-таки к визуализации. Нарисуем еще один рисунок.

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

Сколько наших продуктов покупают?

Потребительский кризис — на этот раз в цифрах

Итак, мы увидели своих клиентов (по крайней мере так, как мы их сами представляем), отметили некоторые различия между ними и даже стали обдумывать, чего именно они ожидают от программного обеспечения, разрабатываемого нашей компанией. Все это весьма полезная информация, призванная помочь компании добиться возобновления роста объемов продаж, но это только начало. Чтобы все эти данные приобрели для нас еще большее значение, необходимо узнать, сколько у нас клиентов каждой категории, количественно определить, сколько из них готовы тратить деньги на продукты, подобные нашим, и даже постараться в количественном выражении оценить их отношение к предлагаемой нами продукции. То есть теперь мы говорим уже не о категории «Кто» и «Что» — теперь нам предстоит ответить на вопрос «сколько?». В этой ситуации Кодекс визуального мышления рекомендует перейти от портрета к диаграммам: рисункам, которые отражают количество, иллюстрируют подлежащие оценке критерии, представляют количественные сравнения. В отличие от портретов, которые мы можем создавать, не располагая никакой количественной информацией, для диаграмм нужны цифры, показания и данные.

После того как мы заметили и распознали кого-то или что-то, мы отмечаем количество разных объектов и их компонентов. Если «сколько» — небольшое число, наш мозг быстро подсчитывает общее количество; относительно более внушительных показателей мы делаем приблизительную прикидку, а о внушительных цифрах просто говорим: «Этого много». Чтобы представить данные подобного рода другим людям, мы используем диаграмму (или количественное представление), позволяющую преобразовать абстрактные цифры в визуальную, конкретную картину, отражающую количество.

Диаграммы: общие правила

  1. Важнее всего данные, их и нужно продемонстрировать. Многие люди считают изучение цифр ужасно скучным занятием, поэтому мы зачастую стараемся составлять диаграммы, используя разнообразные, пусть и не слишком нужные, но привлекательные украшения. Мы искренне надеемся, что это сделает наши картинки более интересными, особенно если намерены показать аудитории не один, а несколько таких рисунков. В связи с этим предлагаю вашему вниманию три ценные мысли: во-первых, нужные, полезные сведения никогда не бывают скучными. Если наша мысль действительно заинтересует аудиторию (либо потому, что точно совпадает с ее ожиданиями, либо потому что людей восхищают новые идеи), можете не бояться — во время вашего выступления никто не заснет. Во-вторых, чтобы продемонстрировать идею и в чем-то убедить людей, нужно использовать минимально возможное количество картинок. Всегда следует либо ограничивать количество рисунков на одну и ту же тему, либо объединять их в один-два графика с переменными параметрами (подробнее об этом мы поговорим несколько позже). И в-третьих, добавление к таким презентациям изображений человечков — если это логично и оправданно — многократно усилит их когнитивное воздействие. Иными словами, если вы считаете клиентов, покажите это в своем рисунке.

  1. Для изложения своей точки зрения используйте простейшую модель. Последняя версия самой популярной компьютерной программы для создания масштабных электронных таблиц включает девяносто девять готовых вариантов диаграмм, поэтому неудивительно, что мы можем испытывать затруднения, решая, какой из них выбрать. Однако различаются они только с виду. На самом деле девяносто девять процентов вариаций — это только разновидности четырех базовых типов изображений: в виде столбцов, линий, секторов или кружков. Все остальное — не что иное, как приукрашенные версии одного из видов. Если к выбору правильного способа относиться определенным образом, у вас никогда не возникнет особых проблем.
    • Столбцы используются для сравнения абсолютных величин (например, 1000 яблок с 800 апельсинами и 120 грушами).
    • Линии и зоны используются для сравнения абсолютных величин по двум разным критериям или в разных временных точках (на пироги пойдет 1000 яблок, 0 апельсинов и 60 груш, а на торт 0 яблок, 800 апельсинов и 60 груш). (Временные шкалы мы более подробно рассмотрим при изучении структуры «Когда».)
    • Сектора используются для сравнения относительных величин (52% яблок, 42% апельсинов, 6% груш).
    • Кружки применяются для сравнения более чем двух переменных (мы обсудим их подробнее в главе 14, когда будем говорить о структуре «Яочему»).
  2. Строго придерживайтесь выбранной модели. Если диаграмма построена с применением подходящей для представления конкретного типа данных системы координат и в ее основе лежат прекогнитивные признаки, аудитория должна понять вашу идею очень быстро. Однако ни в коем случае не следует испытывать ее способности и терпение, внезапно изменяя расположение осей координат, меняя тип диаграммы или предлагая какой-то совершенно отличный от первого подход к осмыслению проблемы. Подумайте о процессе представления серии разных диаграмм как о поездке на автомобиле по красивой местности: плавные и ожидаемые изменения пейзажа будут очень приятны глазу, а вот сорваться вдруг со скалы вряд ли кому-нибудь понравится.

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

Если говорить о количественном составе потребительской аудитории, то ничего точнее этого рисунка невозможно и придумать: на нем они как будто собрались на парковке у нашего офиса и сделали коллективную фотографию. Но если говорить честно, наша картинка недостаточно хороша: во-первых, хотя мы и можем различить во всей этой мозаике представителей разных типов, мы не можем увидеть группы (потому что они все перемешаны друг с другом); и во-вторых, разные категории очень трудно подсчитать и сравнить. Мы видим их количество, но точные математические расчеты в этом случае невозможны. Следовательно, необходимо включить в рисунок систему координат и суммарные данные.

Что ж, уже намного лучше. Теперь мы можем классифицировать и сравнивать разные типы клиентов за считаные секунды. Сразу отметим, что бухгалтеров среди наших клиентов намного больше, чем продавцов; инженеров почти в два раза меньше, чем специалистов по сбыту, а руководителей совсем мало. Однако следует признать, что на создание такого рисунка может уйти немало времени. Нам нужен более простой способ отражения количественных показателей, чтобы не нужно было изображать отдельно каждого клиента. Давайте попробуем сделать так: откажемся от рисунка вообще и просто покажем цифры на листе бумаги.

В этом случае мы тоже получаем точное количественное выражение данных, но утрачиваем моментальность восприятия, которую обеспечивает визуальная презентация. Теперь нам требуется несколько секунд, чтобы пробежаться взглядом по строкам и столбцам таблицы и сравнить сведения о разных типах потребителей. Кроме того, в этой таблице, что называется, не за что зацепиться зрительной памяти: если мы, например, не отличаемся способностью запоминать точные цифры, то в данной ситуации не сможем прибегнуть к помощи более широкого контекста. Иными словами, очевидно, что нам нужна комбинация, объединяющая наилучшие качества обоих этих вариантов представления количественных данных. Может, оптимальной будет столбчатая диаграмма?

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

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

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

Однако нельзя не упомянуть об одной проблеме, типичной для диаграмм: поскольку в ней отражается только количество, легко забыть о других важных отличиях, которые могут существовать между оцениваемыми и сравниваемыми объектами. Иными словами, хотя цифры, представленные при количественном сравнении, точны, они все равно могут привести нас к неправильному выводу. Например, если бы продемонстрированная выше секторная диаграмма была единственным мерилом количества наших клиентов, то теоретически у нас оставался бы один-единственный выбор — предположить, что нам следует выделить 75% маркетингового бюджета на клиентов-бухгалтеров, так как они составляют 75% всех зарегистрированных пользователей наших программ. Однако вполне возможно, что это не соответствовало бы реальному положению дел в сфере сбыта нашей компании.

Великая битва секторальный диаграмм

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

Представим теперь, что в процессе анализа сведений о сбыте компании мы подошли к изучению заказов наших клиентов на покупку. В них указаны уплаченные ими суммы с указанием фамилий заказчиков — не тех, на кого зарегистрировано купленное у нас программное обеспечение, а его непосредственных покупателей. Воспользовавшись диаграммой другого типа (не секторной, ведь в данном случае нас интересуют абсолютные показатели, а не проценты), мы видим, что за последний год потребители-бухгалтеры потратили на наши продукты 100 тыс. долл., в то время как торговый персонал всего 5 тыс. долл.

Мы видим, что картина совершенно изменилась. Хотя бухгалтеры составляют треть зарегистрированных клиентов компании, они приобрели наши продукты на чуть большую сумму, чем специалисты. И это притом, что группа технических специалистов очень мала, меньше нее только группа руководителей! Это уже интересно — кто бы мог подумать, что инженеры так активно покупают бухгалтерские программы! Чтобы получить еще более четкую картину, составим еще одну диаграмму, на этот раз с учетом количества клиентов каждого типа и сумм, затрачиваемых ими на наши продукты. В результате довольно простых математических вычислений (делим суммарные затраты на число клиентов каждой категории) получаем следующую картину: один руководитель в среднем тратит на наши программы 5500 долл., один инженер — 5300 долл., а один бухгалтер всего 640 долл.

Ого! Вы только посмотрите: хотя на ИТ-специалистов и руководителей приходится всего половина суммарных закупок наших продуктов, индивидуальная покупательная способность каждого из представителей этих двух категорий почти в девять раз выше, чем у бухгалтеров. А ведь все предыдущие диаграммы этого важнейшего факта не отражали. И хотя эта диаграмма не показывает, почему значение по разным типам клиентов столь сильно варьируется, задуматься, несомненно, есть над чем. Может, технические специалисты приобретают значительную долю программ от имени бухгалтеров? Если так, они обладают поистине огромной покупательной способностью. А как вам тот факт, что всего четыре представителя высшего руководства фирмы покупают еще больше наших продуктов? Это дает нам принципиально новые сведения о процессе принятия решений о покупке нашими клиентами. Благодаря этим данным становится ясно, что нам следует уделить больше внимания процессу совершения покупки такими группами наших клиентов, как ИТ-специалисты и руководители высшего звена.

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

Где наш основной бизнес?

Перемещение по карте

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

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

После того как мы заметили, сколько было разных объектов и их компонентов, мы видим, как они расположены относительно друг друга. Мы отмечаем их позиции, относительную ориентацию и разделяющие их расстояния. Чтобы представить сведения такого рода другим людям, мы используем карты. Такого рода картинка отражает размещение объектов, их близость или удаленность, наложение друг на друга, расстояние и направление. И все это относится отнюдь не только к географии; благодаря картам на удивление четко проявляются пространственные взаимосвязи не только между физическими объектами, но и между любыми идеями.

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

Кроме того, карты — еще и самые знакомые из шести рассматриваемых структур. Будучи очень разными — начиная с организационных схем (которые сегодня умеет рисовать любой сотрудник) и заканчивая старыми добрыми картами для поиска сокровищ (которые любят рассматривать все люди за земле), — карты используются чаще всех остальных визуальных изображений.

Карты: общие правила

  1. Все имеет свою географию. Карты используют не только для изображения природных ландшафтов; все, что состоит из множества уникальных компонентов — городов и рек или концепций и идей, — можно изобразить в виде карты. Задача визуального мыслителя в данном случае заключается в том, чтобы спросить себя: «Если бы эти идеи (концепции, элементы, компоненты и т. д.) были государствами, где проходили бы их границы и какие дороги бы их соединяли?»
  2. Север — это умонастроение. Мы привыкли думать о картах как о системе координат север-юг, восток-запад, на которую наносят разные местности и объекты с учетом их положения в пространстве. Но мы можем составить карту практически чего угодно на основе других пар противоположных друг другу понятий: хороший-плохой против дорогой-дешевый; высокий-низкий против победитель-проигравший и т. д. По сути, единственная сложность при составлении большинства карт заключается в определении правильной системы координат. После того как это сделано, нанести на карту ориентиры уже не составит никакого труда.
  3. Выйдите за рамки иерархии. Традиционные (иерархические) «организационные схемы» — отличные инструменты для графического изображения формальных цепей соподчиненности в организации, четко показывающие, кто в ней за что отвечает. Но если нужно выяснить, где находятся менее явные — но, как правило, более мощные — политические взаимосвязи, лучше воспользоваться таким инструментом, как кружковая «карта влияния», т. е. схемой, изображаемой кружками и стрелками. Собрать данные для ее построения намного труднее, но эти усилия окупятся сторицей, если необходимо понять, что на самом деле происходит внутри организации.

Но вернемся к SAX. Из Кодекса визуального мышления мы знаем, что для решения проблемы «где» требуется такая структура, как карта, а по модели SQVID мы определяем, что наш рисунок должен быть простым, количественным, основанным на видении и индивидуальных характеристиках и отражающим ситуацию статус-кво. Следовательно, нам нужно нарисовать нечто среднее между концептуальной моделью и картой для поиска сокровищ, нечто, что будет четко отражать структуру интересующей нас компании. Нам также известно, что стартовать при создании карты следует с рисования самой заметной характеристики «ландшафта», которой в данном случае является очень большой бухгалтерский отдел — фундамент и основа деятельности фирмы-клиента.

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

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

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

Странно! Совершенно отсутствуют «дороги» между отделом сбыта и бухгалтерией. Отсутствие прямых связей между ними означает, что эти компоненты бизнеса оказывают друг на друга совсем незначительное влияние, следовательно, они вряд ли существенно влияют и на решения друг друга о покупке. В сущности, наша карта готова. Теперь давайте определим, где именно на ней обозначено положение «сокровища».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здесь нам поможет диаграмма Венна — разновидность карт, используемая для наглядного изображения пространственных пересечений разнообразных элементов, в том числе и идей. Диаграммы Венна относятся к более широкой категории т. н. «концептуальных карт», которые абсолютно не похожи ни на карты для поиска сокровищ, ни на организационную схему. Но суть их та же: это тот же способ видеть (где), в них используется та же система координат (пространственная: верх-низ, влево-вправо, передний план — задний план), они создаются на базе тех же принципов (начинать с наиболее заметной характеристики и добавлять другие с учетом их расположения относительно первого) и отражают одно и то же — относительное положение нескольких объектов в пространстве.

Раз диаграмма Венна так здорово помогла нам определить, чего вообще ждет от программных продуктов заинтересовавший нас Джейсон, давайте воспользуемся похожей, но более сложной и детальной концептуальной картой, чтобы смоделировать основные компоненты нашего пакета программного обеспечения Super Account Manager, или сокращенно SAM. Такой рисунок поможет нам определить, что следует изменить и усовершенствовать в этом пакете, чтобы он соответствовал всем критериям Джейсона относительно идеального программного обеспечения: надежность, безопасность и гибкость.

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

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

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

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

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

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

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

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

Когда следует действовать?

Действуйте поэтапно

Итак, мы выяснили, какие именно изменения в программном обеспечении позволят нам повысить его привлекательность с точки зрения наших главных покупателей. Даже если предположить, что нам уже удалось убедить руководство в том, что усовершенствования помогут увеличить объем сбыта (надо сказать, очень смелое предположение, но об этом мы поговорим позже, при обсуждении вопросов «почему?»/«зачем?»), тут же возникает следующий важный вопрос: сколько времени займет реализация проекта? Пару недель, несколько месяцев, год или больше? Очевидно, теперь нам предстоит решить проблему из категории «Когда», и Кодекс визуального мышления рекомендует в этом случае использовать такую структуру, как временная шкала.

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

Временная шкала: общие правила

  1. Время — это дорога с односторонним движением. Хотя обсуждение четвертого измерения и природы такого явления, как время, несомненно, было бы весьма интересным, к проблеме, которую мы сейчас рассматриваем и с которой обычно сталкиваемся в бизнесе, это не имеет никакого отношения. Мы с вами будем рассматривать время как некую прямую, неизменно следующую от вчера к сегодня и только слева направо. Конечно, путешественники во времени, скорее всего, этого правила не признают, но это полезные и удобные стандарты, с которыми нам следует безоговорочно согласиться.
  2. Повторяющиеся временные шкалы образуют жизненные циклы. Яйцо и цыпленок, постоянно колеблющиеся маркетинговые циклы, дни, вновь и вновь слагающиеся в месяцы и годы, — временные шкалы довольно часто повторяются. В этом случае мы называем их жизненными циклами и изображаем графически либо в виде бесконечной окружности, либо возвратной стрелкой «в начало», которая ставится в конце прямой. Но для нас с вами не важно, повторяется временная шкала или нет, мы все равно создаем ее одним и тем же способом: если установить «отправной пункт» невозможно, просто выбираем какую-то важную веху в любом месте цикла и начинаем оттуда — все равно он обязательно повторится.
  3. Линейная временная шкала предпочтительнее круговой. И окружность, и линейка, в сущности, состоят из прямой линии, просто в первом случае она изогнута так, чтобы ее начало соединялось с концом. Круговая шкала времени обычно точнее отражает повторяющиеся жизненные циклы, но при решении бизнес-проблем практически во всех случаях больше подойдет прямая линия: ее проще изобразить (особенно если вехи на шкале сопровождаются большим текстом), она быстрее прочитывается и лучше запоминается. Круговые временные шкалы и календари (такие, например, как у древних ацтеков или у современных астрологов) — отличная вещь, если ваша основная цель — подчеркнуть повторяющуюся природу того или иного цикла. Но даже в этих случаях рекомендуется создать еще одну версию с прямой линией, на которой будут изображены дополнительные детали.

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

В SAX все проекты начинаются с четкого определения общей проблемы, которую предстоит решить. Мы называем это фазой «открытия» и, надо признать, довольно далеко продвинулись по этому пути. Нам уже точно известно, какая задача перед нами стоит — постараться сделать так, чтобы предлагаемый нами пакет компьютерных программ одобрил Джейсон.

Теперь приступаем к выработке возможных решений. Мы называем эту процедуру составлением «концептуального плана»; на данном этапе определяем конкретные характеристики будущего продукта.

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

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

Закончив тестирование и исправив все выявленные в его ходе программные ошибки, мы переходим к следующему этапу — продаже усовершенствованного продукта. Этот последний этап называется «размещением» — мы упаковываем программу и передаем клиентам. На этом же этапе приложение передается также в компанию, которая оказывает техническую поддержку. Итак, теперь мы можем вернуться непосредственно в начало процесса и заняться разработкой следующей версии программного пакета.

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

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

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

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

Итак, у нас есть две системы координат — в сущности, почти так же, как при составлении диаграмм и карт, — но на этот раз мы имеем и два разных набора информации, представленных, так сказать, на одном «игровом поле»: «кто» (наши команды) и «когда» (наша временная шкала). Располагая двумя системами координат, мы можем приступить к нанесению «что», начав с указания основных вех проекта, обозначающих окончание одного этапа и начало другого.

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

Но каким бы ценным ни было содержание документов, все они — просто конечный результат вложенного в них напряженного труда. Несомненно, видеть, когда должен быть готов каждый такой документ, очень важно для планирования, но нам также необходимо знать, что нужно для их создания. И тут на сцену выходят т. н. «текущие работы» — список задач, которыми руководствуются все проектные команды для достижения той или иной конкретной вехи. Нанесение текущих работ на рисунок — заключительный этап создания более детализированной временной шкалы. Теперь мы можем довольно точно оценить, сколько времени займет реализация данного проекта.

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

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

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

Как и на любой другой временной шкале, на горизонтальной оси мы указываем время, а на вертикальной — количество. Мы начинаем отмечать на них затраты на разработку приложения за прошлые годы, получив эти данные из управленческой документации по предыдущим проектам. Первая версия SAM была выведена SAX на рынок в 1996 году, сразу после создания фирмы. Что ж, будет логично начать с нее. В первый год затраты на разработку SAM составили меньше 500 тыс. долл. — команда из десяти человек работала над проектом без отпусков и практически без выходных почти в течение года. Вторая версия, вышедшая на рынок через два года после первой, обошлась уже в 2 млн долл., что объяснялось довольно просто: проектная группа разрослась до сорока человек, и многие сотрудники получали весьма высокую зарплату. В 2000 году проектный бюджет составил уже 6 млн долл., однако именно третья версия SAM сделала SAX лидером отрасли.

После этого у компании наступили трудные времена. В конце 2001 года на рынке начался экономический спад, и, чтобы удержаться на плаву, SAX пришлось провести масштабное сокращение штата. Она с трудом продолжала выпускать на рынок новые версии SAM, но затраты на это сократились, поскольку с каждым разом проектные команды уменьшались, а сама компания становилась все менее амбициозной.

Потом, от версии к версии, наши расходы постепенно увеличивались. В 2006 году SAM 6 обошлась фирме в 6 млн долл., сравнявшись с предыдущим максимумом 2000 года. Так что, учитывая столь устойчивую тенденцию, начавшуюся в 2002 году, можно с большой долей уверенности сказать, что затраты в размере 9 млн долл. будут вполне закономерными.

Но и это еще не все. Мы определили, что имеем все основания попросить у руководства фирмы 9 млн долл. на проект, представив в качестве весомого аргумента составленный график временных рядов, но мы можем не сомневаться, что начальство захочет увидеть то, чего мы пока еще и сами не видели: как эти затраты согласуются с совокупным доходом компании.

Чтобы понять это, следует создать еще один график временных рядов. Мы воспользуемся той же горизонтальной временной шкалой, но на вертикальной оси на этот раз укажем данные о совокупном доходе SAX за разные годы. Это значит, что верхний показатель на оси будет уже не 10 млн долл. (максимальные на данный момент затраты на проект), а 40 млн долл., т. е. самый высокий совокупный годовой доход компании за все годы ее существования. Мы опять начнем с 1996 года, когда данный показатель составил около 1 млн долл., чтобы всего через четыре года взлететь до 21 млн долл.

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

Но после 2004 года настал наконец час триумфа: всего за два года наши доходы «взмыли» до 30 млн долл., а затем... наступило затишье. Вялый сбыт, невысокие доходы. Это возвращает нас к началу проблемы, т. е. к структуре «Кто»/«Что».

Если рассмотреть два составленных нами графика по отдельности, они расскажут нам о двух важных вещах: 1) затраты на разработку приложения увеличиваются вполне закономерными темпами; 2) наши доходы (хотя они и довольно высоки) расти перестали. Но после того как мы объединяем эти графики, сразу возникают новые мысли — и вопросы. Прежде всего, чтобы объединить два графика, нам приходится прибегнуть к одному хитрому маневру: поскольку вертикальные оси были разными, мы будто бы «сплющиваем» график затрат, чтобы разместить соответствующие показатели с другого графика на одном уровне.

Итак, теперь мы можем сравнить, как говорится, яблоки с яблоками и увидеть, как расходы компании на разработку программы в прошлые годы варьировались относительно ее доходов.

И вот в наших ушах уже звучит то, что, вероятно, ответит нам руководство на просьбу о выделении 9 млн долл. на новый проект: Если четыре года назад 30-процентное повышение затрат привело к 300-процентному увеличению доходов, а еще одно такое же увеличение расходов два года назад совпало с периодом вялого сбыта, то можно ли ожидать, что очередное повышение затрат на 30 процентов принесет компании пользу?

И мы понимаем, что, прежде чем идти к начальству, должны ответить на этот вопрос — чем и займемся в следующей главе.

Как нам улучшить бизнес?

Как нам действовать?

Итак, у нас с вами очередная проблема: как убедить руководство компании (а сначала и самих себя), что затраты в 9 млн долл. на усовершенствование программного обеспечения — это верный путь к росту доходов? Надо признать, наш переход от молодого сотрудника фирмы-клиента, который в организационной схеме своей компании находится в самом низу иерархической пирамиды, к расходам в размере 9 млн долл. — прыжок гигантский, не так ли?

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

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

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

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

Далее следует обсуждение представленных вами решений: выполнимы ли они с технической точки зрения? Если нет, можете о них забыть. Если да, то насколько они целесообразны с финансовой точки зрения? И снова, если нецелесообразны, отправляйтесь на свое рабочее место; но если да, пришло время для этакого «теста с лакмусовой бумажкой» — момента, когда руководство оценит ваши предложения на интуитивном уровне. Наш руководитель работает в бизнесе по разработке программного обеспечения уже довольно давно, и из опыта ему хорошо известно, что может сработать, а что, вероятнее всего, безнадежно. Именно на этом этапе он прежде всего спросит себя: «Позволит ли подобное предложение разрешить данную проблему?» — и только после этого начнет по-настоящему обдумывать вашу идею.

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

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

Мы можем сразу назвать как минимум три причины вялого сбыта. Возможно, наши клиенты сами толкутся на одном месте и не растут (однако это не так; нам известно, что в последние два года интересующая нас фирма росла на двадцать и более процентов в год). А может, им уже не нужно наше программное обеспечение? (Это тоже неправда; наше компьютерное приложение — самое полное и всеобъемлющее на рынке, и такая ситуация сохранится еще как минимум год, до тех пор пока наши конкуренты не предложат аналогичный диапазон функций и услуг). Следовательно, наиболее вероятная причина в том, что наши клиенты не слишком довольны нашим продуктом.

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

Как вы помните, давным-давно мы уже составили портрет своего клиента. Так что теперь нам доподлинно известно, кто из них является наиболее важным для нас (инженеры, в частности Джейсон, руководители компании и в меньшей мере непосредственно бухгалтеры). Кроме того, мы уже определили, чего каждая из этих категорий ждет от хорошего программного обеспечения — гибкости, безопасности и надежности. Все это приводит к возможному решению проблемы: если мы улучшим хотя бы одну из перечисленных характеристик программы — лучше всего гибкость, потому что именно этого хочет самый влиятельный клиент, Джейсон, — мы сможем увеличить объем сбыта.

Итак, с первым этапом нашей «торговой презентации» для руководства покончено. Мы предельно четко определили проблему и выработали для нее потенциальное решение. Единственная загвоздка в том, что для реализиции предлагаемого нами решения потребуется 9 млн долл. И теперь нам нужно убедить руководство в том, что игра стоит свеч.

Стоит ли что-то предпринимать?

Зачем тратить деньги?

Итак, мы убеждены, что самый лучший способ повышения объема продаж нашей фирмы заключается в том, чтобы полностью изменить платформу нашего программного обеспечения, потратив на это 9 млн долл. Только такая модификация позволит нам внедрить в компьютерное приложение те изменения, которые, как выяснилось, больше всего необходимы нашим самым важным и влиятельным клиентам. Однако факт остается фактом: мы могли бы вложить намного меньше средств, внедрив менее серьезные усовершенствования в существующую платформу. А учитывая, что наше руководство во главу угла ставит основные экономические показатели деятельности компании, вполне вероятно, и решение оно примет соответствующее.

Чтобы убедиться в том, что все же стоит вложить деньги в более затратное решение (и убедить в этом руководителей), мы намерены рассмотреть нашу отрасль в целом: кто наши конкуренты, каковы перспективы их роста, как изменяются потребительская аудитория и тенденции сбыта, сильно ли модификации технологической платформы влияют на доходы фирм-конкурентов. Только проанализировав данную информацию в целом, мы получим общую убедительную картину. Но как же мы можем увидеть все это в совокупности — и вообще, разве можно одновременно разместить на графике так много информации и сделать это так, чтобы в этом был смысл и содержались все нужные нам сведения?

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

Только после того как мы увидели, «кто», «что», «сколько», «где», «когда» и «как», мы начали понимать логику происходящего. И чем дольше мы наблюдали за взаимодействием объектов, чем больше внимания уделяли причине и следствию в этих взаимосвязях, тем понятнее нам становилось, «почему» все сложилось именно так, а не иначе. Чтобы представить свои выводы другим людям и сообща принять решение, каким путем можно прийти к желаемому результату, мы создадим график с переменными параметрами.

Мы видим «почему» только после того, как в нашем воображении составят свою картинку другие способы восприятия. При построении графика с переменными параметрами происходит то же самое, только на этот раз мы объединяем эти способы на листе бумаги. Мы начнем с «кто»/«что», проработаем «сколько», перейдем к «где», а затем добавим «когда». Поскольку мы уже рисовали похожие рисунки в предыдущих главах, создание такого графика можно было бы рассматривать как обобощение всего сказанного, если бы не два очень серьезных отличия. Во-первых, мы будем вводить все, что нам известно, в один большой рисунок, а не рисовать несколько отдельных картинок; и во-вторых, начнем с создания портрета конкурентов, а не клиентов.

Графики с переменными параметрами: общие праВила построения

  1. Графики с переменными параметрами создавать нетрудно, но это требует терпения, практики и, прежде всего, четкой цели. Из шести основных картинок и сотен графических образов тщательно продуманный и четкий график с переменными параметрами является самым мощным и полезным при принятии решений практически любого типа. (О причинах этого мы поговорим далее.) И тем не менее я так и не нашел в наших бизнес-книгах ни одного простого и понятного объяснения, как его составлять. Мой совет таков: начните с простого графика с осями x и y, воспользовавшись для этого любыми двумя количественными переменными, по которым у вас имеется достаточно данных, и двумя осями координат. Помните, что, если со временем вы поймете, что такое сравнение не дает нужной информации, эти переменные всегда можно изменить. Нанесите любую количественную переменную, по которой у вас есть данные, используя кружки нужного размера. Начните с какого-то одного показателя, затем добавьте еще один набор кружков, отражающий тот же набор данных о количественной переменной, но уже в другой момент времени. Вот так — это все, что вам потребуется, чтобы построить график с переменными параметрами, который в итоге либо отразит общую картину, либо станет отличным отправным пунктом для введения в него новых переменных.
  2. Лучше всего варить суп средней густоты. Составляя график с переменными параметрами, мы создаем масштабированную модель всей бизнес-вселенной или бизнес-проблемы. При составлении такого графика мы надеемся в итоге выявить ограниченное количество характеристик нашей отрасли (или конкретной проблемы), которые могут оказывать серьезное влияние друг на друга. Тогда мы взяли бы только эти аспекты и внимательно проанализировали их, не отвлекаясь на другие многочисленные, но менее влиятельные переменные. При недостаточном количестве переменных у нас получится только простая столбчатая диаграмма. Это, несомненно, весьма полезный инструмент в очень многих ситуациях, но для выработки новых реальных идей явно не подходит. А при слишком большом количестве переменных мы вновь окажемся перед лицом исходной проблемы: слишком много данных для анализа. Понятно, что и в этом случае наша задача выполнена не будет. И снова единственный способ узнать, каково же «правильное» количество переменных, — начать наносить их на график и внимательно следить за тем, как благодаря этому на бумаге постепенно вырисовываются новые идеи.
  3. Можно объединить что угодно с чем угодно, но... Существует одна «ловушка» в графиках с переменными параметрами: в них постоянно следует учитывать все новые и новые слои переменных, из-за чего очень просто выявить взаимосвязи между переменными, которые, по сути, не имеют друг с другом ничего общего. Это, кстати, самая сложная задача статистики и даже многих фундаментальных наук: четкое отделение «корреляции» (возникновение похожих тенденций между разными переменными) от «причинной обусловленности» (непосредственного влияния одной переменной на другую). И хотя, возможно, порой очень хочется, например, наложить график температурных колебаний на частоту повторных показов мыльных опер — что, вероятно, даст очень высокий коэффициент корреляции, — это вовсе не означает, что один из этих показателей непременно напрямую влияет на другой.

А теперь вернемся опять к SAX. Нам известно, что наша отрасль состоит из двух категорий конкурентов — «старой гвардии» (это мы, SAX, а также SMSoft и Peridocs, компании, с которыми мы конкурируем в течение последних десяти лет) и новичков (Univerce и MoneyFree, вышедшие на рынок всего пару лет назад). Эти группы отличаются друг от друга по целому ряду критериев: наша «Большая тройка» работает в бизнесе не меньше десяти лет, наше программное обеспечение построено на частных, запатентованных кодах и платформах, все мы предлагаем программы с множеством опций и характеристик, и все мы зарабатываем деньги, продавая программные продукты, а модернизацию и обслуживание предлагаем потребителям бесплатно. А две компании меньшего размера создают свои программы на открытых исходных кодах (т. е. исходный код разрабатываемых ими приложений свободно и бесплатно предоставляется всем желающим), их программное обеспечение по сравнению с нашим не столь функциональное, и они получают прибыль преимущественно за счет контрактов на модернизацию и обслуживание своих программных продуктов. То есть они предоставляют приложения бесплатно, а затем взимают с пользователей плату за их обслуживание и модернизацию.

Итак, у нас есть пять компаний, две разные платформы и два разных подхода к бизнесу. Теперь давайте подсчитаем, сколько денег заработала каждая из них в прошлом году. После того как мы нанесли на график кружки размером, пропорциональным доходам анализируемых нами компаний, явно наметилась еще одна тенденция. Мы видим, что в прошлом году «старая гвардия» заработала весьма неплохо, а вот новички едва сводили концы с концами. Лидировала по показателю доходности SAX, ее годовой доход составил 25 млн долл. За ней следовали SMSoft с 20 млн долл. и Peridocs с 18 млн долл. Univerce удалось заработать 3 млн долл., а MoneyFree с трудом наскребла 250 тыс. долл.

Продолжаем. Используя отчеты аналитиков, прогнозы Уолл-стрит и неформальные слухи в нашей отрасли, мы можем приблизительно прикинуть, какие доходы могут ожидать эту пятерку к концу следующего года. Нам хорошо известно, что объем сбыта нашей компании в последнее время практически не увеличивается, к тому же появилась настораживающая информация: как оказалось, SMSoft ведет переговоры о выкупе Peridocs, в результате чего, в случае успеха переговоров, будет создана компания с доходом в 40 млн долл. Более того, анализ показал, что Univerce — фирма, которой всего три года назад еще и в помине не было, в следующем году вполне может получить доход, превышающий наши прогнозируемые 30 млн долл. больше чем на миллион. В результате мы с первого места будем отброшены сразу на третье. И даже маленькая MoneyFree, судя по всему, может рассчитывать на целых 18 млн долл. дохода. Ничего себе!

Если эти прогнозы подтвердятся, в ближайшем будущем нашу отрасль ждут очень серьезные перемены. Но что же может произойти помимо крупного слияния? Очевидно, значимых событий будет намного больше, чем можно изобразить на простом графике «Сколько». Нам необходимо не только увидеть размеры своих компаний-конкурентов, но и сравнить, где они находятся относительно друг друга по клиентам, платформам и технологиям, т. е. по тем основным уникальным характеристикам, которые мы выявили при составлении портрета отрасли.

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

Итак, мы получили исходную систему координат. Теперь нам остается только нанести на нее соответствующие данные. Поскольку у нас уже имеется кружковая диаграмма, отражающая доходы за прошедший год, мы можем разместить кружки в соответствующих зонах графика. Например, SAX, SMSoft и Peridocs должны находиться на горизонтальной оси там, где указаны запатентованные стандарты, а остальные две фирмы там, где обозначены открытые стандарты. А по вертикали компании будут располагаться согласно функциональности предлагаемого ими программного обеспечения (самые высокие показатели у SAX, затем SMSoft и т. д.).

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

Итак, мы ввели в игру пять разных переменных: название компании, платформа, функциональность, доход за прошедший год и предполагаемый доход в следующем году. Прежде чем вводить очередные переменные (а мы собираемся это сделать), давайте рассмотрим, что у нас получилось на данный момент и что благодаря этому мы сможем узнать. Во-первых, созданная после слияния SMSoft-Peridocs обгоняет нас по показателю доходности (кружок большего размера), а общая функциональность ее программного обеспечения выше нашей (кружок SMSoft-Peridocs поднялся на рисунке выше). В то же время слияние этих фирм заставит их объединить две запатентованные платформы, в результате чего их платформа станет еще менее открытой, чем раньше (соответствующий кружок сдвигается влево). При этом наши доходы несколько выросли (кружок чуть-чуть увеличился), а постоянная «шлифовка» компьютерных программ передвинула нас вверх по уровню функциональности (соответствующий кружок сместился вверх), и, если нам удастся вовремя внедрить все запланированные нами усовершенствования нынешней платформы, она станет чуть более открытой (кружок перемещается немного вправо).

А теперь давайте посмотрим, что произошло с той частью графика, на которой отражены данные о компаниях, уже сегодня использующих открытые стандарты. Мы видим, что на общей картине увеличение доходов и повышение функциональности представителей «старой гвардии» выглядят вовсе не так уж впечатляюще. Так, аналитики прогнозируют, что к концу следующего года Univerce не только обойдет нас по показателю доходности, но и «побьет» по количеству функций предлагаемых ею программ. Как такое может случиться?

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

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

Итак, мы смогли установить, что происходит в нашей отрасли. Уже в следующем году новички — компании, пришедшие на рынок совсем недавно и использующие открытые стандарты, — собираются предложить потребителям услуги аналогичного или более высокого качества, чем мы, «старая гвардия», которая начала свою деятельность относительно давно и специализируется на закрытых платформах. В итоге это возвращает нас назад, к исходному вопросу: так стоит ли тратить 9 млн долл. на создание новой технологической платформы или целесообразнее затратить намного меньше средств и внедрить в текущую платформу лишь некоторые незначительные усовершенствования?

Хотите верьте, хотите нет, но на данном этапе мы с вами собрали все сведения, необходимые для ответа на вопрос «почему?»/«зачем?». Вы помните, что мы начинали анализ с довольно простого вопроса: если мы лучше узнаем своих клиентов, поможет ли это определить, почему перестал расти наш сбыт? Воспользовавшись шестью базовыми структурами визуального мышления, мы не только ответили на этот вопрос (да, наша проблема в том, что мы не удовлетворяем требования нашего главного клиента Джейсона), но и четко поняли, что необходимо сделать, чтобы клиенты были вполне довольны нашим продуктом (нам следует повысить его надежность, безопасность и гибкость), и при этом остаться лидером отрасли (для этого нужно перейти на открытую платформу). Проблема заключается в том, что такой переход обойдется компании в целых 9 млн долл. А это значит, что нам предстоит сделать еще одно чрезвычайно важное дело — показать созданные нами рисунки руководителям компании и заставить их увидеть все то, что удалось увидеть нам. При этом они должны найти ответы на вопросы «почему?»/«зачем?» сами, своими собственными глазами.


© 1998-2023 Дмитрий Рябых