Тест на культуру разработчиков Pragmatic Engineer

Я обсуждал с десятками разработчиков программного обеспечения, что им нравится и не нравится на рабочем месте - в команде и в компании - с профессиональной точки зрения. Я вижу интересную тенденцию в среде, которая делает людей счастливыми и процветающими - и заставляет их оставаться дольше - по сравнению с той средой, где люди чувствуют себя несчастными. Около 4-5 лет я уделяю особое внимание людям, работающим в одной компании, которые не заинтересованы в изучении других вариантов. Что заставляет их остаться? А людей, отчаянно желающих двигаться - что их отталкивает?

Удивительно, что на сегодня не так уж много сделано для количественной оценки этих наблюдений (по состоянию на 2020 год). У нас есть тест Джоэла, который все еще прилагается к списку вакансий на Stack Overflow. Большинство в объявлениях о вакансиях утверждают, что у них 11 или 12 из возможных 12. Но тест Джоэла, написанный в 2000 году, кажется слишком устаревшим и не рассматривает аспекты, важные для продуктивных разработчиков в 2020-х годах: автономия, обзоры кода или непрерывный профессиональный рост. Поэтому я сделал шаг назад и переосмыслил, каким будет Джоэл-тест в 2020-х годах.

Итак, я предлагаю вам тест на культуру разработчиков: 3 области с 5 вопросами для здоровой организации (где разработчики преуспевают). По моему опыту, любая техническая компания, которую вы бы назвали достойной, должна иметь 3 основных балла и покрывать как минимум 4 из 5 баллов в каждой области.

Основы

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

1. Психологическая безопасность и безупречная культура. Чувствуют ли люди себя в безопасности и высказывают ли свое мнение, даже если они могут не соглашаться с другими? Является ли внимание и воздействие на микроагрессии и бессознательные предубеждения частью культуры? Когда что-то идет не так, вы запускаете безупречный процесс, сосредотачиваясь на системной первопричине того, кто это вызвал? Это может происходить из-за перебоев, технических проблем или неудачных решений.
2. Справедливая компенсация. Ваша компания платит справедливую заработную плату, которая более или менее соответствует уровню местного рынка?
3. Гибкость в рабочем времи. Могут ли инженеры работать гибко, как для своей команды, так и для себя? Это может быть разумным руководством WFH, поскольку оно должно быть гибким в отношении краткосрочных изменений в расписании и личных обстоятельств, концентрируясь на работе, выполняемой в течение времени, когда люди начинают и заканчивают рабочий день.

Я не буду тратить слишком много времени на первые два пункта. Что касается последнего, (гибкости здравого смысла), некоторые могут удивиться, почему я добавляю его сюда. Дело в том, что гибкая организация работы для разработчиков программного обеспечения - повсеместна. Происходит взрыв удаленных ролей, WFH является мейнстримом, так как Коронавирус и любая компания, которая держится за 9-5 или что-то подобное, окажется в меньшинстве. И люди в этих местах будут (и должны) спрашивать, почему они не изменятся где-нибудь еще, где присутствует такая гибкость.

Ясность, автономия и сотрудничество

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

• Понимание "почему". Есть ли у вас процесс, чтобы поделиться с инженерами деловыми причинами для работы? Это могут быть такие вещи, как дорожные карты, OKR, цели компании и организации и другие.
• Бэклог/"дорожная карта" и инженеры, вносящие свой вклад в этот процесс. Есть ли у команд четкий бэклог/дорожная карта, позволяющая легко ответить на вопрос "над чем мы будем работать дальше и почему?". Соответствует ли нисходящее планирование планированию "снизу вверх"? Могут ли инженеры вносить предложения, которые в конечном итоге попадают в "дорожную карту" команды - либо в качестве поддержки "зачем", либо как часть бюджета инженерных работ? Приоритизируются ли таким образом разумные предложения по погашению технологического долга?
• Прямая коммуникация при решении проблем. Поощряется ли решение проблем напрямую, обращаясь к разработчикам в других командах? Отсутствие необходимости проходить через своего менеджера, который разговаривает с другим менеджером, который разговаривает с менеджером команды, который разговаривает с...
• Межфункциональное сотрудничество. Работают ли разработчики напрямую с пользователями, дизайнерами, менеджерами по продукту, специалистами по обработке данных и другими заинтересованными лицами, не полагаясь на прокси-сервер (например, на своего менеджера)?
• Приветствие проявляющих инициативу. Считается ли ненужным отвлечением внимания, когда люди проявляют инициативу, возможно ли их отметить или вознаградить?

