Сначала договориться о результате
- Как вы понимаете, что такое «Паспорт QA»?
Именно с этого вопроса я начала обсуждение новой инициативы на нашей еженедельной встрече с тестировщиками.
Команде предложили разработать шаблон документа с названием «Паспорт QA». Честно говоря, за свои 14+ лет работы в ИТ я впервые встретила такой термин. Если бы документ назывался, например, «Шаблон чек-листа по тестированию доработки», его назначение было бы понятно уже из названия. В этом случае обсуждение, скорее всего, сразу перешло бы к структуре документа.
Но что такое «Паспорт QA»? Название само по себе не давало ответа.
Поэтому вместо обсуждения шаблона я предложила сначала ответить на несколько простых вопросов: - что должно получиться в итоге; - какую задачу должен решить этот документ; - для кого он создается; - кто будет поддерживать его в актуальном состоянии после создания.
И только потом переходить к структуре.
Дальнейшее обсуждение оказалось очень показательным. Один и тот же документ участники представляли совершенно по-разному. Для кого-то это была база знаний по QA, для кого-то - описание автоматизации, для кого-то - документ для быстрого погружения новых сотрудников. Кто-то видел его как паспорт компетенций специалиста.
И самое интересное - ни один из этих вариантов нельзя было назвать неправильным. Но каждый участник обсуждения вкладывал в этот документ свое назначение.
В этот момент стало очевидно, что разговор о структуре был бы преждевременным. Сначала нужно было договориться о результате.
После этой встречи я еще раз убедилась, что для меня любое подобное обсуждение должно начинаться с нескольких простых вопросов: - что должно получиться; - зачем; - для кого; - кто будет отвечать за результат после того, как работа будет завершена.
На первый взгляд может показаться, что такое обсуждение занимает слишком много времени. Но мне кажется, гораздо лучше потратить его в начале, чем позже обнаружить, что каждый решал свою задачу.