12 разрушающих факторов Девелопера

04.05.2020
Posted in blog-article
04.05.2020 admin

12 разрушающих факторов Девелопера

Как сохранить своему разработчику ясную голову

Топ-12 Вещей, Которые Разрушают Производительность Разработчиков

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

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

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

Перед вами перечень из 12 факторов, не позволяющих вашим разработчикам «войти в материал» и быть продуктивными. Я выстроил список в порядке убывания, начав с наиболее опасных и распространенных вредителей. Не стесняйтесь оставлять комментарии под статьёй!

1) Перерывы и встречи

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

Как насчет встреч? Единственное различие между встречей и внезапным перерывом заключается в том, что встреча является запланированной паузой, а потому снижает продуктивность сильнее, чем обычный перерыв. Разработчики не могут спокойно решать задачу, когда знают, что им придётся прерваться в середине работы. Если встреча запланирована на 13 или 14 часов, будьте готовы мысленно вычеркнуть день, поскольку решение большинства инженерных задач требует большего времени при полной концентрации сотрудника.

2) Микроуправление

Разработчики микропредприятий обладают самой низкой производительностью. Причина этого заключается в чрезмерно тесной производственной связи с менеджером.

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

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

3) Vagueness/Неопределённость

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

Другой разновидностью неопределённости является неясная спецификация на функцию. В этом случае разработчики начнут реализовывать то, что им кажется правильным. Если в результате выяснится, что требовались иные действия, им придётся снова начинать с нуля.

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

4) Менеджер — «чайка»

Вы когда-нибудь слышали об этом явлении? Возможно, нет, но вы могли его наблюдать в собственной компании. Оно возникает, когда менеджеры полностью не вовлечены в работу, но время от времени налетают разом на все задачи. «Это неправильно, и это, и это выглядит плохо» – говорят они перед тем, как снова «улететь».

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

5) Кредит Жадности

У вас когда-нибудь был менеджер или другой разработчик, который забирал все заслуги за работу, которую вы проделали в последние недели? Прежде всего, разработчики ценят компетентность. Выдавая «кредит», позволяя кому-то презентовать свою работу, они признают превосходство компетентности этого сотрудника над собственным уровнем. Также они чувствуют, когда человек бесправно и алчно присваивает чужие заслуги.

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

6) Environment? — Noises, Motion, Workspace Design…/ Окружающая среда? – Шум, движение, обстановка.

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

Аналогично, если рабочее пространство спроектировано так, чтобы разработчику приходилось совершать как можно больше движений, это не поможет ему сосредоточиться. Также неприятно, если монитор компьютера развёрнут в сторону менеджера или сам сотрудник оказывается у него «как на ладони». В таком случае приходится прикладывать больше усилий, чтобы сосредоточиться. Кроме того, повышается вероятность быть прерванным в самый неподходящий момент.

7) Creepiness Объема/Креповость/Ползучесть объема

Ползучесть объема (также известная как «ползучесть фокуса», «ползучесть требования», «ползучесть характеристики» и «синдром кухонной раковины») в управлении проектом относится к бесконтрольным изменениям в его объеме. Это может произойти, если рабочая область не определена, не задокументирована или не контролируется.

Scope creep («область ползучести») превращает относительно простые запросы в ужасно сложных и трудоемких монстров. Чаще всего это происходит во время разработки. Продемонстрирую этот процесс на примере простой функции.

Вариант 1 (до внедрения): функция «Показать на карте расположение».

Версия 2 (для версии 1, почти завершен): функция меняется на «Показать 3D карту местности».

Вариант 3 (для версии 2, почти завершен): характеристика снова меняется на «Показать 3D карту местности, которая позволяет пользователю пролететь через…».

8) Процесс определения продукта

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

9) Отсутствие учета технического долга

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

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

10) Современное техническое оснащение

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

«Древние» инструменты обладают скудными возможностями и заставляют совершать действия, от которых избавлены пользователи современных программ. Даже если улучшенное оборудование повысит производительность сотрудников всего на 5%, ваша компания ощутит существенный прирост прибыли! Просто дайте разработчикам те инструменты и оборудование, с которыми они предпочитают взаимодействовать.

11) Запутанная документация

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

К сожалению, многие программисты неправильно интерпретируют этот совет. Они предполагают, что им требуется создавать построчное описание кода, поэтому нередко мы наблюдаем следующую картину (пример от Джеффа Этвуда из поста “Кодирование без комментариев”):

r = n / 2; / / Установить r на n, разделенный на 2

// Loop while r — (n/r) больше t while (abs (r — (n/ r)) > t) {r = 0.5 * (r + (n/r) ); // Set r к половине r + (n / r

}

Вы хоть представляете, что делает этот код? Я тоже не представляю. Проблема в том, что обилие комментариев, описывающих действия, не сопровождается описанием причин, по которым эти действия совершаются. Если бы в программе была ошибка, и вы наткнулись на этот код, вы бы не знали, с чего начать.

12) Невероятно сжатые сроки

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

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

Разве перечисленные факторы важны только для разработчиков?

Если вы посмотрите на все 12 пунктов, то заметите, что они значимы и для большинства других проектов-заданий. Тем не менее, именно разработчики для продвижения своих задач нуждаются в особенно глубоком фокусе. То, что для других исполнителей остается «желательным», для разработчиков является необходимой базой.

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

И хотя сегодняшние технологии сильно отличаются от тех, что были 30 лет назад, урок остаётся актуальным: при рассмотрении производительности команды нельзя игнорировать человеческий фактор. Создайте для своих сотрудников удобное рабочее место, уделите внимание их привычкам и потребностям, и тогда они смогут достичь наивысших результатов, а вы – собрать щедрый урожай в виде прибыли и качественных проектов!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Contact

Давайте работать вместе!

Пишите нам и найдем точки соприкосновения, может станем партнерами, а может поможем вам зайти в нашу чудесную нишу

Вы разработчик?

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

Новичок?

Поможем быстро войти в нишу, не тратя годы на понимание

Давно в нише?

Рады будем пообщаться как на темы whitehat, так и blackhat тематики ^_^ + всегда есть что обсудить по поводу рекламных сетей

ПИШИ В TELEGRAM!

Contact