Как перестать "писать ТЗ" и начать работать?

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

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

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

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

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

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

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

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

Уточняйте готовые описания в процессе работы - они помогут выявить скрытые “тайм киллеры” и стать основой для настройки системы управления проектами или ERP под ваш проект.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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