Public web — следуем за потребителем

В 24 статье серии «Менеджмент цифрового мира» (оглавление) мы поговорим о тех практиках следования за потребителем и исследования его поведения, которые в ИТ принесло развитие public web: соцсетей и энциклопедий, интернет-магазинов, торговых площадок и агрегаторов.

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

Те, кто читал мою первую статью из блока Agile «Краткая история IT-менеджмента» помнят, что я там выделял четыре культуры ведения IT-разработки, и после культуры Agile там была культура нового времени, пришедшая примерно в 2012 году.

Что же тогда произошло? Примерно в это время развитие public web стало массовым, и в результате применявшиеся там технологии превзошли то, что применялось в корпоративной разработке. Это было замечено, в 2013 Gartner анонсировал на 2014 год новый тренд Web-Scale IT for Enterprise – применение технологий, наработанном в публичном Web для разработки "серьезных" enterprise-приложений.

Как я отмечал в своем отчете о конференции Highload-2019, развитие этого тренда хорошо видно. При этом для банков, которые активно переходили в интернет-пространство, он естественным образом развернулся уже давно. Тинькофф, Сбербанк, Альфа, Райффайзен активно представлены на IT-конференциях. А сейчас эти технологии активно осваивает Retail, в том числе тот, который производит товары, а не просто их продает. На конференции стояли стенды Lamoda, Леруа, Спортмастера и других. Был целый трек, на котором они рассказывали о своих проектах, о переходе с традиционных технологий на современные, и технологический стек там соответствует современному уровню - ClickHouse, Elastic, Kafka, Go и многое другое. И все это неизбежно предстоит другим отраслям.

Однако, public web – это не только технологии, это и свои подходы к ведению проектов. Именно их мы и будем разбирать в этой статье, а в следующей посмотрим ,что получилось от их синтеза с классическими технологиями после прихода в корпоративный сегмент. Основой по-прежнему являются Agile-методы, итерационная разработка, кроссфункциональные команды, активные коммуникации и сотрудничество, и весь остальной багаж Agile сохранился и лежит в основе. Что же добавилось принципиально нового?

Сайты ведут постоянную конкуренцию за пользователей. Довольно быстро выяснилось, что хороший дизайн сайтов имеет существенное значение, что дизайн и расположение кнопок и ссылок может в разы или даже на порядки изменить переходы по ним, и это открыло эпоху UI-дизайна, породив соответствующую специализацию. Затем сайты стали интерактивными, и было выяснено, что удобство взаимодействия – далеко не тоже самое, что дизайн элементов и следующий волной была работа с usability. И, наконец, когда взаимодействие с сайтом стало достаточно сложным, выяснился еще один принципиальный момент, отличающий public web от корпоративного софта: пользователя практически нельзя заставить учиться и читать инструкции, он должен осваивать работу на сайте интуитивно. И это породило интерес к изучению интуитивных представлений пользователей – User experience (UX).

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

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

IT наработало свои разнообразные методы изучения пользователей. Многие из них применимы не только к IT-продуктам, поэтому полезно о них знать. Один из мощных подходов – метод персонажей. Изучая своих потребителей, вы делите их на кластеры с характерным поведением, и для каждой из них создаете персонажа, наделяя его личностными качествами – возрастом, полом, образованием, рисуете его портрет. Конкретизация нужна такая, чтобы любой член команды, разрабатывающий новый продукт, мог представить себя на его месте и говорить от его имени. И тогда они могут учесть группу, представленную персонажем, при создании продукта гораздо лучше, чем при более традиционном формулировании требований. Если вы заинтересовались, то про технику персон хорошо рассказывал Юра Веденин в докладе «Persona grata» на AnalystDays-2017.

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

В качестве примера можно рассказать историю Google Glass – очков с встроенным дисплеем. Штука в том, что аналогичные устройства делали много компаний, но все они шли по одному и тому же пути: сначала делали тяжелый прототип, вкладывая довольно много средств в разработку, потому пытались привести его к приемлемому весу и габаритам и терпели неудачу. А Google пошел по другому пути: после того, как предлагали принципиальную архитектуру, конструкторы примерно оценивали узлы и делали прототип из пластилина, проволоки и подобных материалов, и проверяли: человек в принципе может это носить или нет? И потому много идей они отсеяли быстро и дешево на раннем этапе – что и принесло успех.

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

Те, кто следил за развитием Google, помнят, что после первоначального успеха компания разрабатывала множество разнообразных продуктов и сервисов. А потом, в начале 2010-х их количество начало сокращаться, в основном как раз потому, что продукты оказались вовсе не столь востребованы. А еще потому, что при их создании разработчики вообще не подумали о монетизации продукта – инженерам это свойственно. И тогда пришли менеджеры и объяснили разработчикам, что эти факторы учитывать необходимо. Изменения оказались не простыми, эту историю можно прочесть в посте Джеймса Уиттакера, одного из разработчиков в Google с рассказом о тех изменениях (2012).

