Итак, мы поговорили о том, зачем вам нужны требования, что они должны содержать и кто должен их писать. Это четвертая и последняя часть цикла статей про требования, в которой я хочу поделиться своим собственным опытом написания хороших требований.
Главное возражение, которые вы услышите от команд, которые пишут требования, — “их никто не читает”. Когда никто не читает требования, люди которые их пишут, становятся немного циничными. Это как старый мультик с Дилбертом, в котором инженеры используют толстенные стопки требований для создания пристроек в их кабинах. . В вашей большой бюрократической компании, каждый тратит месяцы и месяцы на написание подробных скучных требований. После того как требования написаны, они идут на полку, и их больше никто оттуда не достает. Продукт же реализуется с нуля и без учета того, что написано в требованиях (потому что никто их не читает). Сам процесс написания требований уже полезен сам по себе, так как заставит каждого, по крайней мере, продумать вопросы, которые могут возникнуть при реализации. Но тот факт, что требования забрасывают не читая, заставляет людей чувствовать, что они проделали кучу работы впустую.
Также, если ваши требования никто не читает, вы получаете массу аргументов после того, как продукт был выпущен. Кто-то (менеджмент, маркетинг или клиент) говорит: “Постойте! Вы обещали мне, что добавите в продукт Устрицы (автор тут утрирует, но я не придумал хорошего русского слова для сферической фичи) ”. И программисты говорят “Погодите. Если вы посмотрите в требования в раздел 3, подраздел 4, параграф 2.3.0.1, то увидите, что там четко сказано ‘никаких Устриц’”. Но это не нравится клиенту, который всегда прав, и поэтому сварливые программисты должны модернизировать продукт еще раз, добавив Устрицы (что делает их еще более циничными в отношении требований). Или менеджер говорит: “Послушайте, все формулировки в этом диалоге слишком многословны и в верхней части каждого диалогового окна должна быть реклама”. Программисты отвечают в отчаянии: “но вы же утвердили требования, в которых были точные макеты и содержимое каждого диалогового окна!”. Но, конечно, менеджер не читал внимательно требования, потому что когда он попробовал это сделать, его мозг начал просачиваться через глазницы, и в любом случае это мешало его игре в гольф во вторник.
Итак. Требования отличная штука, но их никто не читает. Как тот, кто пишет требования, вы должны обхитрить людей, чтобы они их прочитали, и вам, вероятно, следует также постараться не допустить утечки уже слишком маленьких мозгов через глазницы.
Обхитрить людей, чтобы они прочитали требования достаточно просто, обычно для этого достаточно хорошо писать. Но с моей стороны было бы нечестно просто сказать “пишите лучше” и уйти. Вот 4 простых правила, которым вы должны следовать, чтобы написать требования, которые действительно читают.
Правило 1: будьте забавным
Ага, первое правило как обхитрить людей, чтобы они читали требования, это сделать этот процесс приятным. Не говорите мне, что у вас нет чувства юмора, я на это не куплюсь. У каждого из нас постоянно возникают забавные идеи, только мы их самоцензурируем, потому что думаем, что будем выглядеть “непрофессионально”. Что ж. Правила иногда приходится нарушать.
Если вы читали тот мусор, который я пишу в своем блоге, то вы заметили несколько моих неудачный попыток быть смешным то тут, то там. Всего четыре абзаца назад я грубо шутил над мозгом и высмеивал менеджеров за игру в гольф. Несмотря на то, что я на самом деле не такой уж смешной, я все же стараюсь изо всех сил, и даже сам процесс шутки в попытках быть смешным сам по себе забавен. Когда вы пишите требования, то можете легко пошутить в примерах. Каждый раз когда вам надо рассказать историю о том, как будет работать функциональность, вместо того чтобы писать:
- Пользователь нажимает Ctrl+N, чтобы создать новую таблицу Сотрудников и начать вводить имена сотрудников.
пишите что-то вроде:
- Мисс Свинка, тыкает в клавиатуру карандашом для подводки глаз, потому что ее пальцы слишком толстые, чтобы нажимать отдельные клавиши, и жмет Ctrl + N, чтобы создать новую таблицу Бойфренды, где вводит единственную запись «Кермит».
Если вы почитаете Dave Barry, то обнаружите что один из самых простых способов быть забавным это быть чересчур точным, когда необходима точность. «Лоскутные мопсы» смешнее, чем «собаки». “Мисс Свинка” смешнее, чем просто “пользователь”. Вместо того чтобы говорить «особые интересы», говорите «фермеры левши, выращивающие авокадо». Вместо того чтобы говорить «Люди, которые отказываются убирать за своими собаками, должны быть наказаны», говорите, что их следует «отправлять в тюрьмы, где так одиноко, что заключенным приходится платить паукам за секс».
Да, кстати, если вы думаете, что быть забавным это непрофессионально, то мне жаль, но у вас нет чувства юмора. (Не отрицайте. Люди без чувства юмора всегда это отрицают. Вам не провести меня). И если вы работаете в компании, где люди будут меньше уважать вас, потому что ваши требования свежие, веселые и приятные, то найдите себе другую компанию, потому что жизнь чертовски коротка, чтобы тратить ее в таком суровом и жалком месте.
Правило 2: Пишите требования как код для мозга
Я думаю, что программистам очень сложно написать хорошие требования, и вот почему.
Когда вы пишите код, ваша целевая аудитория это компилятор. Да, я знаю, люди тоже будут читать ваш код, но в целом это непростая задача. Для большинства разработчиков достаточно сложно привести код в такое состояние, чтобы компилятор его успешно читал и интерпретировал; беспокоится о том, чтобы код очень легко читался, это роскошь в большинстве компания. Когда вы пишите:
void print_count( FILE* a, char * b, int c ){
fprintf(a, “there are %d %s\n”, c, b);}
main(){ int n; n =
10; print_count(stdout, “employees”, n) /* code
deliberately obfuscated */ }
или
printf(“there are 10 employees\n”);
вы получаете один и тот же результат. Если вы над этим задумаетесь, то сразу поймете почему большинство программистов пишут требования, которые похожи на:
Предположим, что функция AddressOf(x), которая определена как мапинг пользователя x на адрес электронной почты, который соответствует RFC-822, возвращает ANSI строку. Представим, что есть пользователь A и пользователь B, где A хочет послать электронное письмо пользователю B. Поэтому пользователь A создает новое сообщения с использованием (или нет) техник описанных в другом месте и набирает AddressOf(B) в поле для ввода, которое называется “To:”.
Такие же требования могут быть записаны как:
Мисс Свинка хочет пойти на обед, поэтому она начинает писать новый email и набирает адрес Кермита в поле “To:”.
Техническая заметка: адрес должен быть стандартным Интернет адресом (соответствует RFC-822).
Теоретически, оба этих требования “означают” тоже самое, кроме того, что первый пример невозможно понять, пока не декодируете его очень внимательно, а второй пример легко понять любому человеку. Программисты очень часто пытаются написать требования, которые похожи на толстые академические труды. Они думают что “правильные” требования должны быть “технически” правильными и тут они попались на крючок..
Ошибка в том, что когда вы пишите требования, кроме того чтобы они были корректными, их также должно быть легко понять. На языке программистов это означает, что нужно написать так, чтобы их мог “скомпилировать” мозг человека. Одно из основных отличий между компьютером и мозгом человека в том, что компьютер будет терпеливо ждать, пока вы четко опишите для него термины, которые будете использовать дальше. Но люди не поймут о чем вы говорите, если вы не начнете с того зачем это все нужно. Людям не нужно ничего декодировать, они хотят читать требования по порядку и понимать их. Для людей вам нужно сначала нарисовать общую картину и затем погружаться в детали. С компьютерными программами, вы начинаете сразу подробно описывать все детали. Компьютеру все равно имеют ли смысл названия ваших переменных или нет. Человеческий мозг же понимает вещи намного лучше, если вы можете нарисовать яркую картинку, рассказывая историю, даже если это всего лишь фрагмент истории. Наш мозг изначально развивался, чтобы понимать истории.
Если вы покажите опытному игроку шахматную доску, в середине партии в шахматы, то ему понадобится секунда или две, чтобы мгновенно запомнить позицию каждой фигуры. Но если вы поставите несколько фигур так, как они никогда не могут стоять в реальной игре (например, поместите несколько пешек в первый ряд или поставите обоих черных слонов на черные клетки), то игроку станет намного сложнее запомнить позицию фигур. В этом и есть одно из отличий нашего мозга от компьютерного. Компьютерная программа может одинаково легко запомнить оба состояния — возможное и невозможное. Принцип работы человеческого мозга — не случайный доступ; нейронные связи, как правило, усиливаются в нашем мозгу, и некоторые вещи легче понять, чем другие, потому что они встречаются чаще.
Поэтому, когда вы пишите требования, попробуйте представить того, кому вы их адресуете, и что вы просите их понять каждый шаг. Предложение за предложением, спросите себя, сможет ли их понять человек, который будет их читать, в том контексте, который вы рассказали. Если кто-то из вашей целевой аудитории не знает, что такое RFC-822, вам нужно либо дать определение, либо по крайней мере, поместить RFC-822 в технические заметки, чтобы менеджеры, которые будут читать требования не сдались и не бросили чтение, когда столкнутся с большим количеством технического жаргона.
Правило 3: Пишите как можно проще
Не используйте неестественный, формальный язык, потому что вы думаете, что непрофессионально писать простыми предложениями. Пишите так просто, как только сможете.
Люди используют такие слова, как «эксплуатировать», потому что они думают, что «использовать» выглядит непрофессионально. (Снова это слово «непрофессионально». Каждый раз, когда кто-то говорит вам, что вы не должны что-то делать, потому что это «непрофессионально», знайте, что у них закончились реальные аргументы.) Я думаю, что множество людей считает, что простой и ясный текст означает, что с ним что-то не так.
Разбивайте текст на простые предложения (прим. переводчика: автору не помешало бы использовать такой подход в своем блоге :) ). Если у вас не получается четко и понятно описать мысль в одном предложении — разбейте его на два или три небольших предложения.
Избегайте простыни текста: когда текст занимает всю страницу. Такие тексты пугают людей и они не читают их. Когда вы последний раз видели статью в популярном журнале или газете (прим. переводчика: или в блоге), которая состояла бы только из текста?
Журналы зайдут так далеко, что возьмут цитату из статьи и напечатают ее в середине страницы гигантским шрифтом, чтобы избежать появления полной страницы текста.
Используйте нумерованные или маркированные списки, рисунки, диаграммы, таблицы и много пробелов, чтобы чтение «выглядело» более плавным.
Ничто так не улучшает требования как множество скриншотов или макетов. Картинка может сказать больше, чем тысяча слов. Любой, кто пишет требования для Windows программ, должен купить себе Visual Basic и научиться его использовать для создания макетов экранов. (Для Mac, вы можете использовать REAL Basic; а для веб страниц Front Page или Dreamweaver) (прим. переводчика: к счастью, в современно мире появились более удобные инструменты для прототипирования). Затем снимайте скриншоты этих макетов (Ctrl+PrtSc) и вставляйте их в ваши требования.
Правило 4: Проверяйте и перечитывайте по несколько раз
Хм, ну, я изначально планировал провести здесь длинное объяснение для этого правила, но оно слишком простое и очевидное. Просмотрите и перечитайте ваши требования несколько раз, ОК? Когда вы найдете предложение, которое не очень легко понять, перепишите его.
Я сэкономил так много времени, не объясняя правило 4, что собираюсь добавить еще одно правило.
Правило 5: Не используйте шаблоны
Боритесь с искушением сделать стандартный шаблон для требований. На первый взгляд кажется очень важным, чтобы “все требования выглядели одинаково”. Совет: это не так. Что это меняет? Разве все книги на вашей книжной полке выглядят одинаково? Вы бы этого хотели?
Хуже того, если у вас есть шаблоны, то, как правило, в шаблон будут добавлять все больше разделов, которые, как вам кажется, важны для каждой функции.
Например: Большой Билл постановил, что с этого момента каждый продукт Microsquish должен содержать Интернет-компонент. Поэтому в требованиях появляется раздел, который называется “Интернет-компонент”. Когда кто-то пишет требования, не важно на сколько они тривиальные, ему приходится заполнять этот раздел, который называется “Интернет-компонент”, даже если они пишут требования к клавиатуре от Microsquish (А потом вы удивляетесь почему эти бесполезные кнопки для запуска IE вырастают как грибы на вашей клавиатуре).
Все эти обязательные секции копятся и шаблон становится слишком большим (Вот пример очень очень плохого шаблона для требований: кому, черт возьми, нужна библиография в требованиях? А глоссарий?) Проблема таких больших шаблонов для требований в том, что они пугают людей, которые эти требования должны писать, для них задача начинает выглядеть слишком сложной и унылой.
Требования — это такой документ, которые люди захотят читать. Если рассматривать их с этой точки зрения, то нет никакой разницы между эссе в The New Yorker или в школьной газете. Вы когда-нибудь слышали, чтобы профессор давал своим ученикам шаблоны, по которым они должны писать статьи в газете? Вы хоть раз читали две хорошие статьи, которые могли быть написаны по одному шаблону? Просто забудьте про эту идею.