Форум Сообщества Аналитиков

Дисциплины => Проектирование => Тема начата: yaroslav от 23 Июня 2009, 13:05:46

Название: Peer Review ТЗ
Отправлено: yaroslav от 23 Июня 2009, 13:05:46
Коллеги, добрый день!

Хочу поинтересоваться на следующую тему. Как у Вас в компании организован процесс PeerReview.
А точнее:

1) Что у Вас понимается под этим процессом
2) Какие цели он имеет
3) Как выделяются ресурсы на его проведение
4) Как измеряется эффективность проведения PeerReview

Название: Re: Peer Review ТЗ
Отправлено: Григорий Печенкин от 23 Июня 2009, 13:12:24
А что такое PeerReview? Это откуда?

В русскоязычном интернете я нашёл только это:

<<Peer Review — процесс реферирования поступившего в издательство научного материала, предшествующий его публикации. Обычно осуществляется коллективом ученых и специалистов, концентрирующихся вокруг издательства.>>

http://www.gpntb.ru/win/ntb/ntb2000/5/f05_20.html
Название: Re: Peer Review ТЗ
Отправлено: yaroslav от 23 Июня 2009, 14:09:10
Да, это процесс проверки ТЗ перед передачей на согласование заказчику. Формальная цель - поиск ошибок требований.

А вот какие ошибки требований ищут коллеги, как  и зачем - хотелось бы услышать от коллег
Название: Re: Peer Review ТЗ
Отправлено: yaroslav от 23 Июня 2009, 19:13:47
Ида, описанный Вами процесс есть процесс согласования ТЗ. Он бесусловно имеет место быть и необходим.

Однако главная проблема данного процесса, как я ее понимаю, связана с тем что то,  что записано в ТЗ и подписано заказчиком не является на самом деле тем, что хотел заказчик. 

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

Заказчик считает, что то что он вам рассказал устно или написал по почте или даже подумал - будет asis и  с правильным акцентом перенесено в ТЗ. И очень удивляется когда этого не происходит.

Один из путей решения данной проблемы это как раз PeerReview - т.е. оценка ТЗ сторонним экспертом или группой экспертов.  У них глаз не замылен и времени побольше - они могут указать аналитику проекта сомнительные моменты, требующие уточнения или переработки.
 
Название: Re: Peer Review ТЗ
Отправлено: Denis Beskov от 23 Июня 2009, 19:20:30
А что такое PeerReview? Это откуда?
Здравствуй, Гриша

Книга, которую написал Вигерс перед своей библией «Software Requirements», называлась — surprise! — «Peer Reviews in Software»: http://www.processimpact.com/pubs.shtml#prbook Там же смотри статьи на эту тему: http://www.processimpact.com/pubs.shtml#pr
Название: Re: Peer Review ТЗ
Отправлено: Григорий Печенкин от 23 Июня 2009, 20:15:28
Здравствуй, Гриша

Книга, которую написал Вигерс перед своей библией «Software Requirements», называлась — surprise! — «Peer Reviews in Software»: http://www.processimpact.com/pubs.shtml#prbook Там же смотри статьи на эту тему: http://www.processimpact.com/pubs.shtml#pr


Привет, Денис!

Моя плохо-плохо читать по-английски. :)

Пользуясь случаем, хочу передать тебе привет: что сделать с разделом "Книги", который был настроен странным образом: пункт меню был виден всем, а сама страница только зарегистрированным пользователям? Страница архиважная и архинужная, можно её уже открывать для общего доступа, или она ещё не готова?
Название: Re: Peer Review ТЗ
Отправлено: bas от 23 Июня 2009, 23:07:33
Мы боремся с этой проблемой с помощью привлечения максимального количества людей в процесс согласования Документов, постоянным их дерганьем по Согласованию, но у нас внутренняя разработка нам легче. + еще презентация требований Заказчикам.
Название: Re: Peer Review ТЗ
Отправлено: yaroslav от 24 Июня 2009, 10:44:25
Это кто вам такое сказал?...
Если аналитик квалифицированный, то ТЗ отражает то, что хочет заказчик - именно за это аналитику платят его зарплату.
Данная проблема чисто процедурная. Много жалоб - обучите аналитика или наймите другого (если причина не в разработчиках).

