Читать «Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО» онлайн
Джефф Лоусон
Страница 30 из 79
Поначалу работа по переносу клиентских телефонных номеров легла на плечи нашего первого наемного сотрудника Лизы Уайтекамп. Лиза была мастером на все руки. Я перетянул ее из валютного департамента Wells Fargo, где она координировала торговлю. Какую бы проблему я ей ни подкидывал, она моментально разбиралась в ней. А в период становления компании таких проблем масса. У нас одной из них был перенос телефонных номеров.
В конце концов, Лиза наняла молодого парня – назовем его Тим – и поручила ему заниматься переносом телефонных номеров. Она показала Тиму алгоритм работы и передала ему электронную таблицу для отслеживания статуса процесса. Наше внимание было тогда сосредоточено на другом, и мы полагали, что Тим разберется со своим делом. Так и было некоторое время.
Но весной 2012 г. мы начали получать жалобы от клиентов на то, что перенос номеров занимает вечность. Сперва электронные письма приходили в нашу службу техподдержки, потом сообщения стали сыпаться в Twitter, в конечном итоге жалобщики добрались до меня и членов совета директоров. Одна жалоба, две, а потом словно плотину прорвало. В один прекрасный день мы поняли, что 90 % жалоб клиентов связаны с переносом телефонных номеров. Поэтому мы провели расследование.
Как оказалось, количество запросов на перенос телефонных номеров в сервисы Twilio было огромным. По мере того как наш бизнес набирал обороты, росло и количество переносимых телефонных номеров. Тим старался выдерживать темп работы, но количество запросов было больше того, с которым он мог справиться. Он добавлял их в электронную таблицу, но они поступали быстрее, чем он успевал обработать. В силу своей молодости и неопытности Тим не решался рассказать об этом. Вот запросы на перенос номеров и накапливались.
Это походило на тот эпизод фильма «Я люблю Люси», где героиня работает на кондитерской фабрике. С ростом скорости конвейерной ленты она начинала сначала есть конфеты, а затем запихивать их за пазуху. В исполнении Люсиль Болл это выглядело смешно, но нам было не до смеха.
Стало очевидно, что работа по переносу номеров должна быть не ручной, а максимально автоматизированной. И это нужно было сделать еще вчера.
Поскольку Лиза была знакома с процессом переноса номеров, лучше нее никто не знал, как его автоматизировать. Крис Коркоран был новым инженером в команде, но уже проявил способность находить сквозные решения проблем. Хотя он совсем недавно получил степень по информатике в Массачусетском университете, ему уже удалось пройти стажировку в NASA и поработать в Google. Ему дали прозвище Озон из-за инициалов CFC, совпадающих с химическим обозначением фреона – разрушителя озонового слоя Земли.
Я пригласил Озона и Лизу и освободил для них на две недели один из драгоценных конференц-залов в нашем офисе. Я обрисовал им проблему с процессом переноса телефонных номеров и предложил за две недели создать программу, необходимую для его автоматизации. Лиза знала, как осуществляется перенос, а Озон знал нашу программную базу вдоль и поперек. Лиза должна была рассказать Озону все, что знала, и предоставить ему свободу в поисках решения проблемы. А потом я ушел.
В первый момент они оторопели, но потом принялись за работу. Лиза продемонстрировала Озону несколько операций по переносу номеров, проработав все детали вместе с ним. Затем она передала ему клавиатуру и заставила выполнить с десяток таких операций – мы называем это «прогулка в обуви клиента». После того, как Озон прочувствовал проблему, она спросила его: «Ну вот, можно создать программу, которая будет делать это?»
Озон начал моделировать проблему, переспрашивая Лизу: «Это верно?» К концу первого дня у них была собрана основа модели данных. Имея ее, Озон уже мог создать форму, с помощью которой клиенты будут вводить информацию о переносе своих телефонных номеров. Как выяснилось, клиенты нередко предоставляли неверную информацию, которая требовала уточнений. Эта проблема легко решалась с помощью ПО. К концу второго дня у них была рабочая форма для сбора необходимой информации.
Затем Лиза заметила, что если бы оператор мог переносить номера на разных этапах взаимодействия с клиентами, то это значительно ускорило бы работу. Озон сказал, что в типичном процессе разработки ПО добавление такой функции могло занять несколько месяцев. Но в этом случае он смог построить рабочий вариант за час.
Конечно, было бы лучше, если бы мы с самого начала не заварили всю эту кашу. Но такова реальность в быстрорастущем стартапе. Внесу ясность: не в моих правилах запирать разработчика и менеджера по продукту в конференц-зале на две недели и просовывать им пресловутую пиццу под дверь. Это не лучшая управленческая практика. Но данный пример показывает, что могут сделать разработчики, когда они мотивированы. Я приношу свои извинения Лизе и Озону. Но я им очень благодарен.
Проект по созданию программы для переноса телефонных номеров – отличный образец совместного поиска не просто хорошего, а эффективного решения. Предоставить разработчику возможность глубоко понять потребности пользователя, а затем позволить ему удовлетворить их – вот что такое совместное решение проблемы. Лиза помогла Крису понять, зачем нужен код, который он пишет, и проникнуться эмпатией к клиентам, ну а после этого создание приложения стало тривиальным.
Эмпатия к пользователям – это более качественные и быстро создаваемые продукты
Истина заключается в том, что большинство программных средств довольно просты. Это то, что разработчики называют CRUD-приложениями – от слов Create, Read, Update, Delete (создание, чтение, обновление, удаление). Большинство приложений в интернете – это формы, которые позволяют пользователю вводить, изменять, выводить или удалять данные. Почти все сайты или мобильные приложения, которыми вы когда-либо пользовались, на 95 % состоят из CRUD-операций. Это вовсе не высшая математика.
Это означает, что время, требующееся для решения проблемы, и качество решения зависят от того, насколько разработчик понимает проблему, как в