В теме 11 ответов, и 8 участников, последнее обновление сделано пользователем 
Normalnaja 13 г, 6 мес. назад.
-
Сообщения
-
Привет всем,
Я вот на досуге задумался, а какие вообще документы должен знать, уметь и разрабатывать аналитик по долгу службы?
Вопрос довольно общий, и я постараюсь сформулировать исходные факты и предпосылки, которые собственно и вызвали у меня интерес:1) Методик и принципов бизнес-анализа довольно много. Некоторые из них общеизвестны и приняты повсеместно; другие же используется только в отдельных командах. Соответственно и выходная документация бывает разная по содержанию и назначению.
2) Опять же, исходя из многообразия методов бизнес-анализа, документы можно называть по-разному, хотя суть остается одна и та же. Тем не менее интересно будет узнать, если вдруг у кого-то в процессах есть тот же Vision and Scope, только под названием Вася Пупкин
.Можно начать со следующего исходного набора документов, которые я либо использую, либо когда-то использовал на своих проектах:
1. Proposal — письменное формальное предложение потенциальному заказчику. Зачастую пишется как ответ на Request for Proposal (RFP) от заказчика. Так как RFP есть плод творения заказчика, то здесь я его не упоминаю. Кстати, очень часто путают Proposal и RFP, думая, что аналитик пишет RFP, хотя даже по названию можно понять, что это не так.
2. Vision and Scope — общее видение на систему и ее границы.
3. Software Requirements Specification — полное описание поведения разрабатываемой системы, включающее функциональные и нефункциональные требования.
4. Software Design Document — описание системы с точки зрения ее архитектуры и реализации. Пишется естесственно не бизнес-аналитиком, но он может принимать активное участие в ее написании как опытный "писатель документов".
5. User Guide — понятная и удобная инструкция пользования системой, предназначенная для конечного пользователя.Какие еще есть варианты?
Скажу с колокольни тех. писателя
я бы сказал что юзер гайды пишут именно техрайтеры, зачастую основываясь на спеках.
В данный момент пишу Software Design Document. Но имхо такого типа документ должен писать сист. архитектор.Мне приходилось сталкивать со следующими типами документов, не считая перечисленных выше:1) Marketing Documents — описание системы/продукта с точки зрения маркетинга и продаж. Как правило включает краткое описание системы и задач которые она решает, сравнение со схожими продуктами, возможные плюсы приобретения конкретного продукта.
2) Manuals — тут вроде все понятно. ИМХО один из основных документов, создаваемых техническими писателями.
3) EULA (End User License Agreement) — что то вроде соглашения пользователя на условия распространения ПО (практически при каждой установке нового ПО каждый из нас подписывает такое соглашение). Как правило, подписывая EULA, пользователь отказывается от каких-либо претензий к разработчику ПО в случае если оно нанесет вред/ущерб системе пользователя, а так же обязуется не распространять ПО "пиратскими" способами.
К сожалению понятия не имею, кто создает такого типа документы.4) Online Documentation — WIKI для отдельно взятого проекта. Доступ к такой документации имеют одновременно исполнитель и заказчик, что является несомненным плюсом. Создается и поддерживается проектным менеджером и/или аналитиком.
Ниже будут и документы и не совсем.. ну, в общем, я решил припомнить всё, что вы ещё не назвали
· Meeting Minutes — формализированные результаты встреч, статус, action items, follow ups и т.д. (Meeting Minutes in Wiki)
· Communication Plan — (Communication Plan in Wiki)
· BRD (Business Requirements Document)
· BAP (Business Analysis Plan)
· RMP (Requirements Management Plan)Вспомнила и я:
1. Acceptance matrix — перечисление всех разработанных фич с целью сбора комментариев по результатам разработанного функционала для приемки продукта.На IBM (по крайней мере, когда я там работал) были такие документы:
Statement Of Work — документ, описывающий суть и скоуп работы. Можно сказать, что он является подмножеством Vision.
Architecture Specification — описание всей системы "с высоты птичьего полета". Как ни странно, это описание полностью оторвано от специфических технологий или решений. Включает перечисление основных бизнес-объектов и свяей между ними.
Functional Specification — описание системы на уровне Use Cases. Т.е.: "когда пользователь делает это — программа отвечает вот так".
Detailed Specification — описание каждой кнопочки и галочки, каждого поля с указанием допустимых значений, умолчаний. Часто включает даже описание алгоритмов на псевдо-программном языке.Состав документов может определяется методологией на проекте. Гляньте RUP , там столько артефактов нужно делать, что мама не горюй. Если на проекте как таковых требований к документации нет, то я бы рекомендовал писать следующие документы (причем в указанной последовательности):
1) Vision and Scope
2) User requirements document (URD)
3) SRSЕсли бизнес заказчика очевиден для команды, то URD можно опускать. Если проект простой, то можно URD объединять с SRS.
Ну, собственно, так оно и есть на большинстве проектов — Vision and Scope + SRS
Я бы даже сказал, что в половине случаев — только SRS… и это себя оправдывает.А кто-нибудь сталкивался с документами Business Case и Executive Summary?
Судя по всему их пишут именно бизнес-аналитики — еще до того, как начать работу над Vision and Scope.
Может у кого-нибудь есть хорошие шаблоны?А кто-нибудь сталкивался с документами Business Case и Executive Summary?
Судя по всему их пишут именно бизнес-аналитики — еще до того, как начать работу над Vision and Scope.
Может у кого-нибудь есть хорошие шаблоны?Эмм.. никогда не слышал, чтобы Executive Summary создавался как отдельный документ. Я его писал только как секцию Коммерческого Предложения (Proposal). Сказать, что для него есть шаблон? Ммм.. ну у меня есть некоторые правила и рекомендации по его написанию. А шаблона нет, к сожалению.
Да, executive summary — это некое обобщенное и часто употребимое понятие. Это может быть и секция, и отдельный документ. Причем применимость у него абсолютно разная.
2Юра — а поделись рекомендациями и правилами в контексте твоей применимости.
2All — а вы писали когда-нибудь по желанию заказчика такой документ?Позвою себе вместо Юры предоставить те самые рекомендации по Proposal (т.к. столкнулась сегодня с необходимостью качественного написания КП). http://www.slideshare.net/greesha/laf2010-vedenin
Простите, если это уже где-то есть на сайте. И отдельное спасибо Юре за шикарную презентацию. Для меня такие вещи на вес золота)))
Вы должны авторизироваться для ответа в этой теме.
