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

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

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

Мне попадалось два типа людей.

1️⃣ Problem Solver

Это человек, который видит препятствие и сразу начинает думать: "Как это обойти?" Вместо того чтобы приходить к заказчику с проблемой, он приходит с несколькими вариантами решения.

Столкнулся с багом в библиотеке? Найдет workaround, напишет в issues на GitHub, посмотрит альтернативы. API сервиса упало? Предложит временное решение и запасной вариант интеграции. Дедлайн горит? Разобьет задачу на MVP и полную версию, чтобы успеть показать результат.

Problem Solver не ждет, когда кто-то решит за него. Он берет ответственность и превращает блокеры в возможности показать свою ценность. Заказчик видит: этот человек не останавливается перед трудностями.

2️⃣ Problem Creator

А вот этот тип превращает каждую мелочь в проблему. У него всегда есть причина, почему что-то не работает, но никогда нет предложений, как это исправить.

"У меня не компилируется", "Эта библиотека не подходит", "API документация непонятная", "Дизайнер дал неправильные макеты" — список бесконечен. Самое опасное: он часто прав технически, но его энергия направлена на поиск причин, почему задачу нельзя выполнить, а не на поиск способов ее выполнить.

Problem Creator переносит ответственность за решение на других. Заказчик начинает чувствовать себя вашим менеджером, который должен разбирать каждый технический нюанс. А это убивает доверие быстрее всего.

Конечно, в реальности все сложнее.

Есть скрытые Problem Creator, которые выглядят как Problem Solver. И кривая обучения может обмануть. Об этом — в следующей заметке.

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

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