5 вызовов при управлении ИТ-проектом в сфере обеспечения качества

Функции менеджеров проектов в сфере обеспечения качества

Основная функция проектного менеджера — организовать всё так, чтобы процессы на проекте работали как «швейцарские часы». В грамотно выстроенном проекте даже если менеджер отлучится от работы на пару недель, ничего критичного не произойдёт.

Руководитель проекта в QA (Quality Assurance) выполняет следующие задачи:

  • оценивает предстоящий объём работ
  • оценивает риски и вырабатывает меры их предотвращения
  • составляет и актуализирует календарный план
  • определяет и ставит цели и KPI
  • декомпозирует и распределяет задачи
  • контролирует выполнение задач через трекинговые системы и дашборды
  • считает и контролирует трудозатраты
  • верстает отчёты по выполненным работам
  • анализирует метрики, «узкие места» производственных процессов 
  • проводит встречи, демонстрации и ретроспективы
  • выдаёт обратную связь команде тестирования по их работе

Опыт и компетенции руководителя проектов по тестированию ИТ-продуктов

Помимо ответственности, пунктуальности и педантичности, для того чтобы стать грамотным проектным менеджером, специалисту необходим реальный опыт в тестировании ИТ-решений. 

Чтобы вести проектную команду в правильном направлении, важно уметь предвидеть риски и проблемы, которые могут возникнуть во время работы, а также уметь отдавать себе отчёт в выполнимости поставленных требований. О том, как управлять ИТ-проектами в сфере обеспечения качества, невозможно вычитать в книгах или прочувствовать на тренингах. Но опыт работы рядовым инженером по тестированию будет крайне полезен. 

Менеджеру в QA необязательно обладать узкоспециализированными экспертными знаниями при управлении проектами, например, по тестированию мобильных приложений, веб-сервисов, баз данных и т.д. Достаточно любого опыта в тестировании ПО в течение нескольких лет. Не обойтись без хорошего софт скила управления командой. Нужно быть активным, открытым и всецело готовым на продуктивное взаимодействие с людьми.

Проекты по обеспечению качества ПО — это отдельный мир ИТ со своими особенностями. Например, специально обучить человека находить дефекты, если у него нет к этому склонности, практически невозможно. Навык находить дефекты оттачивается во всех плоскостях: анализ требований в ТЗ, создание тестовой документации, заведение дефектов, подготовка отчётов и т.д. И если человек не предрасположен к поиску дефектов, он лишь будет замедлять работу всей команды.

Тестирование всегда идёт бок о бок с разработкой. Они преследуют зачастую общие цели и соотносятся с единым календарным планом. Но подходы к управлению проектами по разработке и тестированию, а также вызовы во многом разнятся.

Вызовы при управлении командой тестирования

1. Оценка трудозатрат на работы по проекту при отсутствии подробной документации, опираясь только на общие требования от клиента.

Решение: 

Оценить риски и выработать меры их предотвращения. Примером превентивных мер служит:

  • выделение дополнительного времени на работу при отсутствии чётких требований со стороны клиента
  • погружение в особенности проекта ещё одного инженера по тестированию, который сможет оперативно приступить к работе в случае необходимости

Чем больше у проектного менеджера опыта, тем лучше он оценивает риски. Степень и количество рисков зависит от детализации требований клиента, вводных данных, целей проекта и т.д. 

Если клиент отвечает на все вопросы, задаваемые менеджером в начале сотрудничества, тогда риски минимальные. Если горизонт проекта небольшой и немного вводных данных, рисков закладывается больше. Для каждого проекта они рассчитываются индивидуально.

2. Обоснование клиенту превышающих расчётный бюджет трудозатрат после анализа производительности, исходя из текущей сложности проекта или наличия блокирующих факторов.

Решение:

Аргументировано и в доступной форме обосновать заказчику, зачем нужно выделить дополнительные средства из бюджета для 100% достижения цели проекта.