Устойчивая инженерная культура

Сделайте все правильно, и разработчики не перегорят и не будут разочарованы.

1. Различие между функционально законченными и готовыми к производству. Различаете ли Вы прототип/MVP/функционально законченный этап и состояние готовности к производству кода? Есть ли у Вас контрольный список того, что означает дополнительная планка качества для того, чтобы что-то было готово к производству?
2. Проверка и тестирование кода. Являются ли обзоры кода и автоматизированное тестирование (единица измерения, интеграция и т.д.) частью ежедневного процесса разработки, так как их отсутствие является редким исключением, для очень понятных случаев?
3. CI и CD или разработчики, внедряющие их в производство. Есть ли у вас настройка процесса CI, который запускается перед фиксацией кода? После фиксации кода, есть ли у вас процесс CD, чтобы продвинуть его прямо в производство - и если нет, то могут ли разработчики продвинуть код, которым они владеют, в это окружение?
4. Здоровый вызов. Для команд, где разработчики находятся на вызове, измеряете ли вы состояние здоровья oncall и его влияние на разработчиков? Имеет ли исправление нездоровой oncall приоритет над любой работой над продуктом?
5. Внутренний открытый исходный код. Соблюдаете ли вы внутреннюю модель с открытым исходным кодом, в которой любой разработчик может читать и вносить свой вклад в любую другую кодовую базу - с соответствующим правом собственности на код?

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

Карьерный прогресс

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

1. Технические менеджеры, которые строят доверие. Являются ли большинство технических менеджеров техническими, то есть имеют опыт создания программного обеспечения в какой-то момент своей карьеры? Делают ли менеджеры регулярные действия 1: 1 таким образом, чтобы укрепить доверие (например, слушать, давать обратную связь, обсуждать карьерные цели)?
2. Карьерная лестница. У вас есть карьерная лестница с уровнями и ожиданиями на каждом из определенных уровней, а также четкий процесс продвижения на следующий уровень?
3. Параллельные пути IC & менеджера. Есть ли у вас параллельные карьеры IC и менеджеров, которые проходят на несколько уровней выше роли менеджера по проектированию начального уровня?
4. Культура обратной связи. Есть ли у вас по крайней мере два из следующих трех: 360 обзоров эффективности (где директивы также дают обратную связь менеджерам), культура коллег, дающих отзывы друг другу, и регулярные отзывы, собираемые, передаваемые и действующие компанией через всю компанию или общегосударственные опросы.
5. Инвестирование в профессиональный рост. У вас есть по крайней мере два из следующих трех: активная программа наставничества с разработчиками, также наставляющими других разработчиков, стипендии для профессионального развития для книг / тренингов, регулярные технические беседы, где люди в компании учатся друг у друга - или от внешних экспертов.

Менеджеры - это те, с кем я много общался. Хоть я и понимаю, как нетехнические менеджеры могут быть чуткими и замечательными: им будет не хватать как способности бросать вызов команде, так и возможности защитить ее от необоснованных запросов. Им будет не хватать способности эффективно пропагандировать устойчивую инженерию - как для защиты команды от необоснованных запросов, так и для внедрения практики для хорошего здоровья команды. Без практического опыта объяснения того, почему определенные практики важны, очень трудно отстаивать и то, и другое. Им также будет трудно наставлять людей в своей команде в области программной инженерии, что особенно важно для людей на ранних этапах их карьеры.

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

Как все это выглядит?

Вы можете спросить: Гергели, это хороший список, но насколько на практике применимо все вышеперечисленное? Это вполне возможно, исходя из моего профессионального опыта и моих бесед с парой дюжин разработчиков программного обеспечения в разных регионах и отраслях. Все это также отражает работу самых инновационных и быстро развивающихся технологических компаний, от Microsoft, Google, Facebook и Uber, вплоть до небольших, но успешных стартапов, таких как Monzo, N26 и мн.др.

Хотя я написал это независимо от других источников, Tech-First Culture Test также, похоже, повторяет некоторые выводы книги «Ускорение: наука построения и масштабирования высокопроизводительных технологических организаций» . Мысли об индивидуальной и командной автономии, устойчивом проектировании - это то, о чем идет речь в книге.

Узнайте, как Flo Sports оценивается в тесте на культуру разработчиков Pragmatic Engineer. Как ваша текущая организация оценивает тест на культуру разработчика?