Ответ
Да, систематическая нереализация задач по вине коллег является сильным демотивирующим фактором в разработке. Это приводит к:
1. Эмоциональным и профессиональным последствиям:
- Выученная беспомощность: Ощущение, что собственные усилия не влияют на результат.
- Профессиональный застой: Невозможность освоить новые технологии или завершить значимые проекты.
- Выгорание: Постоянный стресс от срывов сроков и накопления невыполненных обязательств.
2. Практические проблемы для команды:
- Срыв сроков и нарушение обязательств перед заказчиком.
- Накопление технического долга из-за незавершённых или костыльных решений.
- Токсичная атмосфера взаимных обвинений.
Технические и процессные методы минимизации проблемы:
-
Чёткая декомпозиция и определение зависимостей:
// Плохо: Неявная и полная блокировка public void deployFeature() { waitForDBApiFromTeamB(); // Блокер. Когда? Где статус? // ... наша логика } // Лучше: Изоляция зависимости и асинхронная обработка public void startFeatureDeployment() { FeatureDependency dependency = getDependencyStatus(); // Проверяем статус if (dependency.isReady()) { proceedWithDeployment(); } else { scheduleRetryOrNotify(dependency); // Чёткое действие при блокировке } } -
Использование инструментов: Явное выставление блокеров (blockers) в тикетах (Jira, GitHub Issues), использование Definition of Ready (DoR).
-
Коммуникация: Регулярные sync-митинги по межкомандным зависимостям, обсуждение блокеров на daily stand-up и retrospective.
-
Архитектурные решения: Проектирование слабо связанных (loosely coupled) модулей и использование асинхронных взаимодействий (очереди сообщений, события).
Ключевой вывод: Проблема часто кроется не в людях, а в процессах. Её нужно решать на уровне организации workflow, коммуникации и архитектуры, переводя из области личной ответственности в область управляемых процессов.
Ответ 18+ 🔞
А, ну это же классика, блядь! Сидишь ты, такой, весь в белом, архитектуру продумал, код пишешь, а потом — пиздец! — оказывается, что твоя супер-фича упёрлась рогом в какого-нибудь левого коллегу, который про твой тикет и не слышал, или в другую команду, которая твой API в свой бэклог засунула так глубоко, что хуй достанешь.
И вот ты уже не разработчик, а какая-то мартышлюшка в клетке, которая бегает по кругу: «Ну когда? Ну что там?». А в ответ — тишина, блядь. И чувствуешь себя полным мудаком, потому что обещал, планировал, а нихуя не сделал. И не потому что ленивый, а потому что тебя заперли в этой ебаной зависимости.
И знаешь, что самое пиздатое? Это не просто «ой, неприятно». Это тебя нахуй ломает изнутри!
Во-первых, мозг ебёт. Развивается эта самая, как её… «выученная беспомощность», ёпта. Ты начинаешь думать: «А нахуя я пашу, если всё равно упрусь в стену?». Мотивация — ноль ебать. Хочется просто в монитор плевать.
Во-вторых, скиллы проёбываешь. Вместо того чтобы новый фреймворк освоить или сложную задачу решить, ты месяц тратишь на пинг-понг в почте: «Добрый день! Напомните, пожалуйста, о статусе…». Профессиональный рост? Да хуй там! Топчешься на месте, как конь под окном.
И для команды — сплошной пиздец. Сроки горят, заказчик орет, а технический долг растёт, как грибы после дождя, потому что приходится костыли лепить, лишь бы хоть что-то показать. Атмосфера становится такой, что все друг на друга косо смотрят. Токсичная, блядь, жопа, а не работа.
Но орать «все пидарасы!» — это не метод, хотя и приятно. Надо головой думать, э бошка!
Первое — не создавай себе эти грабли. Смотри на код:
// Вот это — прямой путь в ад. Сиди и жди, как лох.
public void deployFeature() {
waitForDBApiFromTeamB(); // А TeamB про тебя уже забыли. Жди до второго пришествия.
// ... наша логика
}
// А вот так — уже с мозгами. Изолировал проблему.
public void startFeatureDeployment() {
FeatureDependency dependency = getDependencyStatus(); // Чётко проверил статус.
if (dependency.isReady()) {
proceedWithDeployment(); // О, готово? Работаем!
} else {
scheduleRetryOrNotify(dependency); // Не готово? Не молчи! Запланируй повтор или оруби всех.
}
}Второе — используй инструменты, они для чего? Выставляй в тикете BLOCKER жирным шрифтом, чтоб аж глаза слепило. Требуй Definition of Ready (DoR) перед тем, как задачу в работу брать. Если от тебя что-то нужно другим — пиши тикет им, а не себе в заметки.
Третье — коммуникация, ёпта. Не стесняйся на стендапе орать: «Я заблокирован Васькой из команды Б!». Тащи это на ретро. Делай отдельные синки по зависимостям. Пусть всем будет стыдно, но зато понятно.
И главное — архитектура. Старайся делать так, чтобы модули друг за друга не цеплялись, как пьяные в подъезде. Асинхронные взаимодействия, очереди сообщений — это твои друзья. Сделал событие — отправил в очередь — и похуй, когда его обработают. Ты свою часть работы сделал.
Короче, вывод-то какой? Проблема обычно не в том, что все вокруг идиоты (хотя иногда очень хочется так думать). Проблема в кривых процессах. Задачу нужно вытаскивать из тёмного угла личных разборок и превращать в управляемый, видимый для всех блокер. Тогда и орать меньше придётся, и делать больше. Ну, в теории, по крайней мере.