Soloviov.ru / Веб для бизнеса

Иди туда - не знаю куда, принеси то - не знаю что — Часть 3

Как правильно принять задачу у исполнителя?

Завершая серию об управлении задачами обязательно надо упомянуть о том, что делать, когда задача возвращается к постановщику с радостным сообщением “Готово!”. Часто встречаю ситуацию, когда по истечении длительного времени в результатах обнаруживаются дефекты. Было бы очень несмотрительно думать, что это вина исполнителя. В первую очередь, это вина постановщика, который не потрудился проверить результаты.

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

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

Если это всем понятно, то займемся менее тривиальными вещами. Итак, что мы делаем неправильно?

Слепая приемка

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

Не забывайте, что любой исполнитель - человек и имеет право на ошибку. Ваша ответственность - убедиться, что все действительно сделано верно и полностью. В конце концов, именно с Вас в итоге буду требовать бескомпромиссное качество!

Приемка с опозданием

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

Процесс пойдет значительно быстрее, если Вы сможете выдавать обратную связь почти моментально (например, в тот же день, когда сдана задача). Конечно, это несколько утопично, но стремиться к такому идеалу стоит.

Ошибочные критерии приемки

Одна из основных аксиом менеджера: Задача может считаться принятой, если она соответствует заданным критериям качества. Критерии эти задаются на трех уровнях:

• Внешние стандарты
  Например, стандарты делопроизводства для документов или стандарты HTML кода от W3C
• Корпоративные стандарты
  Например, фирменные бланки и шаблоны (опять же, для документов) или контрольные списки для проверки качества визуального дизайн-макетов
• Исходная постановка задачи
  Она, в частности, может содержать и отклонения от вышеназванных стандартов

Наиболее частая ошибка: игнорирование чего-либо из этого списка. Особенно часто, как ни странно, игнорируется исходная постановка. Особенно это проявляется, когда задачу принимает не тот, кто ее ставил (не такая уж и редкость). Руководствоваться собственными представлениями о результате вместо того, что реально требовалось от исполнителя, некорректно. Даже если Вы обнаружили ошибку в постановке, правильнее извиниться перед исполнителем, чем обвинять в недобросовестности.

Разный уровень щепетильности для разных типов задач

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

Приемка 98%

Задача должна быть выполнена на 100%. Даже если сделано 98%, это означает, что задача не выполнена. Здесь проще всего объяснить примерами:

• Если программист разработал функциональность на локальной версии веб-сайта, а Вы ее протестировали на той же локальной версии и убедились, что работает правильно, это не означает, что работа выполнена. И любой клиент, который не увидит функциональность на рабочей версии сайта, легко Вам это объяснит.
• Если дизайнер нарисовал макет и даже положил его в правильную папку на сервере, но назвал файл “final_design.psd”, то любой верстальщик будет прав, когда скажет “я не мог начать верстку вовремя, потому что не знал, какой макет брать - final_design.psd или design_approved.psd”.
• Если программист разработал баннерную систему на сайте, а Вы не видите там ни одного баннера, принимать задачу нельзя. Отсутствие работающего примера означат, что исполнитель сам не проверил качество своей работы прежде, чем сдавать ее.

Неверное управление доработками

Ошибка заключается в том, что доработки не воспринимают, как новые (под)задачи, а поэтому халатно относятся к их формулировке. На самом деле, нет никакой разницы, и халатность при выдаче доработок приведет к тем же проблемам, что и при постановке исходной задачи: Вы либо упустите половину из внимания, либо увязнете в бесконечном футболе, передавая задачу туда-обратно.

Решение - управляйте доработками так же, как задачами: письменная постановка, SMART формат и далее по тексту. Работайте итерациями, каждый раз формулируя список доработок. Принимая очередную итерацию, принимайте по списку, а не по памяти. С каждой новой итерацией список должен сокращаться. Если не сокращается, значит какой-то процесс работает неверно - ищите проблему.

Молчаливая приемка

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

Правильным решением будет объяснить ошибки исполнителю и дать ему возможность самостоятельно их исправить. Он при этом учится, что очень важно. Если не учится, надо искать замену, но это снова работа с людьми, а не с задачами.

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

Отсутствие действий после приемки

Снова упоминаю контекст: любая задача является частью процесса, а не самоцелью. Результаты выполнения задачи всегда используются позднее кем-то еще. Если не используются, возвращаемся на этап постановки и думаем, а нужна ли нам эта задача.

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

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

Удачи! Следите за эфиром!

Предыдущие статьи серии:

• Иди туда - не знаю куда, принеси то - не знаю что — Часть 1 (Какой должна быть задача)
• Иди туда - не знаю куда, принеси то - не знаю что — Часть 2 (Каким должен быть процесс постановки)

Аспекты делегирования

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

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

Что же в нем особенного?

