Метод параноика. Кодекс проектировщика
От редакции
Компании, которые находят способ с помощью технологий изменить устоявшийся способ работы, получают преимущества и меняют правила игры. Новые технологии способны полностью поменять целую отрасль, как это случилось, например, с банковской сферой при появлении мобильных приложений. Появились новые банки без отделений, а существующим банкам пришлось пройти сложный путь трансформации. Сейчас что-то похожее происходит с голосовыми интерфейсами, ИИ и другими технологическими новшествами.
С другой стороны, непосредственно проектами по созданию цифровых продуктов, которые использует бизнес, занимаются отдельные профессионалы и целые компании. ИТ-индустрия живет по своим правилам и специалистам из этой среды не всегда знакома реальность классического бизнеса. При этом бизнесу не так просто разобраться, кто лучше сможет спроектировать и разработать новый продукт и как следует построить проектную работу. В результате множество проектов так и не завершаются удачно и этой истории уже много-много лет.
Цель книги — показать принципы, по которым работает каждая из сторон и предложить подход, позволяющий создавать качественные цифровые продукты, решающие задачи бизнеса. Для бизнес-аудитории книга дает понимание, чем на самом деле являются цифровые продукты и как устроена индустрия, их создающая. В свою очередь профессионалы получают модель работы над проектами, позволяющую пройти полный путь от создания концепции продукта до его запуска. В основе подхода, названного «Метод параноика», лежит продюсерская модель работа, совмещенная с современными подходами к проектированию цифровых продуктов.
Книга написана ИТ-предпринимателем, имеющим опыт в области проектирования и управления проектами. Под его руководством было создано множество мобильных приложений и сервисов, которыми пользуется сотни тысяч людей.
Главы публикуются по мере их готовности. Следить за ходом работы над книгой и узнать информацию о будущих главах можно на сайте автора.
Роль проектировщика
В предыдущей главе я сказал, что сложные цифровые продукты и сервисы возможно создать только предварительно их проектируя. Если бы сложность продукта, а точнее сказать, ИТ-системы, лежащей в основе продукта, равнялась сумме всех ее частей, то потребность в проектировании была бы не столь высока. В конечном счете любой разработчик или дизайнер так или иначе выполняет проектирование, хоть и неявно. Только делает это на локальном уровне и часто используя уже готовые паттерны.
Но сложность систем определяется взаимосвязями между ее частями. И для того, чтобы определить эти взаимосвязи вместо того, чтобы дать им сложиться хаотично, и нужен проектировщик. Его задача — найти наилучший способ организации системы, как с учетом возможных технических возможностей и ограничений, так и с учетом того, как соединяются бизнес-требования с пользовательским опытом. Как видно из этого, вопросы проектирования лежат по большей части за пределами компетенции и ответственности каждого из участников проекта по отдельности. Это в свою очередь означает, что сумма знаний всех участников проекта не дает общего видения создаваемой системы. Отсюда и вытекает особая роль дисциплины проектирования и профессиональных проектировщиков в работе над сложными цифровыми продуктами.
На проектирование можно смотреть как на моделирование будущего продукта. Такой взгляд позволяет увидеть еще один важный аспект подобного подхода к созданию продуктов — возможность избежать поиска решений «по живому». Есть существенная разница в цене, которую придется заплатить за рабочую реализацию и за проектную документацию, описывающую эту реализацию. Проектировщик может многократно высказывать и проверять различные гипотезы относительно того, как следует реализовать ту или иную часть продукта. Но проектной команде, состоящей из разработчиков, дизайнеров, тестировщиков, инфраструктурных инженеров, может потребоваться не один месяц только для того, чтобы получить хотя бы одну возможную действующую реализацию продукта. И вряд ли это будет хорошая идея, тратить бюджет проекта, на то, чтобы таким образом проверять проектные гипотезы.
Все вышесказанное дает понять, насколько ответственная задача стоит перед проектировщиками. От их решений зависит очень много и ошибки могут дорого обойтись. Чтобы проектировщик мог передать разработчикам действительно работающие решение, он должен иметь опыт в соответствующих областях. В противном случае его решения будут просто «абстракциями на заданную тему», нежели чем действительно путеводной картой для проектной команды. Иными словами, не существует такого универсального навыка, позволяющего проектировать любые системы на любых технологиях для любых прикладных отраслей. За полезностью проектировщика, помимо его системного подхода, должен стоять реальный опыт создания систем, когда у него была возможность проверить разные гипотезы и действительно знать, как может вести себя система в реальной рабочей среде. Это относится и к техническим решениям, и к решениям на уровне взаимодействия с пользователем и к бизнес-сценариям.
Хороший проектировщик обладает широтой опыта и профессиональных знаний. В отличие от профильного специалиста, он не может себе позволить иметь глубокие знания только в одной узкой области. Все вместе это даёт проектировщику необходимый диапазон доступных вариантов решения задач, с которыми он может столкнуться в процессе проектирования. При этом знания в разных областях могут являться просто результатом естественного накопленного опыта. Но я за более целенаправленный подход. Есть большая разница между тем, когда твоя профессиональная жизнь складывается под влиянием внешних обстоятельств, и тем, когда ты сам влияешь на свой жизненный путь.
Конечно, только часть решений проектировщика складываются из «знаю». В особенности это относится к проектам, в которых требуется создать продукт по нетипичным требованиям, аналогов для которого еще нет в индустрии. В таких случаях вторая часть решений проектировщика — результат системного поиска, своеобразных «вычислений», за которыми стоят и прототипирование и способность смотреть на задачу с разных точек зрения. Все-таки проектировщик — человек, имеющий привычку принимать решения. И имеющий достаточно смелости для этого.
С какой стороны не посмотри, проектирование — одна из самых сложных проектных задач и дальше я хочу уделить внимание людям, выполняющим эту работу. Они определенно заслуживают отдельную главу.
Триада
Триада или кодекс проектировщика — модель развития, которая, на мой взгляд, отвечает на вопрос, как построить свою карьеру в проектировании. Часто на конференциях и просто в личном общении, начинающие коллеги меня спрашивают, как найти своё место, состояться в профессии. Жаль, что у меня ушло так много времени, чтобы сформулировать ответ. Зато из трёх слов: насмотренность, исследования, мастерство. Позвольте я вкратце расскажу, что стоит за каждым из них, а потом, в отдельных частях этой главы, раскрою их подробно.
Каждый, так или иначе, связан с определённой областью знаний. Это наша территория, которая делает нас востребованными специалистами. Скорее всего, на ней мы оказались случайно, в силу обстоятельств, связанных с учебой или первым профессиональным опытом. Большинство продолжает плутать на ощупь, периодически где-то надолго задерживаясь или оставаясь навсегда. Но если мы хотим оставаться актуальными в своей профессии, нужно взять эту историю в свои руки. Есть два способа развиваться — уходить вглубь профессиональной области, на которой специализируешься, или расширять круг своих знаний, изучая смежные темы или даже переходя к радикально новым темам. Получается своеобразная география знаний.
Первый шаг — развитие насмотренности. Быть проектировщиком означает быть путешественником в мире профессиональных знаний. Нельзя, оставаясь на одном месте, приобрести достаточный опыт и широту видения. Необходимо периодически знакомиться с новыми областями знаний. Небольшие экспедиции, расширяющие твою насмотренность в разных технологиях, подходах, инструментах. Вряд ли получится сразу разобраться в деталях. В этом процессе гораздо важнее посмотреть большое количество новых тем, чем пытаться уйти с головой в любую из них. Как говорят китайцы, перед тем как лезть по лестнице, убедись, что приставил ее к нужной стене. Только когда как следует осмотрел новые территории, можно понять, какие из них больше интересны и дают ощущение перспективы, чтобы посвятить свое время и исследовать их.
Исследование — второй шаг, процесс, когда ты сам и только сам разбираешься в заинтересовавшей тебя профессиональной теме. Результаты исследования безусловно важны, но сам процесс возможно еще более важен. В процессе исследования новой области знаний ты ее осваиваешь, т. е. делаешь своей. Не пройдя путь практики и анализа, terra incognita вряд ли станет terra mea. Такие инвестиции в свои знания и опыт дают тебе как проектировщику больший диапазон и возможности заниматься интересными для тебя проектами.
После того, как новая область, территория знаний становится твоей, ты уже можешь распоряжаться ее ресурсами и быть полезным окружающим. Это могут быть клиенты, которые хотят, чтобы на основе известных тебе подходов и технологий был создан новый продукт, или это могут быть другие специалисты, расширяющие круг своих знаний. Они также, как и ты когда-то, приходят в эту новую для них область знаний, и ты можешь помочь им в ее освоении. Одновременно с этим приходит ответственность. В твоих силах не только исследовать свою территорию, на основе ее ресурсов ты можешь строить что-то новое в этой области, например, создать проектный подход, технологию, инструмент. А это еще больше увеличивает твои профессиональные возможности.
Третий шаг — логическое следствие развития тебя как специалиста, осваивающего новые области знаний. Может наступить момент, когда у тебя появляется достаточно сил, знаний и опыта для открытия принципиально новых территорий, не существовавших до тебя. Это момент, когда ты из профессионала становишься мастером.
Насмотренность
Иногда я впадаю в жуткую панику. Впрочем, почему иногда. Это происходит часто. Я уверен, что все вокруг меня знают и разбираются во всем гораздо лучше. Смотришь интервью с дизайнерами, читаешь статьи проектировщиков, в конце концов общаешься с коллегами на конференциях — каждый из них осведомлен о том, что сейчас в тренде, какие технологии уже устарели, а какие вот-вот рванут вверх. Все излучают уверенность, о которой я могу только мечтать. И я не могу понять, как мне ухватить убегающую от меня современность за хвост. Кажется, вот-вот и поезд уйдет навсегда, оставив меня на заснеженном безлюдном перроне олдскула. Невеселая картина, не правда ли?
Но так бывает не всегда. Как только стартует новый проект и проходит первоначальная подготовительная суета, пропадает и ощущение незнания. Будто я подключаюсь к источнику знаний, который до этой был в режиме stand by. Обсуждая проектные вопросы с коллегами, которые еще вчера меня удивляли, я начинаю чувствовать уверенность в каждом шаге. Ум фокусируется и в нем запускается сильный поисковый ассоциативный механизм. В голове всплывают примеры из моего опыта или из тех бесчисленных статей, которые, как выясняется, я успел прочитать. За отдельными тезисами из просмотренных интервью я различаю намек на возможный вариант решений, и постепенно нащупываемая логика ведет меня, связывая все воедино. Так работает моя насмотренность.
Традиционно в творческих профессиях на развитие насмотренности смотрят как на развитие вкуса, подразумевая под этим способность отличать хорошую работу от плохой. В проектировании этого недостаточно. Тот самый инсайт, о котором пишут в современной мотивационной литературе, не сможет появиться просто так. Наш мозг берет в расчет только то, что ему известно и к сожалению, наличие у вас скоростного доступа в интернет не поможет в моменте. Но вы можете им воспользоваться до того, как перед вами встанет новая неразрешимая задача. Сам факт знания того, что задача может быть решена разными способами, предоставляет степень свободы, так недостающую новичкам. Поэтому смотрите, слушайте, читайте, даже если вам кажется, что это сейчас не пригодится.
Не стоит путать обучение и насмотренность. Осознанно и вдумчиво изучая материал, ты закрепляешь его как свою реальность, в которой ты уверен. Насмотренность — более неуловимое качество. Это только намек на возможность и часто неосознанный. В детстве, учась в школе, я был уверен, что знания как большой океан, не зависят от людей. Просто непостижима была мысль о том, что об одном и том же предмете разные люди думают по-разному и с последним человеком, исчезнет и всякое представление о мире и его свойствах. Теперь я понял, что это так. Мир, в котором живет каждый из нас очень индивидуален и определяется тем, что мы знаем о нем.
Штанга Талеба и проекты
Здесь я хочу подвести вас к концепции «штанги», описанной Нассимом Талебом в «Антихрупкости», второй его большой книги. Если коротко, то суть в том, что большинство из нас всегда усредняет возможности, в то время как стоит все разделить на две крайности, подобно блинам, висящим на концах грифа штанги. С одной стороны (по Талебу это левая сторона, но в данном случае это не имеет значения) должны быть проверенные подходы, гарантирующие результат. В конце концов, как пишет Талеб, это вопрос выживания. С другой стороны (правой) следует расположить все, что несет риск и одновременно может принести неожиданные возможности. Как писатель, устраиваясь работать в кафе, чтобы гарантированно заработать на жизнь, одновременно пишет роман, который может стать бестселлером и принести ему много денег. Худшее, что может случиться, роман не будет иметь успех, но писатель продолжит свою жизнь. Так и вы, будучи профессионалом, можете работать в области, хорошо вам известной и опираться на свои проверенные знания. В то же время, делать рискованные ставки в расчете на неочевидный успех. Главное не смешивать.
Такой подход одинаково применим и к конкретным проектам, и к профессиональному развитию в целом. Давайте разберем каждую историю по отдельности. Начнем с проектов.
В самом начале, когда клиент только пригласил вас для создания нового продукта, стоит определиться, что он ожидает. В большинстве случаев никто не хочет просто так терять деньги и рассчитывает на гарантированный результат. Часто ключевым словом для таких проектов служит «Ну вы же профессионал». Но иногда бывает так, что от вас ждут эксперимента. Хотя по странному, казалось бы, обстоятельству с такими проектами обращаются к специалистам с репутацией. Это значит, что результат все-таки нужен, просто нестандартный. И здесь я пришел к следующей модели работы — нельзя смешивать в рамках одной цепочки задач проверенные и новые подходы.
Вы можете сколько угодно проводить опытов и пробовать нестандартные решения, вынимая на свет все то, что вы накопили, развивая свою насмотренность проектировщика, например, в архитектуре, пользовательских сценариях, дизайне и технологиях, давая шанс проявиться скрытым возможностям. Это правая часть штанги. Но продукт должен работать и его работоспособность обеспечивается не вашей удачей, а опорой на уже известные решения. Это левая часть штанги. Между ними всегда должна быть мертвая зона шириной в многополосное шоссе. Если же вы проигнорируете это правило и нарисуете на нем пешеходный переход без светофора, то первый, кто погибнет, будете вы.
Попахивает паранойей? Как же тогда создавать инновационные прорывные продукты, спросите вы. Мой ответ — проводить исследования и локализовывать неопределенность, связанную с новыми подходами. Про исследования я скажу подробно в следующей части главы, здесь же я хочу сделать акцент на локализацию. Еще один вывод из концепции «штанги» в том, что ущерб от сработавшего риска в правой части, где вы концентрируете всю неопределенность проекта, должен быть заранее известным и ограниченным, а возможная польза от нового подхода, технологии, решения в пределе давать неограниченно большой положительный эффект.
Например, вы проектируете корпоративный сервис для большого количества пользователей и вам кажется отличной идея добавить в мобильное приложение голосового ассистента. Более того, клиенту тоже нравится эта идея, а впереди маячит новая версия сервиса, над которым вы вместе с ним работаете. И здесь возможны два подхода. Первый: вы настолько уверены в своей идее, что готовы реализовать новые функции, сделав голос основным интерфейсом. Второй: проявляете осторожность и даете возможность пользователям взаимодействовать с приложением голосом как опцию, от которой они всегда могут отказаться. Обратите внимание, действуя осторожно, вы тем не менее, не делаете голосовой интерфейс по остаточному принципу, а тщательно подбираете пользовательские сценарии, в которых он может качественно улучшить удобство работы с приложением.
Действуя в рамках первого подхода, смешивая уже проверенные решения с новыми и делая ставку на свою уверенность, есть два риска. Проектный и продуктовый. Проектный риск заключается в том, что, включая в общий план работ исследования по использованию новой неопробованной технологии, вы ставите исполнение других задач в зависимости от результата этих исследований. Я пока даже не говорю, что исследования по своей природе не могут быть зафиксированы в четкие временные рамки. Риски могут проявить себя в выявленных ограничениях новых технологий уже на стадии разработки или в момент детального проектирования, когда вы пытаетесь увязать существующие пользовательские сценарии с новой функциональностью, основанной на голосовом интерфейсе. В любом случае имея общий проектный план и связанные друг с другом задачи, вам придется спешно и на ходу вносить изменения в проект, в то время как команда разработки будет либо простаивать, либо переделывать уже готовые программные компоненты. Сроки запуска уедут в неопределенное будущее, а про качество реализации сервиса можно будет забыть. Издержки по бюджету и времени, которые вы понесете вместе с вашим клиентом могут быть непредсказуемо большими.
Второй, продуктовый риск, проявляется иначе, чем проектный, но не менее болезненно и также непредсказуемо. В данном примере голосовой интерфейс может показаться пользователям неудобным и возможно даже окажется неработоспособным в реальных сценариях. Поскольку вы делали ставку исключительно на голосовой интерфейс, то у вас не будет места для маневра и работа пользователей будет заблокирована. Как вариант, вы сможете откатиться до предыдущей версии, но это будет сопряжено с большими издержками. Тот кредит доверия, который вы копили лично, будет истрачен и уйдет в минус, а ваш клиент надолго откажется от возможности развивать сервис в инновационном направлении, т. к. подобные эксперименты у него будут ассоциироваться с проблемами, несовместимыми с лояльностью его пользователей.
Совершенно по-другому могут развиваться события, если вы используете второй подход и разделяете в проекте область известного и область неизвестного. Прежде всего вам потребуется вынести за границы критического пути проекта эксперименты и техническую экспертизу новых технологий, выделяя исследовательскую работу в отдельный поток задач. В конце концов у вас должно быть достаточно смелости, чтобы не поддаваться давлению клиента, который будет требовать от вас четкие сроки, когда вы закончите эту работу. Исследование есть исследование и его цель — собрать достаточно информации, чтобы двигаться дальше. Может получиться так, что результаты этой работы будут отрицательными и лучше это выяснить здесь и сейчас, чем во время разработки. Таким образом проектный риск, который при первом подходе мог давать непредсказуемые издержки, здесь ограничивается только расходами на исследования.
Точно также второй подход работает для управления продуктовым риском. Если вы рассматриваете голосовой формат взаимодействия с продуктом как эксперимент и явно даете это понять пользователям, то у них не возникает завышенных ожиданий. Одновременно с этим, у вас есть право ограничить использование нового интерфейса только в тех функциях приложения, которые вам кажутся наиболее подходящими. В худшем случае пользователи проигнорируют эту возможность, но продолжат использовать продукт традиционным способом. Если же сработает «магия», то положительный отклик может быть очень сильный и вам как проектировщику будет понятно, что вы нащупали новую точку для развития продукта.
Обратите внимание, что на проекты можно смотреть в разном масштабе. В ряде случаев проект, имеющий лично для вас огромное значение, в масштабах бизнеса клиента, с которым вы работаете, может рассматриваться как чистый эксперимент с правом на ошибку. В таком случае целиком весь проект умещается в правой части штанги, т. е. в области неопределенности. Хотя и в этом случае действует рекурсивное правило и внутри этой области есть смысл структурировать задачи по степени их риска. Да-да, это я вам говорю, уважаемые стартаперы. Работа над проектами — не игра в кости, когда вы проверяете разные варианты в хаотичном порядке, пока не найдёте приемлемый вариант (кстати каковы критерии успеха?) или пока не закончатся деньги инвестора.
Штанга, насмотренность и профессиональное развитие
Иногда хочется все бросить и начать с нуля. Надоевшую работу, одинаковые проекты, бизнес, который работает, но не радует. В надежде, что, сойдя с привычной дорожки, можно будет свернуть к чему-то совершенно новому, увлекательному и конечно же дающему уверенность в будущем. Но как не пропустить такой поворот? Как понять, что настал нужный момент и выбор верный?
Конечно, никто не может отнять у нас право вести себя безрассудно и совершенно нерационально. Читая истории выдающихся людей, часто складывает ощущение, что именно в этом и был их секрет. Но, как мне кажется, этим дело не ограничивалось. Вероятно, кроме готовности к изменениям нужно знание, куда именно можно повернуть. Знание об этих возможностях. Ведь в реальности нет никаких путей, по которым мы движемся, всё это абстракции и находятся они только у нас в голове.
Такое знание даёт насмотренность. Фактически диапазон наших возможных действий определяется нашей осведомлённостью о том, как бывает. И немного фантазией, хотя по опыту могу сказать, истинная фантазия — большая редкость и больше из области мастерства. Короче говоря, только расширяя свои знания можно двигаться дальше.
Вот так просто, но за этой простотой скрывается серьезная проблема. Ресурсы. Время и деньги. Они ограничивают наши возможности и часто из-за них мы остаёмся на одном и том же месте из года в год. Нам хотелось бы попробовать что-то новое, но риск потерять свои профессиональные позиции оказывается сильнее. Хотя ирония в том, что чем дольше мы продолжаем заниматься привычным делом, тем наша профессиональная востребованность становится ниже. Мир меняется и становятся востребованными совсем другие навыки. Поэтому рисковать все равно придётся и лучше это сделать по собственному желанию, а не вынужденно.
Концепция «штанги» работает и здесь. Вместо того, чтобы полностью делать ставку на что-то новое и в случае неудачи все потерять, стоит разделить в жизни то, что гарантирует нам профессиональную востребованность и то, что может принести долгожданные изменения. В таком случае возможные потери от неудачной попытки будут ограничены только временем, которое было потрачено на развитие насмотренности и погружения в новую тему. Жизнь продолжится и через какое-то время можно будет сделать еще одну попытку в чем-то другом. И так до тех пор, пока не будет найдено новое направление в профессиональной жизни. И даже предыдущие попытки рано или поздно пойдут в зачёт, потому что как часто бывает, развитие никогда не идёт по прямой и собирает тех, кто в теме на очередном витке.
У такого подхода есть несколько следствий. Первое, самое неочевидное, при этом наверно самое важное, состоит в том, что нам только кажется, что технологическое развитие идёт предсказуемым образом. Ретроспективно, например, мы уверены, что развитие веба было предопределено, интернет-сервисы не могли не появиться, также как после них не могли не появиться мобильные приложения и так далее. Хотя если вы постараетесь вспомнить более глубоко, то будет видно, что ничего предсказуемого в этом не было. Вы знаете, например, что идея нативных мобильных приложений первоначально казалась самой неудачной и более перспективным считался HTML5? Тоже самое касается голосовых интерфейсов. Вы действительно думаете, что это следующий шаг развития компьютерных систем или вы об этом прочитали в новостях? О появлении той или иной технологии мы часто узнаём уже когда она становится популярной. Что в свою очередь означает, что до этого ещё был период зарождения и раннего развития этой технологии. И к моменту, когда вы обнаруживаете информацию о ней из новостной ленты, ее создателями пройдёт большой путь.
Не лучше ли иметь возможность наткнуться на что-то новое и потенциально перспективное раньше и быть готовым к серьезным изменениям до того, как придётся вступить в конкуренцию со всеми, кто одновременно с вами бросится на освоение новой темы. Постоянное развитие насмотренности как радар у корабля, идущего в океане. Вам необязательно высаживаться на обнаруженный вами берег, но здорово, когда вы заранее знаете о его существовании.
О ценности первоисточников
Если вы, как и я, занимаетесь проектированием цифровых продуктов, то наверняка знакомы с концепцией персонажей, придуманной Аланом Купером. Возможно, при этом, что вы не знали автора этой концепции и познакомились с понятием персонажей в какой-то тематической статье. Также очень вероятно, что из этой статьи вам стало известно об устаревании этого подхода и его ошибочности. И вместо него автор предлагает использовать другой подход к проектированию, например, Jobs-To-Be-Done и Job stories. Самое забавное, что и автор статьи скорее всего недостаточно знаком ни с методом персонажей ни с новым методом, который он описывает. Он также, как и вы, мог о них прочитать в каком-то профессиональном издании и решил собрать все вместе.
Мне становится очень грустно, когда я читаю подобные материалы. Ведь я знаю историю появления концепции персонажей из первоисточника. Изначально подход к проектированию продуктов, основанный на концепции персонажей, подразумевал выяснение их целей. Персонажи ни в коем случае не подразумевали демографические и прочие атрибуты, которые бы сводили их к понятию аудитории продукта, разбитой на возрастные и прочие сегменты, больше похожие на маркетинговые инструменты. Нет, персонажи задумывались как способ определения требуемой функциональности продуктов, основываясь на вопросе ЗАЧЕМ, т. е. на мотивах людей, которые будут его использовать. Таким образом, отдельные персонажи, будучи обобщением мотивов пользователей, позволяют спроектировать продукт не как набор равнозначных функций, одинаково представленных в интерфейсе, а как систему, сфокусированную на целях людей. Более того, такая сфокусированность дает возможность создать интерфейс, устанавливая приоритеты для разных персонажей.
Что же произошло, почему большинство не знает о персонажах так, как они задумывались? В одном из интервью, Алан Купер рассказывает историю о том, как пришел в ужас, увидев книгу, изданную Microsoft, в которой было описание концепции персонажей. Там все было перевернуто с ног на голову, и персонажи были описаны с точки зрения атрибутов разных групп пользователей. Так поняли концепцию авторы книги. Поскольку охват читательской аудитории у издательства Microsoft по определению шире и не сопоставим с независимым консалтинговым агентством Купера, то теперь мы имеем то, что имеем.
Но людей это часто не волнует, они не любят слишком задумываться, ищут простые ответы и даже гордятся этим. Однако если вы профессионал, то я настоятельно советую всегда работать с первоисточниками. Благодаря этому вы избежите таких ошибок и сможете полноценно воспользоваться опытом других людей, вместо того чтобы быть как большинство дилетантов в нашей с вами профессии. С одной стороны это дань уважения к авторам инструментов и методов, которыми мы пользуемся, а с другой возможность глубже разобраться в сути предложенных ими идей.
Экспедиции в мир других
Возможно, вы знаете, те, кто много путешествует, имеют необычный взгляд на окружающий мир и обращают внимание на вещи, которые никто не замечает. Вспомните, как по-новому вы смотрите вокруг себя, даже после недели, проведённой в другой стране. Если же так сложилось, что вы прожили там длительный период, то это даёт вам совершенно новое ощущение при возвращении. Возможно, вы даже возвращаетесь с новыми привычками, которых хочется придерживаться в своей обычной среде. Этот же подход можно использовать и для развития профессиональной насмотренности.
Работая над проектом, я с большим удовольствием предпочту сотрудничество с дизайнером, имеющим опыт и в вебе, и в мобильных приложениях, а еще лучше, если он когда-то, кроме этого, занимался версткой для журналов. У специалистов с изначальной узкой специализацией отсутствует так называемая профессиональная мудрость. Им кажется, то, что они знают, является единственно верным. С другой стороны, те, кто имеет разноплановый опыт, гораздо легче смогут посмотреть на задачу с альтернативной точки зрения и возможно привнести из другой среды что-то полезное в проект.
Для проектировщика такое качество мне кажется не просто желаемым, но обязательным. Специалистам, реализующим продукт по уже готовым решениям, важнее иметь отточенные навыки владения соответствующим инструментарием: языками, средами разработки и т. п. В конце концов по итогу проектирования становится ясно, какие требования нужно предъявить к разработчикам и можно найти лучших из них с необходимой специализацией. Но пока идет проектирование, должны быть рассмотрены совершенно разные идеи.
Заимствовать опыт, кстати, можно не только в цифровой среде. Я наблюдал несколько раз, как специалисты, в прошлом работавшие, например, в строительстве и даже ракетостроении, синтезировали совершенно необычные для ИТ-среды решения. Просто для них существует еще одно измерение, позволяющее развернуть задачу так, как нам даже не придет в голову.
Чтобы прокачивать насмотренность, не обязательно менять работу или прикладную специализацию, в которой вы взаимодействуете с клиентами, проектируя для них продукты. Можно попробовать периодически отправляться в профессиональные экспедиции. Делайте перерывы в своей обычной деятельности и погружайтесь в работу в новой среде. Если вы дизайнер и всегда работали с вебом, договоритесь, например, с командой, которая занимается интерфейсами мобильных приложений, чтобы включиться у них в один из проектов на пару недель. Уверен, вас ждет масса сюрпризов. То же самое касается не только знаний в области проектирования продуктов, но и в управлении проектами и в работе с клиентами.
Такие экспедиции в другие профессиональные области, как и путешествия по разным странам, дадут то, что вы никогда не прочитаете в книгах и статьях. Самое важное, как правило, спрятано между строк и его можно увидеть только вживую. Поэтому посмотрите в свой календарь, договоритесь с коллегами, которые занимаются интересной для вас темой и удачи!
Исследования, как путь профессионального развития
Один на один с требованиями к продукту
В моей практике был случай, в котором для работы над проектной документацией я привлек только аналитика. Это было рациональное решение, ведь все так делают, не правда ли? Предполагалось, что он один соберёт требования к продукту и оформит задание для разработчиков в виде спецификации. Все шло замечательно ровно до тех пор, пока я, как куратор проекта, не оказался на защите первой версии проектной документации.
Я ожидал увидеть, размеченную на разделы, функциональную схему продукта. Ожидал, что будет предложена общая техническая архитектура и выполнена детализация структур данных, которая складывалась из функциональных требований. И конечно же я ожидал, что будут описаны сценарии взаимодействия с продуктом, которые были бы связаны с набросками пользовательского интерфейса. Как вы наверно догадались, ничего из этого я там не увидел.
Могло бы показаться, что у аналитика была низкая квалификация. Но нет, по опыту предыдущих проектов, с профессиональным уровнем было все в порядке. Из рук этого специалиста всегда выходили качественные материалы. Дело
Полный текст статьи читайте на CMS Magazine