Завидую Вам “белой завистью”. Реализовать проект по такой схеме – большое искусство как аналитиков, разработчиков и менеджеров проекта, так и проектной рабочей группы заказчика (особенно, если обошлось без допсоглашений и дополнительных денежных инъекций). Ни разу не только не участвовал, но и не видел (можно сказать, что плохо смотрел :)) проекта по разработке заказной информационной системы, где бы предокончательный вариант системы (сданной в опытную эксплуатацию) полностью совпадал бы с требованиями, четко и однозначно, определенными в утвержденном техническом задании, которое не претерпело никаких изменений со дня утверждения. Может быть за исключением проектов, где техническое задание (не в стандарте ГОСТ34 или ГОСТ19) подготавливала одна компания, а реализовывала другая компания.

IMHO, данный подход ошибочен и обречен на неуспех в проектах по разработке и внедрению информационных систем. Такой подход (называемый каскадным подходом или "водопадом") в современных реалиях приведет к огромному увеличению стоимости проекта и к увеличению сроков ввода в промышленную эксплуатацию. Кроме того, ни один вменяемый заказчик, если ему дороги его деньги и время, не пойдет на такие жесткие условия - после утверждения технического задания ничего нельзя изменить до ввода в опытную эксплуатацию; ну а потом можно, но только за дополнительную плату. Данный подход (с некоторыми оговорками) применим при внедрении готовых решений при наличии грамотных специалистов, как со стороны исполнителя, так и со стороны заказчика.

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

Даже несовершенный в современных реалиях стандарт ГОСТ34.602-809 (Техническое задание на создание АС) допускает изменения к ТЗ на стадии разработки и запрещает изменения на стадии приема-сдачи.

В отличии от разработчиков - я внедряю "готовые решения". То есть - результат, как цель, должен быть известен до того как будет озвучена цена. В противном случае можно делать один проект всю жизнь - нет предела совершенству. :)

Так давайте вернемся к этапу формирования ТЗ, как к документу основопологающему в проекте.
Существуют входные качественные и количественные параметры, а именно:
1. Нормативная база (Законодательство, должностные инструкции и прочая прочая прочая) - это кстати может меняться в процессе формирования ТЗ и до его утверждения... скажем - в целях оптимизации... согласны?
2. Персонал и материально техническое обеспечение - тоже может менятся в процессе формирования ТЗ и до его утверждения... скажем в целях соотвествия техническим требованиям к предполагаемой системе.
3. Кваллификация персонала - точно будет менятся (кто в здравом уме покупает бибику если на ней некому ездить?)

Если на этом этапе все сделано и удовлетворяет требованиям Заказчика к проектируемой системе (то есть полностью отвечает его ожиданиям и удовлетворяет его потребностям) то о каком изменении может идти чем речь?

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

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

Всем привет!

Однажды я прочитал эту книгу....долго думал!


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

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

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

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

Надир - Вы это... людей то не пугайте. Давайте на банальных, общепонятных примерах
1. ТЗ на ИТ инфраструктуру для СУБД.. в ТЗ порешили что сервак, к примеру, имеет большую, достаточную, дисковую подсистему (DAS)
Много памяти, много процессоров. 4 езернет контроллера, RAID офигенный, ОС Windows 2003 R2 Std, СУБД SQL 2005 Std. (ИОПсы, террафлопы - все подсчитали по какой нить формуле или взяли из сайзера производителя... не в этом дело). Зашибись? Подписали.
3. Процесс закупки и доставки прошел как нельзя лучше - железку отгрузили, расстаможили, собрали... тут и лицензии подошли (конвертик)
2. В процессе интеграции и миграции у заказчика появились\сформировались новые требования - нужен отказоустойчивый кластер.
Заказчик согласен пересмотреть условия ТЗ. Готов подписать допу без
увеличения стоимости - буквально слезно просит бамажку.
Ну и как Вы, интегратор, поступите? ;)