Системные требования. Шпаргалка для менеджера

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

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

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

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

Но как? Одной длинной простыней текста про все сразу вперемешку? Плохая затея. Ведь эти IT-шники такие зануды, им подавай структурированный документ. Или документы. Какие? И где их взять? Давайте разберемся.

Документы в наборе бизнес-требований

Крайне желательно разбить весь массив бизнес-требований на несколько коротких (чем короче, тем лучше) документов. Почему? Дело в том, что один большой — неповоротлив и плохо поддается обсуждению и согласованию, а объемом документа легко скрыть его общую бестолковость. К тому же увильнуть от прочтения и осознания одного документа в 30 страниц, как ни странно, куда легче, чем от прочтения и осознания 10 документов по 3 страницы каждый.

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

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

Обоснование проекта

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

Формат. Начните с «Мы хотим» и вдохновенно опишите мечту заказчика.

Объем. Даже для самых крупных проектов не должен превышать половины страницы.

Что дальше. В случае, когда рабочие споры зайдут в тупик, вы всегда сможете сослаться на обоснование проекта и сверить с ним свои приоритеты и новые рацпредложения. Иногда правы будете вы, иногда — разработчики, но суть не в этом: главное, что у вас всегда под рукой будет материализованная «последняя инстанция» и инструмент для удержания фокуса внимания на конечной цели.

Целевая аудитория

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

Формат. Можно ограничиться, как многие делают, демографическими характеристиками: «Молодые платежеспособные москвичи 23−35 лет». Это безлико, но уже лучше, чем ничего. Однако гораздо лучше составить несколько пользовательских профилей: «Вася, 27 лет, неполное высшее техническое, менеджер по продажам крупного автодилера; в Интернете на работе и с мобильного (iPhone); интересуется авто- и мотоновинками; сейчас озадачен покупкой мотоцикла для „прохватов“ по городу». Снабдите историю фотографией Васи для убедительности.

Объем. По страничке на каждого Васю; не больше пяти Вась в наборе.

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

Бриф на эмоции и впечатления

Суть. Представления о прекрасном, как выше уже было сказано, у каждого свои. Поэтому лучше заранее договориться о том, какое впечатление продукт должен производить на потребителя. Должен он быть современным или классическим? Эпатажным или спокойным? Девочковым или мальчиковым? Лёгким или стабильным? И так далее, и тому подобное.

Формат. Достаточно списка прилагательных: мол, таким мы видим наш проект сверху донизу, от дизайна до текстов. И, что важно, их антонимов: а вот таким — не видим.

Объём. 15 прилагательных + антоним к каждому — более чем достаточно.

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

Ключевые пользовательские сценарии

Суть. Что люди будут делать с вашим продуктом? Точнее, какие свои задачи они будут решать?

Формат. Для начала достаточно простого списка целей: «Выбрать подарок тёще на Новый год», «Придумать, чем бы заняться в выходные», «Поиграть минут 15−20 в ненапряжную игру». Заметьте, что в таком списке нет задач «Зарегистрироваться в системе» или «Оставить отзыв о ресторане»: все рассматриваемые цели должны быть внесистемными, взятыми из жизни и существующими независимо от вашего проекта. Если же вы ещё и распишете, как именно Пользователь должен взаимодействовать с Системой для достижения целей — совсем хорошо. Но для начала — список этих целей (пользовательских сценариев).

Объём. Даже в очень больших проектах (интернет-банкинги, сети розничной торговли, системы веб-публикаций) список сценариев обычно умещается на 3−4 страницы. Для небольшого сайта-визитки это обычно 5−7 действительно важных сценариев, не больше.

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

Обзор конкурентов

Суть. Изобрести велосипед в Интернете довольно трудно — да и стоит ли? Лучше грамотно украсть чужие идеи, чем надеяться на собственную гениальность. Обзор конкурентов — это своеобразный отчёт о том, что вы увидели вокруг и в какую конкурентную среду вписывается ваш новый проект.

Формат. Достаточно списка конкурентов. Но если есть возможность написать про отличительные черты каждого — совсем хорошо. А вот подробно рассказывать о сайтах или приложениях не нужно — всякий сможет и сам глянуть и оценить увиденное.

Объём. Список конкурентов редко выходит за пределы одной страницы. Но если в этом списке не больше 5−7 пунктов — значит, где-то вы пытаетесь слукавить и «срезать углы». Ищите. 15−20 — больше похоже на правду.

Что дальше. Сверка с уже существующими решениями — лучший способ не сделать совсем уж ерунду. И этим способом совершенно не зазорно пользоваться.

План продвижения

Суть. Откуда на вашем проекте появятся пользователи? Вы рассчитываете только на SEO и поисковый контекст? Вы пойдёте во ВКонтакте? Вы развесите QR-коды на столбах? Когда это случится, то что вы предложите людям в первую очередь и чего вы от них захотите? Лучше ответить себе на эти вопросы как можно раньше.

Формат. Список площадок для продвижения + список пользовательских целей («купить», «позвонить», «записаться на курсы»).

Объём. Редко больше двух страниц.

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

Пресс-релиз

Суть. О чём вы скажете людям прежде всего? Вот именно это и надо с особым тщанием разрабатывать программистам.

Формат. Пресс-релиз, как ни смешно :)

Объём. Страница текста, как обычно. Что дальше. Анонсированное будет сделано. Про анонсированное будут спрашивать. С анонсированным будут больше всего возиться. Допустим, вы на протяжении всего проекта декларируете как важный функционал А, а в пресс-релизе внезапно анонсируете функционал Б. Это приведёт лишь к тому, что вы покажете публике задворки вместо парадного фасада. Договоритесь с разработкой заранее, где тот фасад, — и сможете избежать неожиданностей. Совет начинать разработку с пресс-релиза может показаться дикостью каждому, кто не знает, что именно так поступает Amazon.

