Никто не станет требовать от разработчика, чтобы он писал код без доступа к компьютеру, но многие компании считают, что он каким-то образом должен работать без возможности полностью задействовать свои мыслительные возможности. А это примерно настолько же нереально.
И поэтому давайте пройдемся по списку из двенадцати вещей, которые не позволяют разработчикам войти в состояние потока и выдать максимальную продуктивность. Я постараюсь двигаться от самых ключевых вещей к менее существенным. Предлагайте свои варианты и замечания!
Если же кто-то сомневается, стоит ли тратить на это деньги и силы, достаточно вспомнить, сколько программистам платят. Даже прирост производительности в 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 пунктов, можно заметить, что они, по большей части, актуальны для всех, кто задействован в проектах. Просто в случае программистов они особенно критичны, так как их работа требует глубокого погружения в процесс.
Если вы заметили, что какие-то из приведенных пунктов характерны и для вашей компании, было бы неплохо пройтись по этому списку вместе с командной разработчиков, выстроить с ними диалог, узнать, где возникают проблемы и как лучше их решать. Что бы они ни говорили, крайне важно всерьез отнестись к этой обратной связи и замечаниям. За последние тридцать в плане технологий много что поменялось, но базовый принцип командной работы остается прежним: рассуждая о производительности, необходимо учитывать человеческий фактор. Совершенствуйте рабочие процессы, обстановку, привычки команды и дайте им возможность подсказать вам, как добиться максимальной продуктивности.
Комментарии (17)
KoldunOne
31.10.2018 09:3513. Пользователи, которые звонят и пишут напрямую программистам.
exehoo
31.10.2018 16:4714. Промежуточное звено, принятое на работу, чтобы задачи пользователей доносить до разработчика в виде ТЗ, но вместо этого изображающее «глухой телефон»
rail-ka
31.10.2018 19:59Ага, в случае бага иногда бывает легче и быстрее связаться с пользователем, столкнувшимся с багом, чем по несколько раз передавать через третье звено разные вопросы, помогающие выявить проблему, в том числе порядок действий пользователя.
Bringoff
31.10.2018 09:48+112 факторов, которые мешают работать программистам
0. Свежие статьи на хабре.
shiru8bit
31.10.2018 10:28Скажем, белый шум — жужжание кондиционера, доносящийся гул машин и грузовиков с улицы — помогает им лучше сосредоточиться.
Это всё про розовый шум.
GamePad64
31.10.2018 13:53белый шум — жужжание кондиционера, доносящийся гул машин и грузовиков с улицы — помогает им лучше сосредоточиться
У нас очень шумный офис из-за центрального кондиционирования, которое шумит как раз розовым шумом. Так вот, приходится надевать наушники, чтобы от него спрятаться, потому что два часа без них — и голова трещит.
G1yyK
Проблемы такие есть, но это не так страшно как написанно
1. Отвлекающие факторы: Тут наверное достаточно просто, шум, ходьба и тп — наушники, которые изолируют от внешнего мира, а избыточные совещания и тп — донесите до менагера — что часы проекта(списывайте часы на митинги) и он сам будет меньше вас лишний раз беспокоить.
2. Второе — это скорей всего про первый пункт.
3. Неясность — это вообще не проблема, не ясно что делать с задачей отправляйте ее тому кто ее завел и не важно дефект или фича. Лучше вернуть ее чем гадать и делать на свое усмотрение неверно(потому что как приавльно не понятно)
4. Чайки и чайки
5. Кража «лавров» — какие лавры, мы делаем один продукт, и задача разработчика решать задачи, а самоутвердится — можно на митапе выступить или в opensource
6. шум и другие отвлекающие факторы — см пункт 1.
7. Это рабочй процесс, продукт развивается и в первой версии был один функциона(скорей всего MVP), а дальше функционал наращивается.
8. см пункт 5.
9. Технический долг — это все вовласти разработчика и выстраивания процесса разработки, при решении той или иной задачи, технический олг должен закрыватся, а завести задачу на рефакторинг — никто не даст.
10. ХЗ вот тут не понятно, тут можно спорить что решает за производительность, рабочее место или проффесионализм разработчика, потому что можно оргонизовтаь работу таким образом, что тяжелые процессы можно вынести в облако и тп.
11. Это к вопросу про ясность, не понятно — задавай вопросы, возвращай на доработку.
12. Ну что значит примерно оценить, есть куча методологий оценки задачь — плюс менеджер должен риски закладывать, либо тогда вопрсы к менеджеру.
Solexid
5 пункт. Вы менеджер? Так как я был свидетелем как целые команды банально разваливались за пару недель после ОДНОЙ такой выходки.
G1yyK
нет, я не менеджер. я разработчик.
Причин что бы команда развалилась наверное было множество, а вот такая выходка послужила поводом. если человека/команду все устраивает в процесе, то они никуда так сразу не сорвутся. Программист понимает, что он делает то что не многие смогут оценить, работа есть работа. Да бывает не очень приятно
Solexid
Суть 5 пункта в том, что у человека украли из под носа его достижение, присвоив его себе, а не то что это достижение было не оценено по достоинству.
Mishootk
Да очень простая ситуация. Допустим, команда ловит долгосрочную багу в проекте, напряжена вся вертикаль в компании. Бага найдена кем-то из разработчиков, менеджер докладывается начальству, по результатам периода происходит публичная раздача благодарностей которая останавливается на уровне менеджера. Со стороны выглядит как накосячившие разрабочики и герой менеджер. Хотя по факту в прошлом именно этот менеджер мог заставить выпустить к дедлайну кривое (быстрое) решение (дважды герой).
После такого команда естественным образом отделяется от менеджера. И в зависимости от умности руководства компания расстается либо с менеджером либо с командой.