Меня зовут Андрей Глушко. Я менеджер ИТ проектов, занимаюсь менторством, прошёл путь от разработчика до руководителя, в своих подходах опираюсь в первую очередь на людей, а потом уже на практики.
Сегодня я хочу поделиться своим подходом в постановке задачи для сотрудника.
На своём опыте я понял, что необходимо найти баланс между вовлечением сотрудника в цели компании и его собственными целями. Поэтому для себя я определил, что важно уметь ставить задачи таким образом, чтобы это затягивало сотрудника в предметную область его позиции и, он осознавал зачем выполняется эта задача в целях бизнеса.
Про цели компании
Для начала я стараюсь выяснить насколько необходимо вовлекать сотрудника в цели проекта или компании. Рассмотрим несколько вариантов:
Если это внештатный сотрудник, с которым я не собираюсь в дальнейшем работать, то постановка задачи в виде инструкций, на мой взгляд, будет самым подходящим вариантом. Нет необходимости создавать дополнительные встречи для обсуждения, чтобы объяснить, как конкретная задача ложится в роадмап фирмы. Я хочу просто получить результат от исполнителя.
Если это внештатный сотрудник на тестовом задании. В таком случае, я уже стараюсь начать вовлекать потенциального сотрудника в дела фирмы, и чтобы он мог принимать самостоятельные решения в случае вопросов, а не постоянно бегать ко мне за уточнениями.
Другая ситуация, если это штатный сотрудник. Здесь для меня уже вопрос стоит не в том вовлекать ли сотрудника или нет. В данном случае я оцениваю сколько ему нужно дать информации о целях фирмы, чтобы он мог комфортно осознавать и брать ответственность за свою задачу.
Про постановку задачи
После того как мне стала ясна необходимость и степень вовлечения, для развития высокой лояльности сотрудников в фирме, я определяю детальность постановки задачи. Согласитесь, можно сказать в виде инструкций “Пётр, нам нужно поставить ‘конкретный сервис кеширования’ применив техники ‘техника_1’ и ‘техника_2’”. По сути, таким образом, я забираю у сотрудника мотивацию и желание проявлять инициативность. Однако, бывает и такое, что сотрудник пока что новичок, и если я ему доверю много ответственности, перенеся на его плечи решения по выбору конкретных технологий и методик исполнения вашей задачи, то высок шанс, что он провалит исполнение задачи. Поэтому я делаю следующее:
Определяю насколько развиты hard skills исполнителя. Если это senior, который много повидал и который разбирается в системе компании, будет проще ему делегировать анализ и выбор конкретных решений. И я ставлю задачу в виде бизнес цели, которую необходимо достичь.
Опираюсь на зоны ответственности между мной и исполнителем. Независимо от того, насколько у сотрудника сильные hard skills, я стараюсь следить за тем, чтобы не перекладывать на него ту часть ответственности, которая лежит на мне. Ведь если я менеджер проекта, то переносить на программиста обязательство выбора бизнес направлений для решения задачи будет демотивирующим для него. Поэтому я придерживаюсь стратегии дать сотруднику выбор, но при этом не перегрузить его этим выбором. Как следствие, я стараюсь показать ему какие есть рамки бизнес требований, которые необходимо соблюсти при выполнении задач уже на техническом уровне.
Про ресурсы проекта
Заключительным, но не менее важное - я выставляю ресурсные ожидания по выполнению задачи. Как это не печально, но все задания и таски могут быть не выполнены в срок, шанс этого всегда присутствует. Здесь представляется принципиальным для меня, опять же, не перекладывать на сотрудника ответственность за потраченные ресурсы компании. Поэтому я если я знаю, что задача срочная, то времени проводить дополнительные митинги для брейншторма просто нет, и я их не провожу. Как итог, выдаю задачу в виде инструкций. С другой стороны, если я понимаю, что на данный момент у команды есть время и что в случае провала задачи проект не будет на грани, то я уже составляю задачу в более вовлеченной форме для сотрудника.
Подводя итог
На основе моих рассуждений, я создал некоторую классификацию видов постановки задачи для сотрудника, в зависимости от уровня его вовлеченности в бизнесовую часть фирмы:
На уровне бизнес проблемы: “Клиентам важно понимать насколько наше приложение надёжное” Сотрудник, как решение этой проблемы, может внедрить monitoring систему, и он сам принимает решения о выборе способа закрытия проблемы.
На уровне бизнес цели: “Мы хотим показать клиентам, что наше приложение надёжное. Это можно сделать через uptime/downtime метрики. {Дальше даются бизнес требования}” Сотрудник уже лучше осознаёт в каком направлении двигаться и как этого можно добиться.
На уровне цели исполнителя: “Мы решили, что мы должны ввести uptime/downtime метрики, чтобы клиент лучше понимал насколько у нас надёжное приложение” За сотрудника решили, что конкретно необходимо сделать, на нём остаётся выбор какими инструментами этого он сможет достичь.
На уровне инструкций для исполнителя: “Нам нужно ввести monitoring system для расчёта метрик uptime/downtime для нашего приложения. Мы будем имплементировать собственное решение, а не использовать сторонние сервисы. Используй nodejs и чтобы логи шли в elasticsearch, а графики строились через библиотеку chartjs” Тут мало остаётся пространства для самого сотрудника, но и этот вариант подходит в некоторых ситуациях.
Эти виды постановки задачи можно представить в виде простого графика: чем больше сотрудник вовлечён в бизнес, тем меньше ему необходимо детализировать задачу
На этом у меня все. Буду рад обратной связи!
