Никто не станет требовать от разработчика, чтобы он писал код без доступа к компьютеру, но многие компании считают, что он каким-то образом должен работать без возможности полностью задействовать свои мыслительные возможности. А это примерно настолько же нереально.
И поэтому давайте пройдемся по списку из двенадцати вещей, которые не позволяют разработчикам войти в состояние потока и выдать максимальную продуктивность. Я постараюсь двигаться от самых ключевых вещей к менее существенным. Предлагайте свои варианты и замечания!
Если же кто-то сомневается, стоит ли тратить на это деньги и силы, достаточно вспомнить, сколько программистам платят. Даже прирост производительности в 10% — это немало в денежном эквиваленте!
На мой взгляд, отвлекать разработчика — самый верный способ убить его продуктивность на корню. Он не может просто взять и продолжить с того места, где его прервали. Ему нужно сначала снова включиться в процесс, а потом еще пройти всю цепочку размышлений до нужного момента — одно это может занять полчаса и больше. И чем больше случается таких перерывов, тем больше копится раздражение, тем ниже становится качество работы, тем чаще появляются баги, и этот список можно еще продолжать.
Ну а совещания? Единственное их отличие от других отвлекающих факторов заключается в том, что они планируются заранее. И это делает ситуацию только хуже. Программисту сложно продвинуться в решении задачи, если он заранее ожидает перебоя в работе. Поэтому если через час-другой ему предстоит идти на планерку, скорее всего он не сможет сделать ничего существенного ни для одного из своих проектов — ведь большая часть инженерных задач занимает больше времени.
Как говорил Пол Грэхэм: «Одно совещание может убить полдня: время разбивается на два периода, за которые ничего серьезного сделать не успеешь».
Как избежать такого положения дел? На этот счет все уже давно расписано, так что оправданий нет. Нужно просто ставить планерки на самом начало дня или, допустим, сразу перед обедом, чтобы без необходимости не отвлекать людей от работы.
Из всех разновидностей менеджеров те, кто вмешивается по любому поводу, пожалуй, хуже всего влияют на продуктивность сотрудников. Конечно, тут сказывается и то, что именно этот тип особенно склонен организовывать кучу совещаний и требовать внимания разработчиков по непредвиденным поводам. Но дело не только в этом. Такие действия показывают недостаток доверия, и итоге у людей появляется чувство, что их считают ни на что не способными и ставят под вопрос их профессиональные умения. Даже если у программиста еще и осталась какая-то мотивация работать несмотря на бесконечные перерывы, такое отношение отобьет ее напрочь. Последствия не ограничиваются одним падением производительности. Назойливые менеджеры особенно часто вынуждают сотрудников уйти из компании или, как минимум, из команды.
Недостаточную ясность можно проиллюстрировать множеством разных примеров. Например, баг репорт в духе «Тут не работает, почините!» явно не дает разработчикам всю необходимую для работы информацию. Кстати, в этом конкретном случае может помочь введение шаблона для отчетов о багах.
Или другой случай: расплывчатые требования для какой-то части продукта. При таких вводных разработчики просто начинают делать так, как сами себе все это представляют, а потом приходит менеджер с более детальным описанием ожидаемого пользовательского поведения, и им все приходится начинать сначала.
К этой же категории относятся и невнятно расставленные приоритеты. Программисты тратят уйму времени, ломая голову, с чего им лучше было бы начать, хотя избежать этого было бы очень просто. Ну а если уж им когда-нибудь придется отчитываться перед менеджером, почему они занимаются тем, а не этим (при том, что порядок никто не оговаривал), можете не сомневаться, их это здорово выбесит.
Слышали когда-нибудь о таком? Бывают менеджеры, которые вообще не участвуют в рабочем процессе… за исключением тех моментов, когда вдруг решают спикировать на кого-нибудь и все обгадить. «Это никуда не годится, и это тоже, а это совсем не смотрится,» — и полетели дальше. Должен признать, сравнение мне нравится, но вот стоящее за ним явление встречается куда чаще, чем хотелось бы. Такое поведение сказывается на разработчиках очень плохо: многим приходится после этого часами вырабатывать рабочий настрой, а кто-то выпадает из потока на целые дни.
Случалось ли с вами такое, что кто-то из менеджеров или других программистов приписывал себе в заслуги то, над чем вы бились несколько недель? Разработчики ставят свой профессионализм превыше всего. Воровать чужие заслуги — это все равно что отказывать человеку в компетентности, чтобы раздуть свою собственную. Я поставил этот пункт достаточно высоко потому, что считаю, что такие вещи приводят к очень напряженной обстановке, которая может на долгое время «уронить» производительность всей команды.
Может, людям из других профессий это покажется странным, но для программистов окружающая обстановка многое решает в ходе работы. Скажем, белый шум — жужжание кондиционера, доносящийся гул машин и грузовиков с улицы — помогает им лучше сосредоточиться. Именно поэтому многие из нас работают в наушниках! Я вот, кстати, недавно открыл для себя RainyMood — отличная вещь!
Вместе с тем, если офис спроектирован так, что вокруг человека постоянно какое-то движение, то это будет оказывать противоположное действие. А если к тому же мониторы стоят так, что менеджеры постоянно видят то, что на экране, это создает и лишний стресс, и лишние поводы отвлекать разработчиков от дела.
В управление проектами этот термин используют для ситуаций, когда объемы проекта неконтролируемо растут. Такое обычно случается, когда изначально они не были строго определены и задокументированы или же не отслеживались в процессе.
Из-за смещения границ относительно простые запросы разрастаются в замороченных чудищ, которые отъедают кучу времени! И в большинстве случаев начинается это тогда, когда продукт уже в разработке.
Возьмем для примера простую функцию:
Это может показаться непонятным на первый взгляд, но на самом деле, все просто. Если люди, отвечающие за продукт, выстраивают приоритеты, не проверяя свои гипотезы (через обратную связь или любым другим способом) об интересе аудитории к тем или иным возможностям, и разработчики видят, что эти возможности попросту не используются, то у них появится ощущение, что их работа не имеет смысла, и мотивация порушится. Мы все хотим чувствовать, что оставляем какой-то след в мире, а для разработчиков это особенно важно!
Технический долг — это осознаное решение допустить определенные натяжки в выборе решений и написании кода, чтобы выкатить продукт побыстрее. Какой-то объем технического долга возникает в любом проекте неизбежно и может помочь со сроками на коротких дистанциях. Однако в долгосрочной перспективе он повышает сложность системы и тем самым замедляет разработчиков. Далекие от программирования люди зачастую недооценивают влияние этих процессов на производительность и требуют двигаться вперед без остановок — при таком раскладе начинают возникать проблемы. Если рефакторинг всегда остается вне списка приоритетов, страдать будет не только продуктивность сотрудников, но и качество продукта.
Разработчики ежедневно используют множество инструментов для написания, пуша и слияния кода. Чем сильнее им удается автоматизировать процессы, тем лучше. Само собой разумеется, что древние инструменты будут оказывать прямое влияние на уровень производительности. Также многое решает и то, на чем ведется работа — на одном ноутбуке или еще и на дополнительном экране. Если сопоставить цены на железо с зарплатами программистов, то даже 5% роста продуктивности определенно окупит все затраты! Нужно просто предоставить команде ту аппаратуру и инструменты, которыми они предпочитают пользоваться (для аппаратуры решение должно быть индивидуальным, для инструментов — коллективным).
В процессе обучения программированию мы все усвоили, что комментарии к коду нужно начинать добавлять как можно раньше и как можно чаще. Идея состояла в том, что лучше пусть комментариев будет слишком много, чем недостаточно. К сожалению, многие поняли это превратно и решили, что в пояснениях нуждается каждая строка. Потому-то мы имеем образчики вроде вот такого вот, из статьи Джеффа Этвуда «Код без комментариев»:
Вы поняли, что вообще делает это код? Вот и я ничего не понял. Проблема в том, что здесь очень много говорится о том, как все работает, но ни слова о том, зачем это нужно. Если предположить, что в программе возник баг и вы обнаружили под капотом такой фрагмент кода, он ничем бы вам не помог разобраться в ситуации.
Последний пункт завязан на тенденции менеджеров просить разработчиков примерно оценить, сколько времени им потребуется, затем давить на них, чтобы занизили эту оценку, а потом волшебным образом приравнивать итоговую дату к дедлайну! При этом менеджеры полагают даже, что раз уж разработчики «сами установили сроки», значит, подписались на соответствующий дедлайн и его следует считать окончательно утвержденным вариантом, который можно передавать высшему руководству.
Разработчики же считают, что подобный дедлайн — полное безумие и уложиться в него невозможно; в команде возникает разлад и никто не может сосредоточиться.
Если окинуть взглядом все эти 12 пунктов, можно заметить, что они, по большей части, актуальны для всех, кто задействован в проектах. Просто в случае программистов они особенно критичны, так как их работа требует глубокого погружения в процесс.
Если вы заметили, что какие-то из приведенных пунктов характерны и для вашей компании, было бы неплохо пройтись по этому списку вместе с командной разработчиков, выстроить с ними диалог, узнать, где возникают проблемы и как лучше их решать. Что бы они ни говорили, крайне важно всерьез отнестись к этой обратной связи и замечаниям. За последние тридцать в плане технологий много что поменялось, но базовый принцип командной работы остается прежним: рассуждая о производительности, необходимо учитывать человеческий фактор. Совершенствуйте рабочие процессы, обстановку, привычки команды и дайте им возможность подсказать вам, как добиться максимальной продуктивности.
И поэтому давайте пройдемся по списку из двенадцати вещей, которые не позволяют разработчикам войти в состояние потока и выдать максимальную продуктивность. Я постараюсь двигаться от самых ключевых вещей к менее существенным. Предлагайте свои варианты и замечания!
Если же кто-то сомневается, стоит ли тратить на это деньги и силы, достаточно вспомнить, сколько программистам платят. Даже прирост производительности в 10% — это немало в денежном эквиваленте!
1) Совещания и прочие отвлекающие факторы
На мой взгляд, отвлекать разработчика — самый верный способ убить его продуктивность на корню. Он не может просто взять и продолжить с того места, где его прервали. Ему нужно сначала снова включиться в процесс, а потом еще пройти всю цепочку размышлений до нужного момента — одно это может занять полчаса и больше. И чем больше случается таких перерывов, тем больше копится раздражение, тем ниже становится качество работы, тем чаще появляются баги, и этот список можно еще продолжать.
«Чем чаще меня отвлекают, когда я пытаюсь приступить к задаче, тем больше времени начинает проходить между попытками. Если меня дергают все утро, нечего удивляться, что день получился непродуктивный» — Анонимный разработчик с Reddit
Ну а совещания? Единственное их отличие от других отвлекающих факторов заключается в том, что они планируются заранее. И это делает ситуацию только хуже. Программисту сложно продвинуться в решении задачи, если он заранее ожидает перебоя в работе. Поэтому если через час-другой ему предстоит идти на планерку, скорее всего он не сможет сделать ничего существенного ни для одного из своих проектов — ведь большая часть инженерных задач занимает больше времени.
Как говорил Пол Грэхэм: «Одно совещание может убить полдня: время разбивается на два периода, за которые ничего серьезного сделать не успеешь».
Как избежать такого положения дел? На этот счет все уже давно расписано, так что оправданий нет. Нужно просто ставить планерки на самом начало дня или, допустим, сразу перед обедом, чтобы без необходимости не отвлекать людей от работы.
2) Придирки к мелочам
Из всех разновидностей менеджеров те, кто вмешивается по любому поводу, пожалуй, хуже всего влияют на продуктивность сотрудников. Конечно, тут сказывается и то, что именно этот тип особенно склонен организовывать кучу совещаний и требовать внимания разработчиков по непредвиденным поводам. Но дело не только в этом. Такие действия показывают недостаток доверия, и итоге у людей появляется чувство, что их считают ни на что не способными и ставят под вопрос их профессиональные умения. Даже если у программиста еще и осталась какая-то мотивация работать несмотря на бесконечные перерывы, такое отношение отобьет ее напрочь. Последствия не ограничиваются одним падением производительности. Назойливые менеджеры особенно часто вынуждают сотрудников уйти из компании или, как минимум, из команды.
3) Неясность
Недостаточную ясность можно проиллюстрировать множеством разных примеров. Например, баг репорт в духе «Тут не работает, почините!» явно не дает разработчикам всю необходимую для работы информацию. Кстати, в этом конкретном случае может помочь введение шаблона для отчетов о багах.
Или другой случай: расплывчатые требования для какой-то части продукта. При таких вводных разработчики просто начинают делать так, как сами себе все это представляют, а потом приходит менеджер с более детальным описанием ожидаемого пользовательского поведения, и им все приходится начинать сначала.
К этой же категории относятся и невнятно расставленные приоритеты. Программисты тратят уйму времени, ломая голову, с чего им лучше было бы начать, хотя избежать этого было бы очень просто. Ну а если уж им когда-нибудь придется отчитываться перед менеджером, почему они занимаются тем, а не этим (при том, что порядок никто не оговаривал), можете не сомневаться, их это здорово выбесит.
4) Менеджеры-чайки
Слышали когда-нибудь о таком? Бывают менеджеры, которые вообще не участвуют в рабочем процессе… за исключением тех моментов, когда вдруг решают спикировать на кого-нибудь и все обгадить. «Это никуда не годится, и это тоже, а это совсем не смотрится,» — и полетели дальше. Должен признать, сравнение мне нравится, но вот стоящее за ним явление встречается куда чаще, чем хотелось бы. Такое поведение сказывается на разработчиках очень плохо: многим приходится после этого часами вырабатывать рабочий настрой, а кто-то выпадает из потока на целые дни.
5) Кража лавров
Случалось ли с вами такое, что кто-то из менеджеров или других программистов приписывал себе в заслуги то, над чем вы бились несколько недель? Разработчики ставят свой профессионализм превыше всего. Воровать чужие заслуги — это все равно что отказывать человеку в компетентности, чтобы раздуть свою собственную. Я поставил этот пункт достаточно высоко потому, что считаю, что такие вещи приводят к очень напряженной обстановке, которая может на долгое время «уронить» производительность всей команды.
6) Обстановка: шум, движение, дизайн рабочего пространства…
Может, людям из других профессий это покажется странным, но для программистов окружающая обстановка многое решает в ходе работы. Скажем, белый шум — жужжание кондиционера, доносящийся гул машин и грузовиков с улицы — помогает им лучше сосредоточиться. Именно поэтому многие из нас работают в наушниках! Я вот, кстати, недавно открыл для себя RainyMood — отличная вещь!
Вместе с тем, если офис спроектирован так, что вокруг человека постоянно какое-то движение, то это будет оказывать противоположное действие. А если к тому же мониторы стоят так, что менеджеры постоянно видят то, что на экране, это создает и лишний стресс, и лишние поводы отвлекать разработчиков от дела.
7) Смещение границ проекта
В управление проектами этот термин используют для ситуаций, когда объемы проекта неконтролируемо растут. Такое обычно случается, когда изначально они не были строго определены и задокументированы или же не отслеживались в процессе.
Из-за смещения границ относительно простые запросы разрастаются в замороченных чудищ, которые отъедают кучу времени! И в большинстве случаев начинается это тогда, когда продукт уже в разработке.
Возьмем для примера простую функцию:
- Первая версия (до реализации): функция определена как «Отображать карту локации»
- Вторая версия (когда первая итерация уже почти закончена): описание меняется на «Отображать 3D карту локации»
- Третья версия (когда вторая итерация уже почти закончена): описание меняется на «Отображать 3D карту локации, по которой пользователь мог бы передвигаться»
8) Процесс определения возможностей продукта
Это может показаться непонятным на первый взгляд, но на самом деле, все просто. Если люди, отвечающие за продукт, выстраивают приоритеты, не проверяя свои гипотезы (через обратную связь или любым другим способом) об интересе аудитории к тем или иным возможностям, и разработчики видят, что эти возможности попросту не используются, то у них появится ощущение, что их работа не имеет смысла, и мотивация порушится. Мы все хотим чувствовать, что оставляем какой-то след в мире, а для разработчиков это особенно важно!
9) Игнорирование технического долга
Технический долг — это осознаное решение допустить определенные натяжки в выборе решений и написании кода, чтобы выкатить продукт побыстрее. Какой-то объем технического долга возникает в любом проекте неизбежно и может помочь со сроками на коротких дистанциях. Однако в долгосрочной перспективе он повышает сложность системы и тем самым замедляет разработчиков. Далекие от программирования люди зачастую недооценивают влияние этих процессов на производительность и требуют двигаться вперед без остановок — при таком раскладе начинают возникать проблемы. Если рефакторинг всегда остается вне списка приоритетов, страдать будет не только продуктивность сотрудников, но и качество продукта.
10) Разнообразие инструментов и аппаратуры
Разработчики ежедневно используют множество инструментов для написания, пуша и слияния кода. Чем сильнее им удается автоматизировать процессы, тем лучше. Само собой разумеется, что древние инструменты будут оказывать прямое влияние на уровень производительности. Также многое решает и то, на чем ведется работа — на одном ноутбуке или еще и на дополнительном экране. Если сопоставить цены на железо с зарплатами программистов, то даже 5% роста продуктивности определенно окупит все затраты! Нужно просто предоставить команде ту аппаратуру и инструменты, которыми они предпочитают пользоваться (для аппаратуры решение должно быть индивидуальным, для инструментов — коллективным).
11) Документация в стиле «как»
В процессе обучения программированию мы все усвоили, что комментарии к коду нужно начинать добавлять как можно раньше и как можно чаще. Идея состояла в том, что лучше пусть комментариев будет слишком много, чем недостаточно. К сожалению, многие поняли это превратно и решили, что в пояснениях нуждается каждая строка. Потому-то мы имеем образчики вроде вот такого вот, из статьи Джеффа Этвуда «Код без комментариев»:
r = n / 2; // Set r to n divided by 2
// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}Вы поняли, что вообще делает это код? Вот и я ничего не понял. Проблема в том, что здесь очень много говорится о том, как все работает, но ни слова о том, зачем это нужно. Если предположить, что в программе возник баг и вы обнаружили под капотом такой фрагмент кода, он ничем бы вам не помог разобраться в ситуации.
12) Крайне сжатые сроки
Последний пункт завязан на тенденции менеджеров просить разработчиков примерно оценить, сколько времени им потребуется, затем давить на них, чтобы занизили эту оценку, а потом волшебным образом приравнивать итоговую дату к дедлайну! При этом менеджеры полагают даже, что раз уж разработчики «сами установили сроки», значит, подписались на соответствующий дедлайн и его следует считать окончательно утвержденным вариантом, который можно передавать высшему руководству.
Разработчики же считают, что подобный дедлайн — полное безумие и уложиться в него невозможно; в команде возникает разлад и никто не может сосредоточиться.
Но разве это только про разработчиков?
Если окинуть взглядом все эти 12 пунктов, можно заметить, что они, по большей части, актуальны для всех, кто задействован в проектах. Просто в случае программистов они особенно критичны, так как их работа требует глубокого погружения в процесс.
Если вы заметили, что какие-то из приведенных пунктов характерны и для вашей компании, было бы неплохо пройтись по этому списку вместе с командной разработчиков, выстроить с ними диалог, узнать, где возникают проблемы и как лучше их решать. Что бы они ни говорили, крайне важно всерьез отнестись к этой обратной связи и замечаниям. За последние тридцать в плане технологий много что поменялось, но базовый принцип командной работы остается прежним: рассуждая о производительности, необходимо учитывать человеческий фактор. Совершенствуйте рабочие процессы, обстановку, привычки команды и дайте им возможность подсказать вам, как добиться максимальной продуктивности.
