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

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

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

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

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

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

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

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

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

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


Штанга Талеба и проекты

Здесь я хочу подвести вас к концепции «штанги»,

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

Такой подход одинаково применим и к конкретным

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

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

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

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

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

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

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

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

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

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

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

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

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

Штанга, насмотренность и профессиональное развитие

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

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

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

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

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

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

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

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

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


О ценности первоисточников

Если вы, как и я, занимаетесь проектированием цифровых продуктов, то наверняка знакомы с концепцией персонажей, придуманной Аланом Купером. Возможно, при этом, что вы не знали автора этой концепции и познакомились с понятием персонажей в какой-то тематической статье. Также очень вероятно, что из этой статьи вам стало известно об устаревании этого подхода и его ошибочности. И вместо него автор предлагает использовать другой подход к проектированию, например, Jobs-To-Be-Done и Job stories. Самое забавное, что и автор статьи, скорее всего, недостаточно знаком ни с методом персонажей, ни с новым методом, который он описывает.

Он так же, как и вы, мог о них прочитать в каком-то профессиональном издании и решил собрать все вместе.

Мне становится очень грустно, когда я читаю подобные материалы. Ведь я знаю историю появления концепции персонажей из первоисточника. Изначально подход к проектированию продуктов, основанный на концепции персонажей, подразумевал выяснение их целей. Персонажи ни в коем случае не подразумевали демографические и прочие атрибуты, которые бы сводили их к понятию аудитории продукта, разбитой на возрастные и прочие сегменты, больше похожие на маркетинговые инструменты. Нет, персонажи задумывались как способ определения требуемой функциональности продуктов, основываясь на вопросе «Зачем?», т. е. на мотивах людей, которые будут его использовать. Таким образом, отдельные персонажи, будучи обобщением мотивов пользователей, позволяют спроектировать продукт не как набор равнозначных функций, одинаково представленных в интерфейсе, а как систему, сфокусированную на целях людей. Более того, такая сфокусированность даёт возможность создать

интерфейс, устанавливая приоритеты для разных персонажей.

Что же произошло, почему большинство не знает о персонажах так, как они задумывались? В одном из интервью Алан Купер рассказывает историю о том, как пришёл в ужас, увидев книгу, изданную Microsoft, в которой было описание концепции персонажей. Там все было перевёрнуто с ног на голову, и персонажи были описаны с точки зрения атрибутов разных групп пользователей. Так поняли концепцию авторы книги. Поскольку охват читательской аудитории у издательства Microsoft по определению шире и не сопоставим с независимым консалтинговым агентством Купера, то теперь мы имеем то, что имеем.

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

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


Экспедиции в мир других

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

Работая над проектом, я с большим удовольствием

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

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

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

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

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

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

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

Опытный проектировщик отличается тем, что у него в запасе есть достаточное количество решений и он по

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

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

Для чего нужны исследования в проектировании

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

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

кажущееся удачным решение может быть действительно применено.

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

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

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


Извращённая корпоративная модель использования исследований

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

Если в описываемом мною подходе исследования нужны для проверки гипотез, рождающихся в процессе поиска

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

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

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

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

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

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

Буквально спустя несколько дней после того, я закончил эту главу, в блоге Алана Купера вышла статья «Practitioners in Businessland», которая оказалась очень созвучна моим идеям, и я не могу не процитировать здесь её фрагмент (а лучше прочитайте её целиком):

«Basically, everyone in business is looking for a way to do things more quickly, more easily, and with less skilled people. The solution, of course, is to take more time, work harder, and use more highly skilled people.

In other words, the best business people are wrong. Sadly, those same business people often make lots of money being wrong.

Don't conflate making money with making successful products.

Your boss will not reward you for taking time and working harder. Do you want a raise and a promotion? A nice house and a new Tesla? Or do you want to create a supportive, healthy, peaceful world in which your children can grow old in happiness? You have to make a choice about how you wish to shape the world you live in. That's a very tough choice.»

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

Для чего нужны исследования в вашей профессиональной жизни

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

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

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

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

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

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

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

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

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


Личная история исследования голосовых систем

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

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

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

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

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

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

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

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

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

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

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

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

поставленные вопросы. Запомните, только делая все по порядку, вы оставляете себе пространство для творчества.

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

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


Пасквиль на классический маркетинг

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

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

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

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

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

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

Второе слово — Аудитория. Маркетолог считает, что он должен «направлять свои коммуникации» на аудиторию,

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

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

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

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

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


Альтернативная модель профессиональной работы в цифровой артели

За 15 лет существования моей компании «ГАЛС СОФТ» я достаточно хорошо познакомился с классической бизнес-моделью работы в ИТ-индустрии. Мы, так же, как и наши коллеги, выпускали кейсы о реализованных проектах, выступали на конференциях, писали статьи, участвовали в рейтингах, играли и выигрывали в тендерах, одним словом, вели обычную жизнь «фирмы, оказывающей

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

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

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

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

Мне ближе предпринимательский подход. После того как стало понятно, что старый формат себя изжил, нужно было искать «новые формы». Стоило потрудиться, чтобы в дальнейшем избежать проторённой дорожки, которая приводила все время в одно и то же место. Я задумал создать такой формат работы, в котором профессионалы, работающие над проектами, были бы связаны напрямую с клиентами, избегая фильтра маркетинга. Формат, в котором их параноидальная увлечённость была залогом успеха.

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

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

Так родилась концепция Цифровой артели Eleven, не компании в привычном понимании, а объединения проектных продюсеров, сочетающих в себе навыки проектирования, управления проектами и имеющих

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

Своеобразным переходом от старого формата и одновременно толчком к созданию артели была личная история, на практике показавшая, что такой подход работает. Ещё в «ГАЛС СОФТ» мы с нуля создали мобильные приложения для «Связного Трэвел». Это были два года интенсивной работы, сначала по поиску

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

Специфика индустрии путешествий состоит в том, что она базируется на устаревших технологиях. Вы, наверно, слышали термин GDS (Global Distribution System). Это международные системы бронирования билетов, которые были разработаны несколько десятилетий назад и до сих пор существуют в неизменном виде. Каждый раз, когда вы покупаете билет в любимом онлайн-сервисе, этот сервис обращается к GDS, чтобы запросить информацию о тарифах и оформить покупку в авиакомпании. Многие ограничения, которые вам могут показаться странными, связаны с тем, как реализованы API GDS.

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

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

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

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

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

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