В теме 11 ответов, и 5 участников, последнее обновление сделано пользователем 
Aliaksei Rudzko 13 г, 11 мес. назад.
-
Сообщения
-
Кто тесно работал с русскоязычными заказчиками и на русскоязычных проектах, поделитесь, пожауйста, знаниями, какие документы разрабатываются, как называются и хоть минимально, зачем они и что содержат. Если есть возможность, то приведите, пожалуйста, полный список, т.е. даже те, которые лично аналитик не разрабатывает..Работал недавно с белорусским клиентом. Из документов поставили "Обзор" — полный аналог Vision и "Функциональную спецификацию" — аналог SRS.
Работал недавно с белорусским клиентом. Из документов поставили "Обзор" — полный аналог Vision и "Функциональную спецификацию" — аналог SRS.
А они подчинялись каким-то стандартам? Если да, то можно увидеть ссылки на эти стандарты?
Если доки получились хорошими, то было бы ещё зачетнее (хотя это, я думаю, это займет у тебя много времени), взглянуть на них с вырезанной приватной и конфиденциальной информацией, как на пример организации документов подобного рода..Заказчик не требовал придерживаться конкретных стандартов. Поэтому взяли Vision и SRS от внутреннего СаМовского проекта. Всё очень обычное. Вырезать конфиденциальную информацию не получится, т.к. специфика белорусского рынка для домена клиента предполагает жесткую конкуренцию и публиковать выдержки было бы "нечэсна". Походу проекта заказчик затребовал немало забавных изменениий формата SRS, что впрочем не привело к отходу от стандарта. Я на том проекте с dimon -ом работал. Так что можешь у него спросить подробности.Как мне кажется, здесь многое зависит от Заказчика. Если это большая организация (да еще со своим отделом АСУ), то, скорее всего у них есть и какие-то правила к оформлению документации, которых вы должны будете придерживаться.Вот, что я могу сказать исходя из своего опыта.
1. Государственные Заказчики.
Насколько мне известно, гос. организации обязаны оформлять документацию согласно ГОСТ-34. По крайней мере один наш очень серьезный гос. Заказчик это требовал. С этим Заказчиком работали так:
1. С начала было подготовлено Техническое Задание (что-то около 300 стр.). По нему выполнили определенный объем работ.
2. Когда потребовалось вносить изменения в ТЗ и приступить к новому этапу работ, оформили все изменения/уточнения требований документами "Частное Техническое Задание". ЧТЗ имеют свою нумерацию и соответствуют определенному модулю (или функциональной области) разрабатываемой системы.Несмотря на то, что ГОСТ регламентирует структуру документа, внутри секций вы имеете достаточно свободы действий. Мы, например, взяли пункт «Требование к функциям (задачам), выполняемым системой» и внутри этого пункта расписали почти все требования в том порядке, как посчитали нужным.
Вот ссылка на ГОСТы — http://www.rugost.com/index.php?option= … &Itemid=53м
2. Негосударственные заказчики.
Здесь, как правило, проще, т.к. вы можете использовать любой шаблон. Тем не менее, почти всегда последнее слово будет за Заказчиком. Поэтому если Заказчик требует ГОСТ (или внутренний шаблон) то будет сложно отвертеться
.
В моей компании изначально готовилось ТЗ в свободной форме, куда включали все требования. Все уточнения/изменения требований оформлялись оформлялись в виде отдельных документов , имеющих свою нумерацию в рамках проекта.Самое главное в работе с отечественными Заказчиками — убедитесь, что документ не только подписан, но и внимательно прочитан
Мне кажется есть один опасный момент по поводу использования документов вида Vision and Scope и SRS при работе с белорусскими клиентами. Даже если заказчик не требует следования ГОСТ: если в итоге он окажется недоволен проделанной работой (а повод придумать трудности особой не представляет) и дело дойдет до суда, исполнитель не сможет никак себя обезопасить. Проведение анализа, работа с требованиями — это такая услуга, которую проблематично "пощупать". И если заказчик в итоге скажет, что не получил никакого ТЗ, даже если была создана идеальная SRS: у нас в стране она не является действующим стандартом, и получится, что свои обязательства исполнитель по контракту не выполнил.Ася…написала так, как будто у нас работала.Мне кажется есть один опасный момент по поводу использования документов вида Vision and Scope и SRS при работе с белорусскими клиентами. Даже если заказчик не требует следования ГОСТ: если в итоге он окажется недоволен проделанной работой (а повод придумать трудности особой не представляет) и дело дойдет до суда, исполнитель не сможет никак себя обезопасить. Проведение анализа, работа с требованиями — это такая услуга, которую проблематично "пощупать". И если заказчик в итоге скажет, что не получил никакого ТЗ, даже если была создана идеальная SRS: у нас в стране она не является действующим стандартом, и получится, что свои обязательства исполнитель по контракту не выполнил.
Согласен, у нас всегда все сложно ;) Это вопрос больше из практики управления проектами, нежеле анализа требований. Мне не очень понятна ситуация, описанная выше — Заказчик оказался недоволен проделланной работой по всему проекту или только по стадии анализа? Наверное, по всему проекту:)
Такие риски обычно митигируются на стадии заключения контракта. Если это Fixed Price проект, то обычно к контракту уже прилагается детальный перечень артефактов, которые подрядчик предоставит Заказчику и требования к этим артефактом. Также можно обезопасится документом "План приемки" или "План ввода в эксплуатацию" который подписывается Заказчиком, чтобы потом вопросов не было. Как быть здесь с проектами T&M к сожалению не знаю.
Мне доводилось готовить документ типа "Концепция ХХХ системы" — почти полный аналог Vision and Scope. Не помню, чтобы он сильно обезопасил риски доведения дела до суда. Мы дополнительно готовили список фич, которые будут разработаны и прикладывали к контракту. По-моему называлось это что-то типа "Функциональная спецификация".
Мне не очень понятна ситуация, описанная выше — Заказчик оказался недоволен проделланной работой по всему проекту или только по стадии анализа? Наверное, по всему проекту:)
Честно говоря, я имела в виду только стадию анализа. Когда есть готовый проект, мне кажется, проще доказать, что работа выполнена. А вот анализ — это более абстрактное понятие, попробуй докажи, что он проведен, если для заказчика Use Case диаграмма — не более чем дурацкие кружочки.
Наверное, это скорее вопрос к юристам. Почти всегда в календарном плане-графике работ, который прилагается к договору, прописывается стадия сбора/анализа требований. Напротив этой стадии указывается срок исполнения. Ну и необходимо определять критерии выполнения задачи — подписанная документация.
Честно, говоря, я никогда не слышал, чтобы Заказчик не подписывал хорошую документацию, в которой отражены его требования на понятном языке. Тем более что "кружочки" всегда воспринимаются на -ура:)P.S. Просто интересно — у вас был какой-то конкретный прецедент?
У меня лично конкретных прецедентов не было, но я пессимист ) Я знаю, что подобное, увы, случается, чаще всего это касается именно гос. огранизаций, которым получить результат работы хочется , а платить за него — не очень. Но вообще говоря это действительно вопрос к юристам.Здесь очень важно что именно написано в договоре. И юристам на откуп отдавать этот нюанс нельзя. Юристы разбираются в тонкостях делопроизводства, но не знают ИТ стандартов.
Правильный процесс. 1) Юрист берет название документа из первоначального предложения. 1.1) Если название не подходит с юридической точки зрения, то 1.1.1) обсуждает с аналитиками как можно документ переименовать, чтобы тот соответствовал юридическим требованиям или 1.1.2) требует переоценить проект/ отменитьпроект в связи с тем, что придется-таки делать документ соответствующий определенному стандарту.
Неправильный процесс (тут мне стыдно за нашу компанию): 1) Юрист исправляет (посоветовавшись только с руководством) название документа. 2) Ближе к окончанию проекта аналитик узнает, что делает не то.
Вы должны авторизироваться для ответа в этой теме.
