Форум Сообщества Аналитиков
Общий раздел => Для всех => Тема начата: Анна Абрамова от 01 Октября 2012, 14:00:03
-
Добрый день, коллеги!
Нужно оценить, насколько хорошо воспринимаются разрабатываемые мной документы по требованиям заинтересованными лицами (разработка, тестирование, аналитики со стороны заказчика, эксперты предметной области). Пока обратная связь по документам идет слабая. Руководитель предложил создать опросник, в котором пользователь документа мог бы вкратце оценить качество документа.
Я, на вскидку, могу предложить для включения такие пункты:
1. аккуратность оформления;
2. количество опечаток;
3. однозначность терминов, отсутствие синонимов-паразитов;
4. логичность изложения;
5. полнота;
6. соответствие заголовку;
7. достаточно ли примеров и иллюстраций.
У кого-нибудь есть такой опыт сбора обратной связи? Может быть вы уже создавали подобные опросники, поделитесь, пожалуйста.
-
Это-ж неспроста :)
Ну если Вам делать нечего, то рискните. Вы уже назвали 4 пользователей. И соответственно они будут по разному оценивать документ.
Пойдем от процесса.
Вы собрали требования - описали - для кого?
Для разработчика одни аспекты , для других- другие. Вам результат важен или что?
Берем хотя бы свойства требований (http://www.intuit.ru/department/itmngt/analisis/3/) и вперед.
А в целом это Спецификация (http://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B5%D1%86%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F)
-
Это-ж неспроста :)
Это ж-ж-ж действительно неспроста. Но описывать тут откуда оно возникло не стоит.
Ну если Вам делать нечего, то рискните.
Мне не то, чтобы нечего делать, но хочется уважить желание руководителя, и, может быть, простимулировать пользователей документа читать его более внимательно.
Все, что Вы написали, относится к проверке содержания спецификации требований. Просить других участников рассказывать мне, что я не дописала в спецификации конечно смысла нет.
Но, во-первых, в ходе проекта пишутся не только спецификации требований. Во-вторых, красота и простота восприятия текста зависит далеко не только от содержимого. Вопрос был именно о характеристиках документа, отличных от соответствия стандартам.
Понятно, что ответы у всех будут разные и индивидуальные, но наверняка будут замечены общие вещи, которые нужно будет исправлять в первую очередь.
-
Качество документа — совокупность свойств, признаков, определяющих документ и степень соответствия его предназначению.
Какое назначение документа, для кого он пишется?
Вот как пример Общие требования к построению, изложению и оформлению документов учебной деятельности» (http://smk.sfu-kras.ru/documents/)
-
Судя по Вашим утверждениям, Вы не верите, что можно отделить содержание документа от представления, и сделав представление лучше, облегчить восприятие содержания.
Тем не менее есть замечательная статья от белорусских коллег на эту тему: http://analyst.by/how-to-make-your-texts-clear/ (http://analyst.by/how-to-make-your-texts-clear/).
N лет назад уважаемый профессор из ННГУ им. Лобаческого просил нас, тогда студентов, вычитать написанный им учебник именно проверяя на такие пункты, как наличие синонимов-паразиов. По содержанию мы ничего и не могли ему сказать. =)
Также принцип разделения содержания и представления широко используется в web-разработке. ;)
-
Анна, я думаю, что такую обратную связь наверное проще получить в неформальном разговоре с заказчиком документа. Сам обеспокоен решением подобной задачи.
-
Анализ требований включает три типа деятельности:
- Сбор требований: общение с клиентами и пользователями, чтобы определить, каковы их требования.
- Анализ требований: определение, являются ли собранные требования неясными, неполными, неоднозначными, или противоречащими, и затем решение этих проблем.
- Документирование требований: Требования могут быть задокументированы в различных формах, таких как простое описание, сценарии использования, пользовательские истории, или спецификации процессов.
Анализ требований может быть длинным и трудным процессом, во время которого вовлечены много тонких психологических навыков.
отделить содержание документа от представления, и сделав представление лучше, облегчить восприятие содержания
Подготовьте 4 документа и будет вам занятость.
Я не говорю, что не надо так делать. Я хочу понять цель документа. Написать для всех на отлично не выйдет.
Ну хорошо например, 4 требование из статьи ?
Про какой-то там брандмауэр. Заказчик скажет вам "это Вы сейчас с кем разговаривали".
Требования заинтересованного лица - это утверждения, в которых отражены потребности конкретного заинтересованного лица или группы заинтересованных лиц. Они описывают потребности, которые необходимы данному заинтересованному лицу , а так же то, каким образом заинтересованное лицо будет взаимодействовать с разрабатываемым решением
-
Согласна, надо знать цель. Для прогеров, я качество своей доки оцениваю просто, если ко мне прогер не обращался с вопросами, то класс. А если задавал вопросы по какой нибудь шняге, то я фиксирую себе в голове и дописываю в следующем.
Для простых пользователей, важно картинки. Читать они не любят. А для "подшивки" - главное красиво, можно и не содержательно, все равно читать никто не будет.
-
Согласна, надо знать цель. Для прогеров, я качество своей доки оцениваю просто, если ко мне прогер не обращался с вопросами, то класс. А если задавал вопросы по какой нибудь шняге, то я фиксирую себе в голове и дописываю в следеющем.
Для простых пользователей, важно картинки. Читать они не любят. А для "подшивки" - главное красиво, можно и не содержательно, все равно читать никто не будет.
А вот для меня, если прогер не обращался с вопросами - это очень плохо. Либо не читал, либо прочитал и ничего не понял. В любом случае сделал по своему, потом придется переделывать. Может в сработавшихся командах на длительных проектах это правило не работает, но я таких не видела.
-
А вот для меня, если прогер не обращался с вопросами - это очень плохо. Либо не читал, либо прочитал и ничего не понял. В любом случае сделал по своему, потом придется переделывать. Может в сработавшихся командах на длительных проектах это правило не работает, но я таких не видела.
Сделает по-своему - будет переделывать по-моему. Один раз все переделает, второй раз подумает..лучше почитает и сделает как написано.
Но что бы прогеры делали как хочет аналитик- надо быть авторитетным аналитиком. Если не уважают - постоянные скандалы и переделки. Я просто наблюдаю, что хоть какая команда, все равно отношение между прогерам и аналом -одинаковое. Все зависит от человека.
-
разработка, тестирование, аналитики со стороны заказчика, эксперты предметной области
Круто вы пишите один документ для всех. =)
Я не думаю что разработчику нужно то, что хочет увидеть эксперт предметной области и на оборот. Вывод для обоих точек зрения в документе либо не хватает информации, либо куча лишнего информационного шума.
Что касаться внутренних разработчиков и тестировщиков, то попросите их оценить не ваш документ, а выставить их требования к документу. Т.е. что они хотят в нем увидеть, чтобы документ их полностью удовлетворил (шаблон документа с примерами и комментариями) (например, описание юскейсов, диаграммы классов и пр.). Дальше вы ничего не выдумываете, а просто заполняете пустые места в документе по согласованному стандарту (т.е. закрываете формальную сторону их требований).
А вот для меня, если прогер не обращался с вопросами - это очень плохо. Либо не читал, либо прочитал и ничего не понял. В любом случае сделал по своему, потом придется переделывать.
Эта должна быть не ваша проблема, а проблема РП. Не вы выдаете задачу разработчикам, а РП, вот пусть и "учить" разработчиков читать документы.
-
Коллеги, большое спасибо за ответы!
Вы правы.
Нужно писать несколько документов для разных целевых аудиторий. Тогда удовлетворенность каждой стороны будет выше. Осталось только убедить менеджера, чтобы он убедил заказчика, что за это надо платить.
По качеству документа лучше разговаривать с конкретным пользователем.
-
Некоторое время назад, сталкивался со схожей задачей, как раз из-за того что разработчики не считали необходимым уточнять тонкие моменты, додумывали сами, и как правило ничем хорошим это не заканчивалось.
По этому например фраза "Сделает по-своему - будет переделывать по-моему. Один раз все переделает, второй раз подумает..лучше почитает и сделает как написано." звучит для меня дико.
Во первых не то чтобы есть сроки, удовлетворять фантазии программистов, а во вторых, с чего бы ему читать лучше во второй раз, если после первого раза не последовало никаких выводов?
Скажу сразу, у нас принято готовить единый документ, и для заказчиков и для команды разработки.
Но т.к. круг интересов у этих групп разный, то и опросника следует сделать два, в каждом делая фокус на то что действительно важно для группы.
И если при опросе заказчика зачастую провести личную или приватную беседу нельзя, то при опросе команды разработки, можно использовать опросник как список тем, и уже более полно по каждой беседовать лично.
Как показывает практика, из тех пунктов что ты упомянула в начале поста, заказчиков больше всего интересует полнота и простота изложения, а для команды важнее всего однозначность толкований.
Ни разу не сталкивался чтобы кто-то отмечал опечатки или стиль оформления.
Хотя тут может зависеть от людей. В моей команде, например, есть разработчик который просит чтобы я рисовал ему в ТЗ прототипы интерфейсов буквально для всего нового функционала, вплоть до добавления поля в отображаемой таблице:)
-
Руководитель предложил создать опросник, в котором пользователь документа мог бы вкратце оценить качество документа.
Проверено неоднократно - не работает.
Главная проверка - если заказчик сказал "Вах, это то, что я хотел" два раза: один читая документ, второй - после работы с программой, - то есть шанс, что документ был неплох. (Есть еще шанс, вам попался не кодер, а разработчик, который требования сжег не читая, но зная предметную область все сделал правильно)
Но такая проверка дорога. Более простая - если по требованиям можно написать ПМИ - то качество не слишком плохое. Возможно, требования неполны, но они хотя бы нормально интерпретируются.
-
[/quote]
У кого-нибудь есть такой опыт сбора обратной связи? Может быть вы уже создавали подобные опросники, поделитесь, пожалуйста.
Есть возможность отказаться - не делайте. Нет возможности не делать - не вкладывайтесь.
Лучше всего распечатать и с ручкой с каждым ВАЖНЫМ человеком прочитать.
-
Александр, спасибо за совет. Стараюсь эту тему лишний раз не поднимать. С основными лицами, заинтересованными в хорошей документации, договорилась, что они мне ответят в вольном стиле.
Сесть рядом с ручкой, к сожалению, не получится, т.к. все важные люди в разных городах.
-
Если обратная связь слабая - значит, все хорошо.
Когда документы плохие, поднимается такой вой, что его невозможно не услышать.
В нашей культуре ведь как - мы люди дикие, пещерные, к поощрениям не приучены, зато обгадить что-нибудь - это милое дело )
-
Если обратная связь слабая - значит, все хорошо.
Когда документы плохие, поднимается такой вой, что его невозможно не услышать.
В нашей культуре ведь как - мы люди дикие, пещерные, к поощрениям не приучены, зато обгадить что-нибудь - это милое дело )
Я тоже так думала, пока не увидела релиз. ;)
-
А при чем тут релиз?
Если программисты криворукие (или кривомозгие), это не ваша ответственность
-
А при чем тут релиз?
Если программисты криворукие (или кривомозгие), это не ваша ответственность
Хороший аналитик пишет спецификацию не для идеальных программистов, а для тех, которые есть.
В противном случае, нет шансов достичь главного критерия качества работы аналитика, о котором упомянул Salar:
Главная проверка - если заказчик сказал "Вах, это то, что я хотел" два раза: один читая документ, второй - после работы с программой, - то есть шанс, что документ был неплох.
Другими словами, если ваша работа не привела к выходу продукта ожидаемого качества -- значит вы делали не то, что нужно. Независимо от того, много ли вы работали, насколько устали, и кого считаете виноватым в провале.
Программисты, вообще говоря, en masse люди довольно образованные. Если у вас есть основания считать какого-то из своих программистов кривомозгим, попросите заменить его на другого, предложений на рынке программистских услуг достаточно, в течение 3 дней можно решить эту проблему.
-
Хороший аналитик пишет спецификацию не для идеальных программистов, а для тех, которые есть.
Вы мне рассказываете, как работают аналитики?.. Может вы меня еще рожать поучите?
Повторяю свою мысль - если разработчик молча проглотил ТЗ и не задал по нему никаких вопросов, а потом выпустил некачественный продукт - это ответственность исключительно разработчика. Обычно за такое увольняют именно разработчиков, а не аналитиков.
Программисты, вообще говоря, en masse люди довольно образованные.
А также беспомощные в плане коммуникации, невротичные и снобы.
Я считаю, что мы, аналитики, должны им немного помочь развить в себе некоторые качества - а для этого надо позволить им совершать ошибки.
предложений на рынке программистских услуг достаточно, в течение 3 дней можно решить эту проблему.
а потом месяц интегрировать его в команду и продукт.
-
Хороший аналитик пишет спецификацию не для идеальных программистов, а для тех, которые есть.
Своим подходом вы сразу определяете в аналитике "козла отпущения" за провал любого проекта.
Хороший аналитик пишет хорошую спецификацию.
Хороший программист умеет правильно читать хорошую спецификацию и готовит ожидаемый продукт.
Криворукий (кривомозглый) программист готовит не понятно что, в не зависимости от качества спецификации.
Программисты, вообще говоря, en masse люди довольно образованные.
Аналитики, вообще говоря, тоже бывают с мозгами ;D
Если у вас есть основания считать какого-то из своих программистов кривомозгим, попросите заменить его на другого, предложений на рынке программистских услуг достаточно, в течение 3 дней можно решить эту проблему.
Где-то, что-то подобное я уже читал, типа "каждая кухарка может управлять государством". В задачи аналитика не входит управление ресурсами проекта и тем более увольнение и прием нового персонала.
З.ы. в первоисточнике про кухарку было нечто другое: "Мы не утописты. Мы знаем, что любой чернорабочий и любая кухарка не способны сейчас же вступить в управление государством", но в сознании отдельных умных товарищей цитата кардинально поменяла свой смысл. Так и в разработке ПО - пришел человек работать аналитиков, а тут на него задачи РП спихивают, вешают ответственность за код программиста, да и еще и тестировшиком иногда заставляют работает. ;D
-
Так и в разработке ПО - пришел человек работать аналитиков, а тут на него задачи РП спихивают, вешают ответственность за код программиста, да и еще и тестировшиком иногда заставляют работает. ;D
А что у вас не так? Где работала - везде аналитик виноват.
-
Такая интересная дискуссия получилась. И очень актуальная. =)
-
Боюсь, если проект добрался до стадии обоюдных обвинений в 'кривомозгости', и эта тенденция охватила большинство участников, этот самый проект уже неживой. :) Видимость деятельности в стиле первого закона Паркинсона (http://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%9F%D0%B0%D1%80%D0%BA%D0%B8%D0%BD%D1%81%D0%BE%D0%BD%D0%B0) может поддерживаться еще долгое время, но фактически больше ничего конструктивного внедрено не будет. Стройность архитектуры на этом этапе утрачена (если, конечно, она когда-то была), любые изменения/исправления чреваты добавлением костылей, вносящих непредвиденные эффекты в самые неожиданные части системы. В результате наблюдается лавинообразный рост багов. Коммуникации в команде проекта нарушены (ну все же считают коллег 'кривомозгими' и пользуются взаимностью), поэтому простейшие вопросы вызывают недоразумения и конфликты.
В общем, печальное зрелище.
-
А что у вас не так? Где работала - везде аналитик виноват.
Нет не так. У каждой специализации есть своя зона ответственности. Есть формальные признаки качества выполняемой работы. В частности свои требования к формату постановки задачи на разработку выдают разработчики. Аналитики готовят документы в соответствии с согласованными форматами. И никто ни на кого "бочки" не катит :)
Боюсь, если проект добрался до стадии обоюдных обвинений в 'кривомозгости', и эта тенденция охватила большинство участников, этот самый проект уже неживой. :)
Хороший РП может вытащить проект даже из самой глубокой пятой точки. Видел примеры. где смена руководства положительно влияла на проект. В частности одной из его задач является вывод из проектов ленивых исполнителей и тех кто всеми правдами и не правдами не хочет нести ответственность за свои действия. Если зоны ответственности размыты , то РП должен провести еще и четкие границы, между исполнителями. Вселить во всех уверенность и заставить работать.
В общем, печальное зрелище.
Глаза бояться, а руки делают.
И все будет хорошо. ;D
-
Хороший РП может вытащить проект даже из самой глубокой пятой точки
Да, согласна, случается иногда такая реанимация :)
-
Боюсь, если проект добрался до стадии обоюдных обвинений в 'кривомозгости', и эта тенденция охватила большинство участников, этот самый проект уже неживой. :)
Да, спасибо за четкую формулировку, именно на это я и хотел обратить внимание коллег Ida и Elf, которые в данном топике, по сути, обсуждают проблему "Каким способом лучше перевесить ответственность за провал проекта с аналитика на кого-нибудь еще". А топикстартер задавал несколько другой вопрос :)
-
Вопрос был задан следующий:
Нужно оценить, насколько хорошо воспринимаются разрабатываемые мной документы по требованиям заинтересованными лицами (разработка, тестирование, аналитики со стороны заказчика, эксперты предметной области)
Я на него ответила (см. выше).
Автор темы, судя по последнему комментарию, в целом удовлетворена.
А какую потребность сейчас пытаетесь удовлетворить вы?...
-
аналитик виноват когда себя поставил в команде как козёл отпущения :)
по теме же, вы всё смешали в одну большую кучу, где перемешались заказчики и программисты, в то время как существуют разные документы, предназначенные для:
1. заказчика
2. для имплементации бизнес-логики в системе.
3. сношений с тестированием
4. приёмок и прочего.
любой документ имеет цель: согласовать бизнес логику проекта, согласовать архитектуру разрабатываемого решения, согласовать низкоуровневые архитектурные моменты как методы и интерфейсы взаимодействия, сценарии приёмочных тестирований и прочее.
общая мысль следующая: каждый документ имеет цель, и от неё нужно плясать. для заказчика писать доки в удобном для него формате, для разрабов - в удобном им формате. никогда не будет одного документа, эффективно читаемого как заказчиком, так и разработкой, потому что и те, и другие имеют под собой инкрементную природу (количество согласующих имеет свойство постоянно увеличиваться с обеих сторон)
вопрос формализации обсосан очень и очень много раз. может, конечно, я не правильно понял вопрос темы.
а что до взаимных обвинений в кривомозгости, то я с вами не соглашусь - в ЛЮБОМ сложном проекте с внешним заказчиком, наступает момент таких обвинений. он обусловлен рамками реализации и бюджета. заказчик хочет побольше, а денег заплатить поменьше, подрядчик же, наоборот. обвинения - это элемент торга :-) вариант кранча, если в терминах теории переговоров.
-
существуют разные документы, предназначенные для:
1. заказчика
2. для имплементации бизнес-логики в системе.
3. сношений с тестированием
4. приёмок и прочего.
...
никогда не будет одного документа, эффективно читаемого как заказчиком, так и разработкой
Согласен, если есть много денег, много времени, и необходимо строго, однозначно и формально фиксировать все факты принятия проектных решений и моменты передачи ответственности за них, то без всего этого не обойтись. Потому что в процессе такой разработки, кроме продукта, должны появиться и документы, на основании которых прокурор мог бы подписать постановление, если не дай бог, применение продукта принесет кому-либо существенный вред (например, потерю серьезных денег, что возможно в банковских системах, не говоря уже про военные приложения и АСУ).
Но мне кажется полезным всегда помнить, что заказчику нужен в первую очередь работающий продукт, а порождение разнообразных документов является неизбежным злом, которое нужно стараться минимизировать, настолько, насколько это возможно в данном конкретном случае.
а что до взаимных обвинений в кривомозгости, то я с вами не соглашусь - в ЛЮБОМ сложном проекте с внешним заказчиком, наступает момент таких обвинений.
Вы же помните из курса логики, что для опровержения логического утверждения с квантором общности ("ЛЮБОЙ") достаточно единственного примера обратного? :)
У меня каждый второй примерно проект с внешним заказчиком обходился без "взаимных обвинений в кривомозгости", в том числе и достаточно сложные, дорогие, и с непростыми госзаказчиками ... тут скорее дело в индивидуальном стиле общения.
-
не могу не согласиться. я, конечно, несколько утрировал пассаж про "обвинения". у нас, как у аффилированного МТС разработчика OSS/BSS решений так происходит постоянно :) но это наша специфика работы.
я не совсем корректно выразил мысль - "обвинениям в кривомозгости" свойственно возникать, когда скоуп проекта бесконтрольно расширяется и сроки начинают срываться. у нас так довольно часто происходит.
в принципе, "обвинения" - это элемент кранча, который легко можно устранить.
а что касается спецификации документов под разные проектные активности, то, естественно, тут играет роль бюджет и сроки.
но я бы очень внимательно просчитал, что дешевле - общий для всех функционеров проекта документ-спецификация требований или несколько, ориентированных на разные активности. но это, опять же, зависит от сложности реализуемой задачи. слона лучше есть по частям :)
-
Забавно, только что попался под руку в книжке Mike Cohn. User Stories Applied For Agile Software Developmet раздел, в котором Майк обращает внимание на взаимосвязь между тем, что
существуют разные документы, предназначенные для:
1. заказчика
2. для имплементации бизнес-логики в системе.
3. сношений с тестированием
4. приёмок и прочего.
, и тем что
"обвинениям в кривомозгости" свойственно возникать, когда скоуп проекта бесконтрольно расширяется и сроки начинают срываться.
" ... the Product Management (or similar) group writes a requirements specification that is given to the developers. The developers then rewrite the document so that it conveys their interpretation of the requirements ... The developers are always careful to give their document a completely different name (something like Functional Specification) to hide that is is the same document ... just written from the perspective of a different group.
...
Both groups know that a requirement specification is too difficult to read and fully understand and impossible to write with the desired precision.
When the project is finished and blame is being allocated they will point to sections of the document and claim that missing features were implied. Or they will claim that expected funcionality is out clearly out of scope because of a sentence buried somewhere in the document.
...
Most of the times when I see two groups writing separate versions of essentially the same document I already know they are positioning themselves for the end-of-project blame sessions..."
-
Про сношения с тестированием ты это хорошо сказал:)
-
Наболевшее :)