Иди туда - не знаю куда, принеси то - не знаю что — Часть 3
Как правильно принять задачу у исполнителя?
Завершая серию об управлении задачами обязательно надо упомянуть о том, что делать, когда задача возвращается к постановщику с радостным сообщением “Готово!”. Часто встречаю ситуацию, когда по истечении длительного времени в результатах обнаруживаются дефекты. Было бы очень несмотрительно думать, что это вина исполнителя. В первую очередь, это вина постановщика, который не потрудился проверить результаты.
Раздумывая, как лучше всего обсудить тему, решил, что проще всего отталкиваться от ошибок, которые допускаются при приемке. Все нижеследующее, разумеется, основано не только на наблюдениях, но и на собственном опыте ошибок.
Рассматривая типичные ошибки я сознательно не касаюсь аспектов, которые больше связаны с работой с людьми, чем с работой с задачами. Совершенно очевидно, что гораздо полезнее возвращать задачу с дефектами исполнителю, а не переделывать за ним. Также элементарно надо благодарить за результаты, даже если они с недочетами. И разумеется, по итогам приемки надо оценить итоговое качество и сделать выводы об исполнителе.
Если это всем понятно, то займемся менее тривиальными вещами. Итак, что мы делаем неправильно?
Слепая приемка
Постановщик (для простоты снова предположим, что это менеджер - руководитель команды) - тоже сотрудник компании, работающий в потоке задач. Это означает, что ему тоже иногда будет не хватать времени уделить достаточно внимания приемке. Часто у него в голове возникает мысль: ну, раз это сделал Вася, все должно быть хорошо - он же профи!
Не забывайте, что любой исполнитель - человек и имеет право на ошибку. Ваша ответственность - убедиться, что все действительно сделано верно и полностью. В конце концов, именно с Вас в итоге буду требовать бескомпромиссное качество!
Приемка с опозданием
Если у Вас есть письменная постановка и письменный отчет, это прекрасно, потому что приемка тогда можно провести когда угодно - все детали прописаны. Но не следует забывать, что откладывая приемку Вы создаете риск: может потребоваться больше времени на доработки результата, потому что когда Вы соизволите сообщить исполнителю о найденных дефектах, он будет погружен во что-нибудь другое. Ему элементарно потребуется время, чтобы вспомнить, о чем речь.
Процесс пойдет значительно быстрее, если Вы сможете выдавать обратную связь почти моментально (например, в тот же день, когда сдана задача). Конечно, это несколько утопично, но стремиться к такому идеалу стоит.
Ошибочные критерии приемки
Одна из основных аксиом менеджера: Задача может считаться принятой, если она соответствует заданным критериям качества. Критерии эти задаются на трех уровнях:
- Внешние стандарты
Например, стандарты делопроизводства для документов или стандарты HTML кода от W3C - Корпоративные стандарты
Например, фирменные бланки и шаблоны (опять же, для документов) или контрольные списки для проверки качества визуального дизайн-макетов - Исходная постановка задачи
Она, в частности, может содержать и отклонения от вышеназванных стандартов
Наиболее частая ошибка: игнорирование чего-либо из этого списка. Особенно часто, как ни странно, игнорируется исходная постановка. Особенно это проявляется, когда задачу принимает не тот, кто ее ставил (не такая уж и редкость). Руководствоваться собственными представлениями о результате вместо того, что реально требовалось от исполнителя, некорректно. Даже если Вы обнаружили ошибку в постановке, правильнее извиниться перед исполнителем, чем обвинять в недобросовестности.
Разный уровень щепетильности для разных типов задач
Людям часто кажется, что сложные задачи надо принимать внимательно, а простые - быстро. Это тоже создает риск, потому что, по сути, сложность задачи не имеет значения. И оплошность, допущенная при приемке просто задачи, может создать большие проблемы “ниже по течению”. Это особенно актуально для проектов веб-разработки, где результаты каждого предыдущего этапа являются исходными материалами для следующего. Следует иметь как метод проверки качества дизайна, так и метод проверки качества Технического задания, а также метод оценки качества всего проекта.
Приемка 98%
Задача должна быть выполнена на 100%. Даже если сделано 98%, это означает, что задача не выполнена. Здесь проще всего объяснить примерами:
- Если программист разработал функциональность на локальной версии веб-сайта, а Вы ее протестировали на той же локальной версии и убедились, что работает правильно, это не означает, что работа выполнена. И любой клиент, который не увидит функциональность на рабочей версии сайта, легко Вам это объяснит.
- Если дизайнер нарисовал макет и даже положил его в правильную папку на сервере, но назвал файл “final_design.psd”, то любой верстальщик будет прав, когда скажет “я не мог начать верстку вовремя, потому что не знал, какой макет брать - final_design.psd или design_approved.psd”.
- Если программист разработал баннерную систему на сайте, а Вы не видите там ни одного баннера, принимать задачу нельзя. Отсутствие работающего примера означат, что исполнитель сам не проверил качество своей работы прежде, чем сдавать ее.
Неверное управление доработками
Ошибка заключается в том, что доработки не воспринимают, как новые (под)задачи, а поэтому халатно относятся к их формулировке. На самом деле, нет никакой разницы, и халатность при выдаче доработок приведет к тем же проблемам, что и при постановке исходной задачи: Вы либо упустите половину из внимания, либо увязнете в бесконечном футболе, передавая задачу туда-обратно.
Решение - управляйте доработками так же, как задачами: письменная постановка, SMART формат и далее по тексту. Работайте итерациями, каждый раз формулируя список доработок. Принимая очередную итерацию, принимайте по списку, а не по памяти. С каждой новой итерацией список должен сокращаться. Если не сокращается, значит какой-то процесс работает неверно - ищите проблему.
Молчаливая приемка
Имеется в виду замалчивание проблем. Это всегда плохо, а в данном контексте просто приводит к тому, что исполнитель, не зная об ошибках, повторяет их снова и снова. Мы же с вами помним, что все работают в контексте определенной среды, и задачи часто повторяются?
Правильным решением будет объяснить ошибки исполнителю и дать ему возможность самостоятельно их исправить. Он при этом учится, что очень важно. Если не учится, надо искать замену, но это снова работа с людьми, а не с задачами.
Конечно, это увеличивает время на выполнение задачи сейчас, но зато сильно экономит время в будущем.
Отсутствие действий после приемки
Снова упоминаю контекст: любая задача является частью процесса, а не самоцелью. Результаты выполнения задачи всегда используются позднее кем-то еще. Если не используются, возвращаемся на этап постановки и думаем, а нужна ли нам эта задача.
После того, как постановщик полностью удовлетворен результатом, необходимо это правильно оформить. Никто ведь не сомневается в том, что при закрытии проекта надо правильно заархивировать все документы, проверить, что все продукты лежат на своих местах и не смешаны с промежуточными версиями, а также провести ретроспективный анализ? Тогда откуда появляются сомнения в том, что после того, как дизайн макет создан, правильно именован и сохранен, следует сообщить об этом менеджеру? Или в том, что ссылку на согласованный прототип надо включить в письменную постановку для следующей стадии?
Все вышеописанное одинаково применяется для задач разного масштаба, в разных отраслях и с разными людьми. По сути, это здравый смысл и простая аккуратность. Но поверьте: эти две составляющие могут сделать Вашу работу заметно продуктивнее, а жизнь - заметно проще.
Удачи! Следите за эфиром!
Предыдущие статьи серии:
- Иди туда - не знаю куда, принеси то - не знаю что — Часть 1 (Какой должна быть задача)
- Иди туда - не знаю куда, принеси то - не знаю что — Часть 2 (Каким должен быть процесс постановки)
