Форум Сообщества Аналитиков
Дисциплины => Управление Проектом => Тема начата: Denis Beskov от 09 Сентября 2010, 21:30:53
-
Статья Влада Балина про подход к управлению разработкой с применением принципов ГОСТа:
http://gaperton.livejournal.com/49867.html
Достаточно провокационная для здешней аудитории («ТЗ — не требования»), но я согласен с большинством тезисов.
Некоторое резюме, которое у меня появилось: Требования не так важны, как цели и правила приёмки.
-
Модератор: Публикация грубых, оскорбляющих и унижающих сообщений и переход на личности запрещены Правилами форума.
Просьба прочитать и соблюдать Правила форума (http://www.uml2.ru/forum/index.php?topic=1901.0).
-
Некоторое резюме, которое у меня появилось: Требования не так важны, как цели и правила приёмки.
Не так важны для чего?
-
Для успеха проекта.
-
В каждом проекте успех - это что-то свое, особенное.
Где-то, действительно, успех -- любой ценой пройти приемо-сдаточные испытания. Несмотря на последующий разрыв отношений с Заказчиком. И тут на первый план выходит "правильно составленная" ПМИ.
Где-то успех -- разработать Систему, которая реально будет помогать Бизнесу решать их проблемы. Даже в убыток себе. Но чтобы Заказчик пришел к нам за помощью в решении своих проблем и в следующий раз. И тут на первый план выходят "правильно выявленные" цели и требования.
То есть я бы немного переформулировал тезис, добавив в него слово "иногда": Иногда требования не так важны, как цели и правила приемки.
-
В каждом проекте успех - это что-то свое, особенное.
Успех - это соответствие результатов работы поставленным целям. :)
"Ключевые требования, определяющие успех" - являются по сути подробной детализацией цели работы, если они правильно сформулированы, конечно. И противопоставление _этих_ требований целям не вполне корректно.
Также, не будет правильно противопоставлять требования правилам приемки (программе и методике испытаний). Дело в том, что каждый пункт ПМИ должен ссылаться на соответствующий пункт "технических требований" ТЗ, и если не будет такого пункта, на который можно сослаться - то включение в ПМИ теста будет не обосновано. Т.е. "требования" в ТЗ могут быть общи, но - обязаны быть полны-непротиворечивы, точно характеризуя весь scope работ.
"Правила приемки" являются по своей сути теми же требованиями, выраженными более подробно и в конструктивной форме - т.е. форме, допускающей проверку.
Короче, все три вещи - это разные грани одного целого. Нельзя говорить, что требования _вообще_ менее важны.
Но вполне можно сказать, что не надо включать в секцию "технические требования" ТЗ, которое является приложением к договору, детально расписанную простыню со всякой прописанной до мелочей ерундой, представление о которой может еще поменяться тридцать раз по ходу работ.
Вопрос в том, что иметь в виду под "требованиями".
-
Успех - это соответствие результатов работы поставленным целям. :)
Совершенно верно. Только в проекте как правило бывает много заинтересованных лиц. И у каждого своя цель. Поэтому и зафиксированные в ТЗ цели, отражающие чаще всего интересы Заказчика в части данного проекта, - не единственные.
Вполне возможна ситуация, что для кого-то полученный в ходе проекта результат будет успехом, а для кого-то - неудачей. В своем посте я рассматривал успех компании Разработчика. Цели которого, в общем случае, могут не совпадать с целями Заказчика.
-
Модератор: За повторное нарушение правил форум пользователь sudo-su забанен на месяц, за дальнейший повтор нарушений, бан будет навсегда.