Фамилии исполнителей в договоре между клиентом и внедренцем

[Lz_]

У меня складывается впечатление, что в результате обсуждения у некоторых коллег сформировалось ошибочное мнение что методология основанная на ГОСТ не позволяет учесть все пожелания и замечания пользователей, а методология на основе Sure Step только и предназначена для более тонкого тюнинга системы под потребности пользователя. Я в корне не согласен с таким утверждением. Документы, создаваемые по ГОСТ никак не регламентируют глубину проработки требований клиента. Глубина проработки целиком и полностью зависит от квалификации внедренца, степени «понятливости» клиента и готовности клиента принять документ в такой форме. Документ должен быть составлен так, что бы клиенту было понятно что будет на выходе.
По крайней мере, в нашей методологии масса мест, где пользователь имеет возможность подкорректировать систему.

1. Исходные требования – чаще всего клиенты самостоятельно формулируют на обычном бытовом языке чего они хотят добиться.

2. ТЗ – содержит:
Данные об объекте автоматизации;
Цели внедрения и критерии оценки достижения этих целей;
установлены четкие технические требования к системе в том числе надежность ;
определены функции системы;
определены входная и выходная информация системы;
определены функции пользователей, т.е. по сути, система «наложена» на организационную структуру предприятия и определены рамки ответственности;
определены состав и содержание работ по созданию системы, т.е. работы, которые выполняются в системе и ответственность за эти работы разделены между клиентом и разработчиком;
составлен календарный график проекта и работ по проекту;
определены требования по подготовке объекта автоматизации ко вводу системы: что должно быть готово для того, что бы начать реально внедрять систему;
требования к документированию: вот здесь четко и понятно расписано какие документы разрабатываются и на каких этапах передаются клиенту.
Создание ТЗ – это очень большой кусок работы. Начиная от упорядочивания требований и по сути архитектурных решений системы, до согласования с заказчиком всех требований функция, а главное функций пользователей (кто что делает и за что отвечает). И этот документ проходит рецензирование пользователями. В процессе рецензирования пользователи могут высказать (письменно ) любые замечания, которые будут рассмотрены. И решение учитывать или отклонить эти замечания принимает Клиент, а не разработчик. Это первая обратная связь.

К слову сказать, ТЗ - это основной документ по которому происходит приемка системы.

[ИМХО]
Если я не прав насчет Sure Step, поправьте меня.
В Sure Step, на сколько я понял, совокупность информации содержащейся в ТЗ по ГОСТ (не уверен в полноте, так как сильно глубоко не копал) появляется только после прохождения 2-х этапов: Диагностики и Анализа. При этом эта информация разрознена и находится в разных документах, которые интегратор может и не делать по разным причинам .
По методологии Sure Step техническое задание является выходным документом этапа Диагностика. Но на этом этапе нельзя сделать ТЗ, соответствеующее требованиям ГОСТ, т.к. для его создания не достаточно информации – этапа Анализ еще не было. И главная нестыковочка – это отсутствие единого документа в котором прописанный все критерии которым должна соответствовать система.
[/ИМХО]

3. Проектирование. Этот этап сильно зависит от сложности системы и объема внедрения. Если объем работ относительно не большой, то создается Технорабочий проект, если внедрение сложное и объемное, то Эскизный, Технический и Рабочий. Все они отличаются степенью детализации. Чем дальше, тем большая степень детализации. Люди реально изучают систему (стандартную + существующие доработки) и пытаются сделать так, что система выполняла свои функции и в то же время было удобно работать. Все эти проекты проходят этап рецензирования. Вот на этом этапе и определяется «весь тюнинг» системы. Это вторая обратная связь.

4. Разработка. Кодим, тестим, еще кодим, уточняем не понятные вопросы и т.п. Согласовываем программу и методику предварительных испытаний и тестовый пример. Импортим исходные данные и Клиент производит выверку данных. Все что криво залили переделываем . «Прогоняем» согласованный тестовый пример сначала мы, потом клиент. Огребаем кучу замечаний, клиент решает, что делаем, а что не делаем. Это третья обратная связь.

5. Опытная эксплуатация и приемка. Это работа в полях. Это, как правило, один из самых длительных этапов.
5.1.Сначала подготавливаем систему ко вводу в опытную эксплуатацию. Асапта уже установлена на рабочих местах, люди пытаются работать, крики, истерики, саботаж все проявляется на этом этапе. Мы работаем с пользователями, учим, объясняем, разруливаем сложные ситуации. Параллельно с ИТ клиента осуществляем техническую поддержку системы и пользователей, тем самым обучаются спецы клиента поддерживать систему решать возникающие проблемы и пользователи учатся работать в системе. Есть рабочий журнал, в котором пользователи пишут свои замечания и сообщения об ошибках и не доработках, ошибки устраняются, дополнительные бантики выносятся на заседание комиссии рецензирования. Примут – сделаем, не примут – не сделаем
5.2. Опытная эксплуатация. Это еще один из видов испытаний системы, всего из 3 (ГОСТ 34.603). По сути, полноценная реальная работа пользователей в системе в системе. Опять работаем с замечаниями. Пишут все начиная от замечаний по делу и просто «потому что так мне работать удобнее/лучше». На все замечания даем ответ. Ошибки – исправляем, если замечание является результатом ошибочных действия пользователя, то расписываем подробно что нужно сделать, что бы этого не было. Ответ пишется в журнале, если он объемный то отправлятся электронное письмо с инструкцией, а в журнале указывается дата и кому было отправлено письмо. Если замечание влечет за собой доработку, не оговоренную в документации, то замечание выносится на заседание комиссии рецензирования. Разрабатываем и принимаем Программу и методику приемочных испытаний. По результатам опытной эксплуатации большое заседание с полноценной обработкой замечаний. Если, система испытания выдержала, то принимается решение о проведении Приемочных испытаний. До начала приемочных испытаний все замечания пользователей подлежащие реализации должны быть сделаны. Это четвертая обратная связь.
Всё, система, по сути, полностью готова.
5.3. Приемочные испытания – третий тип испытаний. Тестируем быстродействие системы и надежность и достижение целей, короче, соответствие системы Техническому заданию. Считаем показатели надежности, если все ок – испытания завершены и система принята, если нет, то .

6. Система принимается в постоянную эксплуатацию. Осуществляем сервисное сопровождение.

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

А у вас внедрение как происходит?