Учесть нужды разных клиентов в пределах одного продукта — невероятно сложная задача. С ней вы сталкиваетесь при выборе функций или способов реализации практически каждого продукта. Проектирование в меняющемся мире с меняющимися критериями успеха может оказаться нелегким делом, однако есть несколько творческих подходов, способных его облегчить.
Недавно я имел опыт весьма удачного общения с CEO одной развивающейся компании (>150 разработчиков). При разработке своей линейки продуктов компания регулярно сталкивается с проблемой определения баланса функциональности — той, что необходима конечным потребителям, в противовес той, что важна IT-профессионалам. Этот вопрос наиболее актуален в развивающейся компании, когда ресурсы ограничены и очень важно завоевать своих первых платежеспособных клиентов.
Я намеренно использовал выражение «в противовес». Чаще всего мы считаем такие конфликты бинарными, «или/или». Такова природа инженерного взгляда на подобные проблемы. «Продажники»/маркетологи, напротив, часто видят это скорее как «и», когда наиболее желаемый результат — удовлетворить потребности каждого типа клиента. На практике же границы между тем, что нужно сделать, и тем, что можно сделать, гораздо менее четкие.
Это естественно, поскольку обычно считается, что «айтишники» и конечные пользователи находятся в противодействиии (к слову, я никогда особо не жаловал термины «пользователь» и «конечный пользователь» — один мудрый program manager, вместе с которым я имел удовольствие работать, однажды заметил, что «есть только одна индустрия, которая называет своих клиентов «пользователями», давай не будем ей уподобляться» (user – англ. жарг. «нарик», прим. пер.). IT-специалистам кажется, что конечные пользователи существуют только для того, чтобы быть причиной утечек информации или перегружать сеть. Конечные пользователи (давайте назовем их просто Людьми) считают, что единственная цель «айтишников» — не давать им работать. Опять же, в реальности всё не столь категорично.
Тем не менее, мы постоянно сталкиваемся с необходимостью идти на уступки во время составления списка функций и, как следствие, плана разработки продукта. Фактически, легко перечислить разные типы клиентов почти любого современного продукта:
Не для всякого продукта будут актуальны все категории клиентов из потенциально возможных, при этом в данном списке приведены далеко не все типы. Иногда бывают пересечения: например, часто IT-профессионалы — еще и энтузиасты и/или продвинутые пользователи. Нередко для обозначения типа клиента используют термин «персона». Это хороший подход, но часто вместо того, чтобы фокусироваться на особенностях личности, для планирования и оценки продукта достаточно просто определить общую категорию в широком смысле. «Персоны» будут задействованы позже.
В отраслях, которые характеризуются сочетанием физических продуктов и физических каналов распространения, продукты сегментируются и предлагаются с разными характеристиками по разным ценам для разных клиентов. Программные и аппаратные продукты, которые применяются смешанно или не предполагают разделения на использование в работе или для личных нужд, или же переключаются между этими функциями по нескольку раз за день, представляют особую проблему для разработчиков продукта (и специалистов по сбыту). Работа в рамках этой тенденции консьюмеризации и подтолкнула меня к тому, чтобы написать этот пост.
Относительно разработки для такого сценария, план продукта может пострадать из-за следующих проблем в планировании или в подходе:
Ключ к проблеме компромиссов — заранее решить, что вы на них пойдете. По сути, продуктовая разработка это всегда компромиссы во многих измерениях — фактически, её можно представить как серию компромиссов и связанных с ними принятых решений.
Сквозные темы этой серии статей — необходимость вскрывать проблемы при составлении плана и заранее приготовиться делать выбор. Чем считать это микро-менеджментом в «водопадном подходе», команде необходимо прийти к принципам, которые будут направлять ее в процессе принятия ежедневных решений. Принципы и планы работают лучше, чем бюджеты, структуры или списки требований. Принципы – это то, что умные и творческие люди могут эффективно использовать как инструмент для разрешения конфликтов, неизбежных при разработке продукта. Бюджеты и требования же больше похожи на оружие, которое можно использовать против других сторон, чтобы затормозить работу. Принципы показывают команде начальную и конечную точки и дают советы о том, как принимать решения по мере движения к финальному результату.
Предположим, к примеру, что в утвержденном вами бюджете указано, сколько ресурсов будет выделено для Людей, сколько для айтишников. На бумаге выглядит хорошо. Кажется, что это простой путь решить заранее, как устранять конфликты и напряжение.
Однако это может дать обратный эффект, поскольку это не целостный план того, чем должен стать продукт. По сути это препятствует реализации целостного плана, так как в таком случае первое ваше решение будет касаться разделения ресурсов. Ответственные за эти ресурсы будут в дальнейшем стараться выполнить именно свою часть плана вместо того, чтобы думать о целом проекте. Это не их злой умысел, а просто естественное следствие распределения и учета ресурсов.
Аналогичная динамика может наметиться и в случае, если вы разделите команду, к примеру, на front end/back end или интерфейс/службы. Это хорошая структура, но она должна создаваться в контексте целостного плана. Закладывать ее до появления самого плана, а затем надеяться, что план разрешит сложные проблемы – такой подход может создать трудности.
Конфликты и напряжение, на самом деле, возникают из-за подхода, основанного на бюджетировании ресурсов: люди естественным образом перекладывают выбор и решения на руководство и на инструменты распределения ресурсов вместо того, чтобы действовать исходя из совместно составленного плана продукта.
Основываясь на информации о том, как разработать основу для принятия решений, изложенной в предыдущем посте, те же самые инструменты можно использовать для перекрестной проверки плана применительно к каждому из типов клиентов.
Мы обсуждали инструмент, который позволяет выделить идеи в отношении функционала и определить стоимость, как способ создать целостное представление о продукте. Его можно применять с разными людьми в организации или даже с клиентами/партнерами.
Составив такой список, можно идти дальше. Не лишним будет улучшить список предложенных идей, используя свои знания в описании функционала и детализации. Полезно на этом этапе разработать каталог функций, который, по вашему мнению, можно будет эффективно донести до широкой аудитории клиентов.
Например, для больших проектов вы можете в рамках мастер-классов для клиентов организовать выступление, в котором расскажете о продукте. Для продукта первого поколения эти функции можно выложить на информационной странице сайта или даже включить в содержание обзора продукта, который вы предложите журналистам.
Можно добиться понимания уступок, на которые вы пошли в отношении разных типов клиентов, сопоставив все функции продукта с определенными вами типами потребителей. Это легко представить в виде в таблице или даже в списке, составленном на доске.
Каждая функция должна значиться в списке всего один раз – одна и та же «фича» не должна преподноситься как реализованная для более чем одной категории клиентов. Это заставит вас решить, кому она больше всего нужна. Функции сами естественным образом расставятся по местам. Например, функционал управления будет отнесен к айтишникам, а простота — к конечным пользователям.
На этой фазе большинство продуктов обнаружат неизбежный «перекос» в сторону одного типа клиентов. Далее всей команде необходимо мысленно вернуться назад и подумать, правильно ли были определены компромиссы.
Затем повторите этот процесс и удостоверьтесь, что вы действительно получили целостный план. Как только вы приблизились к нему, вы можете распределять ресурсы. Конечно, процесс на этом не заканчивается. С усовершенствованным представлением плана и ресурсов вы сможете двигаться дальше. Качество реализации затем повышается на основе доступных ресурсов, и это лучше, чем основанные на них генерация идей и планирование. В отличие от характерного «водопадного подхода», хороший процесс планирования — это процесс итераций, совмещения и параллельных сквозных действий в разных областях.
Возможно, всё вышесказанное звучит неплохо. Реализовав всё это, вы справитесь с задачей распределения ресурсов и определения границ продукта относительно разных типов клиентов. Однако это не решает одного очень серьезного вопроса. Что делать, если клиенту нужен конфликт?
Можно попробовать спрятать голову в песок и просто сказать, что никакого конфликта нет. Предположить, к примеру, будто конечные пользователи оценят отсутствие возможностей, опущенных в угоду айтишникам. Или что айтишники уж как-нибудь свыкнутся с тем, что устройство самовольно загружает расширения. Конечно, этот номер не пройдет.
Поскольку разработка продукта никогда не кончается — релиз становится лишь точкой на временной оси, особенно сегодня, в условиях непрерывных циклов разработки — нужно спокойно относиться к тому, что в каждом релизе всем не угодишь. Но ведь всегда будет следующий. Поэтому для определения правильных компромиссов при разработке вам нужны набор принципов и архитектура продукта, которые вы сможете взять за основу.
Здесь крайне важно понимать долгосрочную стратегию – куда движется ваш продукт. Большинство продуктов, когда они новые, получают смесь похвалы и критики, к примеру, от продвинутых пользователей. Если сценарий или решенная проблема выглядит убедительно, продвинутые пользователи будут нахваливать продукт. Они, как правило, скоры на обратную связь и тут же подбрасывают кучу предложений, как повысить гибкость продукта или добавить функций. Им это нравится.
В процессе проектирования продукта проектировщик прежде всего должен знать направление развития. Откуда вы узнаете, как добавить функциональность и улучшить управляемость? Если у вас нет идей на этот счет на стадии проектирования, вы будете проектировать впустую. Знаменитый пример — первая версия смартфона была выпущена без функции copy/paste. Но проектировщики, точно знали, как дальше будет развиваться новый язык дизайна. Понимание направлений развития было очень важно, и облегчило внедрение данной функции —не ухудшив при этом общую простоту использования, которая была главным достоинством всего дизайна. А ведь мы могли легко наткнуться на конфликт функциональности и простоты использования.
Архитектура кода или архитектурные подходы играют ключевую роль в понимании того, где вы находитесь сегодня и куда двигаетесь. Если сравнить платформы современных ОС с тем, как они выглядели 10 лет назад, вы увидите, что множество архитектурных различий стали результатом компромиссов в архитектуре. Магазины приложений, «песочницы», API посредников — все это было придумано ради создания архитектуры, которая стала бы более защищенной, безопасной для конечного пользователя и позволяла бы устройствам дольше работать от батареи.
Сегодня, глядя на эти архитектурные изменения и сравнивая с тем, с чего всё начиналось, мы легко можем увидеть разницу. Но, подумайте о том, сколько для этого пришлось дискутировать и планировать — это был переломный момент в подходе. Создателям платформ было нелегко пойти на данные компромиссы, исходя именно из этого нового подхода. Творческий подход к новым требованиям — секрет понимания эволюции вашего продукта с течением времени.
Важно иметь инструмент в виде набора принципов продукта — язык дизайна, архитектурные шаблоны решений, предложения потребительской ценности. Эти принципы не только направляют команду разработчиков, но и помогают объяснить клиентам, почему вы пошли именно на эти компромиссы. Это не облегчит диалог и не заставит людей согласиться с вашими решениями. Однако при обсуждении будет понятно, для достижения каких целей предназначен ваш продукт.
Удивительные изменения происходят в нашей отрасли сегодня с появлением«BYOD» (Bring Your Own Device – разрешение использования личных устройств на рабочих местах для доступа к корпоративным ресурсам). Это абсолютно новый уровень конфликтов, которые приходится разрешать. С конца 90-х суть администрирования сводилась к «блокировке» или «контролю» используемых устройств. Это было правильно в рамках существовавшей ситуации и решаемых проблем.
Теперь пользователи могут приносить свои личные устройства на работу, работать из дома или находить свои способы выполнять свои задачи вне границ корпоративной сети/софта/техники. Это не изменяет корпоративных или государственных требований к надежности и безопасности. Это не изменяет и правил принятия решений для IT. У их внутренних клиентов есть выбор, и очень интересно проследить, как этот выбор накладывается на конфликты в разработке продуктов.
Сродни тому, как меняются API и возможности ОС, заставляя, пожалуй, некоторые категории клиентов пересмотреть свои ожидания, так же и устройства, и программное обеспечение меняют свою архитектуру. На этапе планирования продукта разработка такого подхода к архитектуре, который будет удобен в долгосрочной перспективе – главное, что поможет найти нужные компромиссы при проектировании.
Это инженерная составляющая в разрешении конфликтов — иногда не просто новые функции, а новые подходы к архитектуре задают вашу новую траекторию. Эта новая траектория определяет новые способы проектирования продукта для многих типов пользователей.
Единственное, в чем вы можете быть уверены – не существует «правильного» выбора компромиссов, благодаря которому можно было бы удовлетворить всех клиентов. В этом суть разработки для разных типов потребителей. Именно поэтому разработка продуктов — еще и социальная наука.
Сегодня один из самых жарких споров разгорается вокруг того, как уравновесить потребности IT-службы компании и сообщества людей, использующих продукты внутри этой компании. Это серьезный сдвиг, происходящий в отрасли благодаря волне продуктов, позволяющих действовать вне сценариев, подконтрольных IT-службе.
Совершенно точно, что меняются потребности организаций не в защите их цифровых активов и не в поддержании целостности корпоративной сети — и даже не в управлении общим использованием корпоративных ресурсов (баланс работы и активности, не относящейся к работе). Эти требования сейчас не просто остаются актуальными – в современном мире они важны как никогда, поскольку любая утечка клиентской или финансовой информации может вылиться в новость международного масштаба или заинтересовать надзорные органы.
Перемены кроются в том, что люди, работающие в компаниях, получили легкий доступ к инструментам, позволяющим делать то, что им нужно. В другие времена приобретение серверов, лицензирование софта, его запуск на месте и работа с ними требовали помощи IT-службы и, нередко, ресурсов. Сегодня такие инструменты, как облачные хранилища, peer-to-peer взаимодействие, CRM или даже интернет-магазины доступны за пару кликов, и всё, что нужно – это (корпоративная!) кредитка, а порой можно обойтись и без нее.
Единственный регулирующий механизм, который может быть задействован для «борьбы против» этих инструментов – это политический подход. Можно заблокировать TCP/IP порты или сомнительный сетевой трафик (и, конечно, заблокировать на управляемых компьютерах загрузку клиентских приложений), но даже это не решит проблему. Доступ к сети легко получить через WiFi/4G точку доступа или через телефон в режиме общего доступа.
Обычные способы блокировки устройств больше не работают. В мире мобильных устройств и, возможно, даже множества операционных систем, нет четко определенной точки, где нужно блокировать, и уж конечно, это никак нельзя реализовать.
Кто-то видит в этом свободу, кто-то — хаос. А умные разработчики видят в этом возможность. Это хорошая возможность разработать продукт, который решает эту проблему и способен при этом предоставить архитектурное решение для IT, позволяющее им делать то, что от них требуется; и в то же время благодаря такому продукту людям будет проще находить и делиться с коллегами инструментами для решения своих бизнес-задач.
Сложность при разработке — в том, чтобы определить новую архитектуру, которая принимала бы во внимание реальную ситуацию: если при проектировании вы слишком ударитесь в одно из направлений, то загоните себя в тупик. Если вы сосредоточитесь на том, чтобы дать людям максимум возможностей, ваш продукт может либо столкнуться с политикой IT-служб, либо, что еще хуже, с активной компанией сообщества корпоративных аналитиков, направленной против него. Если же вы сфокусируетесь на нуждах айтишников, не исключено, что они превратят хороший продукт в закрытое или подстроенное под себя решение, что вынудит конечных пользователей пойти к конкурентам – а те всегда всего лишь на расстоянии клика.
Здесь вступают в игру принципы разработки. Какая схема управления реализована сейчас — есть ли что-либо, внедренное IT-компаниями, снижающее привлекательность корпоративного использования по сравнению с домашним или, например, с BYOD? Возможно, меры вроде непомерного числа logon-скриптов или сложных ограничений доступа к сети, которые заставляют людей избегать пользоваться сетью и вместо этого выбирать путь наименьшего сопротивления? Или же это возможности персональных настроек, которые применимы и на домашних PC, и из-за того, что на работе «всё по-другому», человек старается использовать домашний компьютер и для работы?
Учитывая подобное окружение и разнообразие возможных решений, какая архитектура сможет учесть недостатки существующих подходов к корпоративному управлению сетью и предложить более подходящий вариант, в то же время обеспечивая безопасность?
Можно ли управлять устройством без изменения user experience? Можно ли заблокировать программный продукт, оставив только жизненно важные функции, тем самым уменьшив число звонков в техподдержку — чтобы айтишники не разрывались между своей работой и обращениями сотрудников?
Подобные вопросы необходимо поднимать при попытках примирить заведомо противоречащие друг другу потребности IT и людей, которые используют современные продукты и услуги. Глубокое погружение в подобные нюансы во время разработки вашего продукта может помочь создать по-настоящему конкурентное преимущество для вашего продукта или услуги.
Компромисс интересов клиентов
Недавно я имел опыт весьма удачного общения с CEO одной развивающейся компании (>150 разработчиков). При разработке своей линейки продуктов компания регулярно сталкивается с проблемой определения баланса функциональности — той, что необходима конечным потребителям, в противовес той, что важна IT-профессионалам. Этот вопрос наиболее актуален в развивающейся компании, когда ресурсы ограничены и очень важно завоевать своих первых платежеспособных клиентов.
Я намеренно использовал выражение «в противовес». Чаще всего мы считаем такие конфликты бинарными, «или/или». Такова природа инженерного взгляда на подобные проблемы. «Продажники»/маркетологи, напротив, часто видят это скорее как «и», когда наиболее желаемый результат — удовлетворить потребности каждого типа клиента. На практике же границы между тем, что нужно сделать, и тем, что можно сделать, гораздо менее четкие.
Это естественно, поскольку обычно считается, что «айтишники» и конечные пользователи находятся в противодействиии (к слову, я никогда особо не жаловал термины «пользователь» и «конечный пользователь» — один мудрый program manager, вместе с которым я имел удовольствие работать, однажды заметил, что «есть только одна индустрия, которая называет своих клиентов «пользователями», давай не будем ей уподобляться» (user – англ. жарг. «нарик», прим. пер.). IT-специалистам кажется, что конечные пользователи существуют только для того, чтобы быть причиной утечек информации или перегружать сеть. Конечные пользователи (давайте назовем их просто Людьми) считают, что единственная цель «айтишников» — не давать им работать. Опять же, в реальности всё не столь категорично.
Тем не менее, мы постоянно сталкиваемся с необходимостью идти на уступки во время составления списка функций и, как следствие, плана разработки продукта. Фактически, легко перечислить разные типы клиентов почти любого современного продукта:
- Люди. Это широкий круг тех, кто будет применять ваш продукт. Обычно не предполагается, что эти Люди имеют высокий уровень навыков в использовании продукта. Это типичные клиенты. Конечно, все остальные клиенты тоже люди :-) Сложность, с которой все сталкиваются — представить свою клиентуру вне рамок типичного потребителя.
- IT-профессионалы. Именно айтишники покупают, устанавливают и поддерживают большинство продуктов. Также они могут отвечать за инфраструктуру или оборудование, необходимое для использования продукта/услуги. А еще айтишники отстаивают интересы людей в компаниях, которые они поддерживают.
- Разработчики. Разработчики вносят свой вклад в написание дополнений или используют API для создания решений, «заточенных» под конкретные нужды. Для множества продуктов разработчики составляют критически важную часть экосистемы и часто создают основу его успеха.
- Продвинутые пользователи/энтузиасты. Эти ребята знают продукт вдоль и поперек. Часто они учат других, как им пользоваться, подписываются на новости и сидят на форумах, ведут блоги и пишут статьи о вашем продукте. Это ваши фанаты. У продвинутых пользователей также есть пожелания (требования!) к функционалу в плане того, как усовершенствовать управление, возможности персональной настройки и так далее. Обратите внимание, как это может сыграть против IT-профи, которым нужно как можно меньше таких функций, или Людей, которых эти самые возможности могут запутать.
- Торговые партнеры. Многие продукты продаются напрямую людям или IT-подразделениям. Но немало и таких, для которых нужны посредники, чтобы продавать их, поддерживать или принимать оплату от клиентов. В случае с продуктами, которым требуется реклама, такими людьми будут ваши рекламодатели. Это создает еще один фактор напряжения, о котором часто говорят применительно к нашей отрасли – реклама в приложениях и на сайтах, которая важна партнерам, но, возможно, не особо понравится, к примеру, Людям.
- Рынки. Многие продукты нацелены на удовлетворение потребностей глобальной клиентской базы. Но даже в масштабах глобальной экономики существуют серьезные отличия в функциях и сценариях, применимых в разных странах и регионах.
Не для всякого продукта будут актуальны все категории клиентов из потенциально возможных, при этом в данном списке приведены далеко не все типы. Иногда бывают пересечения: например, часто IT-профессионалы — еще и энтузиасты и/или продвинутые пользователи. Нередко для обозначения типа клиента используют термин «персона». Это хороший подход, но часто вместо того, чтобы фокусироваться на особенностях личности, для планирования и оценки продукта достаточно просто определить общую категорию в широком смысле. «Персоны» будут задействованы позже.
В отраслях, которые характеризуются сочетанием физических продуктов и физических каналов распространения, продукты сегментируются и предлагаются с разными характеристиками по разным ценам для разных клиентов. Программные и аппаратные продукты, которые применяются смешанно или не предполагают разделения на использование в работе или для личных нужд, или же переключаются между этими функциями по нескольку раз за день, представляют особую проблему для разработчиков продукта (и специалистов по сбыту). Работа в рамках этой тенденции консьюмеризации и подтолкнула меня к тому, чтобы написать этот пост.
Относительно разработки для такого сценария, план продукта может пострадать из-за следующих проблем в планировании или в подходе:
- Сфокусироваться только на одном типе клиента. Иногда подход заключается лишь в том, чтобы просто взять и провести линию, сказав себе «мы ориентируемся на конечного пользователя». Часто такой подход по умолчанию применяется к большинству продуктов. В отношении некоторых продуктов есть четкое представление о целевой аудитории и понятная стратегия. Затем следуют «некоторые возможности», нацеленные на то, чтобы угодить другим типам потенциальных клиентов. Вы можете логически обосновать это, объединив типы клиентов и приняв за основу утверждение вроде «Разработчики – это просто Люди, которые могут писать код».
- Сделать везде понемногу. Может так получиться, что продукт не очень хорошо продуман, и организация или сторона, обеспечивающая предварительное финансирование, в итоге начинают указывать, насколько продукт должен быть ориентирован на тот или иной тип клиента. Например, если выделить на каждый сегмент по несколько разработчиков и дать им планировать независимо друг от друга, шансы того, что все функции в итоге удастся совместить, резко снижаются. Скорее всего, потом эти функции будут соперничать или конфликтовать в ходе разработки.
- Разработать план (и частично его выполнить) и затем в процессе осознать, что вы пропустили клиента. Мы уже обсуждали необходимость объединения инженерных и маркетинговых усилий. Некоторые планы создаются, учитывая только подход со стороны разработки, что не окупается, и как только продукт начинает обретать форму, неизбежно начинается паника из серии «у нас же нет функций для Х», где Х — тип клиента, которого «недолюбили» при разработке. Совещания. Паника. «Допиливание» в последний момент. Не работает.
Ключ к проблеме компромиссов — заранее решить, что вы на них пойдете. По сути, продуктовая разработка это всегда компромиссы во многих измерениях — фактически, её можно представить как серию компромиссов и связанных с ними принятых решений.
Приготовиться делать выбор
Сквозные темы этой серии статей — необходимость вскрывать проблемы при составлении плана и заранее приготовиться делать выбор. Чем считать это микро-менеджментом в «водопадном подходе», команде необходимо прийти к принципам, которые будут направлять ее в процессе принятия ежедневных решений. Принципы и планы работают лучше, чем бюджеты, структуры или списки требований. Принципы – это то, что умные и творческие люди могут эффективно использовать как инструмент для разрешения конфликтов, неизбежных при разработке продукта. Бюджеты и требования же больше похожи на оружие, которое можно использовать против других сторон, чтобы затормозить работу. Принципы показывают команде начальную и конечную точки и дают советы о том, как принимать решения по мере движения к финальному результату.
Предположим, к примеру, что в утвержденном вами бюджете указано, сколько ресурсов будет выделено для Людей, сколько для айтишников. На бумаге выглядит хорошо. Кажется, что это простой путь решить заранее, как устранять конфликты и напряжение.
Однако это может дать обратный эффект, поскольку это не целостный план того, чем должен стать продукт. По сути это препятствует реализации целостного плана, так как в таком случае первое ваше решение будет касаться разделения ресурсов. Ответственные за эти ресурсы будут в дальнейшем стараться выполнить именно свою часть плана вместо того, чтобы думать о целом проекте. Это не их злой умысел, а просто естественное следствие распределения и учета ресурсов.
Аналогичная динамика может наметиться и в случае, если вы разделите команду, к примеру, на front end/back end или интерфейс/службы. Это хорошая структура, но она должна создаваться в контексте целостного плана. Закладывать ее до появления самого плана, а затем надеяться, что план разрешит сложные проблемы – такой подход может создать трудности.
Конфликты и напряжение, на самом деле, возникают из-за подхода, основанного на бюджетировании ресурсов: люди естественным образом перекладывают выбор и решения на руководство и на инструменты распределения ресурсов вместо того, чтобы действовать исходя из совместно составленного плана продукта.
Подход
Основываясь на информации о том, как разработать основу для принятия решений, изложенной в предыдущем посте, те же самые инструменты можно использовать для перекрестной проверки плана применительно к каждому из типов клиентов.
Мы обсуждали инструмент, который позволяет выделить идеи в отношении функционала и определить стоимость, как способ создать целостное представление о продукте. Его можно применять с разными людьми в организации или даже с клиентами/партнерами.
Составив такой список, можно идти дальше. Не лишним будет улучшить список предложенных идей, используя свои знания в описании функционала и детализации. Полезно на этом этапе разработать каталог функций, который, по вашему мнению, можно будет эффективно донести до широкой аудитории клиентов.
Например, для больших проектов вы можете в рамках мастер-классов для клиентов организовать выступление, в котором расскажете о продукте. Для продукта первого поколения эти функции можно выложить на информационной странице сайта или даже включить в содержание обзора продукта, который вы предложите журналистам.
Можно добиться понимания уступок, на которые вы пошли в отношении разных типов клиентов, сопоставив все функции продукта с определенными вами типами потребителей. Это легко представить в виде в таблице или даже в списке, составленном на доске.
Каждая функция должна значиться в списке всего один раз – одна и та же «фича» не должна преподноситься как реализованная для более чем одной категории клиентов. Это заставит вас решить, кому она больше всего нужна. Функции сами естественным образом расставятся по местам. Например, функционал управления будет отнесен к айтишникам, а простота — к конечным пользователям.
На этой фазе большинство продуктов обнаружат неизбежный «перекос» в сторону одного типа клиентов. Далее всей команде необходимо мысленно вернуться назад и подумать, правильно ли были определены компромиссы.
Затем повторите этот процесс и удостоверьтесь, что вы действительно получили целостный план. Как только вы приблизились к нему, вы можете распределять ресурсы. Конечно, процесс на этом не заканчивается. С усовершенствованным представлением плана и ресурсов вы сможете двигаться дальше. Качество реализации затем повышается на основе доступных ресурсов, и это лучше, чем основанные на них генерация идей и планирование. В отличие от характерного «водопадного подхода», хороший процесс планирования — это процесс итераций, совмещения и параллельных сквозных действий в разных областях.
Проектирование конфликтов
Возможно, всё вышесказанное звучит неплохо. Реализовав всё это, вы справитесь с задачей распределения ресурсов и определения границ продукта относительно разных типов клиентов. Однако это не решает одного очень серьезного вопроса. Что делать, если клиенту нужен конфликт?
Можно попробовать спрятать голову в песок и просто сказать, что никакого конфликта нет. Предположить, к примеру, будто конечные пользователи оценят отсутствие возможностей, опущенных в угоду айтишникам. Или что айтишники уж как-нибудь свыкнутся с тем, что устройство самовольно загружает расширения. Конечно, этот номер не пройдет.
Поскольку разработка продукта никогда не кончается — релиз становится лишь точкой на временной оси, особенно сегодня, в условиях непрерывных циклов разработки — нужно спокойно относиться к тому, что в каждом релизе всем не угодишь. Но ведь всегда будет следующий. Поэтому для определения правильных компромиссов при разработке вам нужны набор принципов и архитектура продукта, которые вы сможете взять за основу.
Здесь крайне важно понимать долгосрочную стратегию – куда движется ваш продукт. Большинство продуктов, когда они новые, получают смесь похвалы и критики, к примеру, от продвинутых пользователей. Если сценарий или решенная проблема выглядит убедительно, продвинутые пользователи будут нахваливать продукт. Они, как правило, скоры на обратную связь и тут же подбрасывают кучу предложений, как повысить гибкость продукта или добавить функций. Им это нравится.
В процессе проектирования продукта проектировщик прежде всего должен знать направление развития. Откуда вы узнаете, как добавить функциональность и улучшить управляемость? Если у вас нет идей на этот счет на стадии проектирования, вы будете проектировать впустую. Знаменитый пример — первая версия смартфона была выпущена без функции copy/paste. Но проектировщики, точно знали, как дальше будет развиваться новый язык дизайна. Понимание направлений развития было очень важно, и облегчило внедрение данной функции —не ухудшив при этом общую простоту использования, которая была главным достоинством всего дизайна. А ведь мы могли легко наткнуться на конфликт функциональности и простоты использования.
Архитектура кода или архитектурные подходы играют ключевую роль в понимании того, где вы находитесь сегодня и куда двигаетесь. Если сравнить платформы современных ОС с тем, как они выглядели 10 лет назад, вы увидите, что множество архитектурных различий стали результатом компромиссов в архитектуре. Магазины приложений, «песочницы», API посредников — все это было придумано ради создания архитектуры, которая стала бы более защищенной, безопасной для конечного пользователя и позволяла бы устройствам дольше работать от батареи.
Сегодня, глядя на эти архитектурные изменения и сравнивая с тем, с чего всё начиналось, мы легко можем увидеть разницу. Но, подумайте о том, сколько для этого пришлось дискутировать и планировать — это был переломный момент в подходе. Создателям платформ было нелегко пойти на данные компромиссы, исходя именно из этого нового подхода. Творческий подход к новым требованиям — секрет понимания эволюции вашего продукта с течением времени.
Важно иметь инструмент в виде набора принципов продукта — язык дизайна, архитектурные шаблоны решений, предложения потребительской ценности. Эти принципы не только направляют команду разработчиков, но и помогают объяснить клиентам, почему вы пошли именно на эти компромиссы. Это не облегчит диалог и не заставит людей согласиться с вашими решениями. Однако при обсуждении будет понятно, для достижения каких целей предназначен ваш продукт.
Удивительные изменения происходят в нашей отрасли сегодня с появлением«BYOD» (Bring Your Own Device – разрешение использования личных устройств на рабочих местах для доступа к корпоративным ресурсам). Это абсолютно новый уровень конфликтов, которые приходится разрешать. С конца 90-х суть администрирования сводилась к «блокировке» или «контролю» используемых устройств. Это было правильно в рамках существовавшей ситуации и решаемых проблем.
Теперь пользователи могут приносить свои личные устройства на работу, работать из дома или находить свои способы выполнять свои задачи вне границ корпоративной сети/софта/техники. Это не изменяет корпоративных или государственных требований к надежности и безопасности. Это не изменяет и правил принятия решений для IT. У их внутренних клиентов есть выбор, и очень интересно проследить, как этот выбор накладывается на конфликты в разработке продуктов.
Сродни тому, как меняются API и возможности ОС, заставляя, пожалуй, некоторые категории клиентов пересмотреть свои ожидания, так же и устройства, и программное обеспечение меняют свою архитектуру. На этапе планирования продукта разработка такого подхода к архитектуре, который будет удобен в долгосрочной перспективе – главное, что поможет найти нужные компромиссы при проектировании.
Это инженерная составляющая в разрешении конфликтов — иногда не просто новые функции, а новые подходы к архитектуре задают вашу новую траекторию. Эта новая траектория определяет новые способы проектирования продукта для многих типов пользователей.
Единственное, в чем вы можете быть уверены – не существует «правильного» выбора компромиссов, благодаря которому можно было бы удовлетворить всех клиентов. В этом суть разработки для разных типов потребителей. Именно поэтому разработка продуктов — еще и социальная наука.
Пример: корпоративная проблема
Сегодня один из самых жарких споров разгорается вокруг того, как уравновесить потребности IT-службы компании и сообщества людей, использующих продукты внутри этой компании. Это серьезный сдвиг, происходящий в отрасли благодаря волне продуктов, позволяющих действовать вне сценариев, подконтрольных IT-службе.
Совершенно точно, что меняются потребности организаций не в защите их цифровых активов и не в поддержании целостности корпоративной сети — и даже не в управлении общим использованием корпоративных ресурсов (баланс работы и активности, не относящейся к работе). Эти требования сейчас не просто остаются актуальными – в современном мире они важны как никогда, поскольку любая утечка клиентской или финансовой информации может вылиться в новость международного масштаба или заинтересовать надзорные органы.
Перемены кроются в том, что люди, работающие в компаниях, получили легкий доступ к инструментам, позволяющим делать то, что им нужно. В другие времена приобретение серверов, лицензирование софта, его запуск на месте и работа с ними требовали помощи IT-службы и, нередко, ресурсов. Сегодня такие инструменты, как облачные хранилища, peer-to-peer взаимодействие, CRM или даже интернет-магазины доступны за пару кликов, и всё, что нужно – это (корпоративная!) кредитка, а порой можно обойтись и без нее.
Единственный регулирующий механизм, который может быть задействован для «борьбы против» этих инструментов – это политический подход. Можно заблокировать TCP/IP порты или сомнительный сетевой трафик (и, конечно, заблокировать на управляемых компьютерах загрузку клиентских приложений), но даже это не решит проблему. Доступ к сети легко получить через WiFi/4G точку доступа или через телефон в режиме общего доступа.
Обычные способы блокировки устройств больше не работают. В мире мобильных устройств и, возможно, даже множества операционных систем, нет четко определенной точки, где нужно блокировать, и уж конечно, это никак нельзя реализовать.
Кто-то видит в этом свободу, кто-то — хаос. А умные разработчики видят в этом возможность. Это хорошая возможность разработать продукт, который решает эту проблему и способен при этом предоставить архитектурное решение для IT, позволяющее им делать то, что от них требуется; и в то же время благодаря такому продукту людям будет проще находить и делиться с коллегами инструментами для решения своих бизнес-задач.
Сложность при разработке — в том, чтобы определить новую архитектуру, которая принимала бы во внимание реальную ситуацию: если при проектировании вы слишком ударитесь в одно из направлений, то загоните себя в тупик. Если вы сосредоточитесь на том, чтобы дать людям максимум возможностей, ваш продукт может либо столкнуться с политикой IT-служб, либо, что еще хуже, с активной компанией сообщества корпоративных аналитиков, направленной против него. Если же вы сфокусируетесь на нуждах айтишников, не исключено, что они превратят хороший продукт в закрытое или подстроенное под себя решение, что вынудит конечных пользователей пойти к конкурентам – а те всегда всего лишь на расстоянии клика.
Здесь вступают в игру принципы разработки. Какая схема управления реализована сейчас — есть ли что-либо, внедренное IT-компаниями, снижающее привлекательность корпоративного использования по сравнению с домашним или, например, с BYOD? Возможно, меры вроде непомерного числа logon-скриптов или сложных ограничений доступа к сети, которые заставляют людей избегать пользоваться сетью и вместо этого выбирать путь наименьшего сопротивления? Или же это возможности персональных настроек, которые применимы и на домашних PC, и из-за того, что на работе «всё по-другому», человек старается использовать домашний компьютер и для работы?
Учитывая подобное окружение и разнообразие возможных решений, какая архитектура сможет учесть недостатки существующих подходов к корпоративному управлению сетью и предложить более подходящий вариант, в то же время обеспечивая безопасность?
Можно ли управлять устройством без изменения user experience? Можно ли заблокировать программный продукт, оставив только жизненно важные функции, тем самым уменьшив число звонков в техподдержку — чтобы айтишники не разрывались между своей работой и обращениями сотрудников?
Подобные вопросы необходимо поднимать при попытках примирить заведомо противоречащие друг другу потребности IT и людей, которые используют современные продукты и услуги. Глубокое погружение в подобные нюансы во время разработки вашего продукта может помочь создать по-настоящему конкурентное преимущество для вашего продукта или услуги.