Ида, то что заказчик  не читает ТЗ, а если и читает то не понимает и половины, что там написано я знаю из практики.

По поводу квалификации, скажу так - я еще не встречал и уверен, что не встречу  ни одного системного аналитика,  по  написанному ТЗ (детальному разумеется), которого сделали бы систему, и ее потом СРАЗУ принял заказчик.  И дело здесь не совсем не в квалификации, а в том, что процесс разработки и управления  требованиями не сводится к разработке ТЗ, а является продолжительным процессом с множеством активностей, а направлены эти активности на получение системы, которую ПРИМЕТ заказчик. Одной из таких активностей и является экспертная оценка или PeerRewiev.

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


Проблемы индейцев вождя не волнуют.
Ставя свою подпись под согласованным документом, заказчик берет на себя ответственность за базар.
Я обычно не ленилась при получении очередных замечаний и новых требований найти не только строчку в ТЗ, где оно прописано, но и письмо от заказчика или к-либо другой источник, из которого данное требование было мною получено (с датой и точным названием или именем-фамилией).
Это производит волшебное впечатление. Попробуйте.

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

Я пробовал другую схему - делать все возможное и невозможное для того, что бы получить систему которая НУЖНА заказчику - несмотря на то что написано в подписанном ТЗ. Естественно что по окончании такого проекта подписанная версия ТЗ очень сильно отличается от рабочей (сейчас говорю о детальном ТЗ) . НО зато мы имеем довольного заказчика, а к аналитику вопросов нет.

Повторюсь - если аналитик не умеет делать свою работу хорошо, оправдываясь замыленностью глаз, то я бы не стала ему слишком много платить :) Откуда вы возьмете экспертов? В той же организации? Сторонних? Кто их будет оплачивать - заказчик? И почему у них должно быть побольше времени? Если они эксперты, то без работы не сидят.

Вы делаете ставку на квалификацию аналитиков. Я же на процессы.

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

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

Что же касается экспертов - это аналитики из других проектов. А  когда я говорил про время, то имел в виду, что в  проекте где он делает ревью его больше т.к. он не задрючен текучкой
Название: Re: Peer Review ТЗ
Отправлено: yaroslav от 24 Июня 2009, 16:42:37
То, что заказчик не читает - это проблема заказчика. Вас она касаться не должна.
То, что не понимает - это проблема аналитика. Как написал, так и поняли.
Вы сейчас о чем говорите - о проблемах заказчиков или о проблемах аналитиков?

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

А что плохого в том, что заказчик принимает не сразу?

Это элементарно  увеличивает трудоемкость проекта, и в некоторых случаях просто бесплатная работа команды.

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



Делать лучше так, чтобы ТЗ максимально отражало потребности заказчика - это здорово облегчает жизнь всем участникам проекта.

Я с этим не спорю.

Только как же вы этого добиваетесь?  Можете привести список активностей или рецептов, которые вы делаете для того, что бы получить ТЗ, максимально отражающее потребности. Что для этого нужно, кроме упомянутой Вами высокой квалификации?

Название: Re: Peer Review ТЗ
Отправлено: Виталий Григораш от 24 Июня 2009, 17:32:21
Никогда в реальной жизни вы не найдете МЕГАСУПЕРПУПЕР специалистов которые вам сделают МЕГАКРУТОПУПЕРСУПЕР спеку.
Ярослав правильно говорит - надо ставить процессы. Будут процессы будет и результат. А если завтра МЕГАСУПЕРПУПЕРУ на голову кирпич упадет? Что тогда? Весь проект на свалку? Это глупо.

