К книге
Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПОЧасть III Как сделать своих разработчиков успешными. Глава 9 Умение встать на место клиента. Bunq
76%
Часть III Как сделать своих разработчиков успешными. Глава 9 Умение встать на место клиента. Bunq
64

Помните Bunq, голландскую компанию с мобильным банковским приложением, о которой я рассказывал в главе 1? Эта компания организовала цепочку обратной связи с клиентами с помощью парня по имени Лерой Филон, который никогда не думал, что может полюбить банковское дело. Филон – 32-летний видеооператор, управляющий небольшой дизайнерской студией в Апелдорне, маленьком городке примерно в часе езды на восток от Амстердама. Ему так понравилось приложение Bunq, что он начал рассказывать о нем всем, кого знал. Но Лерой столкнулся с проблемой – продемонстрировать приложение было невозможно, не раскрыв баланс своего банковского счета. Поэтому он разместил предложение об улучшении Bunq на пользовательском онлайн-форуме, встроенном прямо в приложение: «Нельзя ли сделать так, чтобы я мог показывать друзьям приложение, не посвящая их в детали моих финансов?» К обсуждению подключились другие клиенты, и вскоре Лерой получил 77 положительных оценок своего замечания.

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

Для меня интереснее всего в этой истории была эффективность таких форумов. Скорее всего, на то, чтобы скрыть баланс счета, больших усилий разработчиков не потребовалось. Но объем работы службы клиентской поддержки – просеивание идей на форуме и представление выводов менеджерам по продукту, которые, в свою очередь, рассортировывают список по пригодности предложений и разрабатывают планы спринтов и пользовательские истории для инженеров, – огромен и может легко занять несколько месяцев. В таком процессе на каждом этапе теряется часть информации о первоначальном намерении клиента. В какой-то момент инженер получает техническое задание «скрыть баланс счета клиента», однако ему теперь не хватает исходного контекста. А может быть, разработчики предложат лучший способ реализации пожеланий клиента, т. е. демонстрации приложения? Но, скорее всего, в процессе работы эта конкретная идея затеряется среди того, что более существенно для прогресса. Как раз здесь потребности клиентов нередко игнорируются. Любая отдельно взятая функция слишком мала для организации, чтобы присваивать ей высший приоритет. Однако если убрать все промежуточные звенья и позволить разработчику увидеть реальную проблему клиента и потратить несколько часов на ее решение – почти как на личный проект, то клиенты будут воспринимать вас как отзывчивую, клиентоориентированную организацию.

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

Во-первых, вы очеловечите клиентов. Вместо чтения технических требований разработчики напрямую узнают от клиентов не только то, что им нужно, но и зачем это нужно. Клиенты обычно высказывают это красноречиво и в деталях, которые теряются в процессе подготовки технических требований. При непосредственном восприятии слов клиента потребность становится более реальной и человеческой, а работа – более осмысленной. Опыт Лероя сделал его еще большим поклонником Bunq. На самом деле это превратило его, можно сказать, в пропагандиста. Он рассказывает всем о том, как прекрасно приложение Bunq. Представьте, что происходит с разработчиком, который создал подобную функцию и увидел, как эта небольшая работа произвела большой эффект – да что там, настоящий прорыв! Я сам испытывал такое в роли разработчика – и это невероятное чувство. Испытав подобное раз, хочется повторить этот опыт. Тот разработчик в Bunq стал как одержимый искать, кого еще он может превратить в ярых поклонников приложения.

Во-вторых, вы позволите разработчикам инстинктивно оценивать соотношение работа‒вознаграждение. Менеджер по продукту может посчитать неприоритетной функцию «скрыть баланс клиента», поскольку в целом она не кажется очень важной, – и, честно говоря, это может быть правдой. Но изменится ли его заключение, если он узнает, что для создания этой функции потребуется всего полтора часа, а не три месяца? Думаю, что изменится. Разработчики нередко могут делать быстрые оценки, поэтому их инстинкты хорошо помогают в отборе идей с наибольшей отдачей.

Если убрать промежуточные затратные звенья, то инженеры, находящиеся близко к клиентам, могут принимать решения с низким риском, приносящие пользу клиентам. Клиенты становятся реальными людьми, а не записями в базе данных или статистическими данными. Представление о разработчиках как об асоциальных типах, оторванных от человечества, – чушь. Они, как и большинство творческих профессионалов, хотят видеть, что люди с удовольствием пользуются результатами их работы. И «тесное взаимодействие» не просто заставляет разработчиков и клиентов чувствовать себя добрыми и пушистыми – оно стимулирует рост.

Компания Bunq начала функционировать в 2016 г., в 2017 г. выросла на 800 %, а в 2018 г. еще в два раза, закончив год с объемом депозитов €211 млн. В 2019 г. Bunq снова выросла в два раза при объеме поступлений €433 млн. Эта крошечная компания в Амстердаме пользуется такой вовлеченностью и любовью клиентов, о которых мечтает каждая компания в мире. Мало того, она добилась этого без клиентских офисов и торговых агентов. Она опирается на счастливых клиентов вроде Лероя Филона, рекомендующих ее продукт людям, которых они знают лично.

Мне нравятся истории о том, как разработчики узнают непосредственно у клиентов, что нужно создавать. Я не считаю, что нужно реализовывать все идеи. Клиенты далеко не всегда знают, чего именно хотят. Однако они очень хорошо описывают свои проблемы. Дэнни Мейер, самый большой защитник клиентов, даже признал это в своей книге: «Одна из самых старых поговорок в бизнесе – “Клиент всегда прав”. Полагаю, она несколько устарела. Я за то, чтобы давать клиентам возможность быть услышанными, даже когда они неправы. Когда я общаюсь с ними, то всегда предлагаю сообщать нам о том, что у нас, с их точки зрения, неправильно. Когда они это делают, я благодарю их».

Разработчикам требуется на только доступ к потоку идей клиентов, они должны быть в потоке проблем клиентов. Приближение разработчиков к проблемам клиентов позволяет им оценивать проблемы на инстинктивном уровне и искать возможные решения.

Предыдущая главаГлава 64 из 84Следующая глава