Deep Dive #1: Problem Solver vs. Problem Creator (2/3)

Вчера мы разобрали два типа людей: Problem Solver и Problem Creator. Казалось бы, все просто — будь первым, избегай второго.

Но реальность сложнее. Сегодня разберем нюансы, которые меняют всю картину.

Скрытый Problem Creator

Самый коварный вариант — это замаскированный Problem Creator, который на первый взгляд выглядит как Problem Solver. Он создает тикеты в Jira, инициирует созвоны, пишет длинные сообщения в Slack с детальным анализом проблемы. Со стороны кажется, что человек занят делом и проявляет инициативу.

Но если присмотреться — за всей этой активностью нет конкретного движения к решению. Вместо того чтобы взять API документацию и разобраться самому, он созывает встречу на час, чтобы обсудить "как лучше подступиться". Вместо того чтобы написать workaround за 20 минут, он открывает issue на GitHub и ждет ответа разработчиков библиотеки. Вместо того чтобы протестировать два подхода, он запрашивает мнение у трех коллег.

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

Кривая обучения имеет значение

Но вот в чем подвох: не каждый Problem Creator — это проблема характера. Часто это вопрос опыта и погруженности в проект.

Джуниор-разработчик, который только присоединился к проекту, объективно не может быть Problem Solver в первый месяц. Ему не хватает контекста: он не знает, где лежат логи, как устроена архитектура, кто отвечает за какую часть системы. Любая задача для него — это минное поле, где каждое решение может привести к новым проблемам.

То же самое с человеком, который переключился на незнакомый стек технологий. Опытный React-разработчик, впервые столкнувшийся с NestJS, будет какое-то время генерировать больше вопросов, чем ответов. Это нормальная кривая обучения.

Ключевое отличие — динамика. Если через месяц-два человек все еще приходит с теми же типами проблем, не растет в автономности и продолжает перекладывать ответственность — это уже не про опыт, а про подход к работе.

Поэтому важно наблюдать: как быстро человек трансформируется из Problem Creator в Problem Solver? Если долго и упорно создаются проблемы без прогресса — это точно повод задуматься.

Но это еще не все. Завтра выйдет статья, которая поможет научиться отслеживать, когда мы Problem Solver, а когда превращаемся в Problem Creator и как применить это знание на практике.

—

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

🧘 Точка останова #deep_dive

__ В этом посте были ссылки, но мы их удалили по правилам Сетки