🇷🇺
До
60% скидки
до 30-го ноября
Откажитесь от бесполезных показателей производительности и стимулируйте энтузиазм разработчиков и реальные результаты! 🚀 Узнайте, как повысить эффективность команды и уменьшить стресс.
Измерение продуктивности разработчиков (включая no-code разработчиков) представляет собой настоящую путаницу. Разработчики устали от необходимости достигать определенного количества коммитов или относительных оценок объема работы, которые не имеют реальной ценности для клиентов. Когда менеджеры пытаются навязать им метрики продуктивности, разработчики лишь закатывают глаза и начинают сопротивляться, создавая впечатление, что им не важна ответственность. Однако это далеко от истины. Разработчики заботятся о предоставлении ценности не меньше, чем руководители. Проблема заключается в том, что никто не может договориться о том, как именно измерять продуктивность.
Давайте углубимся в эту тему и рассмотрим несколько способов решения проблемы. Мы поговорим о том, как измерять продуктивность так, чтобы это действительно имело смысл, как выявить и устранить узкие места, мешающие команде, и как внести изменения, не вызывая негодования у сотрудников.
Во-первых, нужно ли вообще количественно оценить продуктивность разработчиков? Это зависит от того, как вы ее определяете. Если вы смотрите только на такие показатели, как количество строк кода или число коммитов, то да, это можно измерить. Но что на самом деле это говорит о работе разработчиков? Сколько строк кода нужно, чтобы создать отличный пользовательский опыт? Сколько коммитов должен делать продуктивный разработчик каждый день? Никто не знает.
Существует огромное количество возражений против попыток свести продуктивность к простым цифрам. Давайте поменяем подход и подумаем вот о чем:
На эти вопросы сложнее ответить с помощью одних лишь цифр, но они позволят гораздо ближе подойти к измерению продуктивности, которая действительно имеет значение. Давайте рассмотрим несколько способов ее оценки с разных сторон, но сначала давайте откровенно поговорим о том, какие метрики сами по себе не имеют смысла. Отслеживание таких данных может быть полезным, но их нужно рассматривать в контексте.
Закон Гудхарта довольно прост: «Когда показатель становится целью, он перестает быть хорошим показателем». Другими словами, как только вы начинаете использовать какую-либо метрику в качестве цели, она становится бесполезной для реального измерения чего-либо значимого.
Итак, полезны ли показатели активности для оценки продуктивности ваших инженеров? И да и нет.
Отслеживание того, сколько часов ваши сотрудники проводят за столами каждую неделю, не даст вам ясного представления о том, действительно ли они выполняют важную работу. Простой подсчет коммитов, строк кода или любой другой единственной метрики вряд ли поможет вам понять, продуктивны ли ваши команды и действительно ли это имеет значение. Большая часть реальной работы в программировании и архитектуре происходит в головах людей, а не только тогда, когда они печатают на клавиатуре.
Но это не значит, что эти метрики совершенно бесполезны. Они могут дать вам общее представление о том, с чего начать копать, чтобы выявить потенциальные проблемы или узкие места.
Так что да, показатели активности могут служить отправной точкой, но не полагайтесь на них слишком сильно, иначе вы рискуете гоняться за неправильными вещами.
Когда речь идет о продуктивности, главное — это команда, а не отдельный человек. Показатели продуктивности и дашборды должны использоваться для отслеживания работы команды в целом, а не для выделения отдельных разработчиков. Даже если вы решите использовать определенные метрики в качестве целей, а не просто как способ понять, что происходит, вы не хотите создать ситуацию, в которой:
Как же менеджерам отслеживать продуктивность, не создавая проблем? Существует множество возможных показателей, но выбор зависит от того, что именно ваша компания пытается улучшить. Вот несколько распространенных подходов:
Метрики DORA. Доктор Николь Форгрен, Джез Хамбл и Джин Ким написали книгу под названием «Accelerate», в которой они обсуждают четыре ключевых показателя, которые отслеживают высокоэффективные команды:
Первые два показателя связаны с тем, насколько быстро вы разрабатываете, в то время как последние два касаются стабильности вашей системы.
Фреймворк SPACE. Этот фреймворк ориентирован на оценку продуктивности с различных сторон, а не только с одной или двух метрик изолированно. Он предлагает пять измерений продуктивности разработчиков:
Для каждого измерения предлагаются рекомендации по метрикам, которые можно отслеживать, и способам их сбора. Однако авторы рекомендуют фиксировать несколько метрик по крайней мере по трем измерениям и сочетать это с качественными данными, такими как опросы.
Суть в том, чтобы не зацикливаться на одной цифре и не считать на этом все законченным. Нужно смотреть на общую картину и собирать данные с разных ракурсов, чтобы действительно понять, как обстоят дела у команды.
Если вы хотите реально понять, что замедляет команду, вам нужно поговорить с сотрудниками и провести опросы. Данные, полученные в результате этих бесед, будут как яркая мигающая неоновая вывеска, указывающая верное направление, но это не все. Вам, вероятно, понадобится сочетание твердых цифр и субъективной обратной связи, чтобы действительно разобраться в том, что мешает команде.
Так какие же цифры следует отслеживать? Сводные метрики могут дать вам общее представление о тенденциях и узких местах, не выделяя никого конкретно. Вот несколько простых метрик, которые можно извлечь из уже имеющихся у данных:
Но не стоит переусердствовать, пытаясь отслеживать каждую возможную метрику. Это только усугубит ситуацию. Каждое решение связано с компромиссами, и если вы не понимаете, что действительно важно, можно обосновать практически любое решение. Начните с выбора нескольких метрик, которые действительно имеют значение для достижения целей вашей компании.
И, кстати, если ваши метрики соответствуют вашим целям, то нет ничего плохого в том, чтобы разработчики немного «играли с системой», чтобы достичь нужных показателей.
Но если вы плохо выберете свои цели и стимулы, это может привести к неприятным непреднамеренным последствиям. Взгляните на целевые показатели продаж по часам в Sears, которые привели к завышению цен для клиентов и бесполезной суматохе, или на экономичный автомобиль Ford с крошечным недостатком — он мог воспламениться при столкновении. Эти ужасные истории напоминают нам о важности тщательного анализа того, как ваши метрики могут быть «обмануты», и действительно ли эти побочные эффекты помогают или мешают общим целям.
Код-ревью могут стать настоящей головной болью, когда речь идет о релизе кода. Если ваши пулл-реквесты просто лежат без дела и вы хотите, чтобы ваша команда действительно помогала друг другу, можно установить цель, например, «X% пулл-реквестов должны быть рассмотрены в течение X часов». Таким образом, метрика будет связана с целью, а нацеливаясь на процент вместо «всех», вы оставляете немного пространства для неизбежных исключений.
Если вы пытаетесь создать культуру частых и ранних релизов, установка цели по увеличению количества пулл-реквестов может на самом деле побудить инженеров «обмануть» систему, разбивая свои пулл-реквесты на еще более мелкие части. Но угадайте что? В этом случае именно такое поведение вы хотите видеть, так что это выигрышный вариант для всех.
Обращая внимание как на чувствительные качественные данные, так и на холодные, объективные агрегированные цифры, вы можете сделать метрики продуктивности менее угрожающими для разработчиков. Мониторинг этих агрегированных показателей поможет выявить узкие места, затрудняющие работу, в то время как общение с разработчиками о их опыте позволит им почувствовать, что их слышат, и выявить неэффективности, которые могут не отображаться в чистых метриках активности.
Итак, как же узнать, что именно мешает вашей команде? Вам нужны подсказки о том, какая работа оказывается сложнее, чем должна быть, что занимает слишком много времени и какие задачи можно автоматизировать или полностью исключить.
Индивидуальные встречи. Когда вы проводите встречи с подчиненными, это отличное время, чтобы узнать, как они себя чувствуют и с какими трудностями сталкиваются.
Опросы. Хотите получить более последовательные данные для сравнения? Проведите опрос среди членов вашей команды. Попросите их указать задачи, которые занимают больше времени, чем должны, или процессы, связанные с множеством ручных операций.
Наблюдение за работой. «Лучший способ понять, насколько сломана система проектирования, — это попробовать использовать ее именно так, как задумано.» Попробуйте погрузиться в цикл спринта и посмотрите, как это работает.
Ретроспектива. «Не ограничивайтесь анализом инцидентов, изучайте и свои успехи, чтобы понять, как они произошли... Когда вы это сделаете, вы сможете узнать, как и когда их повторить.»
Как только появляются данные и, надеюсь, выявляются потенциальные узкие места, начинают проступать закономерности. У каждой организации есть свои уникальные проблемы, но существуют общие темы в типах трудностей и способах их решения.
Недиверсифицированная тяжелая работа
Джефф Безос придумал этот термин для описания всей работы, которая необходима для создания и развертывания программного обеспечения, но не влияет на продукт или функции. Речь идет о развертывании серверов, управлении балансировщиками нагрузки или дата-центрами, создании внутренних инструментов — в общем, о «цене входа». Подумайте о стандартизации, автоматизации, аутсорсинге или использовании инструментов для решения этих задач, чтобы ваши разработчики могли сосредоточиться на работе, которую может выполнять только ваша компания. По мере роста вы можете нанять внутренних экспертов, которые теоретически смогут справиться с этими задачами, но все равно нужно думать о наилучшем использовании их времени и экспертизы.
Трудоемкая работа
Трудоемкая работа — это утомительная, рутинная деятельность, которая не решает новых задач и только мешает продвижению вашего бизнеса. Этот термин был придуман Google для обозначения задач в области надежности сайтов, но примеры трудоемкой работы можно найти на всех этапах жизненного цикла разработки программного обеспечения: это любые времязатратные или повторяющиеся задачи, которые не имеют долговременной ценности и могут быть автоматизированы или решены с помощью инструментов. Трудоемкая работа не только тратит время, но и может вызвать недовольство и выгорание у членов команды, которым приходится иметь дело с ее избытком. Эти задачи можно передать на аутсорсинг, но часто более эффективно найти способы стандартизации и повторного использования решений, чтобы избавиться от трудоемкой работы вовсе.
Большинство компаний, стремящихся к масштабированию, в конечном итоге сталкиваются с ловушкой: трудоемкую работу часто можно устранить с помощью внутренних инструментов, но создание этих инструментов само по себе является трудоемким процессом. Задачи, такие как создание интерфейса пользователя с нуля, занимают огромное количество времени, не решая при этом основных бизнес-задач.
Технические преграды
Даже если ваша команда работает исключительно над действительно уникальными бизнес-задачами, ее все равно могут замедлять технические преграды, такие как медленная система непрерывной интеграции (распространенная проблема по мере масштабирования) или плохо спроектированная архитектура с тесно связанными компонентами. Если вы не инвестируете в мониторинг и наблюдаемость, ваша команда будет тратить слишком много времени на анализ первопричин и отладку (что негативно скажется на вашем показателе среднего времени восстановления, если вы отслеживаете метрики DORA).
Ладно, давайте поговорим о культурных проблемах, которые действительно могут замедлить вашу команду.
Слишком быстрое движение вперед
В маленьком стартапе, где работает всего несколько человек, обычно все происходит довольно живо — легко подхватываются новые технологии, нет бюрократической волокиты, которая могла бы тормозить развитие. Но с ростом компании начинают проявляться подводные камни: без четко выстроенных процессов (да и просто их документации) люди частенько тратят уйму времени на то, чтобы заново изобретать велосипед.
Когда никто не фиксирует, какие инструменты использует, какие зависимости нашел или какие тесты написал, становится сложно опираться на опыт коллег. В результате впустую тратится драгоценное время разработчиков. А если постоянно искать короткие пути и дублировать работу, то со временем ситуация только усугубляется, и ваше приложение или сервис становится таким же ненадежным, как шатающийся малыш. Хотя небольшие стартапы редко уделяют внимание документации или как-то поощряют ее ведение, это вполне реально наладить. Более того, даже культурные проблемы можно решить с помощью технических инструментов.
Слишком медленное движение вперед
С другой стороны, когда компания вырастает и накапливается достаточно недовольных клиентов, жалующихся на сбои в работе, начинается внедрение процессов, требований к соответствию стандартам и координации между отделами. И вот уже сложно двигаться быстро, потому что какой-нибудь умник из другого отдела должен одобрить ваш проект, прежде чем вы сможете двигаться дальше, а у него свои цели и обязательства по уровню обслуживания.
Такая жесткость имеет свой смысл (система сдержек и противовесов существует не просто так), но всем известно, что в крупных компаниях небольшие команды, которым поручают особые проекты, вдруг каким-то чудесным образом начинают творить чудеса, когда их освобождают от обычной бюрократической волокиты. Если в вашей компании несколько ключевых метрик, и каждая группа оптимизирует что-то свое, стоит добиться от руководства определения единой, главной цели, вокруг которой должны объединиться все — такая ясность помогает преодолевать тупиковые ситуации, когда процессы одной команды тормозят работу другой.
Совещания... бррр
Совещания всегда мешали сосредоточенной работе, но с ростом числа удаленных встреч (по данным исследования Harvard Business Review, в 2022 году на каждого сотрудника приходилось на 60% больше удаленных совещаний по сравнению с 2020 годом) разработчикам стало еще сложнее быть в ресурсе. Если отследить соотношение часов непрерывной работы и времени, проведенного на совещаниях, картина получится весьма показательная. Необязательно объявлять «банкротство» и отменять все регулярные групповые встречи, но взять их под контроль можно:
Не спешите все разрушать (пока что). Когда пытаешься повысить продуктивность, возникает соблазн начать все с нуля. Но помните: тише едешь — дальше будешь. Потратить лишние 45 минут на написание тестов куда выгоднее, чем постоянно исправлять сборку.
Наличие надежной системы управления функциями, позволяющей безопасно и уверенно откатывать изменения, создает как психологическую, так и фактическую безопасность при выкатке в продакшн. Обеспечение команды правильными инструментами избавляет от необходимости создавать типовые решения с нуля.
Все это примеры того, как начальное замедление позволяет ускориться в дальнейшем. Как руководитель разработки, вы можете посмотреть на ситуацию со стороны, увидеть, где можно сгладить острые углы, и внедрить эти оптимизации для всей команды.
Универсальных решений не существует. «Зависит от ситуации» — любимый ответ опытных разработчиков на вопросы и предложения. То же самое касается и выбора методов повышения продуктивности. Что работает для одного типа узких мест при определенном масштабе, может оказаться бесполезным в других случаях.
Погружение в большую, запутанную кодовую базу — распространенная проблема для разработчиков. Это отнимает много времени и сил. Решить ее можно разными способами:
Какое решение подойдет вашей организации, зависит от размера компании, приоритетов, ресурсов и того, работает ли команда в одном месте или распределена.
Привлечение всех к изменениям начинается с вовлечения команды в процесс. Надеюсь, к этому моменту вы уже учли их мнение при определении преград и потенциальных решений. Следующие шаги:
Начинайте с малого. При внедрении новых технологий хорошо спланированный и успешный пилотный проект может помочь набрать обороты через «сарафанное радио», когда разработчики начинают видеть реальные результаты первого применения. Мы постоянно наблюдаем это: клиенты пробуют платформу для создания одного внутреннего инструмента, а затем ее использование растет, когда другие команды узнают о ней. Услышать об успешном опыте от коллеги всегда весомее, чем получить указание использовать инструмент (или процесс, или систему) от руководства.
Прозрачность — лучшее лекарство от скептицизма. Важно документировать не только решение, но и путь к нему. Предоставление команде такого контекста в письменном виде помогает укрепить доверие и дает людям время усвоить информацию самостоятельно. Организуйте синхронную встречу (или несколько, если команда распределена по разным часовым поясам), чтобы люди могли задать вопросы. Можно пригласить членов фокус-группы или участников пилотного проекта поделиться своим опытом из первых рук.
И, наконец, постоянно совершенствуйтесь. Даже при большом успехе важно не слишком привязываться к своим решениям. Ваша компания может и не масштабироваться активно, но другие меняющиеся факторы могут повлиять на продуктивность команды. Будьте готовы регулярно проводить переоценку.
Хотите узнать больше о no-code и о том, как оставаться эффективным, не выгорая? Посетите наши сообщества — ссылки находятся внизу. Спасибо за внимание и держите хвост пистолетом!
Общие метрики производительности разработчиков включают метрики DORA (частота развертывания, время внедрения изменений, среднее время восстановления после сбоев, уровень неудач в изменениях), параметры фрейма SPACE (удовлетворенность, производительность, активность, общение и сотрудничество, эффективность и динамика), время сосредоточенной работы по сравнению с временем на встречи, время на проверку пулл-запросов и многое другое. Ключевым моментом является рассмотрение нескольких метрик в совокупности.
Выявление препятствий, влияющих на продуктивность команд, возможно через индивидуальные беседы с разработчиками, командные опросы, наблюдение за работой для непосредственного понимания процессов и ретроспективы по успешным и неудачным проектам. Часто возникающие общие темы касаются потраченного времени на повторяющиеся рутинные задачи, отсутствия документации, что приводит к дублированию работы, медленных систем и инструментов, а также чрезмерного количества встреч.
К мерам для повышения производительности относятся: устранение «недифференцированного тяжелого труда» с помощью автоматизации и инструментов, оптимизация встреч и переход на асинхронные форматы, улучшение документации и процесса адаптации, использование управления функциями для безопасного выпуска обновлений, сбор предложений от команды по решениям, запуск пилотных проектов перед масштабными изменениями и непрерывное совершенствование на основе обратной связи. Предоставление контекста и прозрачность данных также помогают.
Получите скидку до 60% на все тарифные годовые планы Directual! Подробнее об акции читайте внутри.
Неполадки случаются постоянно, поэтому без системы управления инцидентами (IMS) отслеживание проблем превращается в настоящий ад. Этот гайд поможет вам разобраться с ситуацией правильным образом.
Откажитесь от кода и присоединяйтесь к революции low-code/no-code! Получите возможность быстрой разработки приложений, автоматизации процессов и инноваций, не прилагая особых усилий (и не превышая бюджет). Перетаскивание, создание и возможность удивлять с помощью простого способа создания кастомных приложений.
Нанимайте разработчиков для реализации своих проектов и предлагайте собственные услуги для реализации чужих! Все это прямо в Directual. Заходите, чтобы узнать больше.
WhatsApp — это поле битвы за привлечение клиентов. Изучите реальные истории успеха, узнайте, как создать свой собственный чатбот, и оставайтесь в курсе перспективных тенденций.
ИИ чат-боты! Узнайте, кто в тренде, кто нет, и как создать своего собственного помощника с ИИ, чтобы добиться максимальной продуктивности с no-code.
Присоединяйтесь к 22 000+ разработчикам на Directual и создавайте проекты быстрее и дешевле. Визуальный интерфейс упрощает разработку, а мощные базы данных и бэкенд делают масштабирование легким и эффективным.
