Приходилось ли вам работать в условиях мультизадачности — множества единовременно активных небольших ИТ-проектов? Наверное, так или иначе с этим сталкивались все менеджеры ИТ-индустрии. Статья будет полезна рекомендациями, как с этим справиться и «привести дела в порядок», а также правильно расставить приоритеты, распределить задачи и сбалансировать нагрузку между участниками на примере небольших проектов в тестировании ПО. ИT-директору компании она поможет в понимании цикла работы над такими проектами, а менеджеру проектов разработки — соотнести свои ожидания с реальностью.

Большинство считает, что работа на маленьких проектах по тестированию — это достаточно просто, ведь они краткосрочные, небольшие и не требуют значительных усилий. Что может быть проще тестирования интернет-магазина или социальной сети? Но на самом ли деле это так?

Оговоримся сразу, сценарии могут рассматриваться разные. Например, компания-разработчик имеет внутреннюю команду тестирования и «поставляет» ей в работу небольшие проекты. Либо же она отдает тестирование ряда небольших проектов независимой компании, специализирующейся на тестировании ПО. Также возможен вариант, когда компания полностью «аутсорсит» свою работу с ПО и пытается разобраться в том, как ее заказы «ходят» от внешнего разработчика к внешнему же тестировщику. Так или иначе, начнемс малого: представьте 15 небольших проектов по оценке качества ПО (Quality Assurance — QA) «в списке задач» QA менеджера за один месяц. Можно сказать: в одном большом проекте может «укладываться» 15 разных задач, ничего необычного. Но давайте посмотрим на это с другой стороны. У каждого из проектов — свой проектный менеджер, то есть 15 в месяц и примерно 45 разработчиков, у которых есть вопросы, желания, планы и личные интересы. Как же справиться с такой нагрузкой?

Каждый из 15 руководителей проектов требует, чтобы именно его проект протестировали как можно скорее, а лучше, прямо сейчас. Дабы контролировать поток спонтанных желаний проектных менеджеров и иметь четкий план, необходимо использовать запрос-прогноз на ближайшую перспективу. Его можно «оформить» в любом удобном виде (MS Outlook, Jira, в общем любой инструмент, позволяющий в автоматизированном режиме получать системную информацию). Самое главное — не тратить свое время на то, чтобы опросить каждого и дать понять команде разработки, что в случае, если информация не придет, очередной вариант скомпиллированного кода (билд) не будет протестирован на следующей неделе. Как говорится, ничего личного...

После того, как план составлен, выясняется, что у всех менеджеров проектов (PM) горят сроки и все они хотят тестировать проекты в один и тот же день. При этом — никто не готов уступать. Здесь начинает работать режим «живой» очереди, — кто прислал информацию раньше и выбрал свободный день, с тем и работает QA менеджер. Это, безусловно, стимулирует руководителей проектов не откладывать все в «долгий ящик» и своевременно отвечать на такие запросы. Не стоит забывать, что есть проекты, срок завршения которых вот-вот подойдет. Естественно, что такой проект становится в очереди раньше менее срочных.

Стоит учитывать, что по размеру билды могут быть разными, и на тестирование одного может понадобится 4 часа, а другого — 32. Нет нужды заставлять маленький билд ждать почти неделю. Иногда планы меняются и билд, тестирование которого запланировано, к примеру, с понедельника по среду, отменен. Соответственно, освободились три дня, на которые может претендовать другой проект (принцип «свободной кассы»).

Бывают случаи, когда PM — бывший разработчик и горит желанием проверить несколько багов сразу после их исправления а-ля: «Можете проверить 10 дефектов?». О том, что есть еще 50 менеджер обычно не говорит. В таких ситуациях полезно руководствуемся принципом из известного мультфильма «Лучше день подождать, потом за 5 минут долететь», объясняя проектному менеджеру, что билд будет принят в работу, когда все активные дефекты исправлены.

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

«Небольшой риск», закладываемый в обещанные проектными менеджерами сроки завершения тестирования обычно оправдан: если форс-мажора не будет и вы сдадите проект раньше срока руководитель будет вам только благодарен.

Очевидно, что каждый тестировщик сталкивался с тем, что билды далеко не всегда выставляются в обещанное время. К примеру, вам обещали в 9 утра. Разработчик приходит в 10, говорит, что билд «придет» через полчаса. Проходит 15 минут, и разработчик уверяет, что еще буквально 5 минут. К обеду вы получаете информацию, что разработчик уже в процессе написания нотификации... к вечеру вконец уставший девелопер сообщает — что-то пошло не так и фронт работ будет выставлен лишь завтра. Здесь сразу 2 проблемы: одна в том, что на завтра уже запланирован другой проект, вторая — что в течение дня обещанной работы не было. Решение этих двух проблем — гибкость планирования работы сотрудников и всем известный «пул задач». Если в команде есть договоренность, то сотрудники могут сами решить проблему с загрузками — взять задачу из пула, или предложить помощь загруженному товарищу.

Работа идет в основном с проектами, у которых есть 2 жестких ограничения — по срокам и по времени работы. Для таких проектов всегда есть спланированная заранее стратегия, и вариант «как пойдет» не сработает. Для таких проектов есть четко обозначенные временные ограничения — например, полчаса на изучение, час на создание тестовой документации. Временная оценка дается на каждый билд, а не на итерацию. А внутри каждого билда так же есть оценка на каждый проводимый тип теста — например, 6 часов на валидацию дефектов и 10 на регрессионное тестирование.

Может возникнуть ситуация, когда билды выставляются буквально «на лету» — разработчик «в параллели» с тестировщиком исправляет найденные дефекты. Когда же он заканчивает работу, разработчик обновляет тестовый стенд — и новый билд готов для работы. Промежуток между такими «горячими билдами» совсем небольшой — около 15 минут. В день в таком темпе работы может быть протестировано 5 сборок.

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

В заключении нужно сказать, что работа с большим объемом «маленьких» задач не так уж и проста. Советы, представленные в статье, пригодятся как в управлении несколькими небольшими проектами, так и в менеджменте одного с большим количеством задач. Приемы, о которых мы упоминали, достаточно просты на первый взгляд, но научиться ими «жонглировать» — большое искусство.