(Уже прочитали первую часть? Она находится здесь.)
Это серия статей о функциональных, а не о технических требованиях (и не о технических заданиях). Люди очень часто путают эти термины. Я не знаю есть ли какая-то стандартная терминология, но вот что я имею ввиду, когда использую эти термины.
- Функциональные требования описывают как продукт будет работать с точки зрения пользователя. Не важно как именно это будет реализовано. Они описывают функциональность (или фичи). Эти требования описывают интерфейсы, меню, диалоги и так далее.
- Технические требования описывают внутреннюю реализацию в программе. Они описывают структуры данных, модели баз данных, выбор языков программирования, инструментов, алгоритмов и так далее
Когда вы проектируете продукт, снаружи и внутри, самое важное это зафиксировать пользовательских опыт (User Experience). Какие пользователь увидит экраны, как они будут работать, что они будут делать. Позднее, вы будете беспокоится о том как именно это сделать. Нет смысла спорить о том, какой язык программирования выбрать, пока вы не решили что будет делать ваш продукт. В этой серии статей я говорю только о функциональных требованиях.
Я написал небольшой пример требований, чтобы показать вам как должны выглядеть хорошие функциональные требования. Прежде чем читать дальше, пожалуйста прочитайте их.
Прочитали?
Нет, не прочитали. Идите и прочитайте сейчас, а затем возвращайтесь, чтобы мы могли поговорить о том, что должно быть в хороших требованиях и чего там быть не должно. Я подожду вас здесь. Спасибо.
(терпеливо жду..)
О, вы вернулись. Отлично.
Вот несколько пунктов, которые я всегда включаю в любые требования.
Disclaimer. Самозащита в чистом виде. Если вы добавите параграф, который говорит что-то вроде “Эти требования находятся в работе”, люди не придут в ваш офис, чтобы откусить вам голову. Пройдет время, требования будут приближаться к завершенному виду, тогда вы измените этот параграф на “На мой взгляд, работа над требованиями завершена. Но если я что-то упустил, пожалуйста, дайте мне знать”. Это напомнило мне о том, что любым требованиям необходим:
Автор. Один автор. Некоторые компании думают, что требования должны писаться командой. Если вы хоть раз пробовали писать что-то группой, то знаете, что нет пытки хуже. Оставьте групповое творчество консалтинговым компаниях с их армиями новоиспеченных выпускников Гарварда, которым нужны тонны бесполезной работы, чтобы они хоть как-то могли обосновать невероятный ценник на свои услуги. Ваши требования должен писать один человек, который и будет их владельцем. Если у вас большой продукт, то разбейте его на области и для каждой области выделите независимого человека, который будет писать для нее требования. Другие компании думают, что это эгоистичный подход и “плохая командная работа”, когда один человек “берет себе в заслугу” сформированные требования, написав на них свое имя. Люди должны взять на себя ответственность за то, что они описывают. Если с требованиями что-то нет так, то у вас будет выделенный человек (которого легко найти, потому что его имя есть над требованиями), который отвечает за их исправление.
Сценарии. Когда вы проектируете продукт, в вашей голове должно быть несколько живых сценариев того, как люди будут его использовать. В противном случае вы проектируете продукт, который не соответствует реальной жизни (такой как Cue?Cat). Возьмите аудиторию вашего продукта и представьте себе вымышленного, абсолютно воображаемого, но абсолютно стереотипного пользователя из каждой целевой аудитории, который использует продукт совершенно типичным образом. Глава 9 моей книги UI-проектирование (бесплатно доступна online) рассказывает о создании таких вымышленных пользователей и сценариев. Чем ярче и реалистичнее сценарий, тем лучше у вас получится спроектировать продукт для реальных или воображаемых пользователей. Именно поэтому я советую погружаться в детали при написании таких сценариев.
Nongoals. Когда вы делаете продукт с командой, у каждого из них есть любимые, настоящие или воображаемые маленькие фичи, без которых они не могут жить. Если вы решите сделать их все, то вам потребуется бесконечно количество времени и слишком много денег. Вы должны сразу начать отбраковывать фичи, и лучший способ это сделать это секция “nongoals” в требованиях. Набор вещей, которые мы не собираемся делать. Это может быть конкретная функциональность, которой не будет в продукте (например, “без телепатического пользовательского интерфейса!”) или это могут быть более общие фразы (например, “в этом релизе нам не важна производительность. Продукт может быть медленным, пока он успешно работает. Если у нас будет время на вторую версию, мы займемся оптимизацией”). Эта часть требований наверняка вызовет обсуждения, однако важно сделать ее открытой как можно раньше. “Мы не будем этого делать!” как говорил George Sr.
Введение. Оно похоже на оглавление ваших требований. Это может быть простая блок схема или обширная архитектурная дискуссия. Каждый, кто прочитает введение, получит общую картинку, тогда и детали ниже будут иметь больше смысла.
Детали, детали, детали. Наконец мы погружаемся в детали. Большинство людей пропустит эту часть до тех пор, пока они не захотят узнать конкретные детали. Когда вы проектируете веб-сервис, вы можете дать каждому возможному экрану имя и добавить в требования главу, описывающую каждый из них в мельчайших подробностях.
Детали — самая важная часть в функциональных требованиях. В приведенном примере вы заметите, как я погружаюсь в детали, когда очень подробно рассказываю обо всех типах ошибок, которые могут возникнуть на странице Логина. Что если пользователь введет не валидный email? Что есть он введет неверный пароль? Все эти случаи относятся к коду, который должен быть написан, но, что еще важнее, эти случаи соответствуют решениям, которые кто-то должен принять. Кто-то должен решить, что мы делаем в случае, когда пользователь забыл пароль. Пока вы не примите решение, вы не можете написать код. Требования нужны для того, чтобы зафиксировать решения.
Открытые вопросы. Для первой версии требований вполне нормально иметь открытые вопросы. Когда я пишу первый черновик, у меня всего есть большой список открытых вопросов (я помечаю их специальным образом, чтобы потом их было легко найти) и, при необходимости, обсуждаю альтернативные варианты. Перед тем как программисты начнут свою работу, все эти открытые вопросы должны быть закрыты. (Вы можете подумать, что было бы нормальным просто начать работу над всеми простыми вещами, которые уже написаны, а все открытые вопросы вы разрешите в процессе. Плохая идея. У вас будет масса проблем с решением новых вопросов, которые будут возникать, когда программисты попытаются имплементировать нужное поведение. Поэтому лучше разрешить все вопросы, которые вам уже известны, заранее. Плюс, то как вы разрешите нетривиальные вопросы, может значительно повлиять на то как должен быть написан код.)
Заметки. Пока вы пишите требования, помните о разной аудитории, которая будет их читать — программисты, тестировщики, маркетинг, технические писатели и так далее. Когда вы пишите требования, вы можете записывать полезные факты, которые пригодятся конкретной аудитории. Например, я отмечаю сообщения для программистов, которые обычно описывают детали технической реализации, флагом “Технические заметки”. Люди из маркетинга игнорируют эти заметки. А программисты погружаются в них с головой. Мои требования часто наполнены “Заметками для тестировщиков”, “Заметками для Маркетинга” и “Заметками для документации”.
Требования должны оставаться живыми. Некоторые команды разработки обладают “waterfall” менталитетом: мы один раз спроектируем программу, напишем требования, напечатаем их и бросим через стену в отдел разработки и пойдем домой. Все что я могу сказать на это: “Ха ха ха ха ха ха ха ха!”
Этот подход — одна из причин почему у требований такая плохая репутация. Множество людей говорило мне — “требования бесполезны, потому что никто им не следует, они всегда неактуальны и никогда не будут отражать реальное поведение продукта”
Извините меня. Может быть ваши требования неактуальны и не отражают поведение продукта. Мои требования постоянно обновляются. Обновления продолжаются пока продукт развивается и принимаются новые решения. Требования всегда отражают наше лучшее коллективное понимание того, как будет работать продукт. Требования замораживаются только тогда, когда вы замораживаете код продукт (то есть, когда вся функциональность уже реализована, но предстоит тестирование и отладка)
Чтобы облегчить жизнь людям, я не обновляю требования каждый день. У меня всегда есть актуальная версия на сервере, которую использует команда. Время от времени, я печатаю копию требований, с историей изменений — чтобы людям не надо было перечитывать все требования целиком — они могут просто посмотреть на номер версии требований и отметить что именно было изменено.
Кто должен писать требования? Читайте об этом в третьей части.