Как перестать «писать ТЗ» и начать работать?06.02.2019 11:10

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

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

Источник

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

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

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

Что делать, чтобы не попасть в такую ситуацию и обеспечить высокий темп работы?

Сделайте производственный процесс понятным

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

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

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

Уточняйте готовые описания в процессе работы — они помогут выявить скрытые «тайм киллеры» и стать основой для настройки системы управления проектами или ERP под проект.

У нас нет готовых бизнес-процессов, что делать?

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

Если такого человека нет, руководствуясь принципами S.M. A.R.T., опишите шаг за шагом действия каждого сотрудника, вовлеченного в выполнение конкретных работ. У вас должен получиться список действий, из которого предельно ясно, кто за что отвечает и что является результатом данного этапа (например, документ, код или результат определенного действия).

Вот упрощенный пример такого процесса для подготовки шаблона электронного письма для рассылки:

• Не менее чем за 5 рабочих дней (минимальный срок — 5 дней, рекомендованный срок — 10 дней) до старта рекламной кампании Менеджер проекта передает Email-маркетологу задание на разработку шаблона и верстку шаблона электронного письма;

Задание на разработку шаблона электронного письма содержит: пункт 1, пункт 2, пункт N

• Email-маркетолог после получения задания в течении 1 рабочего дня выполняет проверку полученной верстки и содержание задания:
• При наличии ошибок в верстке или недостатка в материалах Email-маркетолог предоставляет Менеджеру проекта информацию об ошибках и дает рекомендации по их устранению;
• Если проверка верстки не выявила недостатков переходит к п.3
• Не менее чем за 3 дня до планируемого старта кампании Email-маркетолог производит настройку шаблона для рассылки;
• Не менее чем за 2 дня до планируемого старта кампании Email-маркетолог проводит тестирование

Стандартный план тестирования: пункт 1, пункт 2, пункт N

• По итогам тестирования Email-маркетолог передает Менеджеру проекта сведения о результатах тестирования и результат выполнения задачи.

Нужно быть готовым к тому, что не все процессы, особенно связанные с интеллектуальным трудом или креативные задачи, могут быть описаны подобным образом, но, по моему опыту, только 5–10% работ не поддается или с большим трудом поддается описанию.

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

Нам уже поздно что-либо менять

Совершенно не важно, на каком из этапов вы сейчас находитесь, стоите ли вы перед чертой за которой начинается «бей и беги», или уже перешагнули эту границу. Чем глубже вы погружаетесь в проект, тем больше вы знаете об особенностях работы с клиентом, используемых системах и программном обеспечении, специфике решаемых задач. Один за другим описывайте процессы и постепенно внедряйте их в команду. За пару недель, руководствуясь принципом «достаточности», вы легко справитесь с описанием 10–15 процессов, уделяя по 1–1,5 часа в день этой задаче.

Используйте систему управления проектами

Basecamp, Jira, Slack, и [ваша любимая система управления проектами]. Используйте любую систему, которая вам нравится или больше всего подходит под характер вашей работы. Основная польза от успешного применения СУП (PMs) заключается в повышении эффективности управления и отслеживании статуса задач, а также в ускорении обмена важной информацией между членами команды.

Скажу пару слов о вышеупомянутых сервисах.

Basecamp

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

Источник: basecamp.com

Jira

Jira больше подойдет разработчиков, «из коробки» поддерживает множество типовых шаблонов организации проектов. Здесь для вас и Kanban доски, и Scrum Product Backlog, и управление задачами, а если стандартные опции вам не подходят, то Jira предлагает множество опций для тонкой настройки процессов и рабочего пространства. Но советую быть внимательным, система имеет высокий порог вхождения и может усложнить жизнь неопытной команде. При этом ценовая политика Atlassian не самая демократичная, но попробовать можно бесплатно.

Источник: confluence.atlassian.com

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

Slack

