Внедрение АС: подход к написанию ТЗ

[Ivanhoe]

Для затравки ссылка на хорошую статью по использованию ГОСТ при написании ТЗ: http://boatmanshome.ru/cgi-bin/page.pl?21dev_002.page

В связи с новой партнерской программой MS довелось сдавать экзамен по использованию Sure Step, в ходе подготовки к которому детально изучал саму методологию. Изучая документы, пришел к выводу, что методологию Microsoft не особо затратно можно адаптировать к российскому ГОСТ 34 серии. Особенно это актуально при работе с гос.органами и близкими структурами.

Хотелось бы обсудить итоговые документы на стадии "Системное проектирование" / "Анализ" / "Планирование": пишете ли вы на проектах полноценное ТЗ (техническое задание в терминологии ГОСТ 34, функциональные требования / функциональный дизайн + ряд дополнительных документов по SureStep) и насколько ваша методология соответствует стандартным методологиям?

[AlGol]

Нам буквально недавно проводил семинар по SureStep Юрий Покусаев.
И если мне не изменяет память, то было сказано буквально - методология удовлетворяет требованиям госта 34.

А по вопросу - пишем конечно. По форме несколько отличный от SureStep документ, но очень похожий. Иначе рамки проекта фиг соберешь потом...

[Ivanhoe]

Проблема Sure Step в отношении к ГОСТу в терминологии. Названия стадий, документов и проч. Перевод сделан практически калькой, взять тот же термин "технический дизайн".
Плюс то же ТЗ пишется не на стадии Анализ, а на Диагностике - т.е. еще до формального заключения контракта. По хорошему, и по ГОСТу так можно / нужно делать. Просто на следующих стадиях ТЗ должно обновляться / расширяться. А в Sure Step пишутся _формально_ другие документы. И для гос. контор это принципиальный момент.

Ну и еще немного попиняю за перевод. В трех найденных русских тренингах по Sure Step одни и те же термины переведены на русский по-разному! Догадайтесь сами, соответствуют ли они переводу официального экзамена

[AlGol]

Quote:

Originally Posted by Ivanhoe

Плюс то же ТЗ пишется не на стадии Анализ, а на Диагностике - т.е. еще до формального заключения контракта.

Это смотря на что заключен контракт...
Никто не мешает заключить контракт как раз на стадию диагностики и целью его будет получение нормального ТЗ.
Но понятно, что с госструктурами попытка подписания подобных контрактов как правило упирается в полное непонимание со стороны заказчика.

[gl00mie]

А опрос относится только к работающим в консалтинге или ко всем? А то те, кто работают на клиенте, могут (можем ) подпортить статистику...

[Ivanhoe]

Пусть все пишут Для "на клиенте" я предпоследний пункт предложил. Странно, что пока никто не воспользовался...

[Bober]

Quote:

Originally Posted by Ivanhoe

Пусть все пишут Для "на клиенте" я предпоследний пункт предложил. Странно, что пока никто не воспользовался...

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

[Ivanhoe]

Microsoft в части выполнения методологии может влиять на партнеров, и то не совсем напрямую. А как повлияешь на клиента? Ну и не забываем, что клиент - всегда прав

[kALVINS]

Quote:

Originally Posted by Ivanhoe

В связи с новой партнерской программой MS довелось сдавать экзамен по использованию Sure Step, в ходе подготовки к которому детально изучал саму методологию.

Это вот этот экзамен?
http://www.microsoft.com/learning/en...8&Locale=ru-RU

[Ivanhoe]

Quote:

Originally Posted by kALVINS

Это вот этот экзамен?
http://www.microsoft.com/learning/en...8&Locale=ru-RU

Да.

[kALVINS]

Quote:

Originally Posted by Ivanhoe

Да.

А можно поподробнее рассказать как он проходил?
Сам собираюсь его сдать, хотелось бы узнать к чему готовиться.

[Ivanhoe]

1. Это уже офф-топ.
2. Судя по буквам MCT в вашем профиле, вам ли не знать, что обсуждать экзамены нельзя?
3. Из открытых источников - читайте тренинги, которые указаны по вашей ссылке. Ну и не забываем, что тестирование через Prometric. Т.е. как проходит экзамен знает каждый, кто хоть раз это делал

