Я уже не раз писал про менеджмент в IT, сомнительные KPI, попытки измерить работу разработчика часами и уверенность некоторых руководителей, что с появлением ИИ инженеров можно сокращать пачками.

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

Он доверяет специалисту. Тот говорит, что задача непростая, нужно разобраться с архитектурой, учесть ограничения, проверить несколько гипотез. Звучит разумно. Проходит неделя, потом вторая. На созвонах всё убедительно, человек явно разбирается в предмете, рассказывает много технически грамотных вещей.

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

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

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

Разработчики раздражаются, руководитель нервничает, а задача быстрее не движется.

Причём давайте признаем, что инженеры тоже бывают разные. Кто-то действительно упирается в сложную проблему и пытается найти нормальное решение. А кто-то прекрасно научился объяснять отсутствие результата техническими терминами. Особенно когда понимает, что собеседник не сможет проверить сказанное.

Возникает вполне практический вопрос. Как руководителю отличить одно от другого, не превращаясь в надзирателя❓

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

При этом ответственность должна быть обоюдной❕

Руководитель не обязан понимать каждую строчку кода, но должен понимать, что именно команда собирается получить к определённому сроку. А инженер не должен воспринимать любой вопрос о ходе работы как покушение на профессиональную свободу.

И всё равно остаётся неприятная часть. Можно договориться о контрольных точках, наладить коммуникацию, отказаться от микроменеджмента, а потом столкнуться с человеком, который просто не хочет нормально работать 😩

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

Интересно, как вы находите эту границу? В какой момент доверие должно смениться более пристальным контролем и как сделать это так, чтобы не испортить работу всей команды?