Меня зовут Джереми! Я работаю с StartupLandia, чтобы помогать создавать лучшие стартапы в мире. Пожалуйста, свяжитесь с нами, если вы посчитали это полезным или у вас возникнут вопросы!

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

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

Продуктивность - это не одно и то же, так что вы пытаетесь отслеживать?

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

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

Если мы посмотрим за пределы ПРОСТРАНСТВА, мы сможем начать говорить о вещах, которые мы действительно можем СДЕЛАТЬ.

Но сначала!

Наши KPI кажутся хорошими, но мы все равно пропустили дедлайн, и два человека уволились!

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

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

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

На самом деле у одного КПЭ не было шансов. Не без учета других аспектов, таких как сотрудничество.

Что же тогда делать?

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

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

Что вы думаете об отслеживании и повышении производительности? Я хотел бы поучиться у всех вас, поэтому не стесняйтесь оставлять комментарии или писать мне по электронной почте [email protected]

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