Как я могу управлять кем-то близко, но все же изящно?

Кажется очевидным, что вашей команде нужна лучшая методология разработки. Однако микроуправление вряд ли принесет вам желаемые результаты. Умные люди (которыми, как правило, и являются разработчики) ненавидят микроуправление и готовы бороться с вами на каждом шагу.

Я бы предложил позаимствовать страницу (или две) из методов разработки Scrum/agile. В частности, есть по крайней мере пара вещей, которые могут помочь в вашей ситуации:

1. Начните проводить ежедневные встречи со своей командой. Держите их относительно рано (скажем, в 9:30 утра, если люди обычно приходят около 9:00), и делайте их быстрыми и по теме. Каждый член команды должен сказать: 1) над чем он работал/достиг в течение предыдущего дня, 2) над чем он будет работать сегодня и 3) есть ли какие-либо препятствия, мешающие ему выполнять свои задачи. Это не должно занимать более 10-15 минут каждый день, и проведение этих собраний позволит вам увидеть, что прогресс отстает еще до того, как истечет целая неделя. И они дадут вам больше информации о том, почему именно прогресс отстает.

2. Пусть все заинтересованные стороны/«свиньи» посещают все встречи, связанные с бизнесом/требованиями. Недостаточно привести только лидера команды ; он не единственный, кто заинтересован в проекте. И не только в отношении проблем, которые вы выделили, но и потому, что чем больше разработчиков вы привлечете к этим обсуждениям, тем выше вероятность того, что вы 1) получите точную оценку объема каждого требования и 2) поймете любые проблемы или неточности в требования до того, как они превратятся в серьезные проблемы. Вы также, конечно же, решаете проблему тимлида, не передающего требования команде.

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

Например, почему он несет ответственность за личное рассмотрение всех результатов (под которыми, как я полагаю, вы подразумеваете «исходный код»)? Почему бы не сделать так, чтобы ваша система контроля версий отправляла автоматическое электронное письмо с обзором кода всякий раз, когда вносится изменение, всей команде и не возлагала бы на всю команду ответственность за проверку кода и качество?

И почему нет бэклога проекта или другой структуры, доступной для всех членов команды и содержащей соответствующие варианты использования в ясном и легком для понимания формате? Вы ожидаете, что руководитель группы поймет, запомнит и сообщит обо всем этом помимо всего остального, что он пытается сделать (и если бы у вас был центральный репозиторий для этой информации, у вас было бы легко опровергнуть команду — замечание лида «какие бизнес-сценарии?»). Таким образом, вы действительно должны винить только себя, если что-то начинает идти наперекосяк. Человеческий мозг — одно из худших решений проблемы хранения больших объемов информации точно и в течение длительного времени.

И почему у команды нет четкого определения «выполнено», включающего «ни одна задача не будет выполнена, пока любой связанный код не будет покрыт модульными/веб/интеграционными/какими бы то ни было тестами»?

Итак, я думаю, что у вас есть ряд проблем с процессом, которые, возможно, усугубляются некоторыми неправильными управленческими решениями (передача всего на руководство группы, не вовлечение всей команды на собрания, относящиеся к проекту, и т. д.). Более плохой менеджмент в форме микроуправления руководителем группы вряд ли решит проблему. Вместо этого исправьте проблемы с процессом.

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

Ваш руководитель поручил вам контролировать вашего коллегу, что в данном случае означает, что ваш коллега передает результаты приемлемым для вас способом. Это ваша прерогатива — отклонить те из его результатов, которые находятся в неприемлемой форме, и передать вопрос о его отказе от сотрудничества вашему руководителю. Я предлагаю вам агрессивно использовать эту прерогативу, потому что любая работа, которую он не сделает, в конечном итоге окажется в ваших руках. Без свободного времени.

Объясните коллеге то, что он должен знать. Если он этого не знает, четко дайте ему понять, что то, что он знает или не знает о том, что он должен знать, - это его проблема, а не ваша. Что вам все равно, как и когда он это выучит, лишь бы он это знал, и он это знает, и своевременно использует то, что знает.

Объясните своему коллеге, что он должен делать. Если он должен тестировать бизнес-сценарии, то он должен это делать. Дайте ему понять, что отталкивать вас от ответственности — НЕ вариант.

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

Дополнительный комментарий от @HLGEM: «Поскольку этот парень работает на другого работодателя, я бы позаботился о том, чтобы его босс у его работодателя был скопирован в электронных письмах, обсуждающих проблемы с производительностью».