Иногда бывает сложно начать работать с требованиями.
Мешают толстые книги, в которых в подробностях описано такое, что становится страшно вообще думать о документировании требований, а не…
Однако есть простейший способ для начала работы с требованиями. Вот пример issue:
Summary “Export product list to Excel (csv)”
Description [3:42:34 PM] Маркетинг: а на счет экпортировать репортик?
будет такая возможность?
[3:42:56 PM] Программист: tebe nado exportirovati vse dannie ili postrani4no?
ili konkretnuiu stroku?
[3:44:20 PM] Маркетинг: одной строки не достаточно. мне надо чтоб то что я выберу фильтром (все отфильтрованные продукты) можно было скачать и потом работать с эксель файлом.
Status: Resolved.
И все отлично 
А главный секрет в том, чтобы требования хотя бы как-нибудь хотя бы где-нибудь были записаны в виде БУКВ, а не в виде “Мы созванивались и это дело обсудили“.
Оформлять все это дело можно потом как угодно по какой угодно схеме и методике.
Все хорошо, кроме последнего абзаца.
Почему?
Можно и телефонный разговор записать
Просто записать – да, очень удобно.
Но использовать в качестве рабочего материала – сложно. Нужно и прослушать полностью (иногда это час), и перепрокручивать в поисках чего-то, что время работы с аудио резко увеличивает. И все равно надо делать какие-то текстовые заметки по поводу прослушанного, или на бумаге, или в блокноте…
у меня на столе сейчас Протокол работы (находящийся в стадии согласования).
Там есть фраза:
хорошо бы выводить в некоторых случаях “успокаивающее оператора” текстовое сообщение.
Т.е. в виде букв уже зафиксировано.
Но как до Требования-то далеко!
(со вздохом…)
Важно, что это дело хоть как-то упомянуто. Оформить то, что написано коряво всегда проще, чем писать с нуля.
А по моему – это все же лучше чем ничего, и таки удобнее чем (простите, Allex) аудиозапись. Приму на заметку…
ЗЫ Всех коллег с прошедшим!:)
С пока еще проходящим