Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон
Шрифт:
Интервал:
Закладка:
Впервые я осознал значимость отношений между бизнесменом и разработчиком еще в 2004 г. в Nine Star, магазине товаров для экстремальных видов спорта в Лос-Анджелесе, открытым мной вместе с бывшим коллегой по компаниям Versity и StubHub Мэттом Левенсоном. В Versity Мэтт руководил нашей деятельностью в кампусах. Он отвечал за организацию работы в десятках, а затем и в сотнях кампусов. Он нанимал менеджеров, которые подбирали тех, кто пишет конспекты, и формировали маркетинговые команды. На пике деятельности Versity у нас работало порядка 15 000 студентов колледжей, с которыми, как известно, трудно поддерживать отношения и состав которых почти полностью обновлялся каждый семестр. Управлять деятельностью в таком масштабе можно было только с помощью ПО. Но Мэтт был абсолютным технофобом. Когда он пришел в Versity, я выдал ему ноутбук и определил адрес электронной почты, но он сказал, что ему это не нужно.
– Мэтт, ты будешь управлять тысячами людей на всей территории Соединенных Штатов. Как ты собираешься делать это без электронной почты?
– Я просто буду звонить им, – ответил он.
Как мог парень, отказавшийся пользоваться ноутбуком и электронной почтой, работать в высокотехнологичной компании? Однако Мэтт работал, в этом ему помогал наш уникальный способ сотрудничества, который я позднее стал называть методологией «Спроси своего разработчика».
Время от времени Мэтт обращался ко мне с какой-нибудь проблемой по работе, которую ему нужно было решить. В Versity он пытался превратить менеджеров кампуса – как правило, аспирантов, желавших подработать, – в отличных руководителей. Это было сложно уже потому, что конспекты писали 10 000 студентов, а число самих конспектов доходило до сотни тысяч в каждом семестре. Все начиналось с того, что нужно было выяснить, кто из студентов делает работу хорошо, а кто – нет. Я тогда был директором по технологиям, поэтому однажды Мэтт пришел ко мне и спросил: «Как нам выяснить, какие конспекты наши пользователи считают хорошими?» Чтобы решить этот простой вопрос, мы выработали рейтинговую систему, похожую на ту, что eBay использует для оценки покупателей и продавцов. (Сегодня рейтинги в интернете обычное дело, но тогда это была довольно новая концепция.) Через несколько дней мы сделали приложение для каждого комплекта конспектов, позволяющее пользователям оценивать конспекты по пятибалльной шкале. Это приложение хранило оценки пользователей в базе данных и создавало отчет в режиме реального времени о том, какие конспекты были замечательными, а какие – паршивыми.
Затем Мэтт спросил: «Раз мы знаем рейтинг каждого комплекта конспектов, можем ли мы ежедневно рекомендовать менеджерам кампусов, что делать с точки зрения управления студентами, которые пишут конспекты?» Мы взяли рейтинг конспектов и некоторые другие параметры и создали ежедневный отчет с ключевыми показателями работы порядка 50 студентов и «рекомендуемым действием», которое варьировало от «Ничего не делать» до «Отправить благодарность по электронной почте», «Отправить отзыв по электронной почте» и «Уволить». Рекомендуемое действие выбиралось автоматически, и после того, как менеджер кампуса просмотрел и одобрил его, система сама выполняла нужное действие. За исключением, конечно, увольнения – для этого система создавала список тех, кому нужно позвонить и лично сообщить плохие новости. (Мы не были чудовищами!) У нас в системе даже имелось около десятка шаблонов писем, поэтому студенты никогда не получали одну и ту же похвалу или отзыв дважды. Мы называли это приложение «Робоменеджер», и оно позволяло нашим менеджерам кампуса управлять своей командой, тратя на это не больше пяти минут в день.
Такой способ управления использовался и в Nine Star. Однажды Мэтт спросил: «Знаешь что? Мне хотелось бы стимулировать продавцов в зависимости от количества посетителей, которых им удалось превратить в покупателей. Можно ли как-то подсчитать, сколько человек проходит через дверь, используя инфракрасные счетчики? А потом могли бы мы соотнести это с объемом продаж на кассовых терминалах и выяснить, каков наш коэффициент превращения посетителей в покупателей?»
«Думаю, можно, – сказал я. – Не знаю пока, как именно. Но это действительно интересно. Дай мне подумать».
Итак, я отправился изучать системы подсчета людей – те штуковины с датчиком освещенности на двери магазина. Я обнаружил, что у этих систем есть API. Это означало, что можно написать приложение, которое будет взаимодействовать с датчиками и получать от них данные. Я написал еще одну программу, которая получала данные от системы обслуживания кассовых терминалов, а затем соединил обе программы. Вуаля! Мы получили примитивную систему расчета коэффициента конверсии в нашем магазине. Затем я написал программу, которая сделала данные о коэффициенте конверсии посетителей доступными для наших сотрудников во внутренней компьютерной сети магазина. Теперь у нас был новый показатель, который мы могли использовать для измерения результатов торговли.
Эти штучки мы делали постоянно. Мэтт хотел выяснить, какой товар нужно вернуть поставщикам. Я строил систему, которая позволяла нам присваивать категории товарам. Например, шорты; в горошек; синие; большой размер. Я создал интерфейс, который позволял покупателям маркировать новые товары в соответствии с их категориями, и каждый месяц мы выясняли, какие товары не продаются, и отправляли их обратно.
Такое взаимодействие позволяло нам работать вместе над проблемами бизнеса, даже несмотря на то, что Мэтт был абсолютным технофобом, а я – закоренелым, истинно верующим технарем. Этот стиль работы раскрывает истину, которая кажется простой, но на деле является глубокой и на удивление неочевидной: чтобы добиться плодотворного сотрудничества, бизнесмены должны делиться с разработчиками проблемами, а не решениями.
Мэтт не говорил мне, какой код нужно писать. Он вообще не знал, какое приложение ему нужно. Он не писал длинных спецификаций. Он просто говорил: «Слушай, было бы здорово, если бы мы могли сделать то-то и то-то». Или: «Дружище, а нельзя ли
