Очень часто в моей практике при работе с требованиями их форме уделяется гораздо больше внимания, чем содержанию:
- В этом документе собраны требования ко всему продукту, а мне нужны требования только для моего компонента
- Мне не нравится порядок изложения, он непоследовательный с моей точки зрения
- Слишком много/мало диаграмм
- Не хватает связей / слишком много перекрестных ссылок и я не понимаю ваших стрелочек
- 100 страниц вашего документа для меня слишком подробно… введение на 2 странички - слишком общо, а подготовьте мне документ страниц на 30?
- Мы работаем в своей системе (в отдельном репозитории). Подготовьте нам требования, чтобы мы могли их туда загрузить.
Все эти вопросы могут быть одновременно заданы разными людьми к одному и тому же документу. О чем это говорит?
О том ли, что нужно писать сразу несколько документов (или вести учет в нескольких системах) под каждое заинтересованное лицо и поддерживать их потом в согласованном состоянии при всех изменениях? Часто именно эта мысль опережает все прочие. Ее последствия - убедить начальство в необходимости этой работы, нанять штат ручных белок, посадить их синхронизировать все варианты одной и той же информации, стать над ними менеджером и достичь дзен. Всем хорошо, вот только вся эта работа никак не связана с самым главным - с содержанием. Во всей этой кипучей деятельности оно попросту теряется.
Все становится гораздо проще, если взглянуть на проблему под другим углом. Нужно разделить содержание и способы его отображения. Изменение способа отображения не должно вынуждать создавать отдельную копию содержания. Содержание должно быть всегда в единственном экземпляре, чтобы вы были уверенны, что внесенные вами изменения отобразятся во всех настроенных способах отображения. Что это нам дает? Это дает возможность настраивать отображение, удобное специалисту, независимо от отображений многочисленных заинтересованных лиц. Каждое заинтересованное лицо может получать тот вид, который ему удобен… Что это все напоминает? Правильно, шаблон проектирования MVC (Model-View-Controller). Чего нам для полноты ассоциации не хватает в этой схеме - это логики работы с требованиями - т.е. процесса согласования, внесения изменений и прочих событий жизненного цикла требования - которые тоже должны существовать независимо от представления и содержания.
Что помогло бы решить проблему и снять вопросы по форме?
- Инструмент, который позволит с содержанием в том виде, в котором это удобно его создателю. Я хочу создавать требования, не заботясь о том, удобно ли их читать. Пока я создаю требования, это не важно. Важно содержание.
- Когда я довольна содержимым, я начинаю задумываться, а как их будут читать. В этот момент мне нужно скомпоновать мое содержимое в тех видах, в которых его от меня ждут: упорядочить, сгруппировать, отфильтровать, сверстать в документ в конце концов. И это никак не должно затронуть мое содержание и не должно порождать независимых копий моего содержания.
- Далее предстоит задуматься о жизненном цикле требования. Этот жизненный цикл начинается с того момента, когда я впервые выпускаю в люди готовое и приведенное к нужному виду требование. При этом жизненный цикл должен использовать настроенные на предыдущем шаге представления, а те в свою очередь - то же содержимое, которое я создала на первом шаге. И жизненный цикл, также как и представления не должен порождать независимые копии содержимого (ну разве что некие baseline-ы, моментальные снимки требований, не претендующие на поддержку и развитие). Но это уже совсем другая история, и здесь я ее развивать не буду.
Вроде все просто и почти очевидно. Да? Удалось ли мне испытать полное соответствие всем описанным тезисам на собственном опыте? Пока нет. Зато удалось понаблюдать, как это часто выглядит в жизни.
MS Word
Как известно MS Word - текстовый редактор. Здесь идет речь о документе, а не о работе с информацией. Ни один из описанных тезисов не выполняется: содержание неотделимо от представления. Тем не менее, как инструмент он работает во множестве практических случаев. Он есть у всех и все владеют им хотя бы на уровне Notepad.
- Когда это работает?
- Вы работаете по жестко установленному формату представления (например, по ГОСТ);
- документ имеет два состояния: в работе и согласован.
- Все изменения после согласования оформляются в отдельном документе.
- Когда начинаются проблемы?
- Когда форматов несколько (для заказчика и для проектной команды, к примеру);
- когда изменения надо вносить постоянно. При этом не спасает даже track changes - разные версии документа расходятся по членам команды и последняя версия может просто потеряться в них.
- Когда документ превращается в набор связных документов с перекрёстными ссылками или в талмуд из нескольких сотен страниц - полноту, связность (трассировки) и непротиворечивость отследить становится нереалистично.
MS Excel
1й шаг к работе с информацией: атрибутируйте каждое требование по потребности, сортируйте, фильтруйте, группируйте. Так же как Word, MS Excel есть у всех. Но уже не все владеют фильтрами и сортировками, да и представление нельзя сохранить. Так что настройку удобного отображения придется переложить на читателя.
- Когда это работает?
- Жесткий формат не требуется. Важно, чтобы было просто удобно найти то, что нужно с помощью фильтров по атрибутам.
- Каждое требование атомарно (т.е. может существовать самостоятельно и не содержит ветвлений).
- Все ветвления (альтернативные сценарии) оформляются как отдельные требования с собственными пред и пост условиями. При таком подходе большинство регулярных изменений вносятся как новые требования и легко заметны команде.
- Когда начинаются проблемы?
- Когда жесткий формат все-таки требуют;
- Когда важен автоматический track changes - в Excel он весьма странный.
- И опять-таки мы не решили проблему размножения версий на компьютерах ваших коллег, даже при условии единого для всех хранилища для документа.
- Excel не особо приспособлен для графики - так что если вы много работаете с графическими моделями - забудьте.
MS SharePoint
Вершина преданности решениям от MS; 1й шаг к работе с многопользовательской системой, а главное все 3 тезиса здесь наконец-то могут быть удовлетворены. О наличии готового решения для работы с требованиями мне не известно. Скорей всего придется заказывать решение или изобретать самостоятельно. В зависимости от потребности и изобретательности оно сможет покрыть многие и многие проблемы - от простых решений, использующих списки, до работы c MS Access, InfoPath формами и т.п.
- Когда это работает?
- Все участники имеют доступ к системе и умеют с ней работать хотя бы на уровне чтения, поиска и фильтрации.
- Специалист, способный "подтюнить" систему (администратор) находится поблизости и всегда может поправить или улучшить систему по потребности.
- Вам привычно табличное представление данных, вы хотите сохранить достоинства Excel, и получить одновременно полную свободу работы со способами отображения - средствами самого Sharepoint, а также интеграции с MS Access, Excel, InfoPath.
- Вы реализуете жизненный цикл требований с помощью workflow, что позволяет реализовать логику жизненного цикла требования.
- Когда начинаются проблемы?
- Когда не все заинтересованные лица имеют доступ к системе (например, внешние заказчики).
- Когда люди не готовы отказаться от документооборота и работать с отдельным требованием.
- Когда нет специалиста, способного поддерживать и развивать систему.
- Остается проблема неприспособленности работы с графикой. В лучшем случае вы сможете версионировать с помощью Sharepoint файлы, разработанные другими приложениями, но не более того.
Специализированные инструменты (Doors, EA, QC, ReqisitePro, Raven и прочие)
В этих системах накоплен колоссальный опыт предыдущих поколений, они реализуют все 3 заявленных мной тезиска и это хорошо, но покупая коробочное решение, вы покупаете готовый процесс, который потребует внедрения. Подточить такую систему под себя довольно сложно, да и выбрать ту, которая наиболее подходит сейчас и на ближайшее будущее - не менее сложно.
- Когда это работает?
- Когда компания готова купить дорогостоящую систему и провести полномасштабное внедрение.
- Все участники работают в единой системе (или хотя бы несколько систем автоматически синхронизируются).
- Все участники обучены системе.
- Процесс работы с требованиями стабилен и нет потребности к изобретению нового на лету.
- Есть администратор системы.
- Когда начинаются проблемы?
- Когда вы хотите купить коробочную программу, но не готовы менять свой привычный процесс работы;
- Когда система куплена для одного отдела (например, для аналитиков и архитекторов), а остальные участники проекта работают по-своему;
- когда инновационный проект требует исключения из правил.
- Когда вы не готовы выделить специалиста для поддержки системы.
Как ни странно, существенная часть причин того, что инструмент "не работает" - именно форма. Она первой бросается в глаза, ее гораздо проще "контролировать", именно ее регламентируют методологи и именно за несоответствие ей карают с наибольшей вероятностью. Про нее можно легко написать огромную статью, как эта, к примеру. Она в отличие от содержания не часто попадает под соглашения о конфиденциальности. Более того, отделить форму от содержания гораздо проще, чем содержание от формы. Ну представьте себе определение содержания требования без формы… Так волнует ли кого-то, есть ли младенец в коляске, полной изысканных кружевных пеленок?!