Делайте обычную вычитку, тратьте болше времени на ревью - 30-40 минут на страницу спеки. Ограничте число итераций и будет вам счастие.
Название: Re: Peer Review ТЗ
Отправлено: Михаил Курбасов от 24 Июня 2009, 17:55:47
Коллеги, мне кажется, смешиваются две немного разные вещи - review и peer review. Эти два процесса в чем-то похожи, но имеют совершенно разные цели.

Под review ТЗ обычно понимается процесс внутреннего согласования, когда сформулированный аналитиком документ согласуется внутри проектной команды (менеджерами, архитекторами, разработчиками, тестировщиками и т.п.). Целью данного процесса является приведение ТЗ в "оптимальное" с точки зрения проектной команды состояние. Обычно это означает уточнение слишком общих или непонятных формулировок, устранение нестыковок, а главное - не пропустить в итоговую версию каких-нибудь "нереализуемых" или "слишком дорогих в реализации" требований. Подчеркну, что обычно речь не идет о повышении некоего абстрактного "качества" требований, а именно документ рассматривается в контексте нужд и чаяний данной проектной команды, в данном месте и в данное время (с учетом ограничений по срокам, бюджету, технологиям и т.п.)

В термине peer review ключевое слово - первое. Т.е. это "обзор равных" - коллег по цеху, собратьев по перу, как угодно можно назвать, но, главное - это не руководство аналитика (менеджеры), не заказчики и не "внутренние заказчики" (разработчики etc - кто принимает работу аналитика в проекте). Это именно эксперты, и цель такого review - не отладка ТЗ с целью его улучшения в конкретном проекте, а анализ стиля написания документов данным аналитиком для выявления его личных типовых ошибок и проблем в формулировании требований, структурировании информации, грамматике и пунктуации, если хотите. Аналогичная практика - peer review - существует в программировании, где братья-программисты могут под микроскопом рассмотреть код своего коллеги и по-братски поделиться с ним наблюдениями, как на самом деле надо строить циклы, работать с исключениями, называть переменные и т.п. Еще раз подчеркну, что цель такого мероприятия - чисто учебная. Это повышение квалификации аналитика. Это можно проводить в любое время, не обязательно когда ТЗ "с пылу-с жару", надо утверждать. Это можно сделать хоть через полгода после написания ТЗ - стиль работы аналитика так быстро не меняется...

Практика peer review крайне мало распространена. Есть психологические причины (некоторые считают это чем-то вроде публичной порки). Есть та точка зрения, что эта практика малоэффективна.

Кроме того, есть одно распространенное заблуждение - что peer review можно применить для повышения качества ТЗ. Вот это совсем не так, это не получается...
Название: Re: Peer Review ТЗ
Отправлено: bas от 24 Июня 2009, 17:56:29
Ида,

А можно посмотреть Ваши примеры мега-супер-пупер ТЗ?! А то кажется, что все в мире дураки, а Вы знаете как правильно собирать ВСЕ требования, их анализировать, чтобы ничего не забыть, и еще представить сразу в однозначном виде понятному всем от корки до корки.
Название: Re: Peer Review ТЗ
Отправлено: bas от 24 Июня 2009, 18:12:35
Мега-супер-пупер на чей взгляд?...
На твой.
Название: Re: Peer Review ТЗ
Отправлено: yaroslav от 25 Июня 2009, 10:46:42

Коллеги, мне кажется, смешиваются две немного разные вещи - review и peer review. Эти два процесса в чем-то похожи, но имеют совершенно разные цели.

Под review ТЗ обычно понимается процесс внутреннего согласования, когда сформулированный аналитиком документ согласуется внутри проектной команды (менеджерами, архитекторами, разработчиками, тестировщиками и т.п.). Целью данного процесса является приведение ТЗ в "оптимальное" с точки зрения проектной команды состояние. Обычно это означает уточнение слишком общих или непонятных формулировок, устранение нестыковок, а главное - не пропустить в итоговую версию каких-нибудь "нереализуемых" или "слишком дорогих в реализации" требований. Подчеркну, что обычно речь не идет о повышении некоего абстрактного "качества" требований, а именно документ рассматривается в контексте нужд и чаяний данной проектной команды, в данном месте и в данное время (с учетом ограничений по срокам, бюджету, технологиям и т.п.)

