Job Safety Driven Development: когда незаменимость вредит IT-проекту

Внимание - Job Safety Driven Development!⛔⛔⛔ Кому хорошо быть незаменимым.

Руководитель проектов должен быть готов ко всему. Но сейчас поговорим о ситуации, к которой сложно быть готовым, и тем более сложно принять сам факт возникновения такой ситуации на проекте. Добро пожаловать в теорию “серого” фреймворка Job Safety Driven Development.

Вчера мы говорили о техническом долге и разбирали объективные причины, по которым он мог возникнуть. А есть еще причины субъективные.

Job Safety Driven Development (JSDD) — это концепция, которая не имеет формального определения в мире разработки, но на практике она проявляется как поведение, когда разработчики или агентства намеренно усложняют код или процессы, чтобы сохранить свою незаменимость в проекте. В условиях конкуренции и страха потерять работу, такая практика может кому то показаться разумной, но на деле она приносит больше вреда, чем пользы, как для команды/сотрудника, так и для компании.
JSDD можно охарактеризовать как набор практик, которые усложняют поддержание и развитие кода с целью сохранения рабочих мест разработчиков или агентств. В реальных проектах это проявляется через:

‼❌Создание сложных и запутанных архитектур: внедрение архитектурных решений, которые на первый взгляд могут показаться инновационными, но на деле делают проект зависимым от одного или нескольких разработчиков.
‼❌Отсутствие документации и стандартизации: разработчики, практикующие JSDD, часто избегают написания документации или делают её минимальной. Это усложняет поддержание кода другими членами команды.
‼❌Монополизация знаний: когда разработчик или команда намеренно не делится знаниями, это создает барьер для других, что усиливает зависимость от них.
‼❌Затягивание сроков и скрытая сложность: внешне простые задачи начинают занимать больше времени, чем необходимо, часто из-за «невидимой» сложности, которую добавляют разработчики.

Почему мы об этом говорим?

Job Safety Driven Development — это реальная угроза для устойчивого развития проекта. Зависимость от конкретного разработчика/команды разработки может привести к тому, что компании придется принимать любые условия сотрудничества.

Сильный IT-специалист никогда не будет заниматься не очень правильной историей, потому что в этой профессии важно развиваться, а JSDD будет этому мешать. А вот у агентств иногда просто нет выбора. А еще бывает, что техническая команда достигает предела своей компетенции и просто не может в этом признаться. И получаются ситуации, когда вас иногда подталкивают к принятию архитектурных решений, которые повлекут за собой зависимость от агентства. Как то раз я имела неосторожность наблюдать со стороны за такой ситуацией и была неприятно удивлена. Я считаю, что к разработке стоит все-таки подходить гибко.

Как распознать JSDD со стороны агентства-разработчика? Есть несколько явных признаков:

⚡Если агентство не предоставляет полную и понятную документацию, это тревожный сигнал. Документация должна быть детальной, описывать ключевые решения, архитектуру, и быть доступной для всех участников проекта.

⚡Если код кажется излишне сложным без объективной необходимости, это может быть попыткой агентства сделать проект зависимым от их услуг.

⚡Если агентство активно избегает вовлечения вашей команды в ключевые решения или делится минимальной информацией, это признак JSDD.

⚡Если сроки постоянно срываются, а агентство объясняет это сложностью проекта, при этом не предлагая прозрачных решений для ускорения, это может свидетельствовать о намеренном создании «невидимой» сложности.

Что вы думаете о таком явлении? Сталкивались ли с ним в вашей работе и как справлялись? Мне кажется, каждому будет что подумать на этот счет.

#it #digital #projectmanagement