Добрый день, коллеги!

Нужно оценить, насколько хорошо воспринимаются разрабатываемые мной документы по требованиям заинтересованными лицами (разработка, тестирование, аналитики со стороны заказчика, эксперты предметной области). Пока обратная связь по документам идет слабая. Руководитель предложил создать опросник, в котором пользователь документа мог бы вкратце оценить качество документа.

Я, на вскидку, могу предложить для включения такие пункты:
1. аккуратность оформления;
2. количество опечаток;
3. однозначность терминов, отсутствие синонимов-паразитов;
4. логичность изложения;
5. полнота;
6. соответствие заголовку;
7. достаточно ли примеров и иллюстраций.

У кого-нибудь есть такой опыт сбора обратной связи? Может быть вы уже создавали подобные опросники, поделитесь, пожалуйста.

Это-ж неспроста
Ну если Вам делать нечего, то рискните. Вы уже назвали 4 пользователей. И соответственно они будут по разному оценивать документ.
Пойдем от процесса.

Вы собрали требования - описали - для кого?
Для разработчика одни аспекты , для других- другие. Вам результат важен или что?

Берем хотя бы свойства требований и вперед.

А в целом это Спецификация

Это-ж неспроста

Это ж-ж-ж действительно неспроста. Но описывать тут откуда оно возникло не стоит.

Ну если Вам делать нечего, то рискните.

Мне не то, чтобы нечего делать, но хочется уважить желание руководителя, и, может быть, простимулировать пользователей документа читать его более внимательно.

Все, что Вы написали, относится к проверке содержания спецификации требований. Просить других участников рассказывать мне, что я не дописала в спецификации конечно смысла нет.

Но, во-первых, в ходе проекта пишутся не только спецификации требований. Во-вторых, красота и простота восприятия текста зависит далеко не только от содержимого. Вопрос был именно о характеристиках документа, отличных от соответствия стандартам.

Понятно, что ответы у всех будут разные и индивидуальные, но наверняка будут замечены общие вещи, которые нужно будет исправлять в первую очередь.

Качество документа — совокупность свойств, признаков, определяющих документ и степень соответствия его предназначению.
Какое назначение документа, для кого он пишется?

Вот как пример  Общие требования к построению, изложению и оформлению документов учебной деятельности» 

Судя по Вашим утверждениям, Вы не верите, что можно отделить содержание документа от представления, и сделав представление лучше, облегчить восприятие содержания.

Тем не менее есть замечательная статья от белорусских коллег на эту тему: http://analyst.by/how-to-make-your-texts-clear/.

N лет назад уважаемый профессор из ННГУ им. Лобаческого просил нас, тогда студентов, вычитать написанный им учебник именно проверяя на такие пункты, как наличие синонимов-паразиов. По содержанию мы ничего и не могли ему сказать. =)

Также принцип разделения содержания и представления широко используется в web-разработке.

Анна, я думаю, что такую обратную связь наверное проще получить в неформальном разговоре с заказчиком документа. Сам обеспокоен решением подобной задачи.

Анализ требований включает три типа деятельности:
- Сбор требований: общение с клиентами и пользователями, чтобы определить, каковы их требования.
- Анализ требований: определение, являются ли собранные требования неясными, неполными, неоднозначными, или противоречащими, и затем решение этих проблем.
- Документирование требований: Требования могут быть задокументированы в различных формах, таких как простое описание, сценарии использования, пользовательские истории, или спецификации процессов.
Анализ требований может быть длинным и трудным процессом, во время которого вовлечены много тонких психологических навыков. 

отделить содержание документа от представления, и сделав представление лучше, облегчить восприятие содержания

Подготовьте 4 документа и будет вам  занятость.

Я не говорю, что не надо так делать. Я хочу понять цель документа. Написать для всех на отлично не выйдет.
 Ну хорошо например, 4 требование из статьи ?
Про какой-то там брандмауэр. Заказчик скажет вам "это Вы сейчас с кем разговаривали".

Требования заинтересованного лица - это утверждения, в которых отражены потребности конкретного заинтересованного лица или группы заинтересованных лиц. Они описывают потребности, которые необходимы данному заинтересованному лицу , а так же то, каким образом заинтересованное лицо будет взаимодействовать с разрабатываемым решением

Согласна, надо знать цель. Для прогеров, я качество своей доки оцениваю просто, если ко мне прогер не обращался с вопросами, то класс. А если задавал вопросы по какой нибудь шняге, то я фиксирую себе в голове и дописываю в следующем.
Для простых пользователей, важно картинки. Читать они не любят. А для "подшивки" - главное красиво, можно и не содержательно, все равно читать никто не будет.
 

Согласна, надо знать цель. Для прогеров, я качество своей доки оцениваю просто, если ко мне прогер не обращался с вопросами, то класс. А если задавал вопросы по какой нибудь шняге, то я фиксирую себе в голове и дописываю в следеющем.
Для простых пользователей, важно картинки. Читать они не любят. А для "подшивки" - главное красиво, можно и не содержательно, все равно читать никто не будет.
 

