Каждая крупная организация по стандартизации, сертификации или регулированию напоминает нам о необходимости ведения четких сформулированных требований. Но, несмотря на большое количество информации по управлению требованиями, компании по-прежнему испытывают трудности на всех этапах работы с требованиями.
БЕСПЛАТНО СКАЧАТЬ QA КНИГИ можно в телеграм канале "Библиотека тестировщика"
Ниже перечислены 5 ошибок, которые мы заметили в области разработки и управления требованиями.
1. Отсутствие необходимой коммуникации
Мы часто замечаем, что трудности со сбором требований возникают уже в самом начале разработки проекта. Одним из основных причин тому – отсутствие взаимопонимание и налаженной коммуникации между заинтересованными сторонами.
Например, одну организацию не устраивало несоответствие между тем, что запрашивали отдел продаж и отдел маркетинга, и тем, что предоставляла инженерная команда. Чтобы устранить эту проблему, было решено изменить внутренние процессы разработки продукта.
Но после внедрения новых процессов первый же проект привел к почти таким же неутешительным результатам, как до внедрения процессов. Это произошло потому, что в организации не была решена корневая проблема – пробел в коммуникации.
Выходом из подобной ситуации было бы создание предварительного документа с запросами всех заинтересованных сторон. Фиксировать все пожелания в нем следует дословно. Кроме того, в документ надо добавить, как эти запросы могут воспринимать конечные пользователи. Только после этого следует утвердить окончательные чёткие требования.
Создание такого документа до начала работы над фактическими требованиями поможет заинтересованным сторонам увидеть, как их первоначальные “хотелки” превращаются в более формальные требования.
2. Использование общих ресурсов без обсуждения
Подавляющее большинство проектов, над которыми работали долгие годы, не были изолированы друг от друга. Вся документация была доступна инженерам всех команд. Такая открытая среда хорошо воспринимается сотрудниками в компании и формирует общее поле, в котором взаимодействуют все элементы проекта.
Однако, у такой организации хранения проектной документации есть недостатки. Например, на ранних стадиях разработки некоторые команды решают использовать общие системные ресурсы не обсуждая это с владельцами других подсистем. Часто обнаруживается, что это решение было результатом переговоров в коридорах или неофициальных между командных совещаний, которые не записывались и не транслировались требуемым образом. Может возникнуть ситуация, когда ресурсы приходится менять, а вторая неформальная группа, которая планировала использовать этот ресурс, не информируется об этом. В результате попытка использования этого ресурса может привести к проблемам в работе разных подсистем проекта.
Для примера, одному инженер-механику нужен датчик температуры воздуха в определенной области системы. Другой инженер из команды упоминает, что у него есть подходящее готовое устройство.
После обсуждения механики решают между собой, что это именно то, что им нужно и включают использование устройства в свои планы проектирования. Шесть месяцев спустя устройство заменяется, но никто не сообщает об этом механикам. Они узнают об этом только во время тестирования.
Можно исключить подобные ситуации, наладив процесс проверки требований. Для этого существует огромное количество инструментов, которые можно внедрять в системах по управлению требованиями. Кроме того, следует взять за правило проверять все требования, а не только те, которые относятся к вашей зоне ответственности.
В примере выше команда механиков могла бы отметить это требование в системе. И если бы оно было изменено, то все заинтересованные лица получили бы уведомление об этом.
Таким образом, вы должны убедиться, что у вас есть метод отслеживания изменений в таких неизолированных системах и не следует полагаться только на устную коммуникацию, поскольку в нем могут произойти сбои.
3. Дизайн как функциональное требование
Частая проблема новых или начинающих компаний в том, что они сосредотачиваются на дизайне продукта, а не на том, что оно должно делать. Команды начинают определять размеры экрана, количество кнопок и другие элементы до того, как будут определены конкретные функции устройства.
Например, в качестве верхнеуровневого требования может быть указано, что устройство должно иметь емкостный сенсорный экран. А это подразумевает под собой и другие требования: к техническим характеристикам, процессам, к окружающей среде – все это может играть роль в принятии решений, однако, они напрямую не будут отражены в документации.
Лучший способ избежать проблем в такой ситуации – разделять документацию на функциональные требования и требования к дизайну.
В ситуации из примера выше мы можем узнать, почему сенсорный экран необходим с точки зрения производительности. Ответ необходимо внести в виде требования в техническую документацию. В то же время, можно начать создавать документы, содержащие концепцию дизайна для удовлетворения требований к внешнему виду устройства и к требованиям рабочего процесса.
4. Уход от изменений
Многие организации очень болезненно реагируют на необходимость менять спецификацию, когда она уже готова и утверждена. Но часто эти же организации не хотят ждать завершения работы над документацией по требованиям. Как следствие, документация пишется в то же время, когда разрабатывается продукт.
Неважно, насколько хороша ваша команда – но она не может создать что-то, если вы не сформулировали ожидаемый результат.
Правда в том, что изменения в процессе разработки неизбежны. Просто надо научиться принимать эти изменения и готовиться к ним. Потребности клиентов трансформируются, а мы как инженеры и дизайнеры учимся и приспосабливаемся к новому.
К сожалению, для таких проблем не существует простого и быстрого решения. Единственный способ узнать, как изменения в какой-либо части проекта влияют на другие элементы системы, – это установить и поддерживать систему контроля изменения требований, который позволит замечать взаимосвязи между различными уровнями спецификации требований.
5. Использование Word и Excel
Многие организации для процесса создания и управления требованиями по умолчанию используют Word и Excel. Выбор этих инструментов может быть заманчивой идеей: это дешево и просто. К сожалению, очень быстро версионирование требований начинает становиться настоящей проблемой, а матрицы трассируемости, созданные в Excel, становятся кучей столбцов со ссылками на не связанные документы.
Как упоминалось ранее, изменения при разработке неизбежны и обязательно необходимо отслеживать изменения. В этом поможет система управления требованиями. Она позволит облегчить задачу по поддержанию порядка среди большого объема требований и документаций. Такой инструмент становится единым источником актуальной и достоверной информации, обеспечивающим доступность и взаимосвязь всех данных между собой.
Сталкивались ли вы с какой-либо из вышеперечисленных проблем в своем проекте? Не стесняйтесь делиться с нами своим опытом в разделе комментариев ниже!
Об авторе
Эта статья написана для STH Фернандо Валера – главным техническим директором Visure Solutions, Inc. Фернандо Валера получил степень в области компьютерной инженерии в университете Комплутенсе в Мадриде. С тех пор он посвятил себя делу управления требованиями.
Перевод статьи «5 Deadly Mistakes in Requirements Management and How to Overcome Them».