Ситуация:
Вы являетесь руководителем проекта в небольшой компании, занимающейся системной интеграцией и оказывающей консультационные услуги в области информационных систем. Ваша компания выиграла в тендере и получила заказ на внедрение информационной системы. Ваш текущий заказчик – крупная инжиниринговая компания. Вам необходимо разработать и внедрить информационную систему, на которой, в том числе, будет размещаться информация о текущих проектах. Ваш заказчик (как и ваша компания) очень щепетильно относится к вопросу качества оказываемых услуг и результатов поставки. Заказчик не готов запускать в промышленную эксплуатацию систему при наличии в ней даже мелких, не критичных дефектов. При этом сроками поступиться заказчик также не готов. Вы подписываете договор, согласовываете устав проекта и приступаете к работам по сбору требований. После этапа проведения интервью и подготовки технического задания вы отправляете готовый документ на внутреннее согласование, в том числе и в отдел обеспечения качества, согласно внутренней методике ведения проектов. В результате согласования, вы получаете массу замечаний от отдела обеспечения качества. Замечания касаются как небольших несогласованных разделов в документе, которые можно трактовать различно, так и раздела ролей и прав пользователей, где информации просто недостаточно. После доработки технического задания аналитиком и устранения всех замечаний вы проводите дальнейшее внутреннее согласование технического задания и отправляете его на согласование заказчику в уверенности, что теперь по крайней мере, вы сможете протестировать систему, когда она будет разработана.
Вывод:
Вы поступили верно, привлекая отдел обеспечения качества к тестированию технического задания. Аналитики тоже люди и, зачастую, пропускают некоторые дефекты при написании технического задания. В случае прохождения техническим заданием процесса согласования с отделом обеспечения качества можно быть уверенным, что по крайней мере будет возможность протестировать систему. Если же документ не будет проходить согласование отделом обеспечения качества можно получить проблемы при попытке протестировать разработанный функционал. Например, в техническом задании может не оказаться информации о некоторых ролях или правах определенной роли в отдельных случаях, или об альтернативных сценариях поведения системы (например, что будет если нажать кнопку «Отмена», а не «Ок»), или о браузерах в которых должна функционировать разработанная система. Согласование документов на систему с отделом обеспечения качества или с отделом тестирования позволяет, также получить максимально близкий к пользовательскому взгляд на будущую систему.
- admin's блог
- Войдите или зарегистрируйтесь, чтобы получить возможность отправлять комментарии
- Версия для печати
- Отправить другу