• Роль проектировщика

• Триада

• Насмотренность

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

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

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

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

• Исследования, как путь профессионального развития

  • Один на один с требованиями к продукту

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

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

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

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

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

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

Роль проектировщика

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

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

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

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

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

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

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

Триада

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

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

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

Исследование — второй шаг, процесс, когда ты сам и только сам разбираешься в заинтересовавшей тебя профессиональной теме. Результаты исследования безусловно важны, но сам процесс возможно еще более важен. В процессе исследования новой области знаний ты ее осваиваешь, т. е. делаешь своей. Не пройдя путь практики и анализа, terra incognita вряд ли станет terra mea. Такие инвестиции в свои знания и опыт дают тебе как проектировщику больший диапазон и возможности заниматься интересными для тебя проектами.

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

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

Насмотренность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Исследования, как путь профессионального развития

Один на один с требованиями к продукту

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предыдущая часть книги Как устроена индустрия создания цифровых продуктов.