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

Ссылка на оригинал - https://blog.pragmaticengineer.com/the-developer-culture-test/, автор публикации - Gergely Orosz

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

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

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

Прагматичный инженер
Тест разработчика культуры
Основы: безопасность, справедливая компенсация и гибкость здравого смысла.
Ясность, автономия и сотрудничество
  1. Понимание "почему"
  2. Отставание / дорожная карта и инженеры, способствующие этому
  3. Прямое общение в решении проблем
  4. Межфункциональное сотрудничество
  5. Принятие инициатив
Устойчивая инженерная культура
  1. Функционально завершено! = Готово к производству
  2. Проверка кода и тестирование
  3. CI и CD или разработчики, внедряющие в производство
  4. Здоровый звонок
  5. Внутренний открытый исходный код
Карьерный прогресс
  1. Технические менеджеры, строящие доверие
  2. Карьерная лестница
  3. Параллельные треки IC и менеджера
  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. Как ваша текущая организация оценивает тест на культуру разработчика?

Добавить комментарий

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Не нашли ответ на свой вопрос? Возможно, вы найдете решение проблемы на нашем канале в Youtube! Здесь мы собрали небольшие, но эффективные инструкции. Смотрите и подписывайтесь на наш youtube-канал!

Смотреть на Youtube

Руководства и обзоры

1 Что нужно восстановить?

Видео

MP4, AVI и HD видео хранятся на телефоне и / или по ошибке удаляются вместе с фотографиями и другими медиафайлами.

Контакты

Номера телефонов друзей и знакомых из приложения «Контакты Android», журналы вызовов; Восстановление SIM-карты.

Фото

Удалены файлы JPG / PNG из Галереи Android; фото, загруженные на мобильный, файлы повреждены после восстановления.

Смс и сообщения

Чаты WhatsApp и Facebook, текстовые сообщения в соцсетях, информация на сим-карте

2 Где пропали файлы?

На sd-карте

Фотографии и документы хранятся на SD-картах. Часто на них случайно удаляются файлы

На телефоне

Программы для восстановления не распознают внутреннее хранилище телефона как диск, но есть другие решения.

На USB флешке

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

На HDD или SSD

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