Soft skills. Проактивность. Часть I.

Есть ощущение, что дать строгое определение «проактивности» вообще невозможно. Практический каждый более менее серьезный источник пытается придумать что-то свое. Стивен Кови (да, тот самый, который написал «7 навыков высокоэффективных людей», по мне как любая мотивационная херня – херня), пытался определить через кружки (влияния, забот и прочее) и их расширение. Часто встречается объяснение «от противного» - реактивное/пассивное поведение. Но в целом это все крутится вокруг набора свойств «предлагать идеи, видеть решения, нести ответственность».

Вопрос, а надо ли давать точное определение? Мы все на кончиках пальцев примерно понимаем, что такое проактивность. Я вот всегда представлял себе проактивного сотрудника как чувака с шилом жопе. А сейчас, когда сел писать текст, возникла проблема с приведением интуитивного к словам. Но я попробую.

Моя позиция в том, что проактивность – это комбинация 2 умений и 2 условий.

Умения

👉распознать слабые места. Команды, проекта, идеи, цели, не важно. Вы должны уметь ориентироваться в причинах и последствиях того, что происходит сейчас, что может произойти в будущем.

Вот простой пример. ПРОСТОЙ ТО ЕСТЬ ОЧЕВИДНЫЙ. Он специально простой, чтобы было понятно, а не чтобы кто-то написал «ебать да это и так очевидно». Ваша команда пишет говнокод. Может не каждый разработчик в отдельности, но общее решение принимает окончательный вид говна. Прямо сейчас все хорошо, задачки в джире двигаются, бизнес доволен, начальство тоже. Но с каждым новым витком вести продукт становится все более и более сложным. Предвидеть это уже определенная стадия проактивности.

👉предлагать решения вместе с достижимыми путями их реализации.

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

Условия.

👉Направленность на повышение общего результата. Пожалуй, если мы говорим про команду разработки, то это самое важное.

Ты научился сам писать нормальный код – ок, красавчик. Научился сам и научил коллег – вот тебе медалька «самый проактивный мозгоёб»

👉Оптимальность. Я сначала хотел завязаться на нетривиальность решения, но оптимальные решения часто лежат на поверхности. Путь достижения должен быть оптимальным.

Отойдем от примера с говнокодом. Если у Вас цель увеличить урожай картошки на 10%, то «высадить на 10% больше картошки» будет реактивным решением. Оно не оптимально просто по причине того, что каждая следующая итерация этого решения будет все более и более сложной. Оптимальное решение несет в себе
1️⃣или признаки улучшения количества через улучшение качества – вывести новый сорт картошки, который при схожих или меньших затратах будет производить больший урожай.
2️⃣или должно выводить команду сразу на другой уровень. Не знаю, захватить Беларусь, например. Тут уж кому что больше по характеру подходит.

Продолжение следует. По фасту…

#медведьразмышляет #softskills