День 2532. #ЗаметкиНаПолях
Технический Долг — Миф, Созданный Плохими Менеджерами. Окончание
Начало
Продолжение 1
Продолжение 2

Когда инженерам нужно брать на себя ответственность
Как инженеры, мы должны брать на себя ответственность за своё дело. Нам необходимо:
- Действительно проверять код, а не просто одобрять пул-реквест, не глядя;
- Давать и получать обратную связь как профессионалы;
- Инвестировать в обучение и развитие;
- Просить о помощи, когда мы застряли;
- Отказывать ужасному коду в пул-реквестах, даже если неудобно перед коллегами;
- Устанавливать и поддерживать стандарты в команде.
Если вы одобрили пул-реквест, не прочитав его, вы несёте ответственность за этот код. Если вы написали небрежный код, потому что вам было лень, это ваша вина. Если вы совершаете одни и те же ошибки в течение пяти лет и отказываетесь учиться, проблема в вас.

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

Так как же это называть?
Вместо «технического долга» попробуйте следующие варианты:
- «Технические последствия прошлых бизнес-решений» — многословно, но точно. Это позволяет сохранить ответственность там, где ей место.
- «Затраты на обслуживание» — в каждом коде есть свои затраты. Они растут со временем. Заложите их в «бюджет».
- «Сдвиг контекста» — то, что имело смысл два года назад, сейчас не имеет смысла. Это нормально.
- «Необходимый рефакторинг» — ПО развивается. Рефакторинг — это нормально. Перестаньте относиться к нему как к наказанию.
- «Стоимость обучения» — вы не знали, что то, что вы создавали, будет успешным. Теперь знаете. Пора оптимизировать.

Итого
Технический долг — миф не потому, что коротких путей не существует. Это миф, потому что метафора искажена до неузнаваемости. Он стал способом для менеджеров:
- Обвинять инженеров в бизнес-решениях;
- Избегать ответственности за распределение ресурсов;
- Рассматривать нормальную эволюцию ПО как халатность;
- Уклоняться от ответственности за невыполнимые сроки.

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

Если вы менеджер, читающий это, и вы когда-либо жаловались на технический долг, спросите себя: дали ли вы своей команде время и ресурсы, чтобы сделать это «правильно»? Знали ли вы вообще, что значит «правильно»? Или вы просто хотели, чтобы это было выпущено?

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

А если вам будут возражать и будут настаивать, что это «долг», который вы «заимствовали»…
Начните проходить собеседования. Потому что вы работаете на человека, который не понимает разработку ПО и всегда будет винить вас, когда возникнут трудности.

Источник: https://dev.to/adamthedeveloper/technical-debt-is-a-myth-created-by-bad-managers-2l3k