AWS>но по удаленке как?!

Поясню свои идеи.

Руководитель дает задания? Да
Он понимает примерную сложность задания? Да
Он может видеть результат работы работника? Да
Он может поговорить с ним текстом, по телефону или видео? Да
Он может знать, какие проблемы или плюсы дает код того или иного участника? Да
Он может видеть переписку по делу в командном форуме или ином месте где фиксируются групповые обсуждения? Да

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

Если есть какие-то подозрения, то всегда есть возможность какого-то одного работаника заставить писать отчеты хотя бы на месяц, если уж совсем не понятно, что там происходит. И всегда есть возможность поговорить касаемо технических моментов работника и попутно незаметно узнать за сколько он это делал, сколько примерно потратил времени и т.п. Главное — чтобы это не выглядело как допрос или обвинение в чем-то.

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

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

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

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

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

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

Поэтому я писал «скорей да чем нет».

deleted