В термине peer review ключевое слово - первое. Т.е. это "обзор равных" - коллег по цеху, собратьев по перу, как угодно можно назвать, но, главное - это не руководство аналитика (менеджеры), не заказчики и не "внутренние заказчики" (разработчики etc - кто принимает работу аналитика в проекте). Это именно эксперты, и цель такого review - не отладка ТЗ с целью его улучшения в конкретном проекте, а анализ стиля написания документов данным аналитиком для выявления его личных типовых ошибок и проблем в формулировании требований, структурировании информации, грамматике и пунктуации, если хотите. Аналогичная практика - peer review - существует в программировании, где братья-программисты могут под микроскопом рассмотреть код своего коллеги и по-братски поделиться с ним наблюдениями, как на самом деле надо строить циклы, работать с исключениями, называть переменные и т.п. Еще раз подчеркну, что цель такого мероприятия - чисто учебная. Это повышение квалификации аналитика. Это можно проводить в любое время, не обязательно когда ТЗ "с пылу-с жару", надо утверждать. Это можно сделать хоть через полгода после написания ТЗ - стиль работы аналитика так быстро не меняется...

Полностью согласен с этой классификацией. Когда писал сабж под PeerRewiev имел в виду именно экспертную оценку.

Но в пылу обсуждения унесло уже ближе к ревью )

Еще бы добавил, что PeerRewiev может на мой взгляд иметь целью  так же выявление потенциальных проблем с требованиями в проекте. Как то, недостаточная проработка бизнес процессов или юзкейсной модели. Недостаточная или избыточная детализация требований. Наличие нецелесообразных требования и т.д.




Кроме того, есть одно распространенное заблуждение - что peer review можно применить для повышения качества ТЗ. Вот это совсем не так, это не получается...

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

У нас PeerRewiev имеет две цели: это передача экспертизы и повышение общего уровня аналитиков.
Название: Re: Peer Review ТЗ
Отправлено: 474 от 26 Июня 2009, 12:18:52
У нас Peer Review ТЗ с целью повышения общего уровня аналитиков не практикуется.

А вот внутреннее согласование ТЗ перед согласованием с заказчиком существует. Производится с использованием системы эл.документоборота, согласуют задействованные разработчики, архитекторы и главный начальник :)
Обычно внутреннее согласование ТЗ занимает день-два, но по регламенту отведено шесть рабочих дней.
Название: Re: Peer Review ТЗ
Отправлено: Denis Beskov от 26 Июня 2009, 14:38:30
«А мы когда с парнями и гитарой собираемся, тоже устраиваем согласование — чтобы в один голос петь. Правда, это не Peer Review…»

А всё потому, что аналитики не знают английского и не могут залезть в мультитран и посмотреть значение слова Peer.

Также, ВП: Peer review (also known as refereeing) is the process of subjecting an author's scholarly work, research, or ideas to the scrutiny of others who are experts in the same field.
Название: Re: Peer Review ТЗ
Отправлено: 474 от 29 Июня 2009, 13:29:12
А всё потому, что аналитики не знают английского и не могут залезть в мультитран и посмотреть значение слова Peer.
Можно пояснить сарказм?

