«Подключишься на созвон? Ну и что, что он уже пятый!»; «Доделай за коллегой, там немного осталось»; «ТЗ нет, но сделать надо хорошо». Узнали у экспертов, какие фразы и поручения способны довести сотрудников IT-отделов до белого каления на рабочем месте.
Раздражает создавать и упорядочивать документацию. В процессе бывает сложно перевести знания в голове на человеческий язык. Я понимаю, что это упрощает работу и делать документацию нужно, но заставить себя приступить — тяжело. Без удовольствия работаю с перезапуском тестов и проверками pull request. Это может продолжаться часами (и днями!). Мы часто встречаемся с различными инфраструктурными проблемами. Чем динамичнее проект, тем нестабильнее staging-окружение.
Рефакторить или разбираться в очень старом коде тоже неприятно. Особенно если он написан на фреймворке JS, а привычнее работать с TS или на jQuery. Основная сложность в таких ситуациях — понять, как все работает. Умственной энергии тратится много, а результат чаще всего минимальный.
Наконец, раздражает сведение версий библиотек. Они бывают несовместимы друг с другом. Еще хуже, если нужная библиотека написана на ранних версиях TS или React. В итоге процесс превращается в танец с бубном и лотерею с непредсказуемым исходом.
Членов моей команды раздражает разработка функционала, которая зависит от API внутренних сервисов заказчика, при том что самого API еще нет. Приходится строить архитектуру вслепую: появляется большой риск, что финальная версия этого API не такая, как изначально оговаривалось. Тогда приходится быстро все переделывать.
Однозначно раздражают заказчики, которые не понимают своих целей и не могут оценить итоговый результат. Когда резко меняются требования в задаче — тоже мало удовольствия. Вызывает недовольство монотонная работа, необходимость разрабатывать фронтенд, когда бэкенд не готов, использовать старые технологии и методики.
Иногда коллеги понимают, какое решение будет лучшим, но жесткие сроки и обстоятельства вынуждают придумывать «костыли». Многим не нравится работать над чужим кодом без документации — или когда ее чересчур много, — а еще раздражает отсутствие на проекте тимлида, к которому можно обратиться в случае чего.
Очень раздражает дедлайн «ко вчера». Внезапные срочные задачи сказываются на качестве работы по другим проектам, давят морально и выбивают из колеи.
Сложно бывает взаимодействовать с плохо оптимизированной рабочей средой и постоянными багами. В таких случаях остальные задачи отходят на второй план, а это срыв дедлайнов, переработки и дополнительное напряжение.
Настоящая боль — неинформативные технические задания без деталей. Стабильно раз в неделю прилетает задача с описанием в несколько слов. Приходится разыгрывать допрос и тратить время на кучу уточнений. Раздражают и долгие ответы от заказчиков. Из-за них задачи, на которые ушло бы пять секунд, растягиваются на недели. При этом еще приходится постоянно напоминать о себе. Работать с однотипными рутинными поручениями тоже не доставляет удовольствия.
Многие менеджеры делают одинаковые ошибки при постановке задач для исполнителей. Часто они не понимают, к каким последствиям и проблемам это приводит. Например, задание чересчур объемное, без четких границ и критериев выполнения. По сути менеджер перекладывает свою ответственность на исполнителя: «Что-нибудь придумают, и оно заработает». Разработчик может просто не понять, хватит ли у него навыков его выполнить. В итоге из-за страха ошибки исполнитель будет откладывать работу или потратит время на уточнение деталей.
Бывает и так, что задачу отдают на доработку не тому исполнителю. Классический пример: во время тестирования не заметили ошибки в разработке и их нужно исправить. Если эту задачу ставят стороннему разработчику, ему придется сначала вникнуть в чужое решение — опять трата времени. Раздражает, когда меняется задача, которая уже в работе или почти выполнена. Из-за этого возникает впечатление, что коллеги из продуктовой команды сами не знают, какой нужен результат.
В последнюю очередь программисты приступают к задачам, где приходится работать с устаревшими технологиями или поддерживать код, написанный другими специалистами. Сжатые сроки по задачам выливаются в стресс и усталость, из-за этого разработчики чаще ошибаются.
Как программист в прошлом и человек, активно сотрудничающий с айтишниками в настоящем, могу выделить два типа раздражающих задач.
Меньше всего нравятся задачи, выполнение которых кажется нецелесообразным. Например, программист закончил большой проект, а продакт-менеджер просит изменить шрифт в заголовке и поменять местами блоки данных. Айтишнику может казаться, что это выдумки менеджеров без какой-либо полезной нагрузки. Чаще всего он не знает, зачем вообще нужно такое изменение. Снимает раздражение, когда менеджер поясняет, что таким образом интерфейс приложения адаптируется к пользовательским привычкам.
Еще — когда в задаче есть противоречия, устранить их некому, а ответственные кивают друг на друга. Это демотивирует, лишает сил и отдаляет результат. Сюда же — неполная информация по задаче, когда в процессе программист выясняет, что ему показали только одну часть проблемы, а на самом деле их очень много.
Самое раздражающее — долгие согласования. Сейчас все автоматизируется, но без живых обсуждений не обойтись.
Много ресурса уходит на обработку IT-новостей. Быть в курсе всех нововведений — моя прямая обязанность. Например, в 2022 году вступил в силу закон о рекламе: теперь все креативы необходимо маркировать и передавать эти данные оператору рекламных данных. Если не разбираться в этом вопросе, у компании не получится обеспечить прозрачное сотрудничество с партнерами. Это отнимает энергию — важно знать, как любые нововведения могут повлиять на работу компании, какую пользу из них можно извлечь, как отредактировать внутренние процессы.
Иногда очень не хочется заполнять отчетные таблицы: сверять результаты, вносить исправления и проводить аналитику. Это рутина, а мне в IT больше нравятся нестандартные задачи.
Даже неприятные поручения не будут влиять на работоспособность, если поменять отношение к ним. Когда такие задачи действительно помогают процессам и делают результат лучше — это самое главное.
IT-специалисты считают повторяющиеся или рутинные задачи самой скучной частью своей работы. Например, обновление или резервное копирование данных занимает время, но это важно для безопасности системы.
Еще один источник разочарования — легко решаемые обращения пользователей в службу поддержки. Консультирование утомляет и отнимает время, которое можно было бы потратить на более сложные и интересные проекты.
Медленно обычно идет работа с документацией и другими административными задачами: обновление технических руководств, заполнение отчетов об инцидентах. Это тоже рутина, но она важна для поддержания базы знаний и правильной реакции на инцидент или проблему.
Я работаю инженером поддержки — исправляю ошибки в работе приложений, обеспечиваю уровень доступа для пользователей. Исправляю баги и пишу баг-репорты, тестирую и отслеживаю состояние систем, создаю документацию, а также занимаюсь улучшениями сервиса и обучением новых инженеров.
В моей работе есть как приятные моменты, так и рутина, от которой невозможно избавиться. Например, постоянно менять пароли из-за политики безопасности. Без этого аккаунт вылетает из всех систем, нужно заново входить в учетные записи через двойную аутентификацию. Невероятно раздражает вводить пароли вручную — в некоторых случаях это обязательная процедура.
Самое скучное в моей работе — это межпроектная рутина: когда один проект уже сдан, а новый еще не начался. Это время уходит на развитие внутренних решений и задачи по смежным направлениями.
Техническая поддержка для меня — особый вид мазохизма. Очень демотивирует, когда есть запал создавать что-то новое, а приходится разбирать инциденты, согласовывать мелкие доработки и готовить кипу закрывающей документации. Без подобной работы не обойтись: за созданием сервиса неизменно следует его поддержка, а менеджер — единственный человек, который управляет знаниями проекта, владеет бизнесовой и технической составляющей.
Всех менеджеров раздражает, когда заказчик утверждает техническое задание, а потом выясняется, что со стороны клиента его никто даже не смотрел. Тогда начинается переписывание функционала под новые требования. Если речь идет о небольшом портале или мобильном приложении, это доставляет минимальный дискомфорт. Когда вы разработали огромную комплексную информационную систему, и теперь ее приходится переделывать — конечно, это раздражает всю команду.
Что касается разработчиков — чаще всего они не любят задачи по развертыванию сайтов, установке и настройке приложений. Особенно если процесс не автоматизирован, а фичи и модули по каким-то причинам не работают или несовместимы. Мало кому нравится настраивать рабочее окружение при переходе на новый проект, вносить изменения в архитектуру легаси-проектов, планировать трудозатраты на них.
Айтишники часто откладывают задачи с неочевидными сроками, результатами или процессом реализации. Например, изучение возможности внедрения новой технологии или интеграции со сторонним API.
