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

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

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

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

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

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

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

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

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

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

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

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

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

«Руководство компании требует от менеджеров достижения деловых или финансовых целей. Поэтому менеджеры придумывают идею продукта и устанавливают сроки, но они зависят от разработчиков, выполняющих задания. Технической команде тяжело, если кто-то просто приходит и говорит: “Сделай это быстро и к такому-то сроку”, а затем убегает».