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

[Nadir Zaitov]

Сегодня как в кашмарном сне в очередной раз перечитываю "документы", ранее "подготовленные" для реализации IT проекта, с которым я работаю. Я вполне нормальный чайник в IT бизнесе, однако и мне страшно видеть, как можно "не уметь" работать и готовить документы. Невольно вспомнил топик в баш.орге, который сразу начал упорно искать и отыскал:

c форума sql.ru про разработку информационных систем…

…А вообще, я очень хочу, чтобы наша профессия со временем стала такой же инженерной дисциплиной, как, например, строительство - вам нужно здание? Извольте заплатить за проект, а потом за возведение, или покупайте (арендуйте) готовое, но тут уж не выдвигайте требований пристроить к нему еще 30 этажей. Изволили построить времянку, а теперь хотите ее превратить в доменный цех? нет проблем - СНОСИМ временку и строим цех. Через пять лет вам потребуется переделать цех в аэропорт? Это ваши трудности - х*й в голове медицина бессильна. Вы никогда не задумывались почему в IT такой процент проваленных проектов (представьте себе такой процент например в автомобилестроениии)? А потому, что делают их не в рамках инженерного подхода, а вопреки ему…. И заметьте, никто не кричит “Судостроители пи…сы не хотят переделать речной трамвайчик в ледокол”. Ээээх мечты…

Так вот и мой вопрос: кто знает статистику по проценту проваленных IT проектов в Узбекистане? В госсекторе? В частном секторе? Может кто-нибудь подетится своим опытом, то было бы интересно.

[Erkin Kuchkarov]

Оффтоп:

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

Cегодня как в кашмарном сне в очередной раз перечитываю "документы", ранее "подготовленные" для реализации IT проекта

Это практически каждый день у нас

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

кто знает статистику по проценту проваленных IT проектов в Узбекистане? В госсекторе? В частном секторе?

Тот кто ее ведет, а ведет ее "никто" - у них и спрашивайте

[Eldar Fattakhov]

Оффтоп:

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

кто знает статистику по проценту проваленных IT проектов в Узбекистане?

Здесь лучше будет озвучить количество разваленных (и не реализованных в итоге) проектов...

Хочется думать (базируясь на отсутствии у меня отрицательных данных по проектам на основе технологий HP), что таковых нет. Большинство проваленных проектов с компьютерной техникой не являются ИТ-проектами, так как предусматривали только оснащение рабочих мест (например, поставки в МНО и МВиССО).

[Nadir Zaitov]

Сообщение от Eldar Fattakhov

Хочется думать (базируясь на отсутствии у меня отрицательных данных по проектам на основе технологий HP), что таковых нет.

Одно дело исправно поставить оборудование (и я уверен мало-мальски уважающий себя вендор сделает все, чтобы его так и поставить! ). Идя в том, чтобы оно потом работало и именно так, как задумывалось. Вспомните те же школы, в которых компьютеры просто заперты от детей чтоб не испортились, или те же компьютеры в школах, которые используются детьми для "контры" во время уроков. ИМХО, оборудование работает не значит, что оно выполняет свою функцию.

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

Это практически каждый день у нас

Поделитесь типичными ошибками и как Вы с ними управляетесь, плс. Запарился с обчными проблемами, на которые нарываешься на своем опыте. Хотелось бы увидеть как их предупредить

[Eldar Fattakhov]

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

чтобы оно потом работало и именно так, как задумывалось.

Я - про то же. Поэтому о проектах говорил именно в этом аспекте "чтобы работало так, как задумано". Если заказчик не блокирует наши (HP) попытки помочь ввести систему в эксплуатацию, то проект доходит до положительного результата (как минимум - для заказчика).

[Nadir Zaitov]

Оффтоп:

Сообщение от Eldar Fattakhov

проект доходит до положительного результата (как минимум - для заказчика)

Это игра слов? "проект дошел до заказчика" - наконец заказчик понял, что хотел от него поставщик !

[Eldar Fattakhov]

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

Это игра слов?

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

Если это - игра слов, то возможен и второй вариант: до поставщика наконец дошло, что именно хотел заказчик!

[Erkin Kuchkarov]

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

Поделитесь типичными ошибками и как Вы с ними управляетесь, плс. Запарился с обчными проблемами, на которые нарываешься на своем опыте. Хотелось бы увидеть как их предупредить

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

[Vsevolod Usmanov]

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

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

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

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

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

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

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

[Nadir Zaitov]

Сообщение от Eldar Fattakhov

железо покупается под рекомендации разработчика без формирования цельной картины "что требуется заказчику".

Нет. Уверен - цельная картинк как все будет и что будет потом мне нужна.
Только на днях ругался с несогласованностью в тендерной документацией по закупу компьютеров:

1) Вроде все хорошо. Компьютеры, операционная система, офис, антивирус на все компьютеры.... Стоп.. а где централизованное управление антивирусами и раздача сигнатур спросите вы? Нет. Не предусмотрено... ни софта, ни железа (сервера) - в другой пакет перенесли (кстати, раз тендеры разные - решения могут быть разные: например, локальный софт от Касперского, а центральный от NOD32 ). А к интернету компьютеры подключать нельзя "по определению"

2) Другой пример ляпа, который не сразу увидешь. Персональный компьютер (по спецификации такой домой покупать западло) вдруг иногда называется рабочей станцией и требуются документы, подтверждающие, что это рабочая станция! Загрузка писюка - веб-браузер как максимум, а подавай рабочую станцию - просто нашелся умник красивое слово вставить. Убили бы меня, если я не прав и рабочая станция и персоналка - это абсолютно одно и то же?

3) Выяснилось, что люди не представляют, ЧТО ТАКОЕ растаможка и какие документы и в каком количестве нужны... думаю что делать - за...думался до дыр в мыслях! Решил просто с Вами, ребята, пообщаться пока дыры сами залатаются (с подсознанием распараллелился ).