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

которые не оказывается спроса. Разработка многих продуктов не идет дальше начального этапа.

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

Двери, а не стены

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

Если это сделать, происходит чудо. Для Bunq одна из форм открытых дверей – это участие разработчиков в форуме клиентов и выражение благодарности клиентам за вклад в создание ПО. Результатом является лояльность клиентов и быстрый рост компании, поскольку Bunq уводит клиентов у старых занудных банков. Разработчики этих банков, похоже, никогда не разговаривают с клиентами, а может, даже не понимают, как клиенты пользуются их программами.

Вы могли заметить, что я осторожничаю со словом «стратегия», поскольку его можно ошибочно принять за директиву руководства, т. е. за прямую противоположность выслушиванию клиентов. В Twilio я часто говорю: «Наша стратегия проста: создавайте то, что хотят наши клиенты и за что они платят». Конечно, у нас есть долгосрочные бизнес-планы, но я не хочу, чтобы команды смешивали их с целями нашей компании по обслуживанию клиентов. Единственный путь реализации наших корпоративных планов – обслуживание клиентов. Мой любимый способ понять, влезают ли команды в ботинки клиентов, – это обход разработчиков и выяснение, над какой проблемой клиентов они работают. Если они рассказывают мне о какой-то функции, то я спрашиваю, какую проблему клиента она решает. Если они не могут ответить на этот вопрос, то это говорит об отсутствии у команды достаточной связи с клиентами. Вы тоже можете поступать так – это несложно. Вот еще о чем нужно напоминать разработчикам: во время анализа продукта разговор следует начинать с проблемы клиента. Не переходите сразу к обсуждению стратегии или функций, начинайте с того, почему клиенту это интересно. Спросите руководителей о том, какие клиенты сообщили нам о проблеме и как они убедились в том, что решение этой проблемы нужно широкому рынку. Ответ не так важен, как сам процесс. Есть ли у команды эффективные механизмы, чтобы реально понимать клиентов? Эти вопросы позволят вам понять, как мыслят ваши команды. Уверен, стоит им только узнать об этих вопросах, и они сразу начнут примерять на себя ботинки клиентов.

Глава 10

Развеиваем мифы о методологии аджайл

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

МАНИФЕСТ АДЖАЙЛ, 2001 Г.

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

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

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

Почему именно аджайл?

В 1980-х и 1990-х гг. результаты разработки программных продуктов были нередко провальными. Даже крупные софтверные компании не справлялись со стремительно растущей сложностью проектов, меняющимися требованиями и большими затратами времени. Эти проблемы преследовали все организации – большие и малые, от стартапов до крупных компаний. Например, опытный программист и предприниматель Митч Капор, создавший в 1980-х гг. программы Lotus 1–2–3 и Lotus Notes, в 2002 г. профинансировал амбициозный проект по созданию системы для совместной работы под названием Project Chandler. Шесть лет спустя после неудачи с поставкой продукта, который лишь отдаленно соответствовал первоначальным целям, проект был закрыт. Даже выдающаяся софтверная компания той эпохи Microsoft с трудом справлялась с гигантскими проектами подобного рода. В 2001 г. Microsoft начала работу над самым амбициозным обновлением своей операционной системы Windows, инициировав проект под кодовым названием Longhorn. На создание этой системы ушло пять лет, на полпути была произведена ее серьезная переоценка, и она появилась в 2006 г. под названием Windows Vista. К моменту ее выхода на рынок разработчики отказались от многих функций и не смогли реализовать те инновации, которые Билл Гейтс и Стив Балмер задумали полдесятилетия назад. Как ни странно, но такие примеры были не исключением, а нормой.