Про разработку информационных систем…

[Nadir Zaitov]

Оффтоп:

Сообщение от Erkin Kuchkarov

Так..... скоро тендер намечается?

Когда наметится, тогда объявится Могу продублировать приглашение тут

[Erkin Kuchkarov]

Оффтоп:

Сообщение от Nadir Zaitov

Когда наметится, тогда объявится Могу продублировать приглашение тут

Уж извольте Может и нам перепадет работенка.

[Vsevolod Usmanov]

Сообщение от Erkin Kuchkarov

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

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

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

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

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

1.7. Изменения к ТЗ на АС оформляют дополнением или подписанным заказчиком и разработчиком протоколом. Дополнение или указанный протокол являются неотъемлемой частью ТЗ на АС. На титульном листе ТЗ на АС должна быть запись «Действует с ... ».
...
11. Изменения к ТЗ на АС не допускается утверждать после представления системы для ее очереди на приемо-сдаточные испытания.

[Erkin Kuchkarov]

Сообщение от Vsevolod Usmanov

Данный подход (с некоторыми оговорками) применим при внедрении готовых решений при наличии грамотных специалистов, как со стороны исполнителя, так и со стороны заказчика.

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

Сообщение от Vsevolod Usmanov

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

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

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

[Alexander Kuznetsov]

Сообщение от Vsevolod Usmanov

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

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

[Gebo]

Сообщение от Vsevolod Usmanov

На шаге 2 Заказчик или разработчик увидел неточность в описании требований к реализации какой-либо функции.

Сообщение от Erkin Kuchkarov

(то есть полностью отвечает его ожиданиям и удовлетворяет его потребностям)

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

[kdima71]

Всем привет!

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


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

[Nadir Zaitov]

Сообщение от Gebo

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

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

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

[Erkin Kuchkarov]

Сообщение от Gebo

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

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

[Erkin Kuchkarov]

Сообщение от Nadir Zaitov

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

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