Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - [30]

Истоки методологии «Спросите своего разработчика»

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

Впервые я осознал значимость отношений между бизнесменом и разработчиком еще в 2004 г. в Nine Star, магазине товаров для экстремальных видов спорта в Лос-Анджелесе, открытым мной вместе с бывшим коллегой по компаниям Versity и StubHub Мэттом Левенсоном. В Versity Мэтт руководил нашей деятельностью в кампусах. Он отвечал за организацию работы в десятках, а затем и в сотнях кампусов. Он нанимал менеджеров, которые подбирали тех, кто пишет конспекты, и формировали маркетинговые команды. На пике деятельности Versity у нас работало порядка 15 000 студентов колледжей, с которыми, как известно, трудно поддерживать отношения и состав которых почти полностью обновлялся каждый семестр. Управлять деятельностью в таком масштабе можно было только с помощью ПО. Но Мэтт был абсолютным технофобом. Когда он пришел в Versity, я выдал ему ноутбук и определил адрес электронной почты, но он сказал, что ему это не нужно.

– Мэтт, ты будешь управлять тысячами людей на всей территории Соединенных Штатов. Как ты собираешься делать это без электронной почты?

– Я просто буду звонить им, – ответил он.

Как мог парень, отказавшийся пользоваться ноутбуком и электронной почтой, работать в высокотехнологичной компании? Однако Мэтт работал, в этом ему помогал наш уникальный способ сотрудничества, который я позднее стал называть методологией «Спроси своего разработчика».

Время от времени Мэтт обращался ко мне с какой-нибудь проблемой по работе, которую ему нужно было решить. В Versity он пытался превратить менеджеров кампуса – как правило, аспирантов, желавших подработать, – в отличных руководителей. Это было сложно уже потому, что конспекты писали 10 000 студентов, а число самих конспектов доходило до сотни тысяч в каждом семестре. Все начиналось с того, что нужно было выяснить, кто из студентов делает работу хорошо, а кто – нет. Я тогда был директором по технологиям, поэтому однажды Мэтт пришел ко мне и спросил: «Как нам выяснить, какие конспекты наши пользователи считают хорошими?» Чтобы решить этот простой вопрос, мы выработали рейтинговую систему, похожую на ту, что eBay использует для оценки покупателей и продавцов. (Сегодня рейтинги в интернете обычное дело, но тогда это была довольно новая концепция.) Через несколько дней мы сделали приложение для каждого комплекта конспектов, позволяющее пользователям оценивать конспекты по пятибалльной шкале. Это приложение хранило оценки пользователей в базе данных и создавало отчет в режиме реального времени о том, какие конспекты были замечательными, а какие – паршивыми.

Затем Мэтт спросил: «Раз мы знаем рейтинг каждого комплекта конспектов, можем ли мы ежедневно рекомендовать менеджерам кампусов, что делать с точки зрения управления студентами, которые пишут конспекты?» Мы взяли рейтинг конспектов и некоторые другие параметры и создали ежедневный отчет с ключевыми показателями работы порядка 50 студентов и «рекомендуемым действием», которое варьировало от «Ничего не делать» до «Отправить благодарность по электронной почте», «Отправить отзыв по электронной почте» и «Уволить». Рекомендуемое действие выбиралось автоматически, и после того, как менеджер кампуса просмотрел и одобрил его, система сама выполняла нужное действие. За исключением, конечно, увольнения – для этого система создавала список тех, кому нужно позвонить и лично сообщить плохие новости. (Мы не были чудовищами!) У нас в системе даже имелось около десятка шаблонов писем, поэтому студенты никогда не получали одну и ту же похвалу или отзыв дважды. Мы называли это приложение «Робоменеджер», и оно позволяло нашим менеджерам кампуса управлять своей командой, тратя на это не больше пяти минут в день.

Такой способ управления использовался и в Nine Star. Однажды Мэтт спросил: «Знаешь что? Мне хотелось бы стимулировать продавцов в зависимости от количества посетителей, которых им удалось превратить в покупателей. Можно ли как-то подсчитать, сколько человек проходит через дверь, используя инфракрасные счетчики? А потом могли бы мы соотнести это с объемом продаж на кассовых терминалах и выяснить, каков наш коэффициент превращения посетителей в покупателей?»