Если ваша работа построена главным образом на непрерывных персональных и командных коммуникациях, то Slack станет хорошим подспорьем, чтобы собрать все внутренние чаты и личные переписки в одном месте. В дополнение к этому, в Slack есть кое-какие возможности для организации трекинга задач, создания to-do листов. При этом система имеет богатые возможности для интеграции с разными сервисами, есть высокая вероятность что вы найдете любимый таск-трекер или другой инструмент в их числе. Цены на пользование сервисом сильно зависят от количества человек в вашей команде — от нуля до нескольких сотен долларов в месяц.

Источник: slack.com

Пишите исчерпывающие брифы

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

Например, разрабатывая кампанию, в которой потребитель оставляет персональные данные на лендинге, а затем попадает в цепочку триггерных коммуникаций, можно легко упустить данные, которые клиент планировал использовать для сегментации аудитории кампании в следующих коммуникациях, но забыл вам об этом рассказать. Такими данными могут быть действия пользователей на сайте, взаимодействия получателей с письмами и продвижение клиента по триггерной цепочке. Хотя самой распространённой ошибкой чаще становится потерянный счётчик Google Analytics или DoubleClick, про который вспоминают к концу кампании.

Еще один важный момент в подготовке брифа — качественный бриф можно с меньшими усилиями превратить в функциональное задание!

Стандартизируйте требования к содержанию проектов

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

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

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

Замените техническое задание на функциональное

В чем различие технического задания и функционального?

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

Функциональное задание ограничивается ответом на вопрос «что делать / что делаем» и может быть выполнено в совершенно разном виде, представлять собой сочетание разных материалов (текстовых, графических, готовой документации, дизайн макетов и других). Обычно минимально необходимое описание задачи укладывается в 2–3 страницы против 15–20 листов из оформленного технического задания.

Если в ваших проектах много разнообразного функционала, используйте современные инструменты, например, Scrum Product Backlog поможет вам быстро документировать новые требования к продукту/проекту/сервису и эффективно ими управлять.

При этом формат функционального задания точно описывает, что вы делаете и оставляет вашим коллегам пространство для маневра в достижении поставленной задачи, а его подготовка занимает гораздо меньше времени. Вы сэкономите 60–80% времени на подготовку задания, и даже до 99% на простых проектах (останется сменить заголовок документа).

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

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

Введите исполнительную документацию

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

Почти каждая из систем управления проектами или ERP предоставляет подходящий функционал. Confluence (от Atlassian), Basecamp, Miscrosoft SharePoint — все решения хороши. Ваша главная задача — составить базу знаний о проектах, не затрачивая на это большое количество времени.

Совет, который не понравится вашему руководству

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

Большой бренд может стать тяжелым якорем на вашей шее.

Если вы видите, что с самого начала клиент выстраивает отношения в которых вы всё время находитесь в «заложниках», вынуждены идти на неоплачиваемые переработки или делать бесплатную работу, а темпы роста объемов работ изначально угрожают превысить возможности вашей команды, срочно бейте в набат. У вас большие проблемы. И не думаете, что диверсификация бизнеса придумана дураками. Белеющие на берегах истории кости десятков компаний доказывают — возлагая надежды на бизнес крупного клиента, вы ставите себя в зависимое, слабое положение. На рынке почти нет компаний, которые выполняют настолько уникальную работу и обладают такими знаниями, чтобы стать незаменимыми.

Самый плохой клиент — этот тот кто больше всех платит.

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

Бонус для менеджеров проектов

Я видел много менеджеров проектов, которые в поте лица по несколько часов выравнивают отступы в документах, выделяют жирным и курсивом отдельные слова, форматируют таблицы и делают подписи к изображениям, расставляют нумерацию, составляют глоссарии из объективно понятных терминов. Мои одноклассницы так разукрашивали свои дневники в начальной школе. Никогда так не делайте. Избегайте лишнего форматирования документов!

Заключение

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

Для любителей полистать статьи, я привожу основные мысли кратко:

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

На этом всё. Если вам понравилась статья, материал оказался полезным — поделитесь им в социальных сетях и подписывайтесь на мой профиль. Если вы с чем-нибудь не согласны или у вас есть предложения — давайте обсудим! Оставляйте комментарии или напишите мне лично.

Удачи в полях!

© Habrahabr.ru