Метод параноика. Принципы создания цифровых продуктов для бизнеса в условиях неопределенности

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

Аналитика ≠ проектирование

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

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

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

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

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

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

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

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

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

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

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