Никто не потребует от разработчика писать код без доступа к компьютеру, но многие компании считают, что они должны как-то работать, не имея возможности полностью использовать свои мыслительные способности.
И это примерно так же нереально.
Итак, давайте пройдемся по списку из двенадцати вещей, которые мешают разработчикам войти в поток и показать себя с лучшей стороны.
Я постараюсь перейти от самого важного к менее значимому.
Предлагайте свои варианты и комментарии! Если кто-то сомневается, стоит ли тратить на это деньги и силы, просто вспомните, сколько платят программистам.
Даже 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 пунктов, то заметите, что они по большей части актуальны для всех, кто участвует в проектах.Просто в случае с программистами они особенно критичны, так как их работа требует глубокого погружения в процесс.
Если вы заметили, что некоторые из вышеперечисленных пунктов характерны для вашей компании, было бы неплохо просмотреть этот список вместе с вашей командой разработчиков, построить с ними диалог, узнать, где возникают проблемы и как лучше их решить.
Что бы они ни говорили, крайне важно серьезно относиться к этим отзывам и комментариям.
За последние тридцать лет многое изменилось с точки зрения технологий, но основной принцип командной работы остался прежним: думая о производительности, необходимо учитывать человеческий фактор.
Улучшите рабочие процессы, среду и привычки вашей команды и дайте им возможность рассказать вам, как быть максимально продуктивными.
Теги: #Управление развитием #Управление проектами #Управление персоналом #Менеджмент #управление людьми #работа в команде #рабочее пространство #Человеческий фактор #Человеческий фактор #рабочая среда
-
Илья Сегалович, 1964–2013 Гг.
19 Oct, 24 -
Прототипирование Стола В Axure, Часть Вторая
19 Oct, 24 -
Как Я Создал Анализатор Запуска Spring Boot
19 Oct, 24 -
Рамблер Отвязал Номера Icq?
19 Oct, 24 -
Как Я Вел Управленческий Учет В Excel
19 Oct, 24 -
Что Будет С Социальными Сетями В 2008 Году?
19 Oct, 24
