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

Сергей Соловьев о применении веб-технологий с пользой для бизнеса

Опубликовано: 24.09.2009, 00:08

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

Всегда есть варианты

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

Что может противопоставить этому менеджер проектов?
Самым полезным навыком в данном случае станет умение мыслить предложениями, а не вопросами. На начальном этапе любого проекта задача менеджера - осознать, очертить и согласовать требования к конечному продукту. И только от менеджера зависит, будет ли этот процесс мучительным для Клиента, или он подпишет ТЗ с уверенностью в будущем результате.

Надо ли говорить, что хорошее начало и правильно заданный темп - это уже полдела?

В чем польза?

И все-таки рассмотрим ситуации, когда привычка мыслить предложениями оказывается крайне полезной:

  • Когда Клиент не может адекватно сравнить варианты и оценить, какой из них будет лучшим именно в его проекте.
    То, что очевидно опытным Подрядчикам, может быть совершенно неочевидно Заказчикам.
  • Когда Клиент предлагает заведомо неадекватное или неграмотное решение.
    Увы, это не редкость, но помним - они не обязаны бысть специалистами!
  • Когда очень нежелательно вступать в длинную и непродуктивную дискуссию.
    Довольно часто такие дискуссии заканчиваются триумфальным изобретением велосипеда. Впрочем, некоторым людям принципиально доказать теорему самостоятельно - это стоит учитывать.

А вот некоторые конкретные преимущества, которыми может пользоваться менеджер, активно рекомендующий готовые решения:

  • Экономия времени и ускорение принятия решений
  • Повышение уровня обслуживания Клиентов
  • Повышение доверия к Подрядчику через демонстрацию экспертизы
  • Обучение Клиента и новых сотрудников Подрячика (при их участии в переговорах)

Как выявить талант?

Итак, снова постараемся понять, как можно на этапе собеседования с кандидатом определить его склонность при работе с Клиентами.

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

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

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

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

Мораль

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

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

В предыдуших сериях:

Собеседование проектного менеджера - Часть 2 (не ищем готовенькое - обучаем)
Собеседование проектного менеджера - Часть 1 (конвертируем информацию в задачи)

Опубликовано: 19.08.2009, 22:32

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

Все люди - разные

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

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

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

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

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

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

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

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

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

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

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

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

Примеры

Вопрос: Необходимо интегрировать веб-сайт с ERP системой. Ранее этого в компании не делалось, поэтому требуется изучить стандартные интерфейсы с обеих сторон и найти точки соприкосновения. Как будете решать проблему?
Подтекст: Опытный менеджер проекта знает, что понимание принципиального устройства системы именно для менеджера - довольно важно. Управлять процессом интеграции вслепую - безнадежное дело. Однако человек, который любит учиться, ответит “буду разбираться” с энтузиазмом, а человек, предпочитающий проторенные пути, скажет об усложнении проекта и необходимости привлечения аналитика.
Вопрос: У нас используется своя CMS. Как быстро сможете освоить?
Подтекст: Большинство CMS похожи, потому что решают одни и те же задачи. Поэтому если при ответе человек угадает средний срок освоения (основные функции постигаются примерно за 2 месяца в рабочем режиме), это будет означать, что уже есть опыт, причем адекватный. Если ответит, что заметно больше, значит плохо представляет суть и перестраховывается. Если ответит слишком оптимистично, то хочет хорошее впечатление произвести, не особенно задумываясь. Такого лучше продавцом сделать, чем менеджером проекта.
Вопрос: Проводили ли Вы обучающие семинары для команды Заказчика или коллег? Каковы основные задачи семинаров?
Подтекст: Снова ищем людей, которые станут отвечать с энтузиазмом. Если кандидат говорит, что семинары - это потеря времени, значит он не ценит новые знания. Это ему в управлении проектами никак не поможет.
Вопрос: Имеете ли представление о рестроспективном анализе проектов, понятии извлеченных уроков? В чем их задача?
Подтекст: Человек, который любит узнавать новое, очень часто стремится придать новым знаниям практическую направленность. Такой человек, даже если не знает терминологии, сможет догадаться, что имеется в виду и ответит на вопрос правильно. А терминологию он выучит, не сомневайтесь. Он даже использует ее на собеседовании у Вашего конкурента через неделю, если Вы не возьмете его себе.

Мораль

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

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

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

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

Опубликовано: 12.08.2009, 22:53

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

Ориентированность на результат

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

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

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

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

Что искать

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

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

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

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

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

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

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

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

Как искать

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

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

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

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

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

Мораль

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

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

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

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

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

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

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

Опубликовано: 10.07.2009, 21:38

А что делает Менеджер Проекта?

Как-то меня представили одному разработчику со стороны Клиента, сказав, что я в команде - менеджер проекта. Разработчик не удержался и ответил: “А, так вы один из тех, кто с утра говорит нам, что делать, а сам потом весь день балду пинает?”

Это - классика жанра. Именно так менеджеры проекта воспринимаются многими разработчиками. Не всеми, конечно. Искренне верю, что читатели блога понимают, во что обычно превращается проект без менеджера.

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

Don't push!

Люди и Роли

Первое, что требуется четко осознать: PM - это не навык и не должность. PM - это роль в проекте.

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

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

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

Между тем, это далеко не всегда лучшее решение. Если в двух словах, то риск сводится к тому, что под давлением противоречивых интересов менеджер может допустить слишком много компромиссов, что в итоге пагубно скажется на результате. А то, что проектов без противоречивых интересов не бывает, и про соотношение Скорость/Качество/Бюджет я надеюсь, напоминать не обязательно.

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

  • Подготовка к проекту (Starting up a Project)
  • Открытие проекта (Initiating a Project)
  • Планирование (Planning)
  • Управление стадиями (Controlling a Stage)
  • Управление доставкой продуктов (Managing Product Delivery)
  • Управление границами стадий (Managing Stage Boundaries)
  • Закрытие проекта (Closing a Project)

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

Что часто ожидают от PM?

Оценка

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

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

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

Принятие решений проектного уровня

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

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

Проектирование

Проектирование начинается с составления Технического Задания, которое является частью проектной документации. За проектную документацию традиционно отвечает PM, поэтому ему и карты в руки.

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

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

Практическое знание технологий

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

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

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

Контроль качества

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

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

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

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

Учет ресурсов

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

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

  • Либо выясняется, что новому менеджеру нужно еще 3 человека в помощники
  • Либо оказывается, что прежний менеджер “управлял проектом” 30 часов в неделю, а новый утверждает, что будет тратить на “управление” 15 часов в неделю при схожем размере проекта
  • Либо все это происходит наоборот

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

Категоризация работ внутри проекта веб-разработки может быть, например, такой:

  • Управление проектом
  • Проектирование (включая ТЗ и/или прототип)
  • Разработка дизайна основных шаблонов
  • Графические работы
  • Разработка фронт-офиса (статических шаблонов)
  • Программирование (внедрение функционала и CMS)
  • Тестирование
  • Разработка сопроводительной документации
  • Обучение пользователей
  • Администрирование

Как минимум 5 категорий их этого списка очень часто выполняются менеджером проекта.

И в заключение, заранее отвечая на вопрос “Какие роли объединять, а какие - нет?”, скажу: единого рецепта не существует. Старайтесь балансировать таланты Вашего менеджера и его полномочия/ответственность. На баланс влияют:

  • Размер проекта и организации
  • Типизация проектов
  • Мотивация менеджера
  • Наверняка что-нибудь еще :)

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

Опубликовано: 02.07.2009, 22:08

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

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

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

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

Готово!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приемка 98%

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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