Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон
Шрифт:
Интервал:
Закладка:
Руководители должны обращаться к своим разработчикам и техническим специалистам за помощью в принятии таких решений. Это уже происходит естественным образом. Разработчики создают ПО на основе платформ AWS и Twilio и оплачивают их использование своими кредитными картами. Вместо того чтобы ругать разработчиков, лидеры компаний должны воспринимать эту естественную тягу к созиданию как сигнал и следовать за ними.
Мне вспоминается история Джо Маккоркла, вице-президента по телекоммуникациям в RealPage, крупной публичной софтверной компании, обслуживающей индустрию аренды многоквартирных домов. Она предлагает десятки SaaS-продуктов для компаний, которые владеют и управляют недвижимостью, такой как многоквартирные дома. А еще эта компания очень активна в сфере поглощений. В последнее десятилетие число ее поглощений исчисляется десятками. В 2012 г., после того как она приобрела несколько стартапов, которые были клиентами Twilio, их счета начали приходить к Джо на одобрение, поскольку он отвечал за расходы на связь. Сначала он не обращал на них внимания, но затем операционный директор попросил Джо «выяснить, что это за штука Twilio и можно ли избавиться от нее», например заменив Twilio услугами, которые они уже покупали у оператора связи или телекоммуникационной компании.
Джо пришел на нашу ежегодную конференцию клиентов в 2012 г., тогда называвшуюся TwilioCON, с целью выяснить, что Twilio вообще делает и как он нас уничтожит. Там он познакомился с сотнями других наших пользователей и получил представление о том, сколько компаний используют Twilio для создания инноваций в сфере обслуживания клиентов. Здравый смысл у Джо возобладал, и на обратном пути он написал меморандум, в резюме которого говорилось: «Мы не отказываемся от Twilio, мы перемещаем всю свою деятельность в облачные сервисы Twilio». И в последние годы RealPage поступает именно так.
Это отличный пример того, как Джо последовал за своими разработчиками, которые были в курсе новейших тенденций в своей сфере. Когда вы создаете свою команду разработчиков, фундаментальная задача ее членов состоит в определении правильных областей создания ПО. Принятие решений о том, какие области являются ключевыми компетенциями компании, – вопрос, часто обсуждаемый руководителями компаний, – теперь спустилось на уровень микросервисов. Я не жду, что большинство руководителей компаний приобретут опыт или желание инспектировать работу на этом уровне, но они должны понимать, что их технические команды принимают такие решения довольно часто. Руководители должны быть в курсе доступных услуг и настоятельно поощрять команды к использованию «строительных блоков», ускоряющих создание ценности для клиентов. Также необходимо постоянно спрашивать технические команды о том, на какие области следует переключить их таланты. Это не разовое решение в духе «создать или купить». Ответ при использовании микросервисов будет со временем меняться. И к этому вопросу стоит возвращаться регулярно.
Разработчики обычно первыми узнают о новом и интересном в цифровой цепочке поставок. Вы можете поинтересоваться у них, насколько легко им принимать современные API, или подумать, какие ограничения компания накладывает на их принятие. Как вообще сбалансировать потребность в безопасности с желанием позволить разработчикам использовать самые современные сервисы? Спросите свою команду, не покупают ли они тайно эти услуги цифровой цепочки поставок. Если да, то не наказывайте их. Поймите, почему так происходит, и выясните, как формализовать возможности разработчиков совершать такие покупки. Спросите своих разработчиков, как они определяют, что можно купить, а что действительно позволяет дифференцировать вашу компанию.
Часть II
Как понять и мотивировать своих разработчиков
Итак, вы прочитали первые две главы о том, как создавать ПО для компании, чтобы выжить и процветать в цифровую эпоху. Но на самом деле важно не это, и, думаю, вы совсем не из-за этого взяли в руки мою книгу. Самое важное в том, как все это организовать. Процесс начинается с понимания того, что побуждает разработчиков отдавать все свои силы делу и какие действия лидера мотивируют или демотивируют их. Часть II этой книги – о том, как думают разработчики, в том числе и я.
Глава 3
Привет! Я – Джефф, и я – разработчик
Каждые две недели мы собираем группу новых сотрудников Twilio. Я провожу с ними получасовое рабочее собрание – и начинаю его так: «Привет! Я – Джефф, и я – разработчик программного обеспечения». Все они знают меня как генерального директора и основателя компании, но я по-прежнему считаю себя разработчиком. В очень многих компаниях цифровой эры существует разрыв между руководителями и разработчиками, фактически осуществляющими цифровую трансформацию. Я надеюсь, что эта книга поможет устранить его, позволив разработчикам, менеджерам и руководителям говорить на одном языке. Как генеральный директор публичной компании и разработчик я смотрю на вещи иначе, чем большинство руководителей, как, впрочем, и большинство разработчиков. Я вижу проблемы и успехи сотрудничества между менеджерами и разработчиками с двух сторон. Чтобы понять идею «Спросите разработчика», полезно познакомиться с моей карьерной эволюцией. Хотя сегодня я генеральный директор, я начал свою трудовую жизнь как программист-самоучка и создатель ПО. Я хочу выделить поворотные моменты моей жизни, которые привели к методологии «Спросите разработчика».
Я вырос в пригороде Детройта, в городке под названием Уэст-Блумфилд. Моя мать была преподавателем математики, а отец – рентгенологом. В начале 1980-х гг. рентгенология была полностью аналоговой. Больница получала от компании Kodak коробки, где было порядка десятка листов пленки, разделенных прокладками из белой плотной бумаги. В больнице бумагу просто выбрасывали – имейте в виду, это было
