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

Собеседование проектного менеджера - Часть 2

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

При подборе кандидата всегда возникают дилемма. Кто будет более полезен:

• Человек, который управлял проектами ранее?
• Бывший программист, который знает технологии вдоль и поперек?
• Или человек, который пока мало что знает, но очень интересуется и занимает активную жизненную позицию?

Обучаемость - ключ к эффективности и менеджера, и Ваших проектов

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

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

• Технологии компании
  Я не имею в виду языки программирования. Я говорю о структуре процесса разработки, промежуточных результатах проектов и контрольных точках стадий, управлении качеством и т.п.
• Внутренние стандарты компании
  Это тоже не ограничивается контролем качества продуктов, но также включает требования к процессам: презентация дизайна Заказчику, порядок постановки задач Исполнителям, управление проектной документацией и т.п.
• Новые платформы
  До тех пор, пока не придумали и не раскрутили универсальные стандарты для управления веб-контентом, будет существовать множество CMS и SaaS платформ и сервисов. Следовательно, для каждого третьего человека что-то будет новым при входе в компанию. Кроме того, вы же знаете динамику рынка и скорость появления новых продуктов. Все это тоже нужно постигать - прямо по ходу дела!
• Приемы работы с Заказчиками и Подрядчиками
  Да, осмелюсь утверждать, что это тоже своего рода наука. И если ее не изучать, то одни и те же грабли быстро выбивают менеджера из строя, потому что метрики проектов страдают.

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

О чем спрашивать

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

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

Мой опыт показывает, что собеседование становится интереснее и увлекательнее для всех, если вопросы задаются, так сказать, “по касательной”.

Примеры

Вопрос: Необходимо интегрировать веб-сайт с ERP системой. Ранее этого в компании не делалось, поэтому требуется изучить стандартные интерфейсы с обеих сторон и найти точки соприкосновения. Как будете решать проблему?
Подтекст: Опытный менеджер проекта знает, что понимание принципиального устройства системы именно для менеджера - довольно важно. Управлять процессом интеграции вслепую - безнадежное дело. Однако человек, который любит учиться, ответит “буду разбираться” с энтузиазмом, а человек, предпочитающий проторенные пути, скажет об усложнении проекта и необходимости привлечения аналитика.

Вопрос: У нас используется своя CMS. Как быстро сможете освоить?
Подтекст: Большинство CMS похожи, потому что решают одни и те же задачи. Поэтому если при ответе человек угадает средний срок освоения (основные функции постигаются примерно за 2 месяца в рабочем режиме), это будет означать, что уже есть опыт, причем адекватный. Если ответит, что заметно больше, значит плохо представляет суть и перестраховывается. Если ответит слишком оптимистично, то хочет хорошее впечатление произвести, не особенно задумываясь. Такого лучше продавцом сделать, чем менеджером проекта.

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

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

Мораль

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

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

В предыдуших сериях:
Собеседование проектного менеджера - Часть 1 (конвертируем информацию в задачи)

Предолжение серии:
Собеседование проектного менеджера - Часть 3 (предлагаем, а не спрашиваем)

Собеседование проектного менеджера - Часть 1

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

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

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

Первую статью посвятим ориентированности на результат и отношению к информации.

Что искать

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

Здесь играют роль два фактора:

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

Надо ли говорить, кто отвечает за определение единственно верного способа реализации проекта и одинаковое понимание этого способа и причин его выбора всеми участниками?

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

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

• Быстро запустить в производство.
• Понять из приоритетов, когда важная информация сможет что-то изменить в проекте.
• Получить результат.

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

Как искать

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

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

Если кандидат способен проследить, как видоизменяются и детализируются требования в цепочке “ТЗ - прототип - макет дизайна - постановка задач разработчикам - план тестирования”, ставьте ему два плюсика.

Обратите внимание, какими понятиями оперирует менеджер:

Должно быть не “комментарии клиента с презентации”, а “список доработок макетов дизайна”.

Должно быть не “отложенное требование”, а “задача на пост-проектную стадию” или “потенциальная идея для продавцов”.

