Сегодня хочу поделиться публикацией Есимхана Жалелова и Паши Злобина про справочник на проекте.

Раньше на проектах мы использовали «Карточку проекта» в виде докса, но его постоянно забывали пополнять (нужно было много текста писать). А чем дольше проект шёл, тем сложнее становилось разбираться что и где находится.

Так Паша Злобин придумал сделать Google Sheet документ, в котором просто добавлял все рабочие документы, относящиеся к проекту. Если что-то надо, заходит в него, нажимает Ctrl+F и быстро находит необходимый документ со ссылкой. В этом же доксе он добавляет важную информацию о проекте.

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

У нас бывают ситуации, когда на стороне клиента появляется человек, который начинает управлять командой в ручном режиме. Эдакий микроменеджмент. Это нормальный стиль управления для России и стран СНГ. Появился он из-за низкой квалификации специалистов, когда управленцу приходится собой закрывать дыры в проекте, чтоб не случилась катастрофа.

Что делать?
Микроменеджмент появляется тогда, когда управленец не уверен в качестве команды, которая взялась за проект. То есть он принимает решение выделить свои ресурсы (время, деньги) на присмотр за командой, а не на другие управленческие задачи.

Решается только одним способом — этот управленец должен начать доверять команде. Чем больше ошибок на проекте будет, тем больше будет подкрепления, что микроменеджмент это правильно, и он спас проект, заметив эту ошибку. Любая ошибка на проекте рушит доверие между командой и клиентом.

Со стороны команды, такой микроменеджмент сильно нервирует. Но единственный путь — это повысить доверие со стороны клиента.

При работе с подопечными у меня есть принцип: никогда не пропускать слабые решения. Этот принцип позволяет всем в команде показывать сильную работу перед клиентом.

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

Слабое решение — это когда ты делаешь работу, чтоб её сделать (потому что так заведено), а не потому что это приносит пользу компании или клиенту. Это когда ты принимаешь решение, и не можешь объяснить почему ты это решение принял («я так вижу»). Когда даешь гипотезу, которая не основана ни на цифрах, фактах или твоём опыте.

Принятие слабой работы имеет последствия:
+ для сотрудника (он перестает развиваться);
+ для руководителя (он снижает планку для будущих решений);
+ для агентства и клиентов (общее качество решений будет ухудшаться, а не наоборот).

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

Если слабое решение прошло, и все это поняли, то это нужно разбирать как факап руководителя.

Тут важно понимать, что сильное решение ≠ идеальное решение. Сильное решение — это решение, которое решило проблему и создало пользу. Это может быть табличка собранная на коленке, но которая показывает как проблему можно решить. Чем меньше ресурсов задействуется — тем лучше.

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