Критерии успешного продукта, или Как разделить зоны ответственности в команде разработчиков

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

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

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

Затем в проектную группу вошёл менеджер продукта. Руководитель не обозначил новые зоны ответственности и не распределил обязанности. Менеджеру продукта дали задание повысить показатели сайта (глубину просмотров, количество регистраций и тому подобное) и отправили в свободное плавание.

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

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

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

Категория «Бизнес и развитие»

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

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

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

Категория «Технологии и реализация»

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

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

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

Категория «Взаимодействие с пользователями»

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

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

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

Заключение

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

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

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