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

Джо пришел на нашу ежегодную конференцию клиентов в 2012 г., тогда называвшуюся TwilioCON, с целью выяснить, что Twilio вообще делает и как он нас уничтожит. Там он познакомился с сотнями других наших пользователей и получил представление о том, сколько компаний используют Twilio для создания инноваций в сфере обслуживания клиентов. Здравый смысл у Джо возобладал, и на обратном пути он написал меморандум, в резюме которого говорилось: «Мы не отказываемся от Twilio, мы перемещаем всю свою деятельность в облачные сервисы Twilio». И в последние годы RealPage поступает именно так.

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

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

Часть II Как понять и мотивировать своих разработчиков

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

Глава 3 Привет! Я – Джефф, и я – разработчик

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

Я вырос в пригороде Детройта, в городке под названием Уэст-Блумфилд. Моя мать была преподавателем математики, а отец – рентгенологом. В начале 1980-х гг. рентгенология была полностью аналоговой. Больница получала от компании Kodak коробки, где было порядка десятка листов пленки, разделенных прокладками из белой плотной бумаги. В больнице бумагу просто выбрасывали – имейте в виду, это было до того, как переработка отходов набрала силу, – и мой отец приносил ее домой и складывал в аккуратную стопку у себя в комнате.

По выходным, когда нам было скучно и хотелось посмотреть телевизор, отец говорил: «Давай сделаем проект!» Мы вытаскивали коробку, полную листов разного размера, и он продолжал: «Что бы ты хотел сделать?» Я говорил что-нибудь вроде: «Давай сделаем робота», или «Давай сделаем видеомагнитофон»», или «Давай сделаем рентгеновский аппарат» – и мы принимались за работу. Например, мы складывали из бумаги коробку размером примерно с видеомагнитофон, а потом я рисовал фломастером кнопки «Воспроизведение», «Пауза», «>>», «<<» и т. п. Я рисовал порт для загрузки кассеты Betamax – да, у нас дома был видеомагнитофон формата Betamax! И всегда, когда мы заканчивали процесс создания, я задавал вопрос, которого боялся мой отец: «Папа, как мы можем сделать так, чтобы это действительно работало?» Если бы отец обладал способностями папы Карло, создавшего Буратино, то он бы, наверное, смог оживить видеомагнитофон, робота… да что угодно, созданное в этот день. Но, увы, оживить наши «проекты» он не мог, и это расстраивало нас обоих.