Введение

В течение моей первой недели здесь, в 8th Light, я использовал огромное количество времени в пути в офис и обратно, чтобы погрузиться в некоторые из самых полезных аудиокниг, которые я когда-либо слушал. Это Экстремальная собственность: как морские котики США ведут и побеждают и Дихотомия лидерства Джоко Уиллинка и Лейфа Бабина, а также Стратегия и тактика лидерства Джоко Виллинка. Эти книги многому меня научили о преимуществах и основах лидерства, а также о том, как взять на себя ответственность и привести команду к успеху. Они охватывают многие темы, связанные с лидерством, включая важность брать на себя ответственность за все, что влияет на вашу команду, как сдерживать свое эго, а также четыре закона боя и их применение в гражданской жизни. Когда я слушал эти книги и прорабатывал материал, который я собрал для изучения своей Матрицы результатов обучения (инструмента, используемого для отслеживания и мониторинга прогресса учеников на 8-м свете), я заметил, как число об этих лидерских качествах и тактике следует применять в нашей отрасли, а также о том, как проявление инициативы и скромность делают нас лучше как разработчиков.

Проверьте свое эго

У каждого есть эго, и это не обязательно плохо. Ваше эго позволяет вам гордиться своими достижениями. Это часто заставляет вас работать усерднее, быстрее и качественнее. Это движущая сила, которая позволяет вам завершить свою миссию и добиться успеха. В то время как эго может быть мощным двигателем этих успехов, оно также может быть серьезной причиной конфликтов между людьми в команде. Существует осторожная дихотомия, которая должна быть сбалансирована между гордостью за то, что вы делаете и тем, как вы работаете, и смирением, отступлением на шаг и позволяя другим внести свой вклад в усилия команды. Например, авторы приводят несколько историй, в которых лидер настолько высокого мнения о себе, что считает себя всегда правым. Это постоянно приводит к катастрофе для команд, затронутых лидерами такого типа, как во время учений, через которые прошли взводы Джоко, так и для предприятий, для которых он консультирует по лидерству через свою компанию Echelon Front. Он также говорит о том, что, когда эти лидеры делают шаг назад и позволяют другим сделать шаг вперед, это движет команду вперед, что приводит к ее успеху.

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

  1. Разработчики могли взять на себя ответственность за свою работу, создавая комплексные наборы автоматических тестов для каждого написанного ими фрагмента кода и поддерживая эти тесты для обеспечения качества своего кода.
  2. Команда QA могла взять на себя ответственность за свою работу и выйти за рамки сценариев, мыслить нестандартно и тестировать как можно больше возможных входных данных от пользователя, которые они могли придумать.

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

Четыре закона боя

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

  1. Прикрыть и двигаться
  2. Простой
  3. Расставить приоритеты и выполнить
  4. Децентрализованное командование

Прикрыть и переместить

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

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

Простой

Боевое правило Simple простое. Концепция простоты — это то, чему учили многие лидеры во многих отраслях. Суть этого закона боя заключается в том, что приказы и задачи должны выполняться слаженно и эффективно, и они должны быть представлены просто. Это показано в книгах на примерах из опыта планирования боевых задач отряда морских котиков. Они говорят о многих миссиях, которые были спланированы с чрезвычайно сложными маневрами и тактиками, которые были связаны друг с другом. Миссии, которые планировались таким образом, в конечном итоге создавали хаос на поле боя и вызывали проблемы, которые никогда бы не материализовались, если бы планы оставались простыми и прямолинейными. Затем они переходят к разговору о компании, которая придумала слишком сложную программу поощрений, пытаясь повысить продуктивность своих сотрудников. Эта система включала в себя бонусы за произведенный продукт высокого качества, вычеты за продукт, который был испорчен, и постоянно меняющееся внимание к товарам, которые должны быть произведены, в зависимости от спроса на указанный товар на рынке. Это привело к разочарованию рабочих и снижению качества работы и производительности. Джоко и его команда из Echelon Front пришли и определили проблему с программой поощрений. Хотя техническому директору было трудно смириться с изменением своего шедевра системы, он был убежден упростить ее, что привело к повышению производительности всей организации и прибыли для компании.

Когда я глубже погрузился в материалы о лучших подходах к написанию программного обеспечения, я столкнулся с этой концепцией упрощения вещей несколькими способами. Один из способов, которым нам нужно сосредоточиться на простоте вещей, выделен в Принципе единой ответственности. Принцип единой ответственности гласит, что каждый модуль, класс или функция должны нести ответственность за одну часть функциональных возможностей, предоставляемых программным обеспечением, и эта ответственность должна быть полностью инкапсулирована классом, модулем или функцией. Если каждый аспект проекта поддерживает этот принцип единой ответственности, это способ сделать ваш код простым, легким для чтения и выполнения. Это также позволяет нам отделять наш код от других частей, что приводит к меньшему количеству ошибок и более легкому тестированию нашего продукта. Другой способ, которым мы используем эту концепцию, — это то, как мы пишем наши тесты. Это демонстрируется с помощью пирамиды тестирования, где мы максимально упрощаем основную часть наших тестов, модульных тестов. Это также продемонстрировано с помощью четырехэтапного теста, настройки, проверки, проверки, разборки (также известного как AAA — Arrange Act Assert). Соблюдение этого принципа простоты является ключом к нашей продуктивности как разработчиков, и строгое соблюдение этого принципа значительно облегчит нашу жизнь.

Расставить приоритеты и выполнить

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

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

Децентрализованное управление

Децентрализованное командование — это концепция распределения обязанностей внутри команды для более эффективного достижения цели. Это достигается в командах тюленей, явно использующих военную систему командной цепочки. Джоко и Лейф также приводят многочисленные примеры децентрализованного управления, когда они делегируют задачи разным членам команды, которые выполняют задачи, не нуждаясь в особом надзоре со стороны самих руководителей. Есть несколько ключевых компонентов, которые необходимы для работы децентрализованной команды. Самый большой компонент, который заставляет эту работу работать, — это доверие. Доверие — важнейшее качество, необходимое руководителю и его подчиненным для эффективного достижения поставленных целей. Руководитель должен быть в состоянии доверять подчиненным для эффективного выполнения работы, это означает, что руководитель должен позволять подчиненным работать независимо от него. Микроменеджмент – это, по сути, недоверие к подчиненным со стороны руководителя. Самая большая причина такого микроменеджмента обычно заключается в том, что лидер не может отбросить свое эго и позволить своей команде управлять своими частями текущей задачи. Это отсутствие доверия к подчиненным приводит к снижению морального духа подчиненных и создает огромное давление, которое часто приводит к снижению производительности и эффективности. Это также может подавить любой творческий потенциал, стремление членов команды проявлять инициативу, а также стремление к лидерству.

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

Заключение

Быть лидером — одно из самых сложных действий по балансированию, которое может предпринять каждый. Это требует от вас огромного смирения, которое каждый из нас изо всех сил старается поддерживать как люди. Эти принципы, изложенные Джоко и Лейфом, необходимы лидеру для достижения успеха в любой сфере жизни. Эти принципы проявляются в нашей отрасли по-разному, и чем больше лидеров мы сможем вырастить, чтобы следовать этим принципам, тем успешнее мы сможем быть и тем лучше мы сможем обслуживать наших клиентов и их клиентов.

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

Экстремальное владение: как морские котики лидируют и побеждают

Дихотомия лидерства

Стратегия и тактика лидерства: Полевое руководство