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

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

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

А что такое PeerReview? Это откуда?

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

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

http://www.gpntb.ru/win/ntb/ntb2000/5/f05_20.html

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

А вот какие ошибки требований ищут коллеги, как  и зачем - хотелось бы услышать от коллег

Ида, описанный Вами процесс есть процесс согласования ТЗ. Он бесусловно имеет место быть и необходим.

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

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

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

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

А что такое PeerReview? Это откуда?

Здравствуй, Гриша

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

Здравствуй, Гриша

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

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

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

Пользуясь случаем, хочу передать тебе привет: что сделать с разделом "Книги", который был настроен странным образом: пункт меню был виден всем, а сама страница только зарегистрированным пользователям? Страница архиважная и архинужная, можно её уже открывать для общего доступа, или она ещё не готова?

Мы боремся с этой проблемой с помощью привлечения максимального количества людей в процесс согласования Документов, постоянным их дерганьем по Согласованию, но у нас внутренняя разработка нам легче. + еще презентация требований Заказчикам.

Это кто вам такое сказал?...
Если аналитик квалифицированный, то ТЗ отражает то, что хочет заказчик - именно за это аналитику платят его зарплату.
Данная проблема чисто процедурная. Много жалоб - обучите аналитика или наймите другого (если причина не в разработчиках).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Никогда в реальной жизни вы не найдете МЕГАСУПЕРПУПЕР специалистов которые вам сделают МЕГАКРУТОПУПЕРСУПЕР спеку.
Ярослав правильно говорит - надо ставить процессы. Будут процессы будет и результат. А если завтра МЕГАСУПЕРПУПЕРУ на голову кирпич упадет? Что тогда? Весь проект на свалку? Это глупо.

Делайте обычную вычитку, тратьте болше времени на ревью - 30-40 минут на страницу спеки. Ограничте число итераций и будет вам счастие.

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

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

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

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

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

Ида,

А можно посмотреть Ваши примеры мега-супер-пупер ТЗ?! А то кажется, что все в мире дураки, а Вы знаете как правильно собирать ВСЕ требования, их анализировать, чтобы ничего не забыть, и еще представить сразу в однозначном виде понятному всем от корки до корки.

Мега-супер-пупер на чей взгляд?...

На твой.

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

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

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

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

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

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

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

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

У нас PeerRewiev имеет две цели: это передача экспертизы и повышение общего уровня аналитиков.

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

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