Джефф Лоусон — серийный предприниматель, программист, основатель и генеральный директор IT-компании Twilio. На примере своего опыта он рассказывает об управлении бизнес-процессами и командами разработчиков.
Название с призывом «Спроси разработчика» неслучайное. Это не просто часть заголовка, а почти дословный текст с билборда в Сан-Франциско. Когда пришло время выбрать рекламный слоган, Джефф Лоусон предложил такой вариант в шутку. Дело в том, что Twilio делает свою работу «за кадром», и часто пользователи могут даже не знать, что соприкасаются с её услугами. «Наш сервис встроен в тысячи приложений и сайтов. Когда вы пишете водителю Uber из соответствующего приложения — это сервис Twilio. Когда Netflix отправляет вам текстовое сообщение с шестизначным паролем для входа в систему — это опять мы. Когда вы заказываете ужин в DoorDash, уведомление о том, что заказ прибыл, отправляется через Twilio. Понимаете, о чем идет речь? Вы, скорее всего, используете Twilio каждый день, но даже не подозреваете об этом», — пишет об этом Джефф Лоусон. Так слоган стал названием книги и даже образом мышления, которым руководствуется автор в бизнес-вопросах.
Книга адресована предпринимателям, чей бизнес стоит на пороге цифровой трансформации или ещё почему-то нет, и содержит советы о том, как коммуницировать с разработчиками и приводить команды к высоким результатам в работе. Почитать интересно и вне контекста IT, потому что многие рекомендации из этой книги универсальны и пригодятся руководителям и из других отраслей. Джефф Лоусон рассказывает, как бизнесменам лучше понимать технарей и сотрудничать с ними для достижения общих целей.
В книге три части. Сперва автор объясняет, почему разработчики важны сейчас как никогда. Далее, во второй части, Джефф пишет о найме сотрудников и их мотивации. В завершении он рассказывает об открытой обучающей среде и том, как сделать своих разрабов успешными. И хотя в сети встречается критика о том, что советы из книги не коннектятся с реальностью, всё сказанное автором на страницах звучит аргументировано. Поделимся по пунктам полезными мыслями.
- Пролог к инновации — эксперимент. Джефф Лоусон предлагает проводить больше дешевых экспериментов, чтобы быстрее находить эффективные рабочие инструменты.
- Код — это творчество. Разработчикам важно обладать не просто свободой самостоятельно выбирать рабочее время или одежду, но и творить.
- Атрибуты корпоративной культуры вроде настольного тенниса или бесплатной еды — это отнюдь не главное. Не получится создать компанию как в Кремниевой долине, просто повторяя плюшки техногигантов. Что нужно для успеха, смотрите в пункте выше.
- Делитесь с разработчиками проблемами. Предоставление сотрудникам полномочий их решать, питает изобретательность.
- Относитесь к найму сотрудников осознанно. «Первые нанятые вами сотрудники особенно важны. Привлечение в компанию правильного лидера с самого начала может быть ключом к успеху», — отмечает Джефф Лоусон.
- Устанавливайте справедливый размер оплаты труда. Когда разработчики достигают этого «справедливого» порога, то могут сосредоточиться на мастерстве и целях. Такая мотивация выгодна всем сторонам.
- Создавайте в компании открытую обучающую среду. Если в процессах есть место гибкости, а в коллективе адекватно относятся к новым вызовам и вопросам, ответов на которые ещё нет, то сотрудники будут заинтересованы в поиске истины. А ещё такой подход поможет подготовить следующую смену руководителей.
- Уделяйте время обучению на реальных задачах. Прохождение курсов и повышение квалификации не дает столько опыта, сколько работа на проектах, в которых можно учиться на ошибках. Кстати, в самой компании Twilio вместе с таким подходом существует и их собственный инкубатор талантов.
- Умейте поставить себя на место клиента. При создании ПО слышать запросы пользователей и отвечать на них архиважно. Можно заложить в основу своей философии два неразрывно связанных понятия, хотя и одно из них больше относится к общепиту. «Обслуживание — это техническая поставка продукта. Гостеприимство — это впечатление, которое поставка продукта оставляет у получателя. Обслуживание — это монолог: мы сами решаем, как мы хотим действовать, и устанавливаем собственные стандарты. Гостеприимство — это диалог. Чтобы быть на стороне гостя, нужно выслушать его предельно внимательно и дать вдумчивый, любезный и уместный ответ. Чтобы подняться на вершину бизнеса, требуется и отличное обслуживание, и отличное гостеприимство», — приводит автор в пример слова ресторатора Дэнни Мейера.
- Давайте разработчикам доступ к обратной связи с клиентами. Не нужно пытаться ограничиться техзаданием. Клиенты бывают красноречивы и могут описать проблему в деталях, и сотрудникам под силу их понять.
- Создавайте двери вместо стен. Процитируем Джеффа Лоусона: «Вы могли заметить, что я осторожничаю со словом «стратегия», поскольку его можно ошибочно принять за директиву руководства, т.е. за прямую противоположность выслушиванию клиентов. В Twilio я часто говорю: “Наша стратегия проста: создавайте то, что хотят наши клиенты и за что они платят”. Конечно, у нас есть долгосрочные бизнес-планы, но я не хочу, чтобы команды смешивали их с целями нашей компании по обслуживанию клиентов». Такая вот аллегория про пути вместо препятствий.
- Эджайл — это не панацея. Мы уже готовили материал на Хабре о книге Роберта Мартина «Чистый Agile», в которой собрана база из первоистоков системы. У Джеффа Лоусона свое видение на методологию аджайл. Тем, кто скептически к ней относится, будет терапевтично ознакомиться с мнением автора. Тем более, что тот приводит показательные примеры из своего опыта: «В Twilio мы не придерживаемся строго какой-либо определенной формы аджайл и позволяем командам выбирать свой стиль работы — какие-то из них принимают более формальные элементы аджайл, другие — менее формальные. Но мы строго реализуем ряд ключевых идей. Самое строгое правило состоит в том, что небольшие автономные команды — основа прогресса. Мы ограничиваем размер команд 10 сотрудниками. Вместо системы планирования, навязывающей им работу, мы просим их намечать собственные ежеквартальные цели на основе пожеланий клиентов. Когда представления команд о том, что необходимо, отличаются от наиболее важных целей руководства, оно не спускает указания сверху, а начинает дискуссию для разрешения конфликта. Это некоторые из обязательных элементов для всех наших команд разработчиков, число которых приближается к 150».
Чтение небольшое, но содержательное. Смело забирайте рекомендацию себе на ближайшие выходные. Читайте от корки до корки — автор делится вдохновляющей историей даже в эпилоге.