8-900-374-94-44
Спек – происходит от английского слова specialization (сокращённо – spec) и переводится как специализация. Что такое спек? Это раздел характеристик или ветка талантов, выбранная у конкретного персонажа.
Этот термин появился в World of Warcraft несколько лет назад, а теперь используется почти везде.
У героев в онлайн-играх есть разные скиллы, таланты и абилки, зависящие от класса. В общем виде все скиллы представлены на дереве талантов, а ветка отвечает за конкретное направление. Например, у «дерева» мага есть три ветки – огонь, вода и земля. Если он развивает огонь, тогда у него огненный spec, если воду – водяной, и так далее. Проще говоря, это основное направление, которое развивает персонаж.
Логично, что вначале лучше качать что-то одно, чтобы достичь в этом направлении определённых успехов. В случае с магом, если вкладывать свободные очки в специализацию огня, то через несколько уровней можно получить мощный файрболл или заклинание с АоЕ-эффектом, например, метеор. Нельзя выучить все заклинания, так как получится имба, и разработчики уберут дисбаланс, то есть понерфят класс.
Спек в игре бывает двух типов – мейн и офф.
Зачем нужна второстепенная ветка? В первую очередь для удобства и улучшения геймплея. Если основная специализация предназначена для чего-то одного (только фарм или только PvP), то вторая добавит нужные скиллы и абилки. Например, в мейн для прохождения инстов и участия в бг, а в офф для фарма в одиночку.
Если вы проходите данж в мейн спеке, то участвуйте в роллах только для этой специализации. Даже если предмет подойдёт для оффа, ждите что ответят другие люди.
Если будете «нидить» в ролле всё подряд, вас перестанут брать в пати и внесут в чёрный список. На низких уровнях такое поведение ещё сойдёт с рук – новичков много и сложно всех запомнить. Но на высоких уровнях вас точно запишут и запомнят, после чего сложно будет найти подходящую группу для прохождения данжа.
«Какой у тебя офф спек – дд или танк?»
«30-й левел апну и возьму 2-й спек для ПвП»
«Зачем тебе меч для деф спека?»
gamebizclub.com
Около года назад мы уже писали о важности ТЗ и некоторых базовых принципах его написания. Однако эту тему смело можно отнести к вечным — сколько бы ни писали рекомендаций по написанию ТЗ, спеки писали, пишут и будут писать как попало. Не все, конечно… но многие :). Вот и Егору Бугаенко надоели очевидные недочеты в спеках, и он попытался просто и понятно объяснить, как избежать хотя бы самых основных. Предлагаем вашему вниманию перевод его статьи:
Есть прекрасная книга “Требования к ПО” авторства Карла Вигерса – собственно, о требованиях к ПО. Я считаю, что она обязательна к прочтению для каждого разработчика ПО. Не вижу необходимости повторять то, что там написано, но все же существует несколько очень простых и очень типичных ошибок, которые мы продолжаем допускать в наших спеках. Я вижу их в наших документах снова и снова, и поэтому решил дать краткий их обзор. Итак, вот они – самые критичные и типичные из них, с точки зрения программиста, читающего спецификацию.
Глава 4.3 известного стандарта IEEE 830-1998 гласит, что хорошая спецификация должна быть безошибочной, недвусмысленной, полной, логичной, упорядоченной, доказуемой, изменяемой и позволяющей отслеживать изменения. Итого 8 качеств. Затем стандарт объясняет их один за другим на очень доступном английском. Но разве у нас есть время читать эти скучные стандарты? Они для университетских профессоров и сертификационных комитетов. Мы же практики! Подождите, я шучу.
Неважно, насколько мал проект и до какой степени мы практики, всегда есть документ, объясняющий, что нужно сделать, и он может называться “спецификация требований к ПО”, или “спецификация”, или просто “спека”. Конечно, остается много места для творчества, но мы ведь инженеры, не артисты. Мы должны следовать правилам и стандартам, большей частью потому, что они делают наше общение проще.
Итак, я подхожу к сути. Спеки, которые я обычно вижу, нарушают, в общем-то, все 8 принципов, упомянутых ранее. Ниже – краткое изложение того, как именно они это делают. Кстати, все примеры взяты из настоящей документации к реальным коммерческим ПО-проектам.
Как насчет чего-нибудь подобного:
UUID определен по нарастающей, чтобы убедиться, что нет двух пользователей с идентичным номером учетной записи.
В чем разница между UUID и номером учетной записи? Это одно и то же? Кажется так, верно? Или, может быть, они различаются… Было бы здорово знать, что же скрывается за сокращением UUID. Это «unique user ID» (уникальный идентификатор пользователя) – или, может быть, «unified user identity descriptor» (единая характеристика идентификатора пользователя)? Без понятия. Я в заблуждении и хочу найти автора этого текста и сделать с ним (или с ней) что-нибудь плохое.
Мы пишем, чтобы быть понятыми, а не впечатлить читателя
Я уже писал, что у самых плохих технических спецификаций нет словаря терминологии. По моему опыту, это самая большая проблема во всех документах с техническими требованиями. Это не художественная литература! Не любовное письмо! Это техническая документация. Мы не можем жонглировать словами просто для того, чтобы было весело. Мы не должны использовать спецификации по продукту просто для самовыражения. Мы пишем их, чтобы читатель нас понял, а не впечатлился. И здесь действует то же правило, что и с диаграммами: если я вас не понимаю, вы сами виноваты.
Вот как этот текст будет выглядеть после хорошего редактирования:
UUID – уникальный идентификатор пользователя, натуральное 4хбайтовое число.
UUID определен по нарастающей, чтобы убедиться, что нет двух пользователей с идентичным номером учетной записи.
Так лучше?
Таким образом, первая и основная проблема – легкомысленное использование терминов и просто слов без предварительного определения их в словаре.
2. Вопросы, обсуждения, предложения, мненияВот такое я увидел совсем недавно в продуктовой спеке:
Я считаю, что нужно поддерживать несколько версий API. Какие у нас есть опции? Я бы предложил остановиться на варианте версионированных URL. Не стесняйтесь высказать здесь ваши мысли на этот счет.
Да, этот текст дословно существует в документе с требованиями. Во-первых, автор выражает свое персональное мнение. Во-вторых, автор спрашивает меня, какие в принципе возможности у нас здесь есть. А затем он предлагает, чтобы я рассмотрел что-то из этого, и следом приглашает меня к дискуссии.
Найдите ответы на все свои вопросы прежде, чем писать документ, именно за это вам платят
Впечатляет, не правда ли? Очевидно, автор – очень креативная личность. Но этого человека нужно держать как можно дальше от проектной документации. Это абсолютно не то, что ценится в документе с техническими требованиями. Нет, мы, конечно, ценим креативность, но все же есть 4 строго запрещенных вещи: вопросы, обсуждения, предложения и мнения.
Спецификации не должны содержать в себе никаких вопросов. Кому эти вопросы адресованы? Мне, программисту? Вы хотите, чтобы я реализовывал ПО или отвечал на ваши вопросы? Мне не интересен брейнсторминг с вами. Я ожидаю, что вы, автор требований, скажете мне, что нужно делать. Найдите ответы на все свои вопросы прежде, чем писать документ. Именно за это вам платят. Если у вас нет ответов, напишите там что-нибудь типа TBD («to be determined», “предстоит определить”). Но не задавайте вопросов. Это раздражает.
Документ с требованиями – не дискуссионный клуб. Как читатель спеки, я ожидаю увидеть, что именно должно быть сделано, безо всяких “может быть” или “мы можем сделать это и по-другому”. Конечно, вам нужно обсудить эти моменты, но сделайте это до того, как вы их задокументируете. Сделайте это где-нибудь в другом месте, в Скайпе, например, или в Слаке, или по электронной почте. Если вы действительно хотите обсуждения в документе, используйте Google Docs или Word с отслеживанием версий. Но когда дискуссия завершена, удалите ее историю из документа. Ее присутствие только вводит меня, программиста, в заблуждение.
Нет необходимости и в формулировании требований в виде предположений. Просто скажите, что должно быть сделано и как ПО должно работать, не бойтесь оказаться неправыми. Обычно люди прибегают к предположениям, когда они боятся высказать что-то прямо. Вместо того, чтобы сказать “приложение должно работать на устройствах с Android 3.x и выше», они говорят «Я бы предложил сделать приложение совместимым с Android 3.x и выше.» Чувствуете разницу? Во втором предложении автор пытается избежать личной ответственности. Он не говорит «однозначно Android 3.x», он всего лишь предлагает. Не будьте трусом, говорите прямо. Если вы ошибетесь, мы вас поправим.
И, конечно, мнения вообще не в почете. Это не письмо другу; это официальный документ, относящийся к проекту. Через несколько месяцев или недель вы можете покинуть проект, и кто-то другой будет работать с вашим документом. Спека – как контракт между инвестором проекта и проектной командой. Мнение автора документа не имеет здесь никакого значения. Вместо того, чтобы заметить, что “кажется, Java была бы быстрее” и предположить, что “нам следовало бы использовать ее”, скажите “Java быстрее, и мы должны использовать ее”. Очевидно, что вы говорите об этом здесь потому, что так думаете. Но когда это отражено в спеке, нам неважно, от кого пришла эта мысль и что вы думали по поводу этой проблемы. Подобная информация только запутала бы нас, так что опустите ее. Только факты, никаких мнений.
Не поймите меня превратно, я не против креативности как таковой. Программисты – не роботы, беззвучно реализующие все, что написано в документе. Но беспорядочный документ не имеет никакого отношения к креативности. Если вы хотите, чтобы я что-то скреативил, определите мне границы этой креативности и позвольте экспериментировать в этих рамках; например:
Должны быть поддержаны несколько версий API. Как именно это сделано, не имеет значения.
Так вы предлагаете мне быть креативным. Я понимаю, что у пользователя проекта нет предпочтений или ожиданий от механизма версионирования в API. Я свободен делать что угодно. Отлично, я сделаю это по-своему.
Но опять же, повторюсь: спецификация – не дискуссионный комитет.
Вот как это выглядит:
Пользователь должен иметь возможность проскроллить весь список изображений в профиле плавно и быстро.
Это типичная ошибка практически всех спек, которые я видел. Здесь мы мешаем в одну кучу функциональные требования (скроллить изображения) с требованиями вне функциональности (скроллинг плавный и быстрый). Почему это плохо? Ну, особой причины нет, но это демонстрирует недостаток организованности.
Подобное требование тяжело перепроверить или протестировать, тяжело отследить и тяжело реализовать. Как программист, я не знаю, что важнее: реализовать скроллинг или убедиться, что скроллинг быстр.
Также тяжело изменить подобное высказывание. Если завтра мы добавляем другое функциональное требование – скроллинг списка друзей, например, – мы захотим потребовать, чтобы этот скроллинг также был плавным и быстрым. Затем спустя несколько дней мы захотим сказать, что “быстро” означает время реакции менее 10 миллисекунд. Соответственно, нам нужно будет продублировать эту информацию в двух местах. Видите, каким беспорядочным наш документ может стать в будущем?
Поэтому я бы настоятельно рекомендовал всегда документировать функциональные и нефункциональные требования отдельно.
Это похоже на предыдущую проблему и выглядит следующим образом:
Пользователь может загрузить PDF-отчет с полным списком транзакций. Каждая транзакция имеет свой ID, дату, описание, счет и итоговую сумму. Отчет также содержит общий итог и ссылку на счет пользователя.
Очевидно, что в этом абзаце описаны две вещи. Первая – пользователь может загрузить PDF-отчет. Вторая – как этот отчет должен выглядеть. Первое – функциональное требование, а вот второе должно быть описано в дополнительном документе (или приложении).
Как правило, функциональные требования должны быть очень краткими: пользователь загружает, пользователь сохраняет, клиент запрашивает и получает и т.д. Если ваш текст становится длиннее, что-то пошло не так. Попробуйте перенести часть этого в дополнительный документ.
Вот о чем я говорю:
Номера кредитных карт должны быть зашифрованы. Приложение должно запускаться менее чем за 2 секунды.
Каждая веб-страничка должна открываться быстрее, чем за 500 миллисекунд.
Каждый интерфейс должен быть респонсив.
Я могу найти множество примеров, просто открыв спеки с требованиями ко многим проектам, которые я видел за последние несколько лет. Они все выглядят одинаково. И проблема всегда одна и та же: очень сложно определить по-настоящему тестируемое и измеряемое нефункциональное требование.
Да, это сложно. Главным образом потому, что замешано много факторов. Возьмем, к примеру, вот эту строчку: “Приложение должно запускаться менее чем за 2 секунды”. На каком оборудовании? С каким количеством данных в профиле пользователя? Что означает “запускаться”; включает ли это в себя время загрузки профиля? Что, если есть проблемы при запуске? Они в счет? И есть еще много подобных вопросов.
Если мы отвечаем на все из них, текст с требованиями займет целую страницу. Никто этого не хочет, но неизмеряемые требования – еще большее зло.
Опять же, это непросто, но это необходимо. Попробуйте убедиться, что все требования к качеству сформулированы полностью и без двусмысленностей.
Этот пример иллюстрирует очень частую типовую ошибку:
Пользователь авторизуется через кнопку “Войти” на Фейсбуке, и мы сохраняем имя пользователя, аватарку и email в базе данных.
Это микроменеджмент, и аналитик технических требований никогда не должен делать этого с программистом. Вы не должны говорить мне, как реализовать функциональность, которую вы хотите. Вы хотите дать пользователю возможность залогиниться через Фейсбук? Так и скажите. Вам действительно важно, будет это происходить по клику на кнопку или как-либо по-другому? Вам действительно важно, что я сохраняю в базу данных? А что, если я использую файлы вместо базы данных? Вам это важно? Я так не думаю. Это действительно имеет значение только в очень редких случаях. В большинстве случаев это просто микроменеджмент.
Спека должна требовать только то, что действительно важно для бизнеса. Все остальное предоставлено нам, программистам. Мы решаем, какую базу данных использовать, где поместить кнопку и какая информация будет сохраняться в базе данных.
Вы не должны говорить мне, как реализовать функциональность, которую вы хотите
Если вам это действительно важно, потому что есть определенные ограничения более высокого уровня, – так и скажите. Но опять же, не в виде инструкции по реализации для нас, программистов, но скорее как нефункциональное требование наподобие следующего:
Страница с логином должна выглядеть следующим образом (скриншот во вложении).
Мы должны сохранять email пользователя локально для последующих нужд.
Смысл в том, что я ничего не имею против требований, но я сильно против инструкций по реализации.
Текст может выглядеть следующим образом:
PDF-отчет генерируется по требованию. Отчет можно скачать или сохранить в своем профиле.
Здесь проблема в том, что не вовлечен “деятель”. Сама функциональность более-менее ясна, только непонятно, кто все это делает. Где пользователь? Это просто история о чем-то, что где-то происходит. Это не совсем то, что нужно разработчику для того, чтобы это имплементировать.
В хороших “пользовательских” требованиях всегда есть… Угадайте, кто?.. Пользователь
Лучший способ объяснить функциональность – это пользовательские требования. И в хороших пользовательских требованиях всегда есть… Угадайте, кто?.. Пользователь. Предложения всегда начинаются с “пользователь…”, за которым следует глагол. Пользователь загружает, пользователь сохраняет, пользователь кликает, печатает, удаляет, форматирует и т.д.
Совершенно необязательно, чтобы пользователь был человеком. Это может быть система, клиент RESTful API, база данных, да что угодно. Но всегда – кто-то. “Можно загрузить” – не пользовательское требование. Можно – кому?
Как насчет чего-нибудь такого:
Больше всего нас интересуют производительность и привлекательный пользовательский интерфейс.
Это шум. Я, читатель этого документа, – не инвестор и не пользователь. Я программист. Меня не волнует, что больше всего интересует вас в этом проекте. Моя задача – реализовать продукт в соответствии со спеками. Если вас больше всего интересует производительность, создайте мне требования, которые можно измерить и протестировать. Я обеспечу соответствие продукта этим требованиям. Если вы не можете создать требования, не засоряйте информационное пространство этими не имеющими значения сведениями.
Разве хороший программист не сообразит сам, что означает “хорошая производительность”?
Я не хочу делить с вами ваши заботы, верования или намерения. Это ваше дело. И вам платят за то, чтобы четко и недвусмысленно перевести все это в требования, которые можно измерить и протестировать. Если вы не можете этого сделать, это ваша проблема и ваша вина. Не пытайтесь переложить ее на меня.
Очень часто… Подождите. Очень-очень часто. Нет. Почти всегда. Опять не так. Всегда! Именно, спеки всегда полны шума. В некоторых его чуть поменьше, в других – побольше. Я считаю, что это симптом ленивого и непрофессионального автора документа. В большинстве случаев – просто ленивого.
Такие авторы не хотят думать и переводить свои заботы, идеи, мысли, намерения и цели в функциональное и нефункциональные требования. Они просто указывают их в документе и надеются, что программист как-нибудь найдет правильное решение. Ведь разве хороший программист не сообразит сам, что означает “хорошая производительность”? Давайте просто скажем ему, что нас интересует производительность, и он что-нибудь придумает.
Нет! Не делайте так. Делайте свою работу и предоставьте программистам заниматься своей. А мы, программисты, никогда не должны принимать подобные документы. Мы просто должны отказываться с ними работать и просить автора требований переработать их и убрать шум. Я бы рекомендовал даже не начинать работу над продуктом, если в его спеках полно шума.
Вот еще одна очень типичная ошибка:
API будет поддерживать JSON и XML. Оба формата должны полностью поддерживать все информационные элементы. XML должен быть подтвержден XSD-схемой.
Видите, как беспорядочно это звучит? Три разных точки зрения, и ни одна из них не подходит для спецификации. Спека должна описывать продукт, как будто он уже существует. Спека должна звучать как руководство, инструкция, справка. Этот текст следует переписать, например, так:
API поддерживает JSON и XML. Оба формата
Полностью поддерживают все информационные элементы. XML подтвержден схемой XSD.
Видите разницу? Все эти словечки “должно” и “будет” только добавляют сомнений в документ. Для читателя такой спеки “API будет поддерживать” звучит как “когда-нибудь в будущем, может быть, в следующей версии, оно будет поддерживать”. Это не то, что автор имел в виду, верно? Не должно быть сомнений, двойных значений, возможности. API поддерживает. Вот и все.
Возможно, я и забыл что-то важное, но приведенные проблемы так очевидны и так раздражают… Я буду использовать этот пост в качестве простого руководства для наших системных аналитиков.
Мы выражаем огромную благодарность аккаунт-менеджеру Галине за вдумчивый перевод этой бесспорно полезной статьи! Надеемся, он поможет сделать жизнь многих русскоязычных техписателей (да и программистов) легче.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
blog.noveogroup.ru
Ричард Франклин Спек (англ. Richard Franklin Speck 6 декабря 1941 — 5 декабря 1991) — американский массовый убийца, убивший восьмерых медсестёр в Чикагском общежитии и приговорённый за это к смертной казни, заменённой на пожизненное лишение свободы. Умер в тюрьме после 25 лет заключения.
Ричард Спек родился 6 декабря 1941 года в небольшом посёлке «Кирвуд», что в шести милях от города Мэнеч в западной части штата Иллинойс, США. В семье Бенджемина Франклина Спека и Маргарет Мери Спек. Он был седьмым из восьми детей в семье. Вскоре после рождения в 1943 году его младшей сестры — Каролины Спек, семья перебралась в Мэнеч, где его отец устроился на работу упаковщиком товара на одном из коммерческих предприятий. У Спека были очень близкие отношения с отцом, однако тот умер в начале 1947 года от сердечного приступа в возрасте 53-х лет.[1] В 1949 году его мать повстречала страхового агента из Техаса, Карла Августа Рудольфа Линдберга, который был полной противоположностью отца Спека. Он был ленивым, обладал сильным пристрастием к алкоголю и был несколько раз задержан полицией за вождение в нетрезвом виде. Тем не менее 10 мая 1950 года они поженились в городе Пало—Пинто, штат Техас, США. В это время Спек и его младшая сестра оставались с их старшей сестрой Сарой Торонтон, которая к тому времени уже вышла замуж. После того, как Ричард закончил 2-й класс он был забран его матерью и они перебрались в городок Санто, что в сорока милях от Форта—Уайт в Техасе, где Спек пошел в третий класс.[1] Через год они перебрались в Даллас, штат Техас, США.
В Далласе семья Спека жила в одном из беднейших и неблагополучнейших районов города. Спек ненавидел своего отчима за то, что тот мог не приходить домой по нескольку дней, почти всё время пил, избивал и оскорблял Ричарда, а также подвергал его моральному давлению.[1] С четвёртого по восьмой класс он проучился в государственной школе Далласа, где ему нужны были очки для чтения, но он отказывался их носить.[2] В 1952 году в автомобильной аварии погиб старший брат Ричарда — 23-х летний Роберт Спек. Осенью 1957 года из-за проблем с алкоголем 15-ти летний Ричард Спек поступил в «Crozier Technical High School», однако бросил её в январе 1958 года отчасти из-за проблем с оценками и алкоголем. В конце 1954 года в возрасте 13 лет Ричард Спек впервые начал пробовать употреблять алкоголь. В конце 1956 года в возрасте 15 лет он начал напиваться почти каждый день. В 1955 году он впервые был задержан полицейскими. В течение последующих 8 лет он ещё несколько раз подвергался арестам за различные мелкие преступления, совершенные им в основном в состоянии алкогольного опьянения.[1]
Ричард Спек работал разнорабочим на предприятии по розливу пива «7-Up bottling company» с 24 августа 1960 по 19 июля 1963 года. В октябре 1961 года 19-ти летний Ричард Франклин Спек познакомился с 15-ти летней Ширли Аннет Мэлоун. В ноябре 1961 года она забеременела, а 19 января 1962 года они поженились. В это время его отчим мать и 16-ти летняя сестра Коралина переехали в Калифорнию. 5 июля 1962 года Шили родила Спеку дочь — Робби Линн. В это время Ричард отбывал трёхнедельное заключение в местной тюрьме за пьяный дебош и драку в местном баре.[1] В конце июля 1963 года Ричард Спек был арестован за кражу 44$, трёх банок пива и пачки сигарет из местного продуктового магазина. 16 сентября 1963 года он был приговорён судом к трём годам тюрьмы, однако отсидев полтора года 2 января 1965 года был условно—досрочно освобождён из «Huntsville Unit Prison».[1] Через неделю — 9 января 1965 года около 2:20 ночи по местному времени вооружённый ножом Ричард Спек напал с целью ограбления на женщину на парковке недалеко от своего дома. Она закричала и преступник скрылся, однако спустя несколько часов он был задержан полицейскими в нескольких кварталах от места происшествия. Ему были предъявлены обвинения в нападении при отягчающих обстоятельствах и он был приговорён к 16 месяцам тюрьмы и возвращён в «Huntsville Unit Prison». Однако из-за ошибки он был выпущен уже 2 июля 1965 года.[1]
С июля по октябрь 1965 года Спек работал водителем грузового автомобиля для «Patterson Meat Company», он попадал в аварии на рабочем грузовике по крайней мере 6 раз за время работы, однако причиной его увольнения стало пьянство и прогулы. В декабре 1965 года Ширли Аннет Мэлоун подала на развод и по рекомендации своей матери Спек ушёл жить к знакомой 29-тилетней женщине, которой нужен был кто-нибудь, кто бы присматривал за её тремя детьми, пока она была на работе. Во второй половине января 1966 суд принял решение развести Шелли и Ричарда. В конце того же месяца Спек был вновь арестован за то, что в пьяной драке ранил соперника ножом. Ему были предъявлены обвинения в нападении при отягчающих обстоятельствах, однако каким-то чудом Спеку удалось отделаться лишь 10$ штрафа и 3 днями заключения. 5 марта 1966 года Ричард приобрёл автомобиль. А вечером 6 марта он украл 70 блоков сигарет из местного магазина, а затем продал их на соседней улице. Спеку стал угрожать арест и 42-х летнее тюремное заключение в Даллаской тюрьме, поэтому 9 марта 1966 года с помощью своей 22-х летней сестры Каролины он был отвезён на автобусную остановку, где он сел на автобус следующий в Чикаго.
Первые несколько дней Ричард жил у своей старшей сестры Марты Торонтон вместе с её семьёй в Чикаго. Затем вернулся в город своего детства — Мэнеч. Первое время он жил с друзьями детства, однако вскоре он повстречал своего брата Говорда работающего плотником в Мэнече и тот помог ему устроиться на работу — шлифовальщиком гипсокартона. 16 марта 1966 он узнал, что его бывшая жена вновь вышла замуж. Это очень огорчило Ричарда и он 9 дней провел в запое в местном баре до 25 марта. В 30-х числах марта Спек угрожая ножом ограбил в туалете местного бара одного из посетителей. 3 апреля 1966 года Спек проник в дом одной 65-тилетней жительницы Мэнеча, связал и изнасиловал ее а затем украл 2,5$ и скрылся. 15 апреля 1966 Спек был допрошен полицейскими по поводу убийства 32-хлетней барменши Мери Кау Пирс, которую якобы видели последний раз 9 апреля 1966 года в 12:45 утра выходившую из бара вместе со Спеком. Не добившись ничего они попросили его оставаться в городе для дальнейших допросов, однако он скрылся из города 19 апреля 1966.[1]
19 апреля 1966 года Ричард Спек вернулся на квартиру к своей сестре. Она жила в северо-восточной части Чикаго на квартире с мужем Генри железнодорожником по профессии и двумя дочерьми-подростками. Сара Торон была медсестрой. Спек рассказал им историю, что якобы ему пришлось бежать из Мэнеча, потому что он отказался продавать наркотики по приказу местной мафии. 25 апреля 1966 его взяли учеником моряка на флот при этом потребовали фотографию, справку от врача и отпечатки пальцев.[1] Сразу после получения доверенности и разрешения на работу он присоединился к экипажу грузового судна «Clarence B. Randall» из 33-х человек. 30 апреля 1966 он пошёл в своё первое плавание по озеру Мичиган. 3 мая 1966 Спек был эвакуирован береговой охраной США в госпиталь Святого Иосифа в Хэнкоке, штат Мичиган, где ему был удален аппендикс.[1] 20 мая 1966 он был выписан из больницы и вернулся на корабль. 14 июня 1966 года в состоянии алкогольного опьянения устроил драку с одним из офицеров на корабле, и был высажен 15 июня на острове Святого Эльма. Там он сел на поезд и приехал в Хэнхок штат Мичиган, где некоторое время жил у 28-милетней медсестры Джуди Лаканеми с которой познакомился в госпитале Святого Иосифа. 27 июня она дала ему 80$ на первое время до нахождения работы, после чего он вернулся в дом сестры в Чикаго.[1] 30 июня 1966 его вновь попытался устроить на работу Генри.
В пятницу 8 июля 1966 года Ричард Спек благодаря своему удостоверению моряка устроился на работу и стал ожидать назначения на судно. Он почти весь день проторчал в баре, а затем вернулся к сестре на квартиру. В понедельник 11 июля 1966 муж сестры уставший от нахождения Ричарда Спека в его семье и почти постоянно пьянства его же выгнал Ричарда из дома и тому пришлось ночевать в ночлежке для БОМЖей в районе Восточного парка в Сант-дибринг, Чикаго. Во вторник 12 июля 1966 он наконец получил назначение на танкер «SS Sinclair Oil» на озере Синклер в штате Индиана. Через 30 минут он на автомобиле прибыл на место, однако оказалось, что его место на танкере уже занято и Спек вновь остался без работы. Он вернулся в Чикаго, но у него не хватало денег на ночлежку и ему пришлось ночевать в недостроенном доме.[2] Почти весь день 13 июля 1966 он провёл в местном баре, при этом он угрожал ножом 53-хлетней Элле Мей Хупер, которую он силой заставил привести его к себе домой, а затем связал и изнасиловал. Уходя, он похитил из её комнаты револьвер 22 калибра и 25$ и вернулся назад в бар для продолжения питья. Около 22:20 он покинул бар в состоянии сильного опьянения одетый во все чёрное, вооружённый двумя ножами и револьвером и направился в сторону Чикагского женского медсестринского общежития.[1]
В 23:00 13 июля 1966 года 24-х летний Ричард Спек ворвался в общежитие и, угрожая ножом и револьвером, связал девятерых медсестёр, находившихся там. После этого на протяжении нескольких часов он стал выводить девушек по одной в другие комнаты, где насиловал и убивал их. С последней жертвой Глорией Деви он практиковал некрофилию, сначала убив, а лишь потом изнасиловав её. Единственная выжившая медсестра Кора Амурао закатилась под кровать, чем спасла свою жизнь. Она оставалась под кроватью до 6 утра 14 июля 1966 года, пока Спек, прихватив кое-какие ценные вещи и деньги, не ушел. После чего она выбралась из общежития через окно в своей комнате и начала кричать «Они все мертвы! Все мои друзья убиты!». В результате резни погибли Глория Дэви, Патриция Mатушек, Нина Джо Шмале, Памела Уайлкенинг, Сюзанна Ферис, Мэри Энн Джордан, Мерелита Гаргуло и Валентина Песион.[3]
Сразу после прибытия полиции на место Кора Амурао была увезена в больницу в состоянии сильного шока и с несколькими ножевыми ранениями. Оперативную группу по розыску преступника возглавил лейтенант управления Чикагской полиции Эмиль Гизе, он сравнил оставленные на месте преступления отпечатки пальцев с предоставленным ФБР досье и получил совпадение. Полиция вышла на след подозреваемого 15 июля 1966. Спек, пьющий недалеко от места преступления, был замечен бродягой Клодом Лунсфордом. В это время полиция составила по его описанию фоторобот Ричарда Спека и разослала его во все газеты. 16 июля 1966 около 20:30 Лунсфорд позвонил в полицию и сказал, что подозреваемый замечен входящим в отель «Старр», однако полиция не обратила никакого внимания на звонок бродяги. В номере отеля Спек в ночь на 17 июля 1966 года попытался покончить с собой, вскрыв себе вены, однако он был доставлен в больницу графства Кук в 0:30 ночи 17 июля. В больнице Спека опознал 25-тилетний доктор Лерой Смит, читавший незадолго до этого заметку о преступлении Спека в газете. Прибывшая полиция арестовала Ричарда Спека, при этом не имея сомнений, что именно он совершил массовое убийство.[4]
Для того, чтобы выяснить был ли вменяем Спек при совершении преступления, была создана специальная комиссия из трёх врачей, однако этого не было достаточно, и к ним присоединились ещё несколько, и в итоге общая комиссия составила 5 психиатров и один хирург. Пока они разбирали психику Спека, тот в это время проходил курс психотерапии по два раза в неделю в тюрьме «Cook County Jail» у тюремного психиатра доктора Марвина Зипрона. В своём отчёте о состоянии Ричарда Спека тот писал, что преступник чувствует вину и раскаяние в своих действиях, а также страдает клинической депрессией. Наряду с сильной ненавистью к женщинам у него присутствует такая же сильная любовь к матери и сёстрам. Также у Спека вследствие раннего начала употребления алкоголя имелись некоторые органические поражения головного мозга, которые отразились на психике Ричарда. В итоге психологическая экспертиза, длившаяся с 29 июля 1966 по 13 февраля 1967, завершилась, и в своём докладе комиссия признала его полностью вменяемым на момент совершения преступления.[4] Сам доктор Зипрон был отстранён от дачи показаний на суде по причине того, что писал книгу о Спеке с целью получения финансовой выгоды. В это он также был уволен с работы. Однако книга была опубликована летом 1967 года с согласия Спека.[3]
Суд начался 3 апреля 1967 года. 25-тилетнему Ричарду Франклину Спеку предъявили обвинения в 8 умышленных убийствах, изнасилованиях, покушении на убийство, повлёкшем за собой телесные повреждения, грабеже и незаконном ношении оружия (имелся в виду револьвер, украденный из дома Эллы Мей Хупер). Суд также не учёл преступления, совершенные Спеком в марте и апреле 1966 года. На суде Спек заявил, что совершал все свои преступления под воздействием наркотиков и алкоголя и не отвечал за свои действия. Также он заявил, что не собирался убивать девушек в общежитии, а первоначально лишь хотел ограбить их.[5] Единственная выжившая жертва опознала Ричарда Спека на суде. Лейтенант Эмиль Гизе выступил с заявлением о совпадении отпечатков пальцев Спека с отпечатками пальцев, найденными на месте преступления. 15 апреля 1967 года после 50-ти минутного совещания суд признал Ричарда Франлина Спека вменяемым и виновным по всем пунктам обвинения и приговорил к смертной казни на электрическом стуле. Спек подал апелляцию, однако 5 июня 1967 года приговор был оставлен без изменений.[6] Спек тут же подал последнюю возможную апелляцию в верховный суд Штата Иллинойс, который 22 ноября 1968 года также приговорил Ричарда Спекка к смертной казни на электрическом стуле.
28 июня 1971 года Федеральный суд США принял решение направить дело Ричарда Спека на пересмотр. Причиной этому стало обвинение со стороны штата Джоджия о неконституционности смертной казни в США. 29 июня 1972 года верховный суд штата Иллинойс начал пересмотр дела Ричарда Спека. 21 ноября 1972 года в городе Пеория, судья Ричард Фитцджеральд повторно приговорил 30-тилетнего Ричарда Франклина Спека к 8 пожизненным срокам по 150 лет, или 1200 годам тюрьмы с правом на условно-досрочное освобождение через 10 лет с момента начала срока, вместо смертной казни.[7][8] Начиная с 15 сентября 1976 года Ричард Спек семь раз подавал прошения о помиловании и условно-досрочном освобождении в 1976, 1977, 1978, 1981, 1984, 1987, 1990 годах.
После замены смертной казни пожизненным заключением Ричард Спек был переведён из камеры смертников в общую зону тюрьмы первого уровня «Stateville Correctional Center» в городе Крест Хилл, Иллинойс, США. В тюрьме он держал двух голубей, которые прилетали к нему и которых он кормил. В тюрьме немного общался с другими заключёнными и прославил себя больше как одиночка. Он никогда не был образцовым заключённым. Несколько раз его ловили за употребление и распространение наркотиков, а также за самогоноварение. Однако он никогда не боялся дисциплинарных взысканий и всегда говорил: «Вы не можете сделать ещё хуже, у меня и так 1200 летний срок за решёткой»[9] Также в тюрьме он хранил коллекцию марок и аудиокассет. По отбытию 10 лет начальник тюрьмы разрешил ему хранить в камере радио. Спек также проявлял активность на тюремных работах. Чаще всего его посылали красить стены, либо вычищать от мусора склады. Также ему разрешалось читать газеты. Так в 1978 году после того, как его посетил журналист Боб Грин. Позже сам Спек читал колонку своего интервью в «Chicago Tribune». Это было первое интервью, где Ричард Спек публично признался в убийстве, а также заявил, что планирует получить условно-досрочное освобождение до 2000 года. И заявил, что после освобождения планирует заняться бизнесом и открыть свой собственный магазин.[9] Когда Гринн спросил, не пытался ли Спек сравнивать себя с другими знаменитыми преступниками, например Джоном Диллинджером, Ричард заявил: «Я не такой как они, я единоличный». Также он говорил, что раскаивается в своём преступлении и сказал, что если бы он мог вернуть тот день, то он бы просто ограбил их и никого не убивал и не насиловал. Когда один из заключённых спросил его, почему тот убил студенток, Спек в шутку ответил: «Это был просто не их день»[10] Также в 1988 году появились слухи о том, что Спек оказывал оральные услуги другим заключённым за дозу кокаина или героина.[11]
Ричард Франклин Спек умер в 6:05 утра 5 декабря 1991 года в тюремной больнице «Silver Cross Hospital», куда был доставлен с жалобами на боли в груди, от сердечного приступа, всего за день до своего 50-тилетия.[12] Сёстры и братья Ричарда Спека отказались от его тела, так как боялись осквернения его могилы. В итоге его тело было кремировано в присутствии тюремного священника, начальника тюрьмы и нескольких охранников, а прах был развеян в неизвестном месте. По описанию тюремного священника, они всего лишь прочитали несколько молитв, а затем развеяли прах Спека.[12]
dic.academic.ru