Этот пост является частью серии из 7 постов на тему Как создать культуру обучения для групп разработчиков ПО:

Определите потребности и расставьте приоритеты целей

Обучение — это обширная тема, и вам неизбежно зададут один вопрос: «О чем должны узнать наши команды разработчиков?» У вас и вашей команды есть ключи к выявлению наиболее актуальных потребностей и упорядочению желаний в соответствии с вашими текущими приоритетами.

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

Обсуждение с вашими командами поможет вам определить потребности и ожидания каждого человека и уточнить ваши цели. Может быть, разработчики хотят изучить React, потому что проект миграции с AngularJS на React запланирован на несколько месяцев? Или вы хотите узнать о передовых методах кибербезопасности, чтобы избежать рисков в ваших приложениях? Или Domain-Driven Design?

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

Получите поддержку своего руководства

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

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

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

"Качество бесплатно, но только для тех, кто готов заплатить за него большие деньги"

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

Вы когда-нибудь слышали, как люди говорят Достичь качества, написать тесты, обучить людей…? Вероятно, да, потому что это все еще знакомо в отрасли. Сандро Манкузо, автор справочника по программному мастерству, справедливо говорит:

«Качество не дорого. Отсутствие навыков делает качественное программное обеспечение дорогим.

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

Учитесь вместе с добротой и смирением

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

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

Вы слышали о Project Aristotle Google? Это исследование, начатое в 2012 году, пыталось ответить на следующий вопрос: Что делает команду в Google эффективной? Интуитивно некоторые люди могут подумать, что главными факторами являются многолетний опыт работы в Google. резюме членов команды. Однако первым фактором оказалась психологическая безопасность: каждый человек чувствует себя комфортно, проявляя инициативу, не опасаясь неудачи и уязвимости перед другими. На практике это приводит к ситуациям, когда мне удобно:

  • Запрашивайте код-ревью и не опасайтесь сбора отзывов;
  • Предлагайте лучшие практики во время Craft Workshops, даже если я не уверен в себе на 100%;
  • Открыто говорите о проблеме, с которой я сталкиваюсь, или о ситуации, которая ставит меня в неудобное положение.

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

Повторяйте и собирайте отзывы

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

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

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

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

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

Извлечение тенденций и выявление добавленной стоимости

Ключевым аспектом любых инвестиций является демонстрация какой-либо добавленной стоимости или выгоды от этой стратегии технического прогресса команд? Будем честными: у нас нет чудодейственных формул, но мы предлагаем способы выявления трендов добавленной стоимости подхода.

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

Также можно сформулировать ожидания и предположения. Конкретным примером является ROE (Отдача от ожиданий), используемая в контексте обучения и обучения. Он состоит в том, чтобы сформулировать наши цели перед учебным курсом и оценить, повлияло ли, по нашему мнению, на нас обучение для достижения этих целей через какое-то время. Мы также можем пойти дальше, используя методику Hypothesis-Driven Development Story Template от Lean-сообщества, которая предлагает указать в форме: «Мы считаем, что такое-то и такое-то действие: … будет иметь такое-то и такое-то влияние: … мы будем знать, что нам это удалось, если будем наблюдать… и для этого опыта мы будем делать…. Логика та же: что ожидается на выходе и как мы можем это измерить?

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

Последнее слово

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

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

Если у вас есть какие-либо вопросы, вы хотите поделиться своими текущими проблемами или представить нам форматы, которые работали в вашем контексте, свяжитесь с нами, и мы будем рады обсудить их вместе.