Во-первых, не надо путать делегирование с перекладыванием ответственности. Единственное, на что может рассчитывать делегирующий менеджер, и ради чего стоит ввязываться в делегирование - это сокращение собственного времени на выполнение задачи. Ответственность все равно на нем остается. Просто вместо, к примеру, 3 часов на выполнение задачи он тратит 0,5 часа на постановку и еще 0,5 часа на приемку.

Во-вторых, делегирование имеет ряд недостатков, которые часто сводят его полезность на нет. Многим людям не нравится нести ответственность за действия других людей. Многие другие люди не готовы одинаково качественно выполнять собственные задачи и перепорученные им кем-то. Из-за подобных противоречий возникает вопрос, как бы так делегировать задачи, чтобы получалось поэффективнее?

Эффективность делегирования

Основное стремление делегирующего - сократить время, которое он потратит на задачу, не уронив качества результата. Как этого добиться?

1. Оцените пропорцию времени на делегирование/приемку и времени на выполнени задачи самостоятельно.
   При делегировании задачи совокупное время на выполнение задачи всегда возрастает. Некоторые задачи нет смысла делегировать, потому что сам менеджер выполнит их в 2-3 раза быстрее.
2. Правильно выберите исполнителя.
   Исполнитель должен уметь делать то, что вы делегируете. Идеально, если это - другой менеджер проекта с такими же навыками.
3. Ставьте задачу письменно.
   Это сокращает количество ошибок и, как следствие, время на перепостановку и переприемку. Да и в целом, относитесь к делегированию, как к обычной постановке задачи.
4. Требуйте письменный отчет об исполнении.
   Это не только повышает ответственность исполнителя, но и экономит ваше время на приемку. Точно так же, как и для постановки, вам не требуется “ловить” исполнителя, чтобы обсудить задачу или ее результат. Вы можете это сделать тогда, когда у Вас есть время.
5. Мотивируйте исполнителя.
   Если забыть о мотивации, задача может быть выполнена плохо, и потребуется больше времени на переделки. Расскажите, как важен результат выполнения задачи, или пообещайте ответное одолжение. На разных людей действуют разные методы!
6. Делегируйте типовые задачи.
   Если в среде менеджеров выполняются типовые задачи (а в сфере управления проектами, это происходит очень часто), то для постановки конкретной задачи достаточно сообщить необходимый минимум информации. Достаточно ответить на вопрос “что требуется”. Ответ на вопрос “как это сделать” при этом должен быть известен, исходя из типа задачи, и закреплен в корпоративных процедурах.
7. Унифицируйте стандарты.
   Руководству компании должно быть выгодно, чтобы все менеджеры работали по единым стандартам. У этого принципа масса преимуществ, и одно из них - легкость делегирования задач.

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

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

Удачи! Следите за эфиром!

Иди туда - не знаю куда, принеси то - не знаю что — Часть 2

Как правильно поставить задачу исполнителю?
Каким должен быть процесс постановки

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

Это действительно может cработать, если Вы занимаетесь… разгрузкой вагонов. Тогда процесс предельно простой: «Вася, еще один вагон пришел, надо освободить побыстрее!» А если вы проектируете интерфейс социальной сети с новым типом контента? Уже не скажешь просто: «Вася, надо спроектировать форму авторизации». В этом случае Вы рискуете потратить больше времени на переработку неверного результата. И все потому, что не уделили достаточно времени и внимания постановке задачи.

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

Подготовка

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

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

Для организации встречи Вам следует:

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

На примере:
Для Вашего проекта требуется 2 варианта прототипа с разной типовой сеткой страниц. Разрабатывать их могут параллельно 2 информационных архитектора. Именно ИА в Вашей компании занимаются проектированием, поэтому единственное, о чем Вам нужно позаботиться – это заранее забронировать их время на свой проект.

• Собрать материалы для встречи и сформулировать постановку.
  К тому моменту, когда Вы придете на встречу, постановка задачи должна быть готова. В противном случае, встреча будет потерей времени, что никому неинтересно. Уважайте тех, кто поможет Вам выполнить задачу. Пригласив их на встречу, Вы наверняка отвлекли их от другого дела, которое им нравится. Чтобы постановка получилась правильная, рекомендую прочесть первую статью из этой серии.

На примере:
На собрание необходимо принести документированные требования к веб-системе, распечатанные в двух экземплярах – каждый архитектор должен оставлять записи на полях по мере обсуждения.

• Отправить всем участникам приглашение с указанием цели, времени, места и необходимых материалов.
  Для всех очевидно, что нужно сообщить место и время, чтобы встреча состоялась. Но, к сожалению, не каждый возьмет на себя труд отправить материалы по цели встречи (например, ТЗ) или объяснить, где их можно найти. А ведь если Исполнители имеют возможность подготовиться к встрече заранее, она может стать на порядок эффективнее: команда сможет потратить меньше энергии на объяснения и больше энергии на генерацию идей.

