Это смертельно. 10 признаков того, что проект катится в пропасть

Обычный четверг, регулярная утренняя встреча. Все как обычно: спрятавшись за аватарками, коллеги говорят что-то вроде «всё ок, работаю над такой-то таской». И вроде все хорошо, стабильно, но внутренний голос говорит что что-то не так. Как будто чувствуется запах гари, но все его сознательно игнорируют.

Может быть ваш проект медленно умирает? Рассмотрим 10 косвенных признаков, по которым можно понять, что проект — кандидат на скорое закрытие.

Признак 1. Последний сеньор ушёл полгода назад, а нового так и не наняли

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

Когда опытные разработчики покидают проект — это не случайность. Это сигнал руководству: «Мы уходим, потому что понимаем, что дальше будет хуже». Сеньорам проще увидеть проблемы на горизонте раньше других. Они знают, что техдолг уже не вернуть, архитектура трещит по швам, а зарплаты заморожены на годы вперед.

Еще хуже, когда их не заменяют равноценными по опыту сотрудниками. Если вместо сеньора приходит стажёр, который «будет разбираться» — всё, ребята, расходимся. Проект перестали развивать. Его переводят на поддержку. А поддержка без развития — дорога к медленному (или не очень) угасанию.

Признак 2. Гору технического долга подпирают новыми костылями

Утро, новый спринт, новая задача на доработку какой-нибудь модалки. Вы открываете компонент и начинаете ускоренно седеть. Больше 500 строк в одном компоненте. Тесты не проходят, потому что их никто не писал. Для новой фичи нужно переписать часть логики, и есть все шансы на то, что это сломает ещё три смежных модуля.

На ретроспективе вы, как неравнодушный к проекту человек, поднимаете тему рефакторинга. Тимлид пожимает плечами: «Нет времени, нужно выкатывать фичи». И это продолжается спринт за спринтом, квартал за кварталом.

Костыли громоздятся. Логика дублируется. Скорость доставки новых фичей снижается. Править старый код до чертиков страшно.

Проект превращается в соломенный домик Ниф-Нифа. Одно неловкое движение, и всё рухнет.

Признак 3. CI/CD падает каждый день, но никто не чинит

Сборка — это лотерея. То зависимости не подтягиваются, то тесты упали, то контейнер не собрался. Каждый деплой превращается в квест, который занимает полдня.

И вместо того чтобы починить пайплайны, команда руками перезапускает их, пока те наконец не пройдут до конца.

Это не просто неудобство. Это индикатор того, что удобству процесса разработки никто не придаёт значения. Разработчики тратят время не на разработку, а на доставку. От этого сильно падает качество продукта. А когда качество падает, проект умирает. Медленно, но верно.

Признак 4. Документация не обновлялась годами

Дата обновления README.md в репозитории датируется 2021 годом. «Как запустить проект» уже не работает. «Как настроить окружение» — никто не помнит. И это полбеды. Может быть, что и в корпоративной вики все статьи последний раз редактировались людьми, которые уволились с три года назад.

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

Если в команде не заботятся о документации, значит, не заботятся о людях. А если не заботятся о людях — проект долго не протянет.

Признак 5. Заказчик постоянно меняет требования, а сроки не сдвигаются

Вы помните, как два месяца назад согласовали макет и требования. Команда сразу начала усердно работать над задачей, но спустя полтора месяца продакт говорит: «А давайте всё переделаем, потому что маркетинг передумал».

И при этом дедлайн остаётся тот же. «Ошибки в планировании? Ну вы же все понимаете, вы профессионалы, вы справитесь, ребята».

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

Если бизнес систематично не понимает, чего хочет, продукт обречён.

Признак 6. Команда перестала общаться

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

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

Это смертельный диагноз для любого дела. Что уж говорить о проекте в IT. Потому что без коммуникации нет синергии. А без синергии — только хаос.

Признак 7. Вы перестали развиваться

Вы работаете на одном и том же стеке уже третий год. React 17, Redux старой версии, Webpack, который собирает бандл вечность. Новые технологии не внедряются. Тулсет не обновляются. Все запросы на улучшение технологического стека игнорируются или отклоняются.

Мотивация развиваться угасает, ваш уровень не растёт. И пока вы стоите на месте, рынок уходит вперёд.

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

Признак 8. Самые интересные фичи отдаются на аутсорс, а команда только «поддерживает»

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

Команда разработки превращается в команду техподдержки. Правки по мелочам, багфиксы, замена текстовок.

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

Кстати, тот проект, в котором я столкнулся с такой ситуацией, закрылся через год после того как я его покинул.

Признак 9. Регулярные увольнения и кадровые перестановки под флагом «оптимизации»

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

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

Если проект востребован, в него инвестируют. Если его «оптимизируют» — его расформировывают.

Признак 10. Страшно открывать почту по утрам

Это последний признак. Очень субъективный и поэтому самый важный.

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

Работа перестала приносить удовольствие. Каждый день — преодоление себя. Каждая задача — через «не хочу, не могу, не буду».

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

Что делать, если узнал себя

Шаг 1. Честно ответьте на вопросы:

• Сколько из 10 признаков есть у вас в проекте?
• Если больше трёх — у проекта есть проблемы, которые нужно решать.
• Если больше пяти — корабль уже тонет, просто капитан не бьет тревогу.

Шаг 2. Начните обновлять резюме.
Сделайте это прямо сегодня. Обновите резюме, укажите все технологии, которыми вы владеете. Напишите про проект, даже если там всё плохо. Опишите задачи, которые приходилось решать.

Шаг 3. Начните ходить на собеседования.
Даже если не собираешься уходить. Просто ради практики и понимания рынка. Посмотри, что требуют, сколько платят, какие технологии в тренде.

Шаг 4. Сделайте выбор.
Уйти сейчас — пока еще не пахнет выгоранием, пока можно спокойно выбрать новый проект и не паниковать. Или остаться и ждать, пока проект рухнет, а потом бежать в панике. Выбор очевиден. Но делать его вам.

Желаю успехов!