Учитывая величину зарплат в ИТ, рабочее время программиста должно быть на вес золота. Именно поэтому некоторые работодатели пытаются как-то контролировать процесс решения IT-задач при помощи различных современных решений. Однако большинство айтишников скажет вам, что эффективно работать больше четырех часов в день невозможно. И будут совершенно правы — вместо того, чтобы навязывать контролирующие приложения и устройства специалисту, стоит подумать о том, как нарастить его производительность. Сегодня я предлагаю вам необычную тему — как повысить продуктивность сотрудников в ИТ.
Создать рабочие условия
Чем меньше в компании разработчиков, тем чаще их будут дергать и отвлекать от работы, вовлекать в совещания и таскать на встречи с клиентами. Однако такая рабочая стратегия губительна для программиста: обычно айтишник глубоко погружается в процесс, и ему сложно быстро выключиться, а потом так же быстро включиться обратно в тему. От бесконечных перерывов только нарастает внутреннее раздражение, а продуктивность, разумеется, падает, иногда до нуля.
Что с этим можно сделать? Все просто: переносите все совещания и планерки на утро, а для созвонов и встреч с клиентами выделите отдельный день недели, если не получится — то хотя бы половину, причем это должна быть первая половина дня. И тогда айтишнику будет проще погрузиться в настоящую работу. И, если у вас в компании нет проджект-менеджера, то самое время нанять человека, который будет собирать обратную связь от клиента, копить и перерабатывать ее, а потом разом выдавать специалисту переваренную информацию.
Окружающая обстановка
В офисе многих программистов можно заметить сидящими в наушниках. Это не потому, что они такие меломаны или музыка помогает лучше сосредоточиться. Просто окружающий офисный шум настолько бесит, что из двух зол выбирают наименьшее.
Что уж говорить про коллег, бегающих взад-вперед с кофе и шоколадками. Особенно раздражают менеджеры, которые любят заглядывать через плечо в монитор. Поэтому в идеале у программиста должен быть отдельный кабинет, а если бюджет не позволяет — то отделенное от основной суеты пространство. Это очень поможет повысить продуктивность программиста.
Кстати, о менеджерах
К сожалению, не все проджект-менеджеры одинаково хороши. Лучшие из них ведут проекты как положено: берут весь удар от клиента на себя, контролируют весь рабочий процесс, требуют обоснования очередных правок, позволяя программисту спокойно работать и творить великие дела. Однако есть и чайки-менеджеры, которые прилетают раз в полчаса, клюют разработчика в затылок и улетают. Уже к середине дня от бесконечной долбежки голова начинает болеть так, что становится слегка не до работы. Многие айтишники после такого просто выпадают из состояния потока на день, а иногда сразу на несколько. Теперь представьте, что такое происходит регулярно. А отдельные индивидуумы очень любят бесконечно организовывать внезапные совещания и брейн-штормы, ломая не только график, но и сознание специалиста. Не менее неприятен вариант, регулярно требующий от программистов отчетов (в идеале в письменном виде).
Здесь решение простое: ищите только хороших проджект-менеджеров). И пусть я буду Капитаном Очевидность — при найме тщательно изучите человека, которого берете на должность проджекта. Иначе он вам сломает весь рабочий процесс.
Плохое ТЗ
Нет ничего хуже для программиста, чем неясно составленное техническое задание. А неясно составлено оно почти всегда. Рассмотрим самые популярные сценарии:
- У клиента ничего не работает/все сломалось. Совершенно непонятно, в чем сложность сделать скриншот или записать видео, как проявляет себя баг. Причем ситуация повторяется из раза в раз, что в конце концов начинает невероятно бесить. Чтобы починить поломку, ее надо сначала обнаружить, но менеджеры отчего-то это не понимают.
- Недостаточно информации для начала работы. Опытный проджект, обговаривая на встрече детали ТЗ, обязательно сразу запросит все необходимые данные/доступы для того, чтобы программист мог незамедлительно приступить к выполнению задачи. Как показывает практика, опытных проджектов в ИТ не так чтобы много — из-за этого работа затягивается на недели. ТЗ поступает к айтишнику, айтишник матерится, в очередной раз запрашивая нужные данные, проджект пытается вытрясти информацию из клиента, а клиент не дает, мотивируя это соображениями безопасности, и так по кругу. Если бы проджект на встрече пояснил, что нужно будет то и то, или же сразу бы обратился с этим вопросом к специалисту, то а) дело бы двигалось быстрее; б) клиенты, категорически не желающие давать доступы, отсеивались бы на начальном этапе.
- Отсутствие в ТЗ четких требований и приоритетов. В результате программист сам себе режиссер: самостоятельно определяет, с чего начать, в каком порядке работать, как это будет выглядеть. А потом приходит умный менеджер и говорит, что клиент вообще хотел не то и не так, а конкретный функционал должен быть готов к завтрашнему утру. И никого не парит, что ты потратил время на решение другой, более важной, на твой взгляд, задачи из ТЗ.
- Бесконечное расширение ТЗ. Из-за отсутствия конкретных договоренностей проект бесконечно растет и видоизменяется. В связи с этим много времени тратится на промежуточные решения, которые в результате оказываются не нужны.
Конечно, программист справится со всеми этими моментами, и будет, как попугай, постоянно повторять менеджерам: надо запросить это, надо уточнить, надо. Но беда в том, что с такой стратегией повышенной продуктивности вам не добиться, скорее, наоборот. А главное, что важные для компании сроки придется в очередной раз отодвигать.
Дедлайны
Нет ничего хуже в ИТ, чем четкие сроки, особенно измеренные в часах. В отрасли часто возникают ситуации, когда программист берется за легкую с виду задачу, и тут всплывает какой-нибудь интересный момент, и часовая задача превращается в сточасовую. Этот момент решается просто — составлением юридически грамотного договора, где не будет никаких нереальных обещаний, связанных со сроками, а также правильной работой все того же проджекта.
P.S. Самый нелюбимый вопрос у многих айтишников — а сколько это будет часов? Особенно на том этапе, когда ТЗ еще нет.
Из статьи может показаться, что программисты будто требуют к себе особенного отношения, так как перечисленные проблемы довольно распространены и в других отраслях. На самом деле сами айтишники обычно не жалуются ни на что: они либо просто хуже работают, либо переходят в те компании, где им обеспечат должные условия. Кроме того, работа у них сама по себе такая, что требует глубокого погружения и детального подхода. Поэтому рассматривайте полученную информацию просто как хороший способ повысить продуктивность своих айтишников, а уж использовать ее как руководство к действию или нет, решать только вам.