Умение обходить препятствия

Умение обходить препятствия

Одним из важных гибких навыков инженера является способность преодолевать препятствия при достижении цели. Движение по инженерной карьере предполагает постоянное развитие этого умения. Если в случае с джуном еще может быть нужно периодически спрашивать "ну как идут дела?", то с мидлом и выше ожидается, что работа либо продвигается, либо предпринимаются усилия по преодолению затыков, либо проблема сигнализируется для ее разрешения сообща. Редкий руководитель любит сюрпризы типа увидеть на ревью изменение, мало относящееся к текущему проекту, а в ответ на вопрос “а зачем мы над этим сейчас работаем?” услышать, что основное дело застопорилось, поэтому было найдено альтернативное “важное” занятие.

Одна из частых ситуаций, когда ничего не происходит, это “я им написал, а они не отвечают”. Вариаций тут много, но суть одна - инженер столкнулся с проблемой, с которой по его/ее мнению должен кто-то помочь (от соседа по столу до коллективного разума интернет-сообщества), и было написано некое сообщение, но ответа получено не было. Почему ответа не было - вариантов много. Сообщение могло быть послано не тому человеку, в сообщении мог не быть сформулирован вопрос (так что адресат вообще не понял, что его о чем-то спрашивают), могла не быть ясно описана срочность вопроса, вопросы могли быть написаны так мутно, что адресат не понял о чем речь, но боится признаться, и т.д. Такие ситуации надо разбирать и помочь человеку отрефлексировать, что пошло не так.

Другой типичная картинка с выставки, это когда Петя думает, что он ждет Колю, а Коля думает, что он ждет Петю, и они тихо ждут друг друга, пока техлид команды не прервет их ожидание неприятными вопросами. Как правило такие прохлопы случаются, когда состоялись переговоры или совещание и стороны думают, что пришли к соглашению, но дальнейшие шаги и действия не были зафиксированы письменно, поэтому Петя подумал свое, а Коля свое. При этом обоим оказалось комфортно находиться в этом состоянии - зуда “что же дальше?” ни у кого не возникло.

Вообще, к молодым специалистам с “чесоткой”, которые рано демонстрируют умение достигать цели, стоит присматриваться внимательно и привлекать их в команду. Таких ребят среда со временем всегда поднимает на лидерские роли, но на начальных этапах им могут быть нужны поддержка и защита. Например, они, как правило, нетерпимо относятся к статусу кво и хотят все переделать, что может стать причиной конфликтов в команде, если не направить усилия в конструктивное русло. При этом в инженерном деле важен оптимум сочетания упорядоченности и хаоса - в команде должны быть люди обоих типов, ведь необычные решения часто возникают вне привычных парадигм.

Очень важно, чтобы достигать результата человек мог экологично. Если в случае возникновения проблем человек немедленно ставит на уши всю команду, чтобы получить помощь, отвлекая других, хотя задача может быть решена самостоятельно, то возникает вопрос о ценности этого инженера. Разумеется, есть срочные ситуации, когда аврал является правильным выбором и есть несрочные ситуации, когда один вопрос к правильному человеку может сэкономить неделю исследований. Я больше говорю об общем ощущении, когда задача решается за счет других и в ущерб общему выхлопу команды. В своей команде надо стремиться иметь людей, которые достигают результата и при этом являются ориентиром, а не помехой для других. От токсичных, пусть даже и продуктивных специалистов, надо избавляться.

Кстати, agile подходы к разработке ПО имеют целью в том числе скорое выявление ситуаций, когда чьи-то задачи заблокированы. Большинство из них в своем арсенале имеют ежедневные standup совещания-летучки, на которых все это может быть обнаружено. Это работает, но все же следует стремиться к самостоятельности людей, чтобы ленинский прищур “расскажи, что делал, что собираешься делать” был не обязателен.