Опыт показывает, что никакое изучение пользователя не дает гарантии, что очередной продукт ему понравится и будет иметь успех, что новые изменения привлекут посетителей на сайт, а не оттолкнуть их. И поэтому изучение user experience дополняется постоянной проверкой гипотез, A/B тестированием на реальных пользователях. Этот процесс поставлен на поток, в таких интернет-компаниях, как Яндекс в тестировании параллельно находятся десятки, если не сотни изменений, каждое из которых оценивается на отдельной испытательной и контрольной группах, при этом в той или иной мере в испытания вовлечены более половины пользователей.

По сути, A/B тестирование представляет собой проверку: а принесла ли новая функциональность действительную ценность пользователю. Естественно, что постоянная проверка гипотез и доработка функционала порождает практики постоянного мониторинга состояния продукта в реальном времени. Мониторинг отражает не только техническую работа софта, но и его бизнес-показатели для компании, а так же получение ценности пользователями и их удовлетворенность.

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

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

Однако, все эти стартапы разворачиваются не «в чистом поле», а вокруг одного и того же продукта, с общей кодовой базой. В некоторых случаях это требует существенной реорганизации команд, и IT умеет это делать в условиях эксплуатации продукта. Фронтирным примером тут может служить опыт ivi. На TeamLeadConf-2018 Евгений Россинский рассказывал как они обеспечивали целостность продуктов и поддерживали знания разработчиков при переходе к кроссфункциональным командам от команд, собранных вокруг отдельных приложений. А через год TeamLeadConf-2019 он же рассказывал как за год они для решения задач реинжиниринга ядра продукта вернулись к командам, организованным по приложениям, провели реинжиниринг, а затем – снова перешли к кросс-функциональным командам.

Отмечу, что при таком режиме работы совершенно нерелевантным становится традиционный процесс годовых бюджетов, и IT с этим тоже умеет работать. Впрочем, в большом корпоративе эта проблема тоже решается, и тут есть интересный подход Beyond budgeting. Я о нем слушал доклад Bjarte Bogsnes, Vice President норвежской компании Statoil (крупнейшая нефтегазовая компания Европы) «Beyond Budgeting — an agile management model for new business and people realities — the Statoil implementation journey» (видео, мой конспект) на ITspring.by (2017). У подхода есть свой сайт http://bbrt.org, можно изучать.

А еще интернет-проекты живут совершенно в другом темпе, чем традиционные отрасли. Там характерный темп изменений измеряется часами, максимум – днями. В то время как в других отраслях темп изменений измеряется неделями и месяцами, а то и годами, многие компании продолжают жить до сих пор. Двухнедельные спринты Scrum и ежедневный пульс daily scrum, который показывали доска и burndown 15-20 лет назад были прорывом. Сейчас темп еще увеличился, и сроки реализации от идеи до выкатки на промышленные сервера часто исчисляются днями, если не часами, и даже ежедневные релизы становятся слишком редкие, идет переход на непрерывную отгрузку нового функционала, continuous delivery, до сотен в сутки. И такой темп принципиально изменяет организацию проекта.

Отметим, что в отраслях реального производства темп тоже увеличивается. Примером может служить fasion-индустрия. Традиционно крупные бренды жили в медленном ритме сезонных коллекций, выпуская две коллекции в год, при этом цикл жизни коллекции от начала разработки до окончания сезона продаж составлял около двух лет. Сейчас многие компании разрабатывают коллекции, которые продаются всего 2-4 недели, при этом цикл жизни коллекции тоже сократился до 3-6 месяцев при том, что значительную часть занимает логистика из Китая или Юго-Восточной Азии. Кстати, чтобы сократить цикл, некоторые компании осваивают производство в России, а часть итальянских брендов начала шить в Польше или Львове.

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

И эти механизмы будут только совершенствоваться и захватывать все больше сегментов бизнеса, и они доступны всем, а не только большим компаниям. Еще в 2015 я на SECR-2015 слушал доклад Сергея Дмитриева, где он демонстрировал как буквально с помощью 10 строк кода с помощью сервисов IBM банк может по текстам переписки с клиентом получить его психологический портрет, который дальше использовать для персонализации предложения по продуктам (видео, мой конспект). А сейчас ряд платформ уже выдают психологический профиль пользователя в те миллисекунды при показе страницы, когда на невидимой бирже идет торговля за то, какая реклама этому пользователю будет показана – и в зависимости от этого рекламодатели могут предлагать разную цену показа.

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

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