Никто не ждет от программиста, что он сделает свою работу, не используя компьютер. Но при этом многие компании ожидают, что он сделает свою работу, не имея возможности спокойно подумать. Это одинаково невозможно.
Давайте же обратимся к нашему списку из 12 факторов, которые не дают вашим программистам работать в комфортных условиях и быть продуктивными. Я постараюсь расположить их по степени влияния: от наиболее важных к менее важным.
Если вы сомневаетесь в том, стоит ли это вашего внимания и инвестиций, то просто подумайте о зарплатах разработчиков. Увеличение продуктивности даже на 10% — это ОЧЕНЬ много.
1) Небольшие паузы и планёрки
Я считаю, что паузы снижают продуктивность программистов больше всего. Разработчику не так то просто снова вернуться к тому, над чем он работал до того, как его прервали. Ему нужно снова настроиться, а потом медленно проследить свою мысль до места, где он остановился. Это легко может занять более получаса. А чем больше таких пауз, тем меньше желания работать, тем ниже качество кода и тем больше багов.
“Чем больше вы мешаете мне в начале работы, тем больше перерывы между моими попытками, чтобы продолжить. Если вы будете прерывать мою работу всё утро, не удивляйтесь, что весь мой день будет непродуктивным”. Разработчик на Reddit
А что насчет планёрок? Они отличаются от пауз только тем, что они запланированы заранее, что только ухудшает ситуацию. Программист не может нормально выполнять задание, когда он знает, что скоро ему придется прерваться. Поэтому, если у них в ближайшие час-два будет планёрка, они не смогут продвинуться в решении задачи, так как большинство из них занимают гораздо больше времени.
Как писал Пол Грэм: “Одна-единственная планёрка может разрушить целый день, разделив его на две части, каждая из которых слишком мала, чтобы сделать что-то сложное.”
Как этого избежать? Это уже давно известно — никак. Старайтесь проводить такие планёрки в самом начале дня или, например, прямо перед обедом, чтобы избежать ненужных пауз в течение дня.
2) Придирчивые менеджеры
Среди всех типов менеджеров именно придирчивые больше всего снижают продуктивность программистов. Да, придирчивые менеджеры обычно проводят больше планёрок и чаще отвлекают программистов от работы, но дело не только в этом. Они чаще выказывают недоверие разработчикам, которые постоянно чувствуют, что их навыки и способность решить поставленную задачу ставятся под сомнение. Это уничтожает всю мотивацию у разработчиков. Кроме того, придирчивый менеджер может стать главной причиной, по которой программист захочет уйти или, по крайней мере, перейти в другую команду.
3) Неопределённость задач
Есть множество примеров такой неопределённости. Отчет об ошибке в духе “Это не работает, почини!” не содержит достаточной информации, с которой может работать программист. Кстати, в этом случае могут помочь шаблоны отчетов об ошибке.
Или же неясное описание задачи, из-за чего разработчики начинают делать то, что считают правильным. А потом им приходится начинать всё сначала, после того, как менеджер подробнее описал суть задачи.
Неясная расстановка приоритетов относится сюда же. При отсутствии четко расставленных приоритетов, разработчик будет тратить время, думая над тем, правильно ли он расставил приоритеты в работе. А если ещё он слышит вопрос от менеджера, почему он работает именно над этой задачей (хотя приоритеты так и не были обозначены)… Ну, вы поняли — желание работать падает.
4) “Чайка-менеджмент”
Слышали когда-нибудь о таком? Это когда менеджеры вообще никак не вовлечены в работу, но… они просто иногда налетают, чтобы всё обгадить. “Это неправильно, это тоже, а это выглядит плохо”, и т.д., а потом снова улетают. Должен признать, мне нравится, как удачно подобран образ, но, к сожалению, такое происходит намного чаще, чем нам бы хотелось. Такое поведение очень мешает работать программистам.
5) Жадность до похвалы
Вы когда-нибудь встречали менеджера или разработчика, который присваивал себе все заслуги за работу, которую вы делали последние несколько недель? Разработчики ценят компетентность выше всего. Если вы присваиваете чьи-то заслуги, то вы присваиваете себе компетентность, одновременно забирая её у коллеги. Этот фактор находится достаточно высоко в списке, потому что, по моему мнению, он создаёт напряженность в коллективе, которая на некоторое время напрочь убивает продуктивность команды.
6) Окружение — шум, движение, планировка рабочего пространства…
Это может показаться странным для тех, кто не работает программистом, но окружение, в котором работает разработчик, очень сильно влияет на его работу. Небольшой белый шум, например, шум проезжающих за окном машин и грузовиков, помогает программистам лучше сосредоточиться. Поэтому многие из нас работают в наушниках! Я недавно открыл для себя RainyMood. Это действительно круто!
Также, если рабочее место устроено так, что вокруг постоянно кто-то ходит, это очень мешает сосредоточиться. Или если экраны компьютеров стоят так, чтобы их постоянно мог видеть менеджер… Ну, это только добавляет лишнего стресса и увеличивает вероятность того, что вас прервут во время работы.
7) Расползание рамок
Расползанием рамок в менеджменте называются неконтролируемые изменения в рамках проекта. Это происходит, когда рамки неясно определены, или никто за этим не следит.
Такое расползание превращает простые просьбы в ужасно сложные и времязатратные задачи! И чаще всего это происходит уже в процессе разработки! Например:
Версия 1 (до начала разработки): запрос: “Покажите карту местности”
Версия 2 (когда версия 1 уже почти завершена): запрос: “Покажите 3D-карту местности”
Версия 3 (когда версия 2 уже почти завершена): запрос снова меняется на “Покажите 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 факторов, они весьма применимы и к некоторым другим профессиям. Просто влияние всех этих факторов более важно для разработчиков, так как им нужна полная концентрация для того, чтобы выполнять свою работу.
Если вы узнали в некоторых моментах, описанных в статье, свою компанию, возможно, вам будет интересно пообщаться со своими программистами. Поговорите с ними, узнайте, есть ли какие-то проблемы и как их можно решить. Что бы они ни сказали, очень важно верить их мнению и отзывам. И хотя нынешние технологии очень отличаются от тех, что были 30 лет назад, суть осталась всё той же. Думая о продуктивности, никогда нельзя забывать о человеческом факторе. Обсудите со своей командой рабочий процесс, привычки и окружение и позвольте им объяснить вам, как достичь наилучшей продуктивности и эффективности.
Перевод статьи John Lafleur: Top 12 Things That Destroy Developer Productivity