Непосредственно постановка

Роли

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

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

Суть задачи

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

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

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

Начать рекомендуется с источника задачи (см. первую статью серии), чтобы дать представление о том, в каком контексте ставится задача, с чем она связана, и как укладывается в обязанности Исполнителей. Им должно быть понятно, откуда задача появилась, что от нее будет зависеть, и почему ее поручают именно им.

На примере:
Контекст – это проект и его текущая стадия. Обычно технологический процесс все в компании представляют хорошо, и он незначительно меняется от проекта к проекту.

Следите за тем, чтобы Ваш рассказ воспринимался именно как постановка задачи, а не как просто интересная беседа или презентация. Исполнители должны осознать, что от них будут ожидать определенных результатов. Об этом надо сказать явно. Я много раз видел, как Исполнители, после подобных встреч на вопрос коллег: «Как прошла встреча?» отвечали: «Да, обсудили новый проект. Есть там какие-то неясности. Наверное, завтра снова соберут языком помолоть».

На примере:
Информационный архитектор – профессия творческая, поэтому люди могут слишком увлечься обсуждением и упустить то, ради чего их позвали. Убедитесь, что после встречи у них в голове осталось: «Мне нужно сделать 20 шаблонов», а вовсе не: «Мне нужно придумать какую-то крутую интерфейсную идею для новой веб-системы».

Обсуждение

Дайте Исполнителям возможность понять задачу лучше. Они должны задать Вам много уточняющих вопросов. Этих вопросов должно быть настолько много, чтобы у Вас не хватило ответов. Запишите вопросы, которым ответов не хватило, и после встречи обязательно проясните. Ваш интерес, как Постановщика – в том, чтобы Исполнители начали выполнять задачу прямо на встрече. Пусть предложат способы реализации, идеи и подходы. Спросите их о возможных подводных камнях. Для Вас это – риски, которых Вы можете избежать, если будете знать о них вовремя.

Вовлекая Исполнителей в обсуждение задачи, Вы добиваетесь того, что так необходимо Постановщику:

• Исполнители автоматически принимают ответственность за задачу, потому что начинают думать над ее реализацией
• У Исполнителей просыпается интерес и появляется мотивация
• Вы (или Консультант) получаете шанс скорретировать направление мысли, если оно неверное или неоптимальное.

На примере:
В этом месте проявляется полезность подготовки Исполнителей перед встречей. Если Вы, как Постановщик, все сделали правильно, то архитекторы придут на встречу, ознакомившись с требованиями и с готовыми идеями. Позвольте им объяснить эти идеи, покритикуйте, похвалите и обязательно выберите наиболее удачные для дальнейшей проработки.

Параметры задачи

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

Зону ответственности каждого, если задача выдается группе.
Если это не определить четко, в результатах обязательно будут пробелы, потому что «Вася решил, что это сделает Петя, а Петя решил, что наоборот».

На примере:
Каждый архитектор должен четко понять, что он не просто как группа поддержки на встрече присутствовал. От него тоже требуется 20 шаблонов, причем Вася делает сетку двухколоночную, а Петя – трехколоночную. А инфраструктуру для прототипов им сделает системный администратор, и им на это время тратить не нужно.

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

На примере:
Если в требованиях сказано, что на главной странице должно быть представлено 9 блоков определенного назначения, то ИА должны знать, что они могут управлять приоритетами блоков, но не могут изменять их состав.

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

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

Также на встрече необходимо определить сроки выполнения задачи.
Важно получить устное подтверждение от Исполнителей этих сроков, даже если они типовые. Отвечая на вопрос о сроках, Исполнитель:

• Помогает Вам определить срок точнее и спланировать свои дальнейшие действия в зависимости от него
• Соглашается с ответственностью уложиться в него
• Может своевременно сообщить Вам о препятствиях, ранее Вам неизвестных

Резюмирование

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

На примере:
Для стадии проектирования в проекте веб-разработки контрольный список, скорее всего, будет включать такие пункты, как: «Сопоставили набор проектируемых шаблонов со структурой веб-системы», «Определили различия между двумя вариантами прототипов» и т.п.

Действия после постановки

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

Во-первых, подтвердите выдачу задачи письменной постановкой. Это может быть что угодно: отчет о встрече со списком действий и ответственных, задача в специальной системе управления проектами или даже Email сообщение.

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

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

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

Ну и наконец, не забудьте подтвердить для всех остальных сотрудников компании тот факт, что задача выдана Исполнителю. Это может быть запись в корпоративном календаре или подтверждение брони ресурса в календаре производства, или простое извещение заинтересованных лиц по электронной почте.

После этого Вы имеете полное право расслабиться до тех пор, пока не наступит время принимать выполненную задачу. И именно об этом процессе мы будем говорить в третьей статье серии. Следите за эфиром!