3. Планирование долгосрочной загрузки инженеров по тестированию, в то время как заказчик устанавливает горизонт планов на проект всего на две недели вперёд.

Решение.

Иногда клиент обозначает горизонт работ на 2-3 недели вперёд, и менеджер проекта не всегда понимает, когда инженер по тестированию выйдет из проекта и сможет приступить к другим задачам. Важно быть в постоянном контакте с заказчиком и стараться договориться о сроках.

Для выстраивания доверительной и продуктивной коммуникации необходимо в начале сотрудничества дать понять клиенту, что мы максимально открыты и готовы к изменениям на любом этапе проекта. Если что-то согласовано, это не значит, что оно неизменно. 

4. Уменьшение объёма тестирования до минимально приемлемого из-за сокращения сроков разработки или бюджета.

Решение.

Цель команды — обеспечить максимально высокое качество предоставляемой услуги, будь то тестирование, консалтинг, бизнес-анализ и т.д. 

Например, в ходе работ мы должны показать клиенту, сколько дефектов обнаружено в разрабатываемом продукте. Когда урезают бюджет, команда инженеров вынуждена сократить объём тестирования. Из-за сокращения объёма работ, есть риск пропустить дефекты в ПО.

При резком сокращении бюджета важно выяснить, какие функции клиент считает ключевыми, а какие —  второстепенными. Важно аргументировано рассказать клиенту о рисках, и к чему они могут привести.

5. Повышение мотивации и заинтересованности работы команды тестирования при выполнении однообразных задач.

Решение.

В каждом проекте главное — это люди. Удовлетворённый своей работой инженер по тестированию находит дефекты быстрее и выполняет свою работу качественнее. 

При распределении задач проектный менеджер должен учитывать компетенции и пожелания каждого сотрудника и осмысленно выдавать задания. Важно, чтобы каждый член команды был на своём месте.

Многих инженеров по тестированию посещают мысли: «вот был бы я менеджером проекта, сделал бы это по-другому, лучше…». Будучи сейчас на роли руководителя я стараюсь делать всё, что в моих силах, чтобы таких мыслей не возникало ни у команды, ни у заказчиков.

Как решать возникшие проблемы

Если проблема на проекте уже возникла, нужно сначала выяснить первопричину, выслушав версии всех участников команды, и только после этого формировать план нивелирования последствий. Менеджер по обеспечению качества всегда должен смотреть на ситуацию шире и думать о пользе для всего проекта / команды в целом.

Важно «подсвечивать» клиенту моменты, когда что-то пошло не так. Лучше как можно раньше сообщить о проблеме, а не скрывать это. Я выступаю за гибкость, открытость и прозрачность всех процессов в ходе реализации проекта.

Как руководитель QA-проекта поможет ускорить тестирование ПО

Как показывает практика, грамотное планирование, при котором удаётся завершить тестирование к установленному сроку и выпустить продукт — это большой успех.

Чтобы ускорить тестирование сборки, можно провести работу над анализом целесообразности автоматизации тестирования (если её ещё нет на проекте). В случае частого регресса автоматизация в разы ускоряет рабочий процесс. Однако требуется некоторое время, чтобы автоматизация тестирования начала приносить плоды. 

Ускорять функциональное тестирование можно через чёткую декомпозицию задач с последующей грамотной приоритизацией. Так критические дефекты находятся быстрее, а значит и риск выйти за сроки проекта — намного ниже.

Чтобы процесс тестирования в целом стал быстрее и точнее, нужно постоянно анализировать обратную связь от клиента, инженеров, собирать метрики и работать с ними. Важно не бояться менять проектные процессы, устранять шаг за шагом «узкие места», приводящие к увеличению сроков или снижению качества тестирования.

Руководители QA-проектов помогают широкому кругу людей: владельцам бизнеса — быстрее достичь поставленных финансовых показателей, пользователям их продукта — сформировать положительный опыт и всей команде тестирования и разработки — вести продуктивную коммуникацию и работать слаженно.