Наблюдается большой хайп вокруг ИТ-сферы и вакансий. Всех вокруг привлекают высокие зарплаты, интересные проекты, да и в принципе растущая диджитализация повседневных вещей. Так хочется прикоснуться к о-великой-айтишечке, некоторые даже кардинально меняют свою сферу деятельности. А все ли так радужно (если это слово еще не запрещено) в ИТ, как оно кажется?
Хочу рассказать про 6 проблемных мест, с которыми сталкаивается каждый разработчик. Речь пойдет, преимущественно, о компаниях, размерность которых больше 100 человек :)
Переработки
Довольно частая ситуация среди моих знакомых - "В 6 вечера я только начинаю работать". Когда целый день созвоны, уведомления в стиле "Наташа, мы все уронили", каждый второй пуляет вопросы в чат - часто происходит, что среди запланированных на день задач к концу рабочего дня нет ни одной в статусе "Done". И, чтобы не копить хвосты - начинаются переработки.
Это "лечится" (хотя, скорее - временно заклеивается пластырем) с помощью честной системы отгулов: переработал - отгулял. Но накопительный итог очень стремный, поэтому зрелые команды стараются снизить количество переработок, а менеджеры - никогда не планировать время спринта "впритык", закладывая буст на непредвиденные разговоры, встречи, починку критов и т.д.
Поздние релизы и ночные подъемы
Релиз продукта - наверное, самый главный момент всего спринта. Все, что так бережно разрабатывалось, тестировалось и правилось - теперь необходимо довезти до пользователя. И есть в этом прекрасном процессе один минус. В продуктах, где в стандартное рабочее время высокая нагрузка на сервисы - катиться приходится во время спада активности, т.е. в вечернее и ночное время. Иначе ваше "непоправимое улучшение" может в самый пик работы пользователей удачно положить прод.
А если что-то пошло не так в ночное время и SRE опускают лапки, потому что проблема не на их стороне - то разработчик должен быть на связи, чтобы залезть в код и поправить ошибку.
Сроки ради сроков
Свежий кейс.
Сверху пришел срок: "9 сентября - готовый редизайн модуля такого-то. Будем презентовать нашим продажникам и начнем включать обновление в маркетинговую кампанию".
Сказано - взято. Но что-то пошло не так, и в срок мы не уложились (вылезло много багов, связанных с преездом на новую технологию, что не было учтено при первчиной оценке).
Со всеми доработками и исправлениями - мы таки выкатили фичу, но в ноябре. И знаете, что произошло? Ничего. Никто не умер, продажи не встали, продукт не испортили. Хотя, нет - метрики после редизайна упали, но это совсем другая история.
Мы бежали к сроку, как ослик к болтающейся морковке, но не понимали почему нам надо именно к этой дате. Что по итогу:
- 2 разработчика ушли сразу после "презентации функционала" продажникам (завершив свою огромную часть задач);
- до сих пор разбираем баги из-за неверно перенесенной в новый редизайн логики.
Какой можно сделать вывод?
Сроки - это, конечно, нужно. Особенно это нужно, когда компания страдает финансово - мы теряем деньги, или нам срочно надо добыть новых клиентов и мы точно уверены, что новая фича нам в этом поможет (я, естественно, говорю про метрики и посчитанную финансовую выгоду).
Есть еще одна проблема, которая порождается сроками. Когда нужно "быстро", иногда принимается решение сделать костыльно, а потом, обязательно, в рамках технического долга - сделать как надо.
Тут я разделяю взгляды Станислава Елисеева (основателя комании Userstory):
"..подгоны под даты релизов создают технический долг, обслуживание которого требует дополнительных ресурсов. Рынок всегда заставит бежать быстрее, чем команда сможет писать качественный код."
Непонятные требования
Неполные, неактуальные, противоречивые - давайте все это называть просто "плохие требования".
Некоторым разработчикам вообще не нужны требования: они часто закладывают в оценку реализации, в том числе, время на аналитику, спокойно разбираются в продуктовой и бизнесовой стороне вопроса, делают маппинги данных при необходимости, и не испытывают попаболи по этому поводу. Но корпоративная культура многим привила привычку - "без требований - к задаче не приступим". С одной стороны - это хорошо, так как чем больше выявить и запроектировать на этапе анализа, тем меньше потом переписывания кода будет. Но с другой - удлинняется цикл разработки даже самой мелкой фичи и требуется действительно отдельная роль, которая будет заниматься написанием требований.
Если отдельной роли бизнес-аналитика - нет, то очень часто требования либо отсутствуют вовсе, либо не имеют всей необходимой информации по юзер сторис, техническим особенностям, краевым условиям.
Много источников информации и время на административку
Один из грехов корпоративного ИТ - это большое количество каналов с поступающей информацией: Jira, Outlook/Gmail, RocketChat/Slack, Skype, Telegram. Когда со всех сторон "идет обстрел" - приходится часто переключаться. А если часто переключаться - то сложно погрузиться в задачку, требующую большого объема мыслетоплива. Поэтому, многие сознательно игнорируют (ну ладно, фильтруют) поступающую информацию.
Как бороться с этим хаосом?
а) Выделять четкое время на проверку почты. Для всего срочного - есть мастеркард каналы asap в ваших мессенджерах.
б) Выключить нотификации малоинформативных чатов, удалиться из чатов, которые несут совсем низкую ценность.
Выгорание
Почему разработчики выгорают?
Монотонная работа в конце-концов съедает жаркий пыл разработчиков. Если страсть пропадает - то нападет уныние и тоска, и иногда даже повышение уровня зарплаты не поможет. Вышеупомянутые дедлайны истощают нервную систему. В особо массово-депрессивные периоды увеличивается текучка.
С выгоранием рано или поздно сталкивается каждый разработчик - иногда и не по одному разу. На Хабре найдено 707 статей по запросу "Выгорание" (за 5 минут - стало 708). Такое количество, с одной стороны - пугает, а с другой - в самих статьях и в комментариях уже есть рабочие инструменты, как с этим справиться. Более того, часто руководство/HRteam идет навстречу, предлагая во время выгораний приходить не с "оффером", а подумать над решением в рамках текущей компании. Часто помогает смена команды, выступление на конференциях, постановка целей развития, денежная "морковка", банально - физическая смена кабинета/места (на удаленке с этим, конечно, сложнее).
А иногда попрощаться - самое правильное решение и для компании, и для сотрудника.
А че хорошего-то?
А хз.
Это вы мне скажите :)