Как продуктивно взаимодействовать с разработчиками

Мне кажется, сейчас «вечный» конфликт Производство vs Продажи («Вы не так продаете!» – «Нет, это вы не то производите!») повторяется в другой паре – Компании-заказчики vs Разработчики ПО. Уверена, вы тоже не раз слышали жалобы, что разработчики не могут быстро и качественно сделать то, что требуется, или что желания заказчика в конечном счете имеют мало общего с утверждённым в начале проекта ТЗ.

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

В качестве иллюстрации последнего принципа Лоусон приводит вот такой пример:

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

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

По сути, методология «Спросите своего разработчика» — это предоставление полномочий. Люди в любой сфере деятельности стремятся соответствовать ожиданиям в их отношении. Методология «Спросите своего разработчика» предполагает высокие ожидания в отношении разработчиков, причем это касается не объема написанного кода, а использования изобретательности и созидательной энергии для решения величайших проблем мира. Разработчики могут соответствовать подобным ожиданиям только в случае предоставления им полномочий и широких возможностей. Самое главное — делиться с ними проблемами, а не решениями.

Конечно, столы для настольного тенниса и трехколесные велосипеды — это неплохо, но я убежден,

что ключ к созданию инженерной культуры мирового уровня заключается в привлечении разработчиков к решению больших проблем и использовании их воображения в полном объеме. Несложно понять, так или не так обстоят дела в вашей компании. Когда вы встретите разработчика, спросите, чем он занимается и какую проблему клиента собирается решить.

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

Кроме задач, которые ставит заказчик, разработчики решают также собственные, внутренние задачи. Например, привожу отрывок о том, как огромной Amazon удается сохранять корпоративную культуру стартапа (а это важно, чтобы сохранять постоянную динамику развития компании).

В 1998 г. мой друг Дэйв Шаппелл (нет, не комик Дэйв Шаппелл!) стал примерно сотым сотрудником молодой компании Amazon. com. Он помог запустить Amazon Marketplace, Amazon Associates, Amazon Auctions и некоторые другие платформы. Именно он пригласил меня в AWS в 2004 г. К тому времени в компании работало уже примерно 5000 человек, а Дэйв покинул Amazon, чтобы основать стартап TeachStreet. Восемь лет спустя, в 2012 г., Amazon приобрела этот стартап, и Дэйв снова оказался в этой компании, где к тому времени работало более 75 000 человек.

Вскоре после его возвращения в Amazon в 2012 г. я позвонил ему с простым вопросом: «Чем, на твой взгляд, отличаются три компании — Amazon со 100, с 5000 и теперь с 75 000 сотрудников?» Он задумался на несколько мгновений, а затем сказал следующее: «Знаешь, это одна и та же компания. То же чувство срочности. Та же быстрая походка сотрудников. Тот же интеллект. Это потрясающе». В 1998 г. в офисе Amazon в Сиэтле был один этаж, полный сотрудников, полный суеты и энергетики, свойственной для стартапа. В 2012 г. картина осталась той же, только таких этажей, занятых стартапами Amazon, было почти тысяча по всему миру. Способность Amazon масштабировать свою культуру с таким размахом действительно поражает.

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

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

То же самое можно сказать и о небольших командах в крупной компании, и именно поэтому они имеют решающее значение. Структура Amazon, состоящая из команд численностью не более 10 человек, позволяет масштабировать компанию без потери чувства срочности, сфокусированности и качества талантов, характерных для стартапа. Помимо прочего, она не затрудняет сотрудничество, которое только усиливается с увеличением размера компании. Сложность координации деятельности компании по мере ее роста возрастает почти экспоненциально. Если вы сталкиваетесь с подобным в своей компании, знайте: в этом не ваша вина, это простая математика. Координация команды из 10 человек требует 45 связей между людьми, из 100 человек — почти 5000 связей, а из 1000 человек — почти 500 00. Amazon со штатом 75 000 человек в 2012 г. могло бы потребоваться 2,8 млрд связей, что сделало бы ее в 500 000 раз более сложной и запутанной по сравнению с компанией из 100 человек, которой она была вначале. Но этого не случилось. Это по-прежнему та же компания — современное чудо, построенное на основе небольших команд.

На рубеже тысячелетий Amazon была быстрорастущим стартапом, но ее обновление начало замедляться.

По словам тогдашнего директора по информационным технологиям (а ныне — члена правления компании Twilio) Рика Далзелла, кодовая база была невероятно запутанной, а в разработке продукта было несколько крупных направлений вроде обзора и поиска, обработки заказов и корзины покупок. Работа замедлялась, а с кодом становилось работать все сложнее, поскольку им занималось слишком много людей. Помимо проблем с кодом, наблюдался избыток тех, кто принимает решения, — и они вмешивались в работу каждого, поскольку все было тесно взаимосвязано. Как вы понимаете, это сильно напрягало инженеров и менеджеров по продукту, которые пытались реализовать свои идеи, но больше всего это обескураживало генерального директора Amazon Джеффа Безоса.

Почти каждый год Джефф брал неделю на то, чтобы оторваться от дел и спокойно поразмышлять о бизнесе. Эти ежегодные «мозговые штурмы» давали время переосмыслить существующие принципы и завершались обычно появлением ряда одностраничных документов с новыми идеями, которые представлялись команде руководителей. Рик рассказывает, как в 2001 г. Джефф отправился в свой ретрит, озабоченный проблемой замедления темпов обновления. Вернулся он с простой идеей: если создать небольшие команды, дать им свои задачи и сделать владельцами кода, то они снова смогут действовать подобно стартапам, как на заре существования Amazon, когда, по воспоминаниям Джеффа, всю команду можно было накормить двумя пиццами. Но для совместной работы требовалась масса API, обеспечивавших взаимодействие. Это позволило бы действовать независимо, а взаимоотношения команд регулировались бы технологией. Так одностраничный документ дал начало «командам на две пиццы». Рик вернулся к своим подчиненным и в течение недели превратил идею Джеффа в шестистраничный рабочий план, который Amazon быстро приняла.

Вот еще несколько разворотов из книги:

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