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