«Горящий» проект – не редкость в IT сфере. Отставание от плана может возникать на разных стадиях: от инициализации проекта до тестирования. Данный доклад - попытка ответить на вопрос: «Почему тестировщики не укладываются в сроки?».
Недавно мне «посчастливилось» принимать участие в проекте, на котором отставание от сроков – обычное дело. Сразу хочу пояснить, что я понимаю под отставанием от сроков. Это разница между реально потраченным и запланированным временем (см. рисунок 1).
В докладе рассматриваются причины невыполнения в срок задач тестовой команды, хотя многое из того, о чём будет говориться ниже, актуально для любых проектных активностей.
Несколько слов о проекте, который вдохновил меня на подготовку этого доклада. Проект был сложный… :) Причём, я сейчас говорю не о сложности задач, которые стояли перед нашей командой, а о сложной структуре проекта. На рисунке 2 представлена схема этого проекта, где З1...З8 – задачи, из которых состоит реализация проекта, К1…К8 – компании (подрядчики), которые принимают участие в проекте. Как видно, каждый подрядчик отвечает за свою задачу. И даже заказчик выполняет часть работ по созданию программного обеспечения.
Многое из того, о чём пойдёт речь дальше, навеяно именно этим сложным проектом, но также я использовала опыт участия в более простых проектах (Рисунок 3).
Думаю, понятно, что вероятность «пожаров» на проектах со сложной структурой больше. Естественно, здесь много зависимостей. Если один из подрядчиков на начальном этапе не уложился в сроки, то «поплывут» даты в планах у остальных компаний-подрядчиков. На сложном проекте часто возникает ситуация: «а это не я». Это когда на выявление ошибки уходит час, а на выявление ответственного за неё тратятся дни или даже недели. Каждая компания пытается сделать крайним кого-то другого. Такая проблема обычно возникает из-за плохой организации взаимодействия между участниками проекта и нечёткого разграничения обязанностей.
Теперь непосредственно о самих причинах. Одна из самых очевидных причин «пожаров» - нереальные сроки. Как эти «нереальные» сроки появляются? Например, заказчик говорит: «нужно, чтобы эта функциональность (F1...Fn) была готова к такому-то числу». И тут начинается попытка уместить всю требуемую функциональность в указанные сроки (хотя бы в плане проекта, который потом не соответствует действительности). В данном случае ошибка в том, что не исполнитель оценивает временные затраты, а заказчик устанавливает дату. Если времени для реализации требуемой функциональности явно недостаточно, то нужно выбирать: или урезанная функциональность в указанные сроки или смещение сроков для реализации полного объёма задач.
Также часто я наблюдала пожары, когда требования менялись в ходе проекта. Если не переписать план в связи с изменением требований, то вероятность своевременного окончания проекта невелика :)
Для тестировщиков, которые выполняют задачи по уже составленному менеджером плану, часто очень актуальной проблемой становится неполный учёт задач в плане. Например, часто забывают о том, что уходит время на новичков, на помощь разработчикам в воспроизведении дефектов, на подготовку тестовых данных, на подготовку внеплановых отчётов для руководства. Плохой анализ требований и спецификации может привести к тому, что в тест-кейсах будут присутствовать не все проверки, а, следовательно, будет неправильно оценено время на тестирование. Даже одна пропущенная строка в спецификации может послужить искрой, из которой вырастет пожар. Например, в требованиях сказано: «Система должна работать под ОС Win 98, 2000, XP, Vista». Если в тест-кейсах об этом нет ничего, то тестирование будет проводиться на любой доступной тестировщику ОС (XP, например). Дальше заказчик начинает принимать Систему (на 98-й, например) – и начинается… Неожиданные ошибки, перепроверка Приложения на всех требуемых ОС, исправление дефектов и т.д. Пожар на лицо :)
Допустим, оценка временных затрат проводилась компанией – разработчиком (а не заказчиком), в плане учтены все задачи ориентируясь на абстрактного среднестатистического тестировщика. Вроде, всё хорошо. Но и здесь могут возникнуть проблемы. Не все тестировщики одинаковые. У них может быть разная квалификация. Здесь можно рассмотреть несколько случаев:
– человек просто плохой работник: или он делает всё слишком медленно (гораздо медленнее, чем среднестатистический сотрудник отдела тестирования), или делает быстро, но так, что доверять результатам нельзя, или и то, и другое... Т.е. человек не на своём месте.
– новичок в профессии (в компании, на проекте) – понятно, что человеку нужно время на адаптацию, и его не сразу можно считать полноценным ресурсом.
– неправильных подбор персонала на проект или неправильное распределение задач внутри тестовой команды на проекте. Например, человек всё время занимался тестированием десктоповских приложений, и тут его назначают на тестирование приложений для мобильных технологий. Понятно, что нужно время на то, чтобы вникнуть в предметную область. Или другой пример: тестировщика, который всегда занимался мануальным тестированием, назначают на проект по автоматизации тестирования. Т.е. при назначении людей на проект и при распределении задач внутри команды тест-менеджер должен учитывать сильные и слабые стороны своих подчинённых. НО: нельзя всегда выдавать человеку однотипные задачи только потому, что он хорошо их выполняет. Рано или поздно тестировщику станет скучно :)
Как правило, задачи в планах плавно перетекают одна в другую, т.е. между ними нет перерывов. Но ведь часто возникают вынужденные простои. Например, увеличение сроков анализа, разработки и других предшествующих тестированию этапов ведёт к простою команды тестирования. Ещё одна причина простоя - блокирующая критическая ошибка, до исправления которой тестировать невозможно или нет смысла. Недоступность приложения также блокирует работу тестировщика. Причины недоступности приложения:
– недоступен сам сервер (сгорел, на нём проводят профилактические работы, например, увеличивают кол-во памяти);
– идёт установка новой версии приложения;
– на тестовой платформе разработчики проводят исследования и эксперименты;
– на тестовой платформе проводится нагрузочное тестирование;
– на тестовой платформе проводится приёмочное тестирование заказчиком.
Т.е. здесь возникает проблема взаимодействия команд тестирования, разработки, внедрения. Сюда же можно отнести проблему коммуникации между участниками проекта, которые находятся далеко друг от друга: в разных странах, а ещё хуже, в разных часовых поясах. Здесь увеличивается время на обсуждения и принятие решений. Также существует проблема «свободного» графика работы, который так популярен в IT сфере. Допустим, в команде есть носитель «тайных знаний», без которого «работа стоит». Если этот «тайный носитель» любит поспать, то плохо дело :) Нужно или передавать знания (а ещё лучше оформить их в виде документации), или договариваться о более строгом графике работы.
И в заключение причины «пожаров», которые предусмотреть сложно – это форс-мажорные обстоятельства. Например, авария на серверах, отсутствие электричества, отсутствие тестировщика на рабочем месте (заболел, уволился и т.п.).
Естественно, я не перечислила всех возможных причин отставаний от запланированных сроков. Главное, о чём я хотела рассказать: нельзя надеяться на то, что всё будет идти идеально. Хотя надеяться можно, но «соломку лучше подстелить», т.е. заложить в план риски. Нужно тщательно проанализировать тип проекта, его размеры и структуру, оценить команду и составить адекватный план, по которому будет комфортно работать. Не будет лишних переживаний ни у Вас, ни у заказчика :)
С Уважением,
Ольга Балашенко
Комментариев нет:
Отправить комментарий