Статья Влада Балина про подход к управлению разработкой с применением принципов ГОСТа:
http://gaperton.livejournal.com/49867.html

Достаточно провокационная для здешней аудитории («ТЗ — не требования»), но я согласен с большинством тезисов.

Некоторое резюме, которое у меня появилось: Требования не так важны, как цели и правила приёмки.

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

Просьба прочитать и соблюдать Правила форума.

Некоторое резюме, которое у меня появилось: Требования не так важны, как цели и правила приёмки.

Не так важны для чего?

Для успеха проекта.

В каждом проекте успех - это что-то свое, особенное.

Где-то, действительно, успех -- любой ценой пройти приемо-сдаточные испытания. Несмотря на последующий разрыв отношений с Заказчиком. И тут на первый план выходит "правильно составленная" ПМИ.

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

То есть я бы немного переформулировал тезис, добавив в него слово "иногда": Иногда требования не так важны, как цели и правила приемки.

В каждом проекте успех - это что-то свое, особенное.

Успех - это соответствие результатов работы поставленным целям.

"Ключевые требования, определяющие успех" - являются по сути подробной детализацией цели работы, если они правильно сформулированы, конечно. И противопоставление _этих_ требований целям не вполне корректно.

Также, не будет правильно противопоставлять требования правилам приемки (программе и методике испытаний). Дело в том, что каждый пункт ПМИ должен ссылаться на соответствующий пункт "технических требований" ТЗ, и если не будет такого пункта, на который можно сослаться - то включение в ПМИ теста будет не обосновано. Т.е. "требования" в ТЗ могут быть общи, но - обязаны быть полны-непротиворечивы, точно характеризуя весь scope работ.

"Правила приемки" являются по своей сути теми же требованиями, выраженными более подробно и в конструктивной форме - т.е. форме, допускающей проверку.

Короче, все три вещи - это разные грани одного целого. Нельзя говорить, что требования _вообще_ менее важны.

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

Вопрос в том, что иметь в виду под "требованиями".

Успех - это соответствие результатов работы поставленным целям.

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

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

Модератор: За повторное нарушение правил форум пользователь sudo-su забанен на месяц, за дальнейший повтор нарушений, бан будет навсегда.