Начиная работать руководителем команды программистов 7 лет назад, я наткнулся (или кто-то посоветовал, уже не помню) на блог Джоэла Спольски. Джоэл пишет с юмором и не понаслышке знаком с проблемами, с которыми сталкиваются компании разрабатывающие программы и сервисы. Прошли годы, но его статьи про требования до сих пор актуальны и я рекомендую познакомится с ними всем менеджерам проектов и продуктов, которые только вступают на этот путь.
Для тех, кто хочет познакомится с оригиналом — Painless Functional Specifications — Part 1: Why Bother? Я, как всегда, открыт к любым замечаниям по моему переводу!
Когда впервые вышел Тест Джоэла, одна из самых больших проблем, о которой сообщили читатели, была связана с написанием требований. Системные требования похожи на зубную нить: все знают, что им стоит писать требования, но никто этого не делает.
Почему люди не пишут требования? Они утверждают, что они экономят время, пропуская этап написания требований. Они ведут себя так как будто написание требований это роскошь, зарезервированная за инженерами космического челнока NASA или людьми, которые работают в гигантских страховых компаниях. Чушь собачья. Во-первых, неспособность написать требования — это самый большой ненужный риск, который вы берете на себя в программном проекте. Это так же глупо, как отправиться пересекать пустыню Мохаве налегке, надеясь «сымпровизировать». Разработчики, которые погружаются в написание кода без требований, думают, что они крутые ковбои, стреляющие от бедра. Но это не так. Они ужасно непродуктивны — пишут плохой код и выпускают откровенно плохое программное обеспечение. Они угрожают своим проектам, принимая на себя гигантские риски, которые совершенно бессмысленны.
Я верю, что любой нетривиальный проект (требующий больше одной недели на написание кода или больше одного разработчика), который вы разрабатываете без требований, всегда займет у вас больше времени и вы получите код плохого качества. И вот почему.
Самая важная функция требований — это проектирование программы. Даже если вы кодите сами, и пишите требования для себя, сам процесс написания требования — подробное описание как именно будет работать программа — заставит вас выполнить проектирование программы.
Давайте встретимся с двумя воображаемыми программистами в двух компаниях. Спиди, работает в компании Hasty Bananas Software, никогда не пишет требования: “Требования? Нам не нужны эти вонючие требования!” В тоже время, мистер Роджерс, работающий в The Well-Tempered Software Company, отказывается писать код, пока требования не были зафиксированы окончательно. И это только два из множества моих воображаемых друзей.
У Спиди и мистера Роджерса есть одно общее: оба они отвечают за обратную совместимость с версией 2.0 их продуктов.
Спиди решает, что лучший способ обеспечить обратную совместимость — это написать конвертер, который просто конвертирует файлы для версии 1.0 в файлы версии 2.0. Спиди берется за работу. Набирает, набирает, набирает. Кликает, кликает, кликает. Компьютер работает. Пыль летает. Примерно через 2 недели у нее получается неплохой конвертер. Но клиенты компании Спиди недовольны. Код Спиди заставляет их обновить все установки в их компании до новой версии продукта. Самый большой клиент компании Спиди, Nanner Splits Unlimited, отказывается покупать новую версию продукта. Nanner Splits хочет, чтобы версия 2.0 поддерживала работу с файлами версии 1.0 без конвертации. Тогда Спиди решает написать обратный конвертор и повесить его на функцию “Сохранить”. Получится небольшой бардак, потому что когда ты используешь новую функциональность версии 2.0 все работает, до тех пор пока ты не сохранишь данные в файле в формате для версии 1.0. Только в этот момент ты узнаешь, что функциональность, которую ты использовал полчаса назад, не работает со старым форматом файла. Итого, разработка обратного конвертера заняла еще две недели, и результат получился так себе. Итого затрачено 4 недели.
Вернемся к мистеру Роджерсу из Well-Tempered Software Company, который принадлежит к одному из тех типов всезнаек, который отказывается писать код до тех пор пока не получит требования. Он тратит около 20 минут на проектирования обратной совместимости так же, как это сделала Спиди, и получает требования, которые выглядят так:
- Когда пользователь открывает файл, созданный старой версией продукта, файл конвертируется в новый формат.
После чего он показывает их клиенту, который говорит: “Подождите минутку! Мы не хотим обновлять все установки продукта одновременно!” Мистер Роджерс еще подумал и исправляет требования следующим образом:
- Когда пользователь открывает файл, созданный старой версией продукта, файл конвертируется к новому формату в памяти. Когда пользователь сохраняет этот файл, ему предлагают сконвертировать его обратно.
Прошло еще 20 минут.
Босс мистера Роджерса внимательно смотрит на эти требований и думает, что это не самый лучший подход. И предлагает другую архитектуру:
- Код будет написан для работы с двумя интерфейсами: V1 и V2. V1 содержит все функции, которые были в первой версии. А версия V2, которая наследуется от версии V1, добавляет всю новую функциональность. Теперь V1::Save может использоваться для обратной совместимости, в то время как V2::Save будет использоваться для сохранения всех новых штук. Если вы открываете V1 файл и пытаетесь использовать функциональность из версии V2, то программа может сразу предупредить вас, и вы можете либо сконвертировать файл, либо не использовать новую функциональность.
Еще 20 минут.
Мистер Роджерс ворчит. Этот рефакторинг потребует целых 3 недели, вместо тех 2 недель, в которые он изначально оценил задачу! Но он решает все проблемы клиента и решает их элегантно, поэтому он сдается и делает рефакторинг.
Суммарное потраченное время мистером Роджерсом: 3 недели и 1 час. Время потраченное Спиди: 4 недели и код получился “грязный”.
Мораль этой истории в том, что с надуманным примером вы можете доказать что угодно. Упс. Это не то, что я хотел сказать. Мораль истории в том, что когда вы проектируете свой продукт на человеческом языке, потребуется всего пару минут, чтобы подумать о некоторых возможностях реализации, пересмотреть и улучшить проект реализации. Никто не чувствует себя плохо, когда удаляет абзац текста в текстовом редакторе. Но когда вы проектируете фичу в продукте сразу в коде (например, пишите интерфейсные классы или тесты), требуются недели для итеративного завершения проектирования. Что еще хуже — программист, который потратил 2 недели на написание какого-то кода, будет привязан к этому коду, вне зависимости от того какого он качества. Чтобы не сказал босс Спиди или клиенты, это не убедит Спиди выкинуть ее красивый код конвертации, даже если архитектура была не лучшая. В результате продукт внутри состоит из компромиссов между первоначальной, неправильной архитектурой и идеальной архитектурой. Вы получаете «лучшую архитектуру, которую мы могли получить, учитывая, что мы уже написали весь этот код, и просто не хотели его выбрасывать». Не так хорошо, как «лучший дизайн, который мы могли бы получить, точка».
Итак, это первая гигантская причина для написания требования. Гигантская причина номер два — сэкономить время на коммуникациях. Когда вы пишите требования, вам надо обсуждать то, как должна работать программа только один раз. Все остальные члены команды могут просто прочитать требования. QA могут прочитать их и понять как должна работать программа и как им проверить корректную работу. Маркетинг может использовать эти требования и подготовить материалы для выкладки на сайте информации о продуктах и фичах, которые еще не были реализованы. Люди, занимающиеся развитием бизнеса, читают и неправильно понимают эти требования, фантазируя о том, как продукт излечит облысение, бородавки и все такое, но он привлекает инвесторов, так что все в порядке. Разработчики также читают эти требования и теперь они знают какой код нужно написать. Клиенты читают их и убеждаются, что разработчики делают такой продукт, за который они готовы платить. Технические писатели читают требования и пишут отличные инструкции (которые теряются или выбрасываются, но это совсем другая история). Менеджеры читают их, чтобы они могли выглядеть так, как будто они знают что происходит на митингах менеджеров. И так далее.
Когда у вас нет требований, все эти люди все равно общаются между собой о задаче, потому что это необходимо, но это происходит ad hoc. QA дурачаться с программой, и когда они встречают что-то странное, они встают и снова, и снова прерывают разработчиков, чтобы задать им еще один глупый вопрос, как это должно работать. Кроме того факта, что это разрушает продуктивную работу разработчиков, разработчики склонны давать ответ, который соответствует тому, что они написали в коде, а не «правильный ответ». Это приводит к тому, что QA тестируют программу в сравнении с программой, вместо сравнения с проектом, что немного полезнее.
Когда у вас нет требований, самое забавное происходит с вашими техническими писателям (в печальном смысле). В большинстве случаев у технических писателей нет политического влияния чтобы прервать работу разработчиков. Во многих компаниях, если технический писатель привыкает прерывать работу разработчиков, чтобы спросить как это должно работать, то разработчики идут к своим менеджерам и жалуются, что они не могут работать из-за этих [описание удалено] писателей. И разработчики просят пожалуйста держите их подальше, и менеджеры, пытаясь улучшить производительность, запрещают техническим писателям тратить время их драгоценных разработчиков. Вы легко найдете такие компании, потому что их файлы справки и мануалы не дают вам вообще никакой дополнительной информации, кроме той, что вы и так видите на экране. Когда вы видите на экране сообщение, которое спрашивает вас:
- Вы хотите включить поддержку LRF-1914?
… и вы нажимаете “Помощь”, и появляется трагикомическая справка, в которой говорится что-то вроде:
- Позволяет вам выбрать поддерживать LRF-1914 (значение по умолчанию) или не поддерживать LRF-1914. Если вы хотите поддерживать LRF-1914, нажмите “Yes” или нажмите “Y” на клавиатуре. Если вы не хотите поддерживать LRF-1914, нажмите “No” или нажмите “N” на клавиатуре.
Хм, спасибо, конечно. Очевидно, что в данном случае технические писатели пытались обойти тот факт, что они не понимают что такое поддержка LRF-1914. Они не могли спросить программиста, потому что (a) им стыдно, или (b) программист работает в Хайдарабаде, а они в Лондоне, или (c) менеджер запретил им отрывать программиста от работы или из-за любой другой корпоративной патологии, которых слишком много, чтобы упоминать, но фундаментальная проблема в том, что не было нормальных требований.
Гигантская причина номер три, без детальных требований невозможно спланировать работу. Отсутствие плана нормально в том случае, если у вас есть ученая степень и вы планируете потратить 14 лет на изучение проблемы, или если вы разработчик работающий над следующей частью Duke Nukem и вы планируете его выпустить, когда все будет сделано хорошо и готово для релиза. Но для любого реального бизнеса, вам нужно знать сколько занимает тот или иной этап работы, потому что разработка продукта стоит денег. Вы не купите пару джинс, пока не узнаете сколько они стоят. Также и бизнес решает разрабатывать продукт или нет, учитывая сколько времени займет разработка и, в итоге, сколько она будет стоить? Если вы хотите узнать больше про расписания, прочитайте Безболезненные Расписания.
Невероятно распространенная ошибка — дискуссия о том, как именно должна быть реализована функциональность, которая так и не была закончена. Брайан Валентайн, ведущий разработчик Windows 2000, прославился своим девизом «Decisions in 10 minutes or less, or the next one is free».
Во множестве компаний разработчиков, каждый раз когда разгораются дебаты по проектированию, никто, даже менеджеры, не принимает решения, обычно по политическим причинам. Таким образом программисты работают только над спорными вещами. Время идет, и все сложные решения откладываются на конец разработки. Это наиболее популярная причина провала проекта. Если вы создаете новую технологическую компанию, и замечаете, что она не способна принимать решения, вы стоит закрыть ее и вернуть деньги инвесторам, потому что вы никогда ничего не выпустите.
Написание требований — это отличный способ закрепить все эти раздражающие проектные решения, большие и маленькие, которые скрываются, если у вас нет спецификации. Даже маленькие решения могут быть зафиксированы в требованиях. Например, если вы создаете веб-сайт с личным кабинетом, вы можете решить, что делать, если пользователь забыл свой пароль — можно отправить его по email. Отлично. Но этого недостаточно чтобы написать код. Чтобы написать код, вам надо знать конкретные слова, которые будут в этом email. В большинстве компаний, программистам не доверяют формулировки, которые будет видеть реальный пользователь (и не зря, в большинстве случаев). Поэтому маркетолог или PR-специалист или от какого-то другого специалиста с хорошим английским потребуется точная формулировка сообщения: «Уважаемый Шлуб, вот пароль, который вы забыли. Постарайтесь не быть таким беспечным в будущем». Когда вы заставляете себя писать хорошие, полные требования (мы поговорим об этом подробнее чуть позже), вы замечаете все эти детали и вы либо исправляете их сразу, либо помечаете их большим красным флагом.
Отлично. Теперь мы в одном контексте. Specs are motherhood and apple pie. Я подозреваю, что большинство людей понимает это, и мои тирады, хоть и забавные, не учат вас ничему новому. Так почему же люди не пишут требования? Это не экономит время, потому что это не так, и я думаю, что большинство программистов признают это. (В большинстве организаций, единственные “требования” это одна страница текста, которую программист накидал в Блокноте после написания кода и после объяснения того, как работает это гребанная штука, сотне коллег.)
Я думаю, основная причина в том, что большинство людей просто не любит писать. Начинать с пустого листа ужасно расстраивает. Лично я справился со своим страхом письма, взяв класс в колледже, на котором требовалось писать 3–5 эссе каждую неделю. Написание похоже на мускул. Чем чаще вы пишите, тем проще и лучше вы сможете писать. Если вам нужно писать требования, и у вас не получается — создайте блог, возьмите уроки письма или просто напишите приятное письмо каждому родственнику и соседу по колледжу, которого вы не видели последние 4 года. Все, что связано с написанием слов на бумаге, улучшит ваши навыки написания требований. Если вы менеджер по разработке программного обеспечения и сотрудники, которые должны писать требования не пишут их, пошлите их на один из двухнедельных курсов по художественному письму.
Если вы никогда не работали в компании, которая пишет функциональные требования, то возможно вы никогда их не видели. В следующих частях, я покажу вам краткие, простые требования, в качестве примера и мы поговорим о том, какими свойствами должны обладать хорошие требования.