Чему инженеры-программисты могут научиться у подводных лодок

Как применить принципы лидерства Дэвида Марке на подводной лодке для разработки программного обеспечения

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

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

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

Как мы можем полностью использовать интеллектуальные возможности каждого в организации, а не только нескольких экспертов?

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

Дэвид Марке сделал именно это, когда стал командиром плохо работающей подводной лодки и превратил ее в одну из самых эффективных подводных лодок военно-морского флота.

Так почему это важно для разработки программного обеспечения? Рынок инженеров-программистов очень конкурентный. Один из самых безопасных способов сохранить таланты - это возложить на них ответственность и вовлечь их. Использование творческих способностей каждого также приведет к более быстрым и инновационным решениям, которые могут быть разницей между успехом и неудачей в программном стартапе. Наконец, инженеры-программисты дороги, так что вам лучше использовать их по максимуму!

Итак, как можно реализовать модель лидер-лидер? Я резюмировал некоторые ключевые методы и идеи, которые заставили его работать и нашли отклик у меня. Это отнюдь не полная картина, и если эти моменты вызвали у вас интерес, пожалуйста, прочтите книгу.

Общие цели и руководящие принципы

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

Вы должны быть уверены, что любое решение будет принято с намерением достичь вашей общей цели.

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

Живите по принципам

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

В зависимости от вашей цели и принципов их можно реализовать по-разному. На них следует ссылаться при принятии важных решений, таких как прием на работу или анализ эффективности. У Amazon, например, есть общедоступный список их ценностей, и в рамках своих интервью они просят привести примеры того, как вы воплощаете разные ценности.

Жизненные ценности и принципы могут начаться с маленьких жестов. Например, на подводной лодке Марке они начинали кричать всякий раз, когда проходили мимо затонувшей подводной лодки, чтобы напомнить всем на борту об истории и миссии подводных сил. В одной из моих предыдущих компаний все вместе брали часовой перерыв на обед. Этого времени было достаточно, чтобы сблизиться с товарищами по команде и пообщаться с людьми из других команд, и это послужило примером того, что к общению и благополучию относятся серьезно. Эти жесты и ритуалы не кажутся особенными, но они помогают сохранять ценности свежими и живыми.

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

Укажите, что, а не как

Цели и принципы должны определять и направлять вас в отношении того, что необходимо сделать, но сам человек должен сам решать, как это сделать.

На подводной лодке это привело к некоторым неожиданным и новым идеям. В одном случае утечка нефти вынудила бы подводную лодку вернуться на базу для пополнения запасов. Но поскольку офицер заметил корабль снабжения ВМФ в нужное время, они смогли пополнить запасы в море без особой предварительной связи с базой. Для военно-морского флота в то время это был творческий и необычный подход, который позволил избежать огромного объезда.

Похожая идея есть в программной инженерии. Во время планирования вы делите работу на тикеты. Хорошие билеты содержат критерии приемки или «определение выполненного», в которых указывается, что означает выполнение этой задачи, но не то, как это должно быть выполнено. Звучит знакомо, не правда ли?

Отсутствие ограничений определенной реализацией может иметь огромное значение в разработке программного обеспечения. Однажды у меня была задача, в которой исходным решением был бы скрипт Python среднего размера. Следуя хорошей практике, этого кода было бы достаточно для написания тестов. Некоторые быстрые эксперименты и нестандартное мышление превратили его в двухстрочный сценарий bash - настолько простой, что он не требует тестирования и намного проще для понимания!

Подход без участия пользователя

Когда Дэвид Марке стартовал на своей подводной лодке, он особо подчеркивал необходимость не отдавать прямых приказов или команд. Вместо этого он спросил всех, что они собираются делать. Это может быть небольшое изменение, но оно имеет серьезные последствия.

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

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

Для Марке это было также труднее всего следовать, и он описывает несколько сценариев, в которых он боролся и возвращался к старым привычкам отдавать приказы. Часто кажется, что это легко сделать, потому что вы уже видите решение в своей голове. Но к настоящему времени вы должны увидеть преимущества вовлечения вашей команды в процесс решения проблем, даже если вы уже решили проблему. Они научатся действовать независимо и могут даже придумать новый подход.

Каждый имеет квалификацию (для выполнения своей работы)

Чтобы доверять кому-то важные решения, вам нужно знать, что у них есть знания, чтобы все обдумать и довести до конца. Здесь я должен полностью полагаться на книгу Марке, но кажется, что во флоте есть большое количество экзаменов и квалификаций. Они позволяют легко увидеть то, что кто-то знает или, по крайней мере, должен знать.

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

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

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

Работайте над тем, чтобы все вокруг могли выполнять свою работу, и вы повысите квалификацию своей команды.

Святой Грааль - это командная культура, в которой ценится не только обучение, но и обмен знаниями и преподавание. Крайний момент - это установка на замену себя. Постарайтесь сделать так, чтобы все вокруг вас могли выполнять свою работу, и вы повысите квалификацию своей команды. Вы почувствуете уверенность, что делегируете больше обязанностей, и у вас будет больше времени для собственного совершенствования.

Последние мысли

Когда я прочитал «Поверните корабль!», Эти пять концепций выделялись для меня: наличие общих принципов, воплощение их в жизнь, определение того, как, а не что, подход невмешательства и обеспечение достаточной квалификации. Конечно, в этой истории есть гораздо больше, и когда вы ее прочтете, вам могут понравиться другие идеи.

Оглядываясь назад, я работал в командах, где многие из них были предоставлены или предоставлены. Я обнаружил, что их эффекты накапливаются и приводят к доверию, более эффективной работе и меньшему стрессу. Я также обнаружил обратное: отсутствие большинства из них подрывает доверие, даже когда все начинают с самыми лучшими намерениями. Я уверен, что вы легко найдете примеры, когда эти критерии были соблюдены или отсутствовали, и как они повлияли на вашу работу.

Ресурсы