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

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

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



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

Просьба прочитать и соблюдать Правила форума.
« Последнее редактирование: 10 Сентября 2010, 10:51:26 от mouse »



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

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



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



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

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

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

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



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

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

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

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

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

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

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

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



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

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

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



Модератор: За повторное нарушение правил форум пользователь sudo-su забанен на месяц, за дальнейший повтор нарушений, бан будет навсегда.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19