Понятие документооборота

[Odil Abdullaev]

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

Ну естественно - работа такая

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

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

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

[Erkin Kuchkarov]

Оффтоп:

Сообщение от Odil Abdullaev

Несколько лет отставания согласитесь достаточно неплохо. Возьмитесь, для примера, сравнивать российские продукты банковского сектора и наши

Это тема для другой ветки Я думаю наши коллеги с ASBT и FIDO там к Вам присоединяться к обсуждению

Сообщение от Odil Abdullaev

Ну и в чем тут фишка?! В том, что используется в качестве нотации используется IDEF0? Или в том, что генерятся SQL скрипты?!

Фишка в том, что собственно сама маршрутизация уже была. Не было встроенного редактора маршрутов

[Erkin Kuchkarov]

Сообщение от Odil Abdullaev

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

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

[Odil Abdullaev]

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

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

Хм.. мне кажется Вы просто консервативны и пытаетесь воссоздать идеальные условия, каковых в реалии нет. Может Вы считаете что "метод водопада" даст фору любой современной методологии, предполагающей итеративный подход, в том числе и при работе с требованиями, и где начальные требования всегда разнятся от конечных?

[Erkin Kuchkarov]

Оффтоп:

Сообщение от Odil Abdullaev

Хм.. мне кажется Вы просто консервативны и пытаетесь воссоздать идеальные условия, каковых в реалии нет.

Да нет... Вы ошибаетесь.

Сообщение от Odil Abdullaev

Может Вы считаете что "метод водопада" даст фору любой современной методологии, предполагающей итеративный подход, в том числе и при работе с требованиями, и где начальные требования всегда разнятся от конечных?

Я не считаю. Я предупреждаю (всегда) "Заказчика" АСУ, что основополагающим документом для проекта внедрения АСУ является согласованное и утвержденное ТЗ(в котором четко описаны требования к проектируемой системе в целом и каждому рабочему месту и функциональности в, в частности, исходя из которых зависит объем работ и стоимость самого процесса внедрения ), от качества разработки которого зависит успех проекта. Доработка же ТЗ для "конечных" условий выдвигаемых "Заказчиком" стоит времени и соотвественно, денег.
То есть я всегда готов на доработку проекта с принятием условий выдвигаемых на конечной стадии но в этом случае "Заказчик" должен осознавать объем тех материальных затрат на которые он должен будет идти.
А так как я и моя команда "стоит" денег (реальных и конкретных) то я всегда призываю "Заказчика" внимательно изучать каждую строчку ТЗ, согласовывать и утверждать каждую страничку указанного документа.

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

[Ibrohim Djuraev]

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

Оффтоп:

Я не считаю. Я предупреждаю (всегда) "Заказчика" АСУ, что основополагающим документом для проекта внедрения АСУ является согласованное и утвержденное ТЗ(в котором четко описаны требования к проектируемой системе в целом и каждому рабочему месту и функциональности в, в частности, исходя из которых зависит объем работ и стоимость самого процесса внедрения ), от качества разработки которого зависит успех проекта. Доработка же ТЗ для "конечных" условий выдвигаемых "Заказчиком" стоит времени и соотвественно, денег.
То есть я всегда готов на доработку проекта с принятием условий выдвигаемых на конечной стадии но в этом случае "Заказчик" должен осознавать объем тех материальных затрат на которые он должен будет идти.
А так как я и моя команда "стоит" денег (реальных и конкретных) то я всегда призываю "Заказчика" внимательно изучать каждую строчку ТЗ, согласовывать и утверждать каждую страничку указанного документа.

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

Эркин ака, можно тут втиснутся? По части к подходу проведения работ по разворачиванию ИС в предприятии, вы упустили момент который необходим перед подготовкой ТЗ проекта, момент называется ПИР (предварительные исследовательские работы, можно просто изучение объекта). Насколько я знаю для составления проектных документаций с учетом всех требований заказчика, необходимо сначала провести исследование объекта, в котором планируется внедрять систему. Во тогда будут отпадать вопросы связанные с

описаны требования к проектируемой системе в целом и каждому рабочему месту и функциональности в, в частности, исходя из которых зависит объем работ и стоимость самого процесса внедрения )

и конечно отпадает вот этот вопрос

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

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

[shumbola]

Оффтоп:

О-о-о, пошел серезный разговор. Водопад, снегопад,...лишь бы камнепада не было, все остальное имеет право на жизнь. :-)

[Erkin Kuchkarov]

Сообщение от Ibrohim Djuraev

По части к подходу проведения работ по разворачиванию ИС в предприятии, вы упустили момент который необходим перед подготовкой ТЗ проекта, момент называется ПИР (предварительные исследовательские работы, можно просто изучение объекта).

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

[Odil Abdullaev]

Честно, Эркин-ака. Мне непонятна Ваша категоричность. Хотите дам ссылки почитать материалы о современных методологиях. При том что жалуетесь на отставание в развитии продукта на несколько лет, сами пытаетесь использовать методики внедрения 80-х. Гибче надо быть, гибче

[Erkin Kuchkarov]

Сообщение от Ibrohim Djuraev

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

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

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