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

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

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

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

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

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

Что искать

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

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

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

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

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

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

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

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

Как искать

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

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

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

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

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

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

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

Мораль

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

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

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

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

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

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

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

Иди туда - не знаю куда, принеси то - не знаю что — Часть 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. Унифицируйте стандарты.
   Руководству компании должно быть выгодно, чтобы все менеджеры работали по единым стандартам. У этого принципа масса преимуществ, и одно из них - легкость делегирования задач.

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

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

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