Мотивация. Фактор 2: Задачи, обязанности и отчет о результатах
«Сделай так, чтобы было хорошо». Увы, такую постановку приходится слышать довольно часто. Конечно, всем хочется, чтобы было хорошо, но никто не любит, когда сверху даются непонятные задачи.
Какой должна быть понятная задача
Какой уровень декомпозиции и «разжевывания» нужен конкретному сотруднику? Ответ определяется спустя некоторое время после начала вашего взаимодействия. Кому-то достаточно «Сверстать вот этот макет, требования по ссылке», кому-то нужно подробное описание с измерениями вплоть до пикселя.
В целом, задача:
1. должна быть зафиксированной.
Брать в работу словесное описание фичи — себе во вред. У любой задачи должно быть согласованные и зафиксированные требования. Фиксировать задачи можно как угодно: корпоративная почта, таск-трекер, описание в корпоративной вики. Также задачи должны быть сохранены, потому что по ним новые сотрудники смогут понять, во что ввязались.
2. должна быть понятной конкретному исполнителю.
Чем понятней и проще вы опишете задачи, тем проще ему будет сориентироваться и вовремя задать вопросы. Если вы не являетесь единственным руководителем (например, в матричной системе у сотрудника есть проектный руководитель и функциональный), то задача должна быть также понятна его другим руководителям. Задача должна быть снабжена всеми необходимыми материалами: описанием API, техническим заданием/брифом, дизайном и т.д. (набор может отличаться для разных компаний и для разных типов задач).
3. должна обладать приоритетом.
Для любой задачи нужно определить ее место в очереди к разработчику:
— «Бросай все и делай новую» — критические баги и блокеры,
— «Закончи текущую задачу и делай новую» — несрочные баги и задачи, которые по каким-то причинам нужно сделать как можно скорей, но не за счет текущей, уже начатой задачи,
— «Закончи всю запланированную работу и делай новую» — задача ставится в конец очереди.
4. должна быть измеримой.
Для задач на дизайн и разработку измерителем является факт максимальной схожести результата работы с запросом. Дизайн-макет должен решать задачи бизнеса, верстка должна быть реализована строго по макету, бэкенд должен выполнять свои функции. Даже для исследовательских задач есть измерение результата: отчет, решение о (не)использовании того или иного стека/технологии, техническое решение. По сути дела у каждой задачи должна быть своеобразная веха: если сделано вот это, это и это, то задача может считаться завершенной:
— Увеличение скорости загрузки страницы на 30%,
— Передача эксплуатации не менее 50% старого оборудования,
— Решить, можно ли использовать [название технологии] или нет, и почему.
Я написал задачу. Что дальше?
Прежде чем браться за работу, сотруднику не мешало бы ознакомиться со всем содержимым задачи. В обязанности сотрудника как исполнителя входит не только «сделать как сказали», но и предупредить о возможных проблемах еще до начала работы. Важно объяснить команде: чем больше вопросов, комментариев и уточнений будет перед началом работы, тем меньше придется переделывать и перепридумывать на ходу.
И как теперь сотруднику отчитаться?
Демонстрация дизайн-макета, код на ревью, техническое решение, отчет — это все формы отчетности по задаче. В разработке при этом главным признаком завершения работы над задачей является ее релиз.
Если задача не предусматривает релиза, то нужно вспомнить, что вы посчитали признаком завершения задачи:
— Скорость загрузки удалось увеличить на 25%, есть предположения насчет дальнейшей оптимизации,
— Передали 70 машин, это примерно 54% старого оборудования,
— Указанную библиотеку использовать не рекомендуется, так как разработчики анонсировали возможное прекращение ее поддержки. Предлагаю использовать [название технологии].
Постановка задач, их изменения и прием результатов должны быть максимально прозрачными, чтобы у сотрудник понимал связь между своими задачами и обратной связью, которую он получает. Запомните несколько простых правил. помните, что никто не умеет читать мысли — ни дизайнеры, ни разработчики, ни админы. Поэтому чем прозрачней и понятней будут задачи сотрудников, тем меньше придется переделывать на ходу, и тем проще вам самим будет принимать результаты их работы.
Источник: https://zen.yandex.ru/media/