А вот для меня, если прогер не обращался с вопросами - это очень плохо. Либо не читал, либо прочитал и ничего не понял. В любом случае сделал по своему, потом придется переделывать. Может в сработавшихся командах на длительных проектах это правило не работает, но я таких не видела.

А вот для меня, если прогер не обращался с вопросами - это очень плохо. Либо не читал, либо прочитал и ничего не понял. В любом случае сделал по своему, потом придется переделывать. Может в сработавшихся командах на длительных проектах это правило не работает, но я таких не видела.

Сделает по-своему - будет переделывать по-моему. Один раз все переделает, второй раз подумает..лучше почитает и сделает как написано.
Но что бы прогеры делали как хочет аналитик- надо быть авторитетным аналитиком. Если не уважают - постоянные скандалы и переделки. Я просто наблюдаю, что хоть какая команда, все равно отношение между прогерам и аналом -одинаковое. Все зависит от человека.

разработка, тестирование, аналитики со стороны заказчика, эксперты предметной области

Круто вы пишите один документ для всех. =)
Я не думаю что разработчику нужно то, что хочет увидеть эксперт предметной области и на оборот. Вывод для обоих точек зрения в документе либо не хватает информации, либо куча лишнего информационного шума.

Что касаться внутренних разработчиков и тестировщиков, то попросите их оценить не ваш документ, а выставить их требования к документу. Т.е. что они хотят в нем увидеть, чтобы документ их полностью удовлетворил (шаблон документа с примерами и комментариями) (например, описание юскейсов, диаграммы классов и пр.). Дальше вы ничего не выдумываете, а просто заполняете пустые места в документе по согласованному стандарту (т.е. закрываете формальную сторону их требований).

А вот для меня, если прогер не обращался с вопросами - это очень плохо. Либо не читал, либо прочитал и ничего не понял. В любом случае сделал по своему, потом придется переделывать.

Эта должна быть не ваша проблема, а проблема РП. Не вы выдаете задачу разработчикам, а РП, вот пусть и "учить" разработчиков читать документы.

Коллеги, большое спасибо за ответы!

Вы правы.

Нужно писать несколько документов для разных целевых аудиторий. Тогда удовлетворенность каждой стороны будет выше. Осталось только убедить менеджера, чтобы он убедил заказчика, что за это надо платить.

По качеству документа лучше разговаривать с конкретным пользователем.

Некоторое время назад, сталкивался со схожей задачей, как раз из-за того что разработчики не считали необходимым уточнять тонкие моменты, додумывали сами, и как правило ничем хорошим это не заканчивалось.

По этому например фраза "Сделает по-своему - будет переделывать по-моему. Один раз все переделает, второй раз подумает..лучше почитает и сделает как написано." звучит для меня дико.
Во первых не то чтобы есть сроки, удовлетворять фантазии программистов, а во вторых, с чего бы ему читать лучше во второй раз, если после первого раза не последовало никаких выводов?

Скажу сразу, у нас принято готовить единый документ, и для заказчиков и для команды разработки.
Но т.к. круг интересов у этих групп разный, то и опросника следует сделать два, в каждом делая фокус на то что действительно важно для группы.

И если при опросе заказчика зачастую провести личную или приватную беседу нельзя, то при опросе команды разработки, можно использовать опросник как список тем, и уже более полно по каждой беседовать лично.

Как показывает практика, из тех пунктов что ты упомянула в начале поста, заказчиков больше всего интересует полнота и простота изложения, а для команды важнее всего однозначность толкований.
Ни разу не сталкивался чтобы кто-то отмечал опечатки или стиль оформления.

Хотя тут может зависеть от людей. В моей команде, например, есть разработчик который просит чтобы я рисовал ему в ТЗ прототипы интерфейсов буквально для всего нового функционала, вплоть до добавления поля в отображаемой таблице:)

Руководитель предложил создать опросник, в котором пользователь документа мог бы вкратце оценить качество документа.

Проверено неоднократно - не работает.

Главная проверка - если заказчик сказал "Вах, это то, что я хотел" два раза: один читая документ, второй - после работы с программой, - то есть шанс, что документ был неплох. (Есть еще шанс, вам попался не кодер, а разработчик, который требования сжег не читая, но зная предметную область все сделал правильно)
Но такая проверка дорога. Более простая - если по требованиям можно написать ПМИ - то качество не слишком плохое. Возможно, требования неполны, но они хотя бы нормально интерпретируются.

[/quote]

У кого-нибудь есть такой опыт сбора обратной связи? Может быть вы уже создавали подобные опросники, поделитесь, пожалуйста.

Есть возможность отказаться - не делайте. Нет возможности не делать - не вкладывайтесь.
Лучше всего распечатать и с ручкой с каждым ВАЖНЫМ человеком прочитать.