Или потому, что аналитики настолько плохо знают русский, что не могут правильно и однозначно перевести значения встречающихся терминов с английского.
Ида, а это к чему было сказано?
Название: Re: Peer Review ТЗ
Отправлено: Михаил Курбасов от 30 Июня 2009, 15:53:45
А я что-то тоже не понял выпадов по поводу перевода. Вот как multitran  (http://multitran.ru/c/m.exe?t=2532885_1_2) определяет понятие peer review (http://multitran.ru/c/m.exe?t=2532885_1_2). Вроде бы никаких противоречий с тем, что мы описали ранее, не обнаруживается...
Денис, что Вы хотели сказать-то, поясните, пожалуйста.
Название: Re: Peer Review ТЗ
Отправлено: Denis Beskov от 30 Июня 2009, 17:06:56
А я что-то тоже не понял выпадов по поводу перевода. Вот как multitran  (http://multitran.ru/c/m.exe?t=2532885_1_2) определяет понятие peer review (http://multitran.ru/c/m.exe?t=2532885_1_2). Вроде бы никаких противоречий с тем, что мы описали ранее, не обнаруживается...
Денис, что Вы хотели сказать-то, поясните, пожалуйста.
Я про реакцию greesha, ida и 474. Вместо того чтобы обсуждать способы применения техники, благодаря им пошло обсуждение «а чё ваще?»
Название: Re: Peer Review ТЗ
Отправлено: Григорий Печенкин от 30 Июня 2009, 17:13:21
Я про реакцию greesha, ida и 474. Вместо того чтобы обсуждать способы применения техники, благодаря им пошло обсуждение «а чё ваще?»

У меня сложилось впечатление, что термин, мягко говоря, не устоялся. А если непонятно, о чём идёт речь, то стоит ли сразу бросаться в "обсуждение техники"?

А ник у тебя красивый, да. :)
Только поисковики сейчас с ума сойдут, переиндексируя форум.
Название: Re: Peer Review ТЗ
Отправлено: Denis Beskov от 30 Июня 2009, 17:20:00
У меня сложилось впечатление, что термин, мягко говоря, не устоялся. А если непонятно, о чём идёт речь, то стоит ли сразу бросаться в "обсуждение техники"?
В русском — похоже, не устоялся.
Точнее — есть понятие «рецензирование», но оно как полноправная техника в российских реалиях системного анализа не очень известно, похоже.

В английском — 10 млн. упоминаний в гугле. Исходный пост был с английским термином.
Название: Re: Peer Review ТЗ
Отправлено: bas от 30 Июня 2009, 17:28:30
Мне кажется нужно заканчивать препираться. Спасибо Денису и Михаилу, все поняли, что такое "peer review".
Название: Re: Peer Review ТЗ
Отправлено: Denis Beskov от 30 Июня 2009, 19:47:47
А ещё мне нравится работа Гуглового переводчика (http://translate.google.ru/translate?prev=hp&hl=ru&js=n&u=http%3A%2F%2Fwww.processimpact.com%2Farticles%2Fseven_truths.html&sl=en&tl=ru&history_state0=), особенно заголовок.
Название: Re: Peer Review ТЗ
Отправлено: bas от 30 Июня 2009, 21:05:07
Глоссарий я где-то уже предлагала создать :)

Предлагаю Глоссарий начать создавать Здесь:
http://uml2.mytrac.ru/wiki/AnalystGlossary

Кому нужен доступ, обращайтесь по аське или по мылу, логин в Вики = логину на форуме, пароль по запросу.
Название: Re: Peer Review ТЗ
Отправлено: 474 от 02 Июля 2009, 09:26:07

Вот первое сообщение темы:
Коллеги, добрый день!

Хочу поинтересоваться на следующую тему. Как у Вас в компании организован процесс PeerReview.
А точнее:

1) Что у Вас понимается под этим процессом
2) Какие цели он имеет
3) Как выделяются ресурсы на его проведение
4) Как измеряется эффективность проведения PeerReview

Вот мой ответ.
У нас Peer Review ТЗ с целью повышения общего уровня аналитиков не практикуется.

А вот внутреннее согласование ТЗ перед согласованием с заказчиком существует. Производится с использованием системы эл.документоборота, согласуют задействованные разработчики, архитекторы и главный начальник :)
Обычно внутреннее согласование ТЗ занимает день-два, но по регламенту отведено шесть рабочих дней.

Доступно?

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