Как превратить свою организацию в место, где разработчики будут любить работать

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

Однако культура - вещь непростая. Ее нельзя измерить, и хотя она не может быть навязана сверху, здоровая культура требует правильной среды для роста и масштабирования. В этом первом разделе книги The Ultimate Guide to Building Technical Teams мы рассмотрим, что могут сделать организации, чтобы заложить фундамент командной культуры, ориентированной на разработчиков, частью которой они с удовольствием станут.


Что объединяет лучшие культуры разработчиков?

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


Они дают возможность разработчикам работать автономно вместе

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

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

Spotify: Организационная структура, рассчитанная на автономию

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

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

Применить на практике

  • Приоритет создания функциональной кодовой базы

  • Сократить технический долг

  • Нормализовать документирование и комментирование кода

  • Создать четкую передачу и хорошо документированные процессы

  • Уменьшение трения с предпочитаемым разработчиками стеком инструментов


Разнообразие и вовлеченность - это не просто метрики

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

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

Asana: Программные инициативы в области многообразия и инклюзивности, которые расширяются

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

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

Применить на практике

  • Создайте пространство для общения членов команды друг с другом

  • Нанимайте руководителей команд, которые поддерживают всех членов команды

  • Документируйте свои процессы и измеряйте их эффективность


Они поощряют карьерный рост и предоставляют "дорожную карту" для достижения успеха

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

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

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

  3. У каждого члена команды есть защитник. Их руководители выступают в защиту тех, кто, возможно, не имеет права голоса, и регулярно общаются с членами команды, чтобы убедиться, что они движутся вперед и вверх.

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

Patreon: Признание стремления к профессиональному росту

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

Применить на практике

  • Создавайте возможности для профессионального развития - работа с инструментами с открытым исходным кодом, тренинги по новым технологиям, финансирование непрерывного образования и т.д.

  • Поддержка регулярных мероприятий по обмену знаниями, таких как Lunch and Learns, парное кодирование, ведение технических блогов, документирование процессов и т.д.

  • Повышение прозрачности организационных схем и путей продвижения по службе для всех членов команды.

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


Они не оставляют ничего недописанного

Племенные знания могут быть очень полезны - до тех пор, пока вы являетесь полноправным членом племени. В быстрорастущих командах, особенно распределенных, те вещи, которые "просто знают" все, не всегда проникают в коллектив так тщательно, как это происходит в общем офисе. Даже если эти знания проникают в коллектив, они не всегда последовательно распространяются между должностями, уровнями и отделами.

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

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

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

GitLab: Повышение доступности и прозрачности информации

Всего за несколько лет компания GitLab создала чрезвычайно успешную платформу DevOps, и все это с помощью полностью удаленной, глобально распределенной команды. В основе их организационной деятельности лежит культура документирования. Единым источником истины для них является энциклопедический справочник, объем которого в полном виде составил бы более 8000 страниц.

Цель такого подхода проста: предоставить каждому члену команды всю информацию, необходимую для выполнения работы, независимо от того, в каком часовом поясе он находится. Подробнее о документации GitLab, ориентированной на справочники

Применить на практике

  • Объедините все ваши инструкции, часто задаваемые вопросы и руководства в одном месте

  • Убедитесь, что ваша платформа обмена сообщениями доступна для поиска

  • По умолчанию используйте общедоступные каналы для общения, а не прямые сообщения

  • Для повторяющихся процессов создавайте учебники или руководства по выполнению

  • Проводите ретроспективы как регулярную часть ваших процессов и рабочих процедур

  • Включайте формальное признание в ритм запусков, рабочих циклов и т.д.


Они используют передовые технологии с открытым исходным кодом

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

Как же понять, какие инструменты подходят вашей команде? Часть уравнения заключается в том, чтобы они сами рассказали вам об этом! По данным программы DevOps Research and Assessment (DORA) компании Google, DevOps-команды, которым предоставлено право самостоятельно выбирать инструменты, работают лучше, чем те, которые не имеют права голоса:

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

По результатам исследований, проведенных DORA, одним из наиболее распространенных показателей удовлетворенности работой является наличие у сотрудников необходимых для успешной работы инструментов.

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

Знаете ли вы?

Самым востребованным навыком для инженеров-программистов в 2021 году станет Redux.js, по которому инженеры получают почти в 3 раза больше запросов на собеседование, чем в среднем. Опыт работы с Google Cloud, AWS, React.js, Go и Scala также был очень востребован - все эти навыки получали как минимум в 2 раза больше запросов на собеседование.

Министерство обороны США: Содействие внедрению инструментов с открытым исходным кодом

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

Platform One, группа DevSecOps Enterprise Services Министерства обороны США, приняла новый подход к оптимизации процесса утверждения и закупки программных решений. Теперь команды Министерства обороны могут гораздо быстрее и с меньшими затратами создавать новые инструменты, что позволяет им использовать передовые облачные технологии и инструменты с открытым исходным кодом, которые ранее были им недоступны. В результате они сократили свои расходы на программное обеспечение на миллионы долларов и позволили своей команде работать в разы быстрее, чем раньше, благодаря революционному подходу к разработке программного обеспечения. Подробнее о цифровой трансформации Министерства обороны

Применить на практике

  • Поработайте с командой, чтобы понять, какие технологии им необходимы и нужны

  • Разработать четкие и быстрые инструкции и процессы закупок

  • Дайте возможность сотрудникам экспериментировать с инструментами с открытым исходным кодом и другими передовыми технологиями


Итог: Лучшие культуры разработчиков - это культуры инноваций

Не существует "правильного" способа создания лучшей культуры разработчиков, и невозможно полностью перестроить культуру за один день. Но даже небольшие изменения могут со временем привести к значительным изменениям. Бывший главный операционный директор StackOverflow Джефф Щепански (Jeff Szczepanski) поделился своими соображениями о найме лучших разработчиков:

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

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

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

  • Создавайте "безопасные" места для выдвижения новых, необычных или "странных" идей. Поощряйте такие проекты, как Open Source Fridays и хакатоны, которые дают разработчикам возможность творчески мыслить.

  • Приоритет баланса между работой и личной жизнью и предоставление возможностей для роста. Поддерживайте коллектив в рабочем состоянии, обновляйте его и думайте о будущем.

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

Комментарии (3)


  1. Stan_1
    17.11.2023 19:38
    +1

    Хм. А я не нашел в статье слова про выручку и счастье фаундеров. Или это не в кассу?


  1. iggr63
    17.11.2023 19:38

    Про Spotify и GitLab в описанном контексте слышал. Про других нет. Да и так что- то немного компаний высокой культуры на слуху.


  1. BA_Mentor
    17.11.2023 19:38
    +1

    Мне не хватило рассказа еще и о том как не просто предоставить открытость, инновации и автономность, но и внедрить в коллективе умение этим пользоваться. В реальности, не каждый к этому готов, ведь 1) автономность означает - отвечаешь за результат именно ты, а не руководитель, 2) открытость означает, что и разработчик открывает карты и тратит время на обмен знаниями, чтение документов и хождение по встречам 3) инновации означают готовность постоянного развития компетенций (здесь проще и понятнее, но все ли готовы?)...

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