Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон Страница 30

Поначалу работа по переносу клиентских телефонных номеров легла на плечи нашего первого наемного сотрудника Лизы Уайтекамп. Лиза была мастером на все руки. Я перетянул ее из валютного департамента Wells Fargo, где она координировала торговлю. Какую бы проблему я ей ни подкидывал, она моментально разбиралась в ней. А в период становления компании таких проблем масса. У нас одной из них был перенос телефонных номеров.

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

Но весной 2012 г. мы начали получать жалобы от клиентов на то, что перенос номеров занимает вечность. Сперва электронные письма приходили в нашу службу техподдержки, потом сообщения стали сыпаться в Twitter, в конечном итоге жалобщики добрались до меня и членов совета директоров. Одна жалоба, две, а потом словно плотину прорвало. В один прекрасный день мы поняли, что 90 % жалоб клиентов связаны с переносом телефонных номеров. Поэтому мы провели расследование.

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

Это походило на тот эпизод фильма «Я люблю Люси», где героиня работает на кондитерской фабрике. С ростом скорости конвейерной ленты она начинала сначала есть конфеты, а затем запихивать их за пазуху. В исполнении Люсиль Болл это выглядело смешно, но нам было не до смеха.

Стало очевидно, что работа по переносу номеров должна быть не ручной, а максимально автоматизированной. И это нужно было сделать еще вчера.

Поскольку Лиза была знакома с процессом переноса номеров, лучше нее никто не знал, как его автоматизировать. Крис Коркоран был новым инженером в команде, но уже проявил способность находить сквозные решения проблем. Хотя он совсем недавно получил степень по информатике в Массачусетском университете, ему уже удалось пройти стажировку в NASA и поработать в Google. Ему дали прозвище Озон из-за инициалов CFC, совпадающих с химическим обозначением фреона – разрушителя озонового слоя Земли.

Я пригласил Озона и Лизу и освободил для них на две недели один из драгоценных конференц-залов в нашем офисе. Я обрисовал им проблему с процессом переноса телефонных номеров и предложил за две недели создать программу, необходимую для его автоматизации. Лиза знала, как осуществляется перенос, а Озон знал нашу программную базу вдоль и поперек. Лиза должна была рассказать Озону все, что знала, и предоставить ему свободу в поисках решения проблемы. А потом я ушел.

В первый момент они оторопели, но потом принялись за работу. Лиза продемонстрировала Озону несколько операций по переносу номеров, проработав все детали вместе с ним. Затем она передала ему клавиатуру и заставила выполнить с десяток таких операций – мы называем это «прогулка в обуви клиента». После того, как Озон прочувствовал проблему, она спросила его: «Ну вот, можно создать программу, которая будет делать это?»

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

Затем Лиза заметила, что если бы оператор мог переносить номера на разных этапах взаимодействия с клиентами, то это значительно ускорило бы работу. Озон сказал, что в типичном процессе разработки ПО добавление такой функции могло занять несколько месяцев. Но в этом случае он смог построить рабочий вариант за час.

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

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

Эмпатия к пользователям – это более качественные и быстро создаваемые продукты

Истина заключается в том, что большинство программных средств довольно просты. Это то, что разработчики называют CRUD-приложениями – от слов Create, Read, Update, Delete (создание, чтение, обновление, удаление). Большинство приложений в интернете – это формы, которые позволяют пользователю вводить, изменять, выводить или удалять данные. Почти все сайты или мобильные приложения, которыми вы когда-либо пользовались, на 95 % состоят из CRUD-операций. Это вовсе не высшая математика.

Это означает, что время, требующееся для решения проблемы, и качество решения зависят от того, насколько разработчик понимает проблему, как в