[Artoodeetoo]

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

[oip]

Quote:

Originally Posted by kALVINS

А можно поподробнее рассказать как он проходил?
Сам собираюсь его сдать, хотелось бы узнать к чему готовиться.

Можно. Обычный прометриковский тест, как и все остальные экзамены по Дайнемикс. Экзамен - по версии 2010.

Я лично тренингов на русском по 2010 не нашел, поэтому при подготовке пролистал два тренинга, 80088 и 80094, оба по старой версии методологии. Но мне кажется, что толку от этих тренингов почти никакого. Для сдачи экзамена пользы в них очень мало. Я сомневаюсь, что их вообще имеет смысл читать. По-крайней мере ничего нового для себя я из них не узнал. Ну и саму Sure Step пробежал глазами. На всю подготовку где-то дня два ушло.

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

Вроде данным сообщением ничего не нарушил. Если я ошибаюсь, просьба мне об этом сказать.

[pm-erp]

Грамотное ТЗ - серьезно снижает риски при внедрении ИТ-систем.
Без него (пусть и сокращенного) подписываться на внедрение - авантрюра как для исполнителя, так и для заказчика.

[Индра]

Мой опыт весьма однобокий - я последние 6 лет работаю только на стороне заказчика, и пришел к выводу, что ТЗ должен писать заказчик. Все предлагаемые системы автоматизации (пока) весьма несовершенны, подрядчики об этом знают, а заказчики - нет. Отсюда конфликт интересов - ТЗ написанное подрядчиком на 200 страницах вряд-ли будет глубоко понято заказчиком, и он подпишет его "на веру". В момент закрытия проекта, когда все проблемы налицо - заказчику предъявляют подписанное ТЗ, дальше возникает превышение бюджета и сроков. Консалтингу это выгодно - бизнес есть бизнес. Когда же заказчик предъявляет собственное ТЗ - ему говорят - "не по методологии".

Проблема в том, что заказчику трудно изыскать ресурсы для написания грамотного и исчерпывающего ТЗ. Увы. Но тем не менее - ТЗ верхнего уровня должно быть на 20 листах - если больше, то это уже мясо. Я описываю бизнес-структуру, перечень бизнес-операций (вклюая учет, планирование, контроллинг), перечень ролей (АРМ-ов) и все. Можно писать и в разрезе процессов - от этого суть не меняется. Я хочу платить за автоматизацию бизнес-операций, системные подробности реализации меня мало интересуют, поэтому в ТЗ верхнего уровня достаточно просто перечислить все операции с возможными вариантами (например - реализация на экспорт, реализация по РФ, планирование от потребности, оптимизация технологических и логистических маршрутов и т.д.). Это будет мало букв, и конечно, создаст определенные риски для подрядчика, зато обезопасит меня. Диалектика, однако...

[Zabr]

Quote:

Originally Posted by Индра

ТЗ верхнего уровня должно быть на 20 листах

Считаю, что должно быть по 2 документа со стороны и заказчика, и исполнителя.
от заказчика
1) концепутальное описание бизнеса и задач по автоматизации - 2-3 листа
2) более развернутое ТЗ - 10-20 листов
от исполнителя
1) концепутальное описание решения - 2-3 листа
2) развернутый дизайн решения - столько листов, сколько понадобится. Может 20, а может 200, а может и 2000.

Это то, что нужно перед тем, как начать что-либо реализовывать на практике. Менеджеры/руководители соответствующего уровня с каждой стороны потребляют либо первый, либо второй документ.

[Ivanhoe]

Кстати, всё это вполне реализуемо в рамках ГОСТ. В таком случае пишется рамочное ТЗ на 20-30 листов с основными спецификациями. А вот детали расшифровываются в соответствующих приложениях типа "Описание автоматизируемых функций" и проч.

[MikeR]

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

Пример:
"при условии, что агентом является Р____А АНДРЕЯ АНАТОЛЬЕВИЧА и процент комиссии = 10% СФОРМИРОВАТЬ:"

[Индра]

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