Должно быть не “Клиенту не понравился цвет кнопок”, а “у нас запрос на изменение - перекрасить кнопки из синего в красный”.

Мораль

Любите менеджера, который:

• в разговоре каждые 5 минут резюмирует следующие действия
• требует ноутбук и мобильный интернет для доступа к интранету
• у которого в конце дня нет писем во Входящих

Гоните менеджера, который:

• ходит на встречи с блокнотом
• часто говорит “Я все понял и подумаю, что можно сделать”
• на вопрос “где последняя версия ТЗ?” запускает поиск по папке “Входящие”

Удачных (и продуктивных) проектов!

Продолжение серии:

Собеседование проектного менеджера - Часть 2 (обучаемость проектного менеджера)
Собеседование проектного менеджера - Часть 3 (предлагаем, а не спрашиваем)

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

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

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

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

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

Подготовка

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

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

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

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

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

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

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

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

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

Роли

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

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

Суть задачи

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

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

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

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

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

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

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

Обсуждение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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

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

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

Исполнитель

Определение исполнителя напрямую означает передачу ответственности. Важно понимать, что до постановки задачи ответственность за ее реализацию лежит на постановщике, поэтому он обязан не просто «указать пальцем» на нового исполнителя, но и обеспечить понимание им того, в чем заключается задача, и по каким параметрам будет оцениваться качество реализации. Только тогда можно рассчитывать, что задача будет выполнена корректно.

Содержание

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

Чтобы не допустить неверного толкования задачи, используется популярный формат постановки – SMART. Это аббревиатура, которая показывает, какой должна быть корректно поставленная задача:

Specific

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

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

Пример:
Вместо фразы: «Требуется найти кандидата на место менеджера по продажам» говорить: «Требуется найти кандидата на место менеджера по продажам с опытом аналогичной работы не менее 1 года и собственной клиентской базой»

Measurable

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

Пример:
Вместо фразы: «Увеличить прибыль компании по сравнению с предыдущим годом» говорить: «Увеличить прибыль компании по сравнению с предыдущим годом как минимум на 20%»

Achievable

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

Пример:
Вместо фразы: «Необходимо выиграть в крестики-нолики за 2 хода» говорить: «Необходимо выиграть в крестики-нолики максимально быстро»

Result-oriented

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

Пример:
Вместо фразы: «Надо бы поискать новых клиентов в северном районе города» говорить: «Требуется найти новых клиентов в северном районе города»

Time-based

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

Пример:
Вместо фразы: «Необходимо разработать дизайн сайта» говорить: «Необходимо разработать дизайн сайта website.ru, состоящий из трех типовых страниц к 16:00 15.03.2009»

Срок

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

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

Здесь возникает важный нюанс – расстановка приоритетов.

Подходы могут быть разные:

• учет при постановке сроков по ранее выставленным задачам
• формирование универсальной шкалы приоритетов и присвоение каждой задаче конкретной метки, но все равно с учетом сроков по ранее выставленным задачам этого же приоритета
• делегирование задач другим исполнителям для освобождения дополнительного времени

Чтобы выбрать оптимальный подход, следует для себя ответить на вопросы:

• часто ли исполнитель получает задачи разного масштаба?
• велика ли критичность сдвига сроков для большинства задач?
• велика ли доля регулярных (рутинных) задач у исполнителя? Сколько времени тратится именно на них?
• является ли исполнитель заменяемым — много ли в Вашем распоряжении сопоставимых специалистов, между которыми можно перераспределять задачи? Насколько безболезненным является процесс передачи задач в ходе реализации?

Ресурсы

Еще один из параметров SMART-задач – Achievable. Постановщик обязан не только поставить задачу, но и обеспечить исполнителя всем необходимым для ее выполнения. При этом нельзя забывать, что для реализации могут требоваться самые разноплановые ресурсы:

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

Его Величество Контекст

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

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

• масштаба задачи
• инструкций для типовых задач
• хорошего взаимопонимания между участниками

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