Схема регулярных обновлений

Суть. Что вы будете непрерывно менять на сайте? Может быть, баннеры? Или новости? Или цвет фона? Или статьи?

Формат. Список, просто список хотелок.

Объём. Если в списке больше 7 пунктов — скорее всего, вы делаете не проект для пользователей, а внутреннюю систему управления контентом. Соответственно, и вести разработку этой системы нужно как обособленный проект — и тогда задачи на внесение изменений попадут уже не в схему обновлений, а в список пользовательских (вы — пользователь) сценариев.

Что дальше. К чему вы попросите сделать рычаги — тем и сможете управлять. А к чему не попросите — то изменить будет очень и очень трудно. Соответственно, инвентаризация потребностей в изменениях — залог того, что эти потребности будут учтены (а в идеале — и реализованы).

Техники выявления требований

Откуда взять все эти волшебные документы? Вы не поверите, но — составить самостоятельно. Как ни соблазнительна идея «Вы же технари, вот вы и напишите», работать она не будет. Берите дело в свои руки.

Дело, кстати говоря, несложное. Нужно лишь соблюдать несколько простых правил.

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

Не надейтесь собрать требования, обмениваясь электронной корреспонденцией. Только живые обсуждения, только hardcore. Плотность информационного потока при обсуждении голосом всегда выше, чем в переписке, режим «вопрос-ответ» всегда динамичней, передача эмоций (и, значит, приоритетов) всегда точней. Да и излагать свои требования письменно, честно говоря, мало кто умеет.

Сначала сбор данных, а только потом — обработка

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

Опросите всех этих людей. Живьём (в крайнем случае по телефону), ни в коем случае не по почте. И задайте им три вопроса: «Что устраивает? Что не устраивает? Что хотите видеть в новой версии?» (если речь о новой версии). Или один: «Каким видите проект?» (если затея совсем новая). Запротоколируйте услышанное. Полдела сделано.

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

Короче и проще

Одна страница — достаточный объём для любого документа. Если у вас получилось больше — значит, где-то вы избыточны. Эта статья, например, избыточна, но так уж попросили :)

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

Черновик лучше чистовика

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

Поэтому: быстро выносите документ на обсуждение, как можно скорей собирайте комментарии и составляйте следующую версию.

Трёх итераций достаточно

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

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

[CENTER] ***

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

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

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

Типовые ошибки

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

«Само собой разумеется»

Часто работа над проектом начинается с составления Универсального Документа Про Всё, или «технического задания». Кажется, что размер этого документа убедителен сам по себе: вот, люди подумали и написали много букв. Между тем уже несколько десятков лет назад IT-отрасль устами своих самых известных методологов признала, что большие технические задания никто никогда не читает, а все работы в проектах с такими ТЗ проводятся «на глазок».

Вместо составления большой бумаги про всё — составьте много маленьких бумажек. Много. И маленьких. Пусть каждый из этих документов отвечает на один ключевой вопрос и показывает проблему с одной точки зрения. Список таких документов — см. выше.

«Техническое задание»

«Что» без «зачем»

Мы все думаем, что отлично ориентируемся в Интернете. Знаем, какие бывают типовые решения, любим одни интерфейсные фишечки и ненавидим другие. И велик соблазн ставить задачу в терминах этих фишечек: «А ещё нам нужна своя внутренняя социальная сеть». Проблема лишь в том, что навязывание ответов (что сделать) без постановки вопросов (зачем делать) вызывает сильное неприятие IT-специалистов. Обычно эти люди не любят размениваться на дурацкие, с их точки зрения, задачи. И будучи трижды посланными со своим вопросом «Зачем?», они найдут собственную формулировку ответа — не всегда совпадающую с вашей. А исходя из этой формулировки они сделают такое, что вам и в страшном сне не приснится. Ну и зачем?

Чтобы избежать проблемы, составьте и зафиксируйте чёткое видение проекта, расширением которого и служит, собственно говоря, набор бизнес-требований. Тогда на каждое «Зачем?» у вас уже будет готов внятный и задокументированный ответ.

Keep up to the Johnsons

90% маркетинговых требований к IT-проектам звучат так: «Свой Groupon, только лучше и дешевле». Но Groupon и другие клонируемые сервисы — это не столько сайты или мобильные приложения, сколько отлаженные бизнес-процессы и маркетинговая политика. Возлагать на IT-производство ответственность за то, что они клонируют бизнес-процесс, — пожалуй, несколько самонадеянно.

Даже если вы хотите кого-то клонировать, разбейте задачу на технологии и бизнес — и ответственность за бизнес возьмите на себя. А «так же, только круче» оставьте светлой целью, но никак не критерием сдачи-приёмки IT-работ.

Отсутствие приоритезации

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

Честно приоритезируйте свои хотелки. И зафиксируйте эти приоритеты для IT-производства по пунктам, а не просто обсудите их устно в общем виде.

Потеря контроля над процессом производства

«А нельзя ли нам поменьше совещаться?» — такую позицию иначе как самоубийственной назвать нельзя.

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

[CENTER] ***

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

Что же во всём вышеописанном — самое важное? То, с чего начиналась статья: уважайте исполнителей. Дайте им достаточно (но не избыточно) информации для принятия решений. Обеспечьте свободу действий. И контролируйте результат в соответствии с зафиксированными требованиями, не опускаясь до